Re: Abnormally dropped sessions & running programs

On Jun 19, 1:24 pm, Kelly Beard <kenverybigl...@xxxxxxxxx> wrote:
On Jun 19, 1:14 pm, Kelly Beard <kenverybigl...@xxxxxxxxx> wrote:



On Jun 19, 8:31 am, CRPence <CRPe...@xxxxxxxxxxxx> wrote:

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

Perhaps further explanation is needed.  My purpose here is to simulate
a 'crash' of some kind on an interactive (Windows) station with an
open ODBC/JDBC connection.  I wasn't involved with this problem
previously but am being asked to investigate a solution now but
apparently there have been problems with ODBC connections being left
'hanging' on the system when power is lost to a PC or Client Access
has bombed for some reason, etc.  For ODBC a job called QZDASOINIT is
created.  For a JDBC connection, I'm not sure yet what system
resources are being used.  My purpose is to find out if any jobs are
created under a default system user, etc, if a JDBC connection is
created and what the options/techniques there are for clean-up or
prevention of the problem.  File-locking is a secondary problem I am
investigating.

I understand the 'design your application better' argument.  When it
comes to my own stuff that surely is my intent since I don't want any
late-night calls, but when you're using stuff for the first time you
aren't always aware of what the potential problem areas are, etc.

This java program is trivial and does not represent one of our typical
applications.  It is simply an automated task that creates a temporary
table, inserts 1000 records at the rate of 1 record per second and
prints on stdout that it has done so.  For the java program it doesn't
seem that System.out.println() is throwing any exceptions when the
network connection is abended because the program continues to run
until the 1000th record is inserted (or until I log back in and kill
the job myself).

Ok, job QSQSRVR, user QUSER has a lock on the file that is being
INSERTed.  One thing learned...

Abnormally ending the Client Access session does not immediately
result in a job log being produced.

I'm getting a little more information. What happens in this
scenario... a user using a Windows PC is using an application that has
a JDBC connection to the 400. That PC is knocked out by a storm or
the user pulls the plug, etc. It seems the problem is that JDBC or
ODBC connection is still "alive" on the 400 with all of the locks on
whatever files were in use at the time. What are the techniques to
deal with or preferably prevent this kind of problem from occurring?
.