Re: 6.1.1 system never ended based on this command ENDSBS SBS(*ALL) OPTION(*CNTRLD) DELAY(*NOLIMIT)

[CRPence <CRPbottle@xxxxxxxxx>]

  IIRC a repeated request for OPTION(*CNTRLD) would be disallowed with 
CPF1034 "All subsystems ending with *CNTRLD option.", irrespective of 
the value specified for DELAY(), such that there is no support to 
override the current DELAY value by issuing a modified request for a 
controlled-end.  However a new request to override the current wait is 
effectively available, by re-issuing the ENDSBS *ALL request but using 
the OPTION(*IMMED); i.e. informing the system that additional waiting 
for job terminations [beyond the QENDJOBLMT] is no longer desirable 
while ending the subsystems.

  Both what was the specific request and the specific message 
identifier and text, may be relevant to best infer what might have 
happened for any given request; possibly also details about the job 
being ended, perhaps from the history, dspjob, and joblog.  Given the 
request was to ENDJOB [generically; i.e. not specifically noting which 
parameter specifications], then there are at least three messages where 
the first level text suggests "already ending" may be an issue:
     CPF1360     &3/&2/&1 already ending because of ENDJOBABN.
     CPF1361     Job &3/&2/&1 already ending with *IMMED option.
     CPF1363     Job &3/&2/&1 is already ending *CNTRLD.

  If the message received was CPF1363, then potentially all that was 
required to cause the job to end was to specify OPTION(*IMMED) on either 
an ENDJOB or an ENDSBS request.

Regards, Chuck

On 27-Jan-2012 06:52 , Jack Kingsley wrote:
> Rob, didn't try the endjobabn route, when I would attempt to end the
> 1 job left it said something like in the process of ending already
> or something like that. What would have happened re-issuing the
> command as you have it.
>
> On Fri, Jan 27, 2012 at 9:38 AM,<rob@xxxxxxxxx>  wrote:
>
> > I'm surprised as much as that ended. The workaround is changing
> > the delay.   ENDSBS SBS(*ALL) OPTION(*CNTRLD) DELAY(120)
> > Some jobs won't die smack when the delay ends. They will take some
> > additional time. If that doesn't kill everything 12 minutes after
> > issuing it then you may have a job that requires ENDJOBABN. That's
> > a pmr situation.