Due to a new 4 layer structure in our Natural applications the number of program- and DB calls per online transaction increases dramatically, thus we have lots of NAT1009 (DB-calls) and NAT1029 (module calls). To avoid applications of crashing we have build in frequent calls to a module, that checks used and available number of calls - but this method is just doing bad things worse! And all applications have to do this call, and all applications have to keep track of how many DB- and module calls have beeing made at a given point. This is not a stable situation!
I therefore have made EP3617 “User exit just before NAT1009 or NAT1029” on this topic, to be discussed on the User Group conference in Lisboa June 20-24 2005. But I would like to take the “user temperature” first, to see how other customers are handling this problem.
In the Enhancement Proposal I suggest that Natural Nucleus keeps track on those counters (it does it already), and just BEFORE giving a NAT1009 or NAT1029 error, a new User Exit should be triggered. In this user exit we should be able to:
Show a window to the user, containing a text like “Working… Press Enter to continue or F3 to cancel operation”
Resume the running program at the point where the user exit was triggered, or…
Return a status to the running program, containing *CANCEL with the value FALSE or TRUE.
There is already the possibility for such an exit. Look at the RDC examples distributed with Natural’s installation. The RDC module(s) are called (before and after) the following conditions: database requests, screen I/Os, error conditions, also called when a module is loaded, a program is started, or terminated, or a call to a non-Natural component is requested. You can code whatever logic you like at those events.
So you mean, the running program cannot be resumed after the exit is invoked? Well, that is exactly the need in this request: Take control just before a 1009 or 1029 occurs, do a sreen IO and thereafter resume whatever was running.
Wolfgang. Just because it was intended as a data collector, does not mean that is its only use. I have used to secure (allow/deny) ADABAS access from one LPAR to another, to alter DB calls in flight, to remove MADIO/MAXCL counts during Entire Connection downloads, and trace our Natural/web sessions, and much more. It is assembler. It has access to the Natural control blocks, and the ADABAS buffers. A little
Oops, I hit send before I was finished…
Anyway, with a little imagination I could check the MADIO/MAXCL counts and limits in the BB , do an EXEC CICS SEND with the query to continue or stop, and check for a PF-key that indicates contine, at which point I would zero the counters or increase the limit in the BB and return.
With each Adabas IO check the MADIO counter and limit fields in the BB. If difference is equal to 1, and you are in an online session, pop up a message.
I dont like the use of RDC to solve application problems.
I think that Henrik has spottet an evolving problem, since it is becomming more common to use business objects/CALLNAT’s (without knowing what is done internally).
At the same time price/performance of Natural, Adabas and the underlaying hardware, is making it all-right to do thousands of program and database calls in a single on-line transaction, which had been impropper for say 10 years ago.
There is still an issue in stopping run-away tasks, but counting program and database calls, might be outdated.
A more usefull mechanism could be a timer, which would pause the transaction after a given elapsed time, and hand over control to an exit or ask the user if he wants to go on, or terminate.
Maybe it could work similar to the RETRY statement in ON-ERROR.
Wolfgang,
The RDC logic would just adjust the necessary counters/limits in the BB and return normally, letting Natural either detect an error at the existing limit (if they decided to stop), or continue because the limit was reset/extended. There is nothing special required, the application will continue where it left off when RDC simply returns.
Steen,
No doubt there is a conflict of goals here; preventing runaway tasks and letting an applicatoin do what it needs to do. This has always been true since the arrival of the MADIO and MAXCL parameters.
There is also a grey line here when we define the “problem”. If you want to classify it as an applications problem, that is fine. Personally I don’t think applications logic should have to deal with things that are not part of the business logic. IMHO counting database IO and subprogram calls is something your customers should not list as part of the application design. Programmers/developers should not concern themselvs with it either. They should make the application as efficient as possible, but should not have to spend time writing logic for jumping over system-level restirictions.
So, if indeed the limits are still required (I agree that perhaps they are outdated), then the proper place to code a solution is at the system level. Therefore, in my opinion, RDC seems the proper place. By coding it at the system level, if you later decide to change the requirements or remove the limits, only one module (RDC) needs changed; not every application program that did a CALLNAT to a common USRxxxx MADIO handler.
Be that as it may, I offered a viable solution that did not have to wait for a Change/Enhancement vote and then possible development/implemention delay. My suggestion is easy to implement, and involves exactly zero application code modifications. If Henrik does not like my suggestion, there is nothing forcing him to use it.
