Re: Abnormally dropped sessions & running programs

Mr. K.V.B.L. wrote:
I have a Java programming running that does an INSERT once every second into a temporary table. If I close the CA window either
by clicking on the close window button or killing it through Task
Manager (End Task) everything cleans up on the 400. If I do an
'End Process', the window is closed but all of the jobs
associated with that device are left and the INSERTs continue.
Is there anything that can be done for this abnormal close?

Does "CA window" mean a 5250 emulation connected? For example a TCP/IP [TELNET] connection to the server via a virtual workstation device, at which an interactive signon was then established; i.e. an interactive job for a user? If so, an appropriate method to terminate the interactive process is via SIGNOFF or ENDJOB at the server, rather than trying to some end attempt from the client. When input inhibited, that former can be accomplished by use of SysRqs-90 [i.e. option 90 from the SysReq menu or data entry line].

If yes, then FWiW: If an application attempts to access the workstation device for a supported function which is not /recoverable/ when there is a device error, then the detection of the disconnected [in error] device will be manifest as an I/O error reported to the application which attempted to access that device. That application should then treat that device error as a terminating condition. For example if after each X inserts the application were coded to request input from the user at the device, perhaps whether it should continue, the application would be unable to request that inquiry from the device since the device had been placed in error [as the side effect of the terminated process which is the communication that established the connection]. It could be possible that writing also to STDOUT [not having been overridden to a device other than the workstation] versus just the INSERT activity into the table, could be a method which would recognize that the device is no longer active\function; i.e. writing to the standard output would effect an error in the application from which the application could conclude that termination would be an appropriate response.

There may not be any reasonable or explicitly supported method to communicate directly with the device, such that the most appropriate resolution would be by running the application in a batch job instead of in an interactive job, such that no dependency exists between the application and a device. Then of course a properly designed method to end the application would seem more intuitive to have included in its design.

Regards, Chuck
.

Loading