Re: ENDSBS SBS(QINTER) OPTION(*IMMED) Takes 10 minutes?

Code was running in a batch job in SBS QBATCH. On week nights we would end multiple subsystems, hold JOBQ QBATCH, submit a batch job to QCTL to run backups. Backup jobs completes and get QBATCH and the sub systems running again.

On weekends we don't worry about backups and have time to spare.

We're at V7R1, cume as of Nov 2012.

The QINTER job log was 1 page. I did not see any other spool files--not sure where else I would look for a dump.

As for jobs running in QINTER, I have no easy way to figure out which were running when we ended QINTER. (and I'm not sure we even created job logs for them.)

The MCH2401 text was exactly as found in the QINTER job log, though it probably wrapped. It looked to me like some truncation happened.

I know we can program around this. (Unfortunately I have a habit of wanting to know "why?" things break.)

I do like your ALCOBJ approach. I could do one statement to ensure that all the SBS I was endind had ended...

Sam

On 4/29/2013 6:33 PM, CRPence wrote:

On 29 Apr 2013 13:58, Sam_L wrote:

In day end processing on Saturday and Sunday we issue
ENDSBS SBS(QINTER) OPTION(*IMMED).
Then we DLYJOB(120)
Then we do STRSBS SBSD(QINTER)
This Saturday evening it took QINTER 10 minutes to end, so the
subsequent STRSBS SBSD(QINTER) failed.

Not that it should matter, but presumably that was done in a program run from the console running in the controlling subsystem, or in a program run in a batch subsystem?

There are much better ways to handle the end without a coded wait. One simple means is to use ALCOBJ OBJ((QINTER *SBSD *EXCL)) WAIT(120) to code a wait with a maximum wait timeout equivalent to what would have been waited irrespective of the time taken for the subsystem to end. The coded wait could be for longer if desirable, polling could be started after the wait timeout, or ??? Alternatively, polling can be done on repeated requests to ENDSBS; waiting on the lock may be viewed by some as /cleaner/ or /easier/ but of course the allocate requires that the subsystem also must be deallocated after the lock is obtained, using the equivalent DLCOBJ request.

Examining recent QINTER job logs it normally ends in less than 12
seconds.

Given that the /normal/ case is one-tenth the time of the coded-wait gives good reason for eliminating the coded wait; i.e. why is there waiting, when there is no reason to wait?

The job log for Saturday has this escape message:
MCH2401 Escape 40 04/27/13 09:05:50.414607
#iiinsen 000D4C QWTMMDSC QSYS 1577 Thread . . . . : 00000920
Message . . . . : Tried to insert duplicate key argument in index
MISREM Disconnected jobs.

The LIC exception x1801 is issued by the Independent Index Insert Entry method to the "SYSTEM EVENT MONITOR FOR DISCONNECT" job feature. That error is the symptom msgMCH2401 F/#iiinsen x/000D4C T/QWTMMDSC x/1577 for which there are no apparent matches [using very generic web searches]. The actual /name/ of the object is not entirely clear without accurate spacing, but it appears to be the device name probably padded to 10 to fifteen bytes, followed by a string "Disconnected jobs"

FWiW, if there had been matching symptoms, knowing the release level is important; that was left unstated by the OP.

MISREM is a virtual display , type 3179.

By default the message MCH2401 ships with "Data to be dumped" DMPLST(*JOB), so if the error was unmonitored by the Work Monitor program, there would be a QPDSPJOB produced by the QINTER at the time of the failure. If the message was monitored, it may just be a message that is left in the joblog even though it was handled, perhaps as an indication of an unlikely but possibly noteworthy incident.... in the event that there was an apparent problem, which could include a performance concern for the ending of the subsystem.

But the job log contained nothing else, except CPF1124 (started) and
CPF1164 (ended.)

The error logged may be unrelated to the length of time. Seeing the status of the jobs and the subsystem monitor over the time of the long ending would likely be of more value.

Sysval QENDJOBLMT is set to 120 and is the only other thing I've
come up with that might impact ending the subsystem.
We were working overtime on Saturday, so there probably were 5250
sessions in QINTER on Saturday evening.

The End Subsystem (ENDSBS) was enhanced many releases ago to provide for better end-time performance, using the available special values on the End subsystem option (ENDSBSOPT) parameter; e.g. *NOJOBLOG and *CHGPTY.

Any idea why it took so long for QINTER to end?

The jobs in the subsystem took a long time to end and\or to produce their joblogs? I would review the history of /job ended/ since the start of the ENDSBS, until the last job ended, and then the subsystem ended. There may be one specific job that did not end until just before the subsystem ended... which would likely be a good place to dig.

I seem to recall an issue, perhaps by design but possibly also something modified, that if an interactive job has already been at the /job ending immediately/ screen, such a condition could delay the ending of the subsystem. I think there was a design change for which that screen would no longer be presented, or at least not left active more than a few moments.?

Hmm. I did a little research with a web search of "PERFM" "ENDSBS" and found the following link for what was noted just above; that delay was formerly 30 seconds, and is now reduced to appear only "briefly":
APAR SE44615
http://www.ibm.com/support/docview.wss?uid=nas2d73b1eb4b14e196a8625777e004997fc