- Received call at my home at 4:50 AM.
- Using a console session from home, I observed that QINTER was still
in ENDING status although job started at 12:03 AM.
The ENDSBS was initiated at 12:03 AM? Sorry... just that "job
started" seems to be lacking any relevant context.
-----------My point was, being that it was 4:50 AM, the ENDSBS had been
running for more than four hours which I in fact do deem relevant
because it implies that it will probably never end without some
intervention. If I had written that, at 12:04, the ENDSBS was still in
END status, this would be a different issue.
IMO that the job did not end from a prior ENDSBS OPTION(*IMMED) would
be a likely defect since the job termination was apparently so easily
effected by the device error which would have originated when the client
session was closed; the joblog likely records such a device error, and
the spooled joblog created moments later upon job ending. At least it
seems the closed session led to the job ending since in my experience
the VRYCFG *OFF of the device should not have been possible until the
job had ended and of course STRSBS would not have been possible until
both the job and then the subsystem had ended. After such a long wait,
seems unlikely to have ended coincidentally near the time of the
canceled client emulation session.
----------I do believe it's a defect - in the TermPro emulator software
running on the thin client. -------------------------------
And the only way to prevent this from occurring again is to ensure
users never put a bar code scanner on a keyboard when they don't sign
off??
That as a requirement would be daft. An ENDJOB would be the effect
of ENDSBS, and the scanner job should end just as one would expect of
an[y other] interactive job. Surely suggesting that as a requirement
would be an untenable position for IBM to hold, except perhaps if the
emulator had a defect. All the more reason to expect the described
outcome would be considered a defect; even if unreproducible.
Unfortunately since the condition was not debugged, a recreate could be
required to further investigate if sufficient details about the problem
were not being logged [e.g. a device "flight recorder?], or necessary
trace\debug were not initiated and output collected for review, in
response to an "apparent hang" condition.
-----------There was no "scanner job". A scanner was on a keyboard
(must probably pressing down on keys) while the system was trying to do
an ENDJOB on a session allocated to the device the keyboard was attached
to. ---------------------------------------
So what was the outcome from the call-back? Any recommended PTFs,
requests for documentation of the failure, or a request to verify a
recreate is possible [optionally with a request to first activate some
trace\debug]?
---------------The call was for "QINTER WILL NOT END" not for
guaranteeing it will end.
I was able to end QINTER, (and therefore start it) myself by TAKING THE
SCANNER OFF THE KEYBOARD, closing the session on the device with an ALT
F4, and varying off the device (if that was necessary, as you posit,
perhaps it wasn't) before I got a call back.
The engineer indicated that the system was working as designed. That
the scanner pressing down on the keyboard was telling the OS "I'm doing
something".
In the heat of the battle, I recalled seeing a *CNTRLD for either the
interactive session or the ENDSBS so; when I did get a call back, the
engineer and thought that the ENDSBS should be changed to *IMMED to
prevent father occurrence of such an "apparent hang condition".
But, when I went to change it, I found it already was *IMMED.
Chuck, is there any scenario where an ENDJOB that is part of an ENDSBS
*IMMED, would be an ENDJOB *CNTRLD?------------------------------
Regards, Chuck
--------------Thanks for the reply Chuck. You're one of my very favorite
contributors to this list. Your writing is so exact. Were you a lawyer
in a past life? Or perhaps you wrote a lot of the IBM reference guides?
Bryan Burns------------------
midrange.com
