Re: Guaranteeing an end to QINTER

[CRPence <CRPbottle@xxxxxxxxx>]

On 3/9/11 6:55 AM, Burns, Bryan wrote:
> Just want to confirm that, even if you specify ENDSBS SBS(QINTER) as
> *IMMED, that's no guarantee that QINTER will end.  Because part of
> the ENDSBS is an ENDJOB, which sometimes hangs?

  Correct.  However, that a job does not end should be rare, and very 
possibly would be a defect.  If the first action had been ENDJOB, and if 
that action had no effect, then best to refrain from issuing ENDSBS 
unless establishing an alternate subsystem or PwrDwn\IPL is going to be 
acceptable as circumvention\recovery.  That is to say, if a job running 
in a SBS does not end, it is very unlikely that ENDSBS will change that 
condition, such that the subsystem will go into END status having ended 
[probably] every other job while preventing any new jobs from entering 
that subsystem [due to status of ending].

> For example, perhaps the following could occur:
>
> - 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.

> - Observed only one job in QINTER (Job SN77, still in ENDING
> STATUS).
> - Drove into work and called IBM at 6 AM.
> - While waiting for IBM to call back, observed that SN77 workstation
> (a thin client running TermPro emulation) had a bar code scanner on
> the keyboard and the display showed JOB ENDING and was input
> inhibited.
> - Closed the session.
> - Varied off device and started QINTER at 6:20 AM.

  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.

> 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.

  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]?

Regards, Chuck