Re: Guaranteeing an end to QINTER

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