A way to report screw-ups
June 26, 2008
When a session program aborts on the HP 3000, the users don't tell us. Is there a mechanism to report user screw ups?
Matt Perdue of the OpenMPE board and Hill Country Technologies replies:
At one of my clients' sites, all online programs (defined as used by anyone acting interactively with the application) have been coded to go to a common abort procedure when IMAGE, VPlus or other file errors cause the program to want to abort, at least somewhat gracefully. That section closes the terminal, calls DBEXPLAIN or prints some kind of status message and sends this information and what section caused the abort to the console. Each section of code starts with a line such as MOVE “6004-DELETE” TO ABORT-SECTION.
Of course there is the random, unprogrammed-for abort. Not much can be done about that, except write a transaction log record to a file or dataset so you can track the exact progress and last point a user was in before the abort.
I also have a mechanism to control users logging off gracefully for backups. All just part of learning and developing ways to manage remote users since 1985! And it makes my life easier in the process.
Each screen times out at five minutes, taking the user back to the previous screen or menu. When the main menu is reached, the program checks the setting of a log off control record and if set to “Y” the program will log off, very gracefully. I have another program that runs 20 minutes prior to the backups, setting the control to “Y”.
With users scattered at dozens of locations in different cities this is the only way to painfully insure everybody is logged off for the backups. It’s automatic. Another program runs in a series of jobs after the backup that sets the control to “N” so the users can log on and stay logged on.
One application has users performing critical update tasks at various times, though not an IMAGE “critical update” for search key items. These critical updates involve changes to multiple datasets and if I need to force a user to be logged off I don’t want to do that in the middle of a critical update the user may be performing. DBBEGIN and DBEND don’t help any in this case as an ABORTJOB #Snnn will complete an individual database call, but not take into account the DBEND hasn’t been reached.
The solution is to have the program at the start of a critical update write a record to a dataset indicating the user info (LDEV, date, time, program section, “critical update”) and to clear this record when the update is completed. A management screen is programmed to check this dataset and display the status of each user by LDEV and I can instantly see who is in critical update and who is not.
I also use this function to have at the start of each screen a user goes into write a dataset record indicating what screen they are in (LDEV, date, time, screen name, other related data). My monitor screen tells me what screen each user is in at any time and if they’re in a critical update. This works great at one site to see if anyone still logged on after 5 PM is really doing any work — if not, I set the log off flag to “Y” so they get logged off after 5-10 minutes. The log off flag is set to “Y” or “N” by the push of a function key in the management screen — easy!