Program termination

[razalas]

Anyone have any suggestions for trapping program termination due to session termination as in a Windows or Unix environment?

We are running RM/Cobol programs in Unix environment (SCO 5.0.6). The users are running these programs under telnet and are sometimes (often enough for us to want to do something about it) prematurely terminating their telnet sessions which causes the Cobol program(s) to terminate.

We would like to trap these terminations from within the program in order to record some key information in order to assist with the subsequent recovery effort. RM/Cobol has a logging feature which allows to us identify the user, date/time and program location of the termination, but of course cannot tell us anything about the internal state of the program (i.e. acct #, cust #, stock #, etc.) Oddly enough, the users are not always a reliable source for this information either.

Has anyone else had to deal with this situation or have any suggestions to offer?

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[Crox]

is it perhaps possible to make a log? For example open a file, (re)write a record with status information and close every 5 minutes? You will have enough information this way.

 

[TonHu]

Hm, any information entered into a screen, and not properly confirmed by hitting a Store, or Ok button is probably not validated and should be discardable. If the user can't remember what he entered, maybe because he typed it in during a phonecall with a customer, and he 'forgets' to record the information until after his coffeebreak (and connection-break?), they should change their habbits IMHO, "Store Before You Walk Out The Door!" (r)

HTH
TonHu

 

[razalas]

Tonhu,

I agree with you, the user's should change their habits. In a perfect world, having brought this issue to management, they would change the motivational scheme for these people to provide the proper incentives to ensure that they would change their behaviour. But until then I need to deal with this situation.


Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[razalas]

Crox,

that's an interesting concept!

I hadn't thought about keeping some kind of a log. I'll have to think about that. It may not be practical since this user group accesses these applications entirely through telnet and can abitrarily terminate their session at any time. Keeping logs would require additional overhead in all critical applications (eventually) to cover all the possibilities. Of course, we could start by concentrating on the parts of applications that are most commonly experiencing this problem. Still, it will be a "hard" sell to my management.

But I think it's worth thinking about.

Thanks!

Any other ideas are still welcome, of course.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[fredericofonseca]

All this depends on how your application is build, and on whether real time information is a MUST or not, e.g. if dealing with a stock order information do you need to keep track of all quantity that is BEING ordered, with still a possibility of NOT being confirmed, or you do not need that, and allow QOH to go negative.

Ways around this.

A - If real time is a MUST

1- All transaction files have a key field that uniquely identifies the user and transaction being performed.
A transaction log file is also updated with this value; so that the system knows which transactions are ongoing or stopped unexpectedly.

2- All files that are important are updated every time the user changes something.
e.g. if accepting an order, when a good is added to a order (e.g. last information related to that good is accepted), that line is written to the file, and stocks info files and so on updated.

3- At the end of the transaction e.g. when the user CONFIRMS the order the field mentioned on 1 gets cleared on all fields. It is also immediately before this particular step that PERMANENT invoice numbers and others like these should be retrieved, and used to update the other files. Note that this is at a stage where it does not matter if the connection gets lost as the system will be able to recover without any problem.

At the end of processing all files with such field the transaction log is updated to reflect the close state of the transaction.


B - If real time is not a major consideration.
Write everything to temporary files. When you load each program/screen load the information related to that item from the temporary files.

If the user hits enter or any other function key, write the active program/screen information to the temporary file.
If you have several screens in a transaction and you need to update files in-between, write a copy of the records affected to the same temporary file (or similar). When you go to the screen that needs information from that file, first check to see if the required record types are already on the temporary file and load them from there, otherwise go to the REAL files.

At the end of the transaction read from the temporary files and update the real files accordingly. At this stage you should revert back to the points mentioned on A.

If the connection is lost at this stage, when the user enters the system again you can set the program/screens to the state they were before (eventually with adjustments to stock levels or similar).



Note that it is also possible to use some aspects of B with A.

Hope this has been clear.


Offcourse that other methods may be used.


Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

Razalas,

You need to contact Liant Technical Support, more exactly, the Manager of Technical Support. (Modesty keeps me from identifying that handsome person. ) No promises, but perhaps if we know more about your application, we can provide something helpful.

Tom Morrison

http://www.liant.com

 

[razalas]

Tom,

I did contact the support group and did receive a prompt reply, for which I was grateful. Please refer to Case: 00023780 Termination detection.

Unfortunately, I think I may have misstated the problem as it was sent to the support group. Having cast it as an issue with trapping user input to the program (i.e. some kind of termination key), when in fact the problem is that user is "killing" their telnet session.

I have replied back support with this clarification. However, as I didn't hold much hope for there being any facilities in Cobol for dealing with this issue, I posted here in the hopes of getting some "outside the box" ideas for dealing with this issue.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[k5tm]

Razalas and I talked, and after I had some time to consider the possibilities, I suggested that he use a simple support module (a custom add-in). One of the features of an RM/COBOL support module is that it is notified when the run unit terminates. It is a straightforward matter, then, to have a couple entry points in the support module that (1) will be called soon after the run unit starts to identify a COBOL data to be dumped to a file upon abnormal termination and (2) notify the support module that the application is terminating normally (any other termination will be considered abnormal).

For the interest of RM/COBOL readers out there, this capability is documented in the CodeBridge manual, Appendices G and H.

Tom Morrison

http://www.liant.com

 

[rearl306]

I thought of another possibility. RM/COBOL allows you to enable automatic logging of opening and closing of datafiles, program termination, open and closing of program files, etc. If you enable this, the log files may grow in size quickly but you could have a script file that clears out the log files on a daily basis.

In your configuration file, add:
RUN-OPTION ENABLE-LOGGING=TERMINATION LOG-PATH=.
RUN-OPTION ENABLE-LOGGING=FILE-OPEN LOG-PATH=.
RUN-OPTION ENABLE-LOGGING=FILE-CLOSE LOG-PATH=.
RUN-OPTION ENABLE-LOGGING=OTHER-OPEN LOG-PATH=.
RUN-OPTION ENABLE-LOGGING=OTHER-CLOSE LOG-PATH=.

These lines will log program termination, datafile opens, datafiile closes, program opens, and program closes respectively. The log files will be placed into the same directory as where the application is installed. See Chapter 10 in the RM/COBOL User's Guide for additional info on these settings.

Based on the info in the log files, you should be able to figure out a lot more than just when the application was terminated.

 

[razalas]

rearl306,

thanks for the suggestion. I am familiar with the RM/Cobol logging facilities. Thanks for bringing it up since it could be useful for anyone running RM/Cobol.

We have used this to verify that the users were prematurely terminating their telnet sessions, because, naturally, they wouldn't readily admit to this. I probably should have explained this earlier.

The issue we had with the termination log is that it identifies the user, date & time of the termination, type of termination and location in the program where the termination occurred. Our problem was that we need internal info (cust #, acct #, stock #, etc.) from the running program to correct issues arising from the premature termination.

We plan to pursue the use of support module suggested by Tom Morrison in the previous post. We will post our results here once we have something we can share.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[mrregan]

We create a file for each user named '$LOGNAME'running when
they log in, and delete the file upon normal termination.

We check for the existence of the file when a user logs in. If the file exists, we inform the user that the program previously terminated incorrectly and they have to notify support to remove the file before they can proceed. This way we know which users are closing their windows instead of exiting their programs.