RE: Subsystem monitor job

["York, Albert" <albert.york@xxxxxxxxxxxxxx>]

I think you need to consider the real issue here. You batch jobs should
always be prepared to be shut down *IMMED.

This is where commitment control is so valuable. If your job ends before the
commit is issued, the transaction is never written to disk.

If you aren't using commitment control then you should make sure that all
data is written to disk at the end of the transaction by using the FEOD op
code. Data areas should also be updated at the end of the transaction, not
when the job ends. If the job ends in the middle of a transaction then your
job should be prepared to recover the next time it is started.

Think about the impact if you manage to come up with a way to circumvent the
intent of ENDSBS *IMMED. If one of your batch jobs gets in a loop it will
never reach a point where it can shut down gracefully, so the subsystem will
never end.

What you are trying to do is change the ENDSBS *IMMED to be ENDSBS *CNTRLD,
so why don't you educate the users to do that? Or at least find out why they
feel they need to use *IMMED.

Albert York

        -----Original Message-----
        From:   Tom Daly [SMTP:Tdaly@sddsystems.com]
        Sent:   Friday, January 11, 2002 6:36 AM
        To:     'rpg400-l@midrange.com'
        Subject:        RE: Subsystem monitor job


        This is just the problem, *IMMED really is pretty immediate.  If
there's a
        bunch of jobs running some jobs don't wake up quickly enough to
finish
        properly before the SBS ends.  I thought about creating my own
ENDSBS
        command....  It'd be fine on _my_ machine but not on customers'.

        One of the manuals has an example program of creating your own
'batch
        machine'.  Looks simple enough, just need to know what queue to
listen on.
        It looks like the sbs monitor jobs run pgm QWTMCMNL... I tried
poking around
        to see if I could figure this thing out but no luck.

        Tom