The orderly shutdown of z/OS address spaces requires not just telling
each address space it needs to terminate, but to shut down address
spaces in an order that is heavily installation-dependent. In general a
server address space (like HSM, DB2, Tape Management, Job management,
TCP/IP, Vtape, etc.) has no way of knowing what other address spaces may
generate future requests, and some of those future requests may be
required for the other address space to terminate "normally". In our
installation an approximate order (ignoring UNIX stuff) was:
(1)shut down batch jobs first (because they could be using job
automation, tape management, DB2, CICS, TCP/IP, HSM). Allow some
opportunity for "short" jobs to quiesce at job boundaries to simplify
job-stream restart, else force termination.
(2)shut down CICS regions (CICS regions use DB2, VTAM, TCP/IP and may
try to submit jobs).
(3)shut down general TSO use (source of batch jobs, HSM requests, DB2
requests, VTAM/TCP/IP)
(3)Initiate DB2 shutdown (could be using Tape Management system and
Vtape, VTAM, TCP/IP)
(4) Shut down various remaining server address spaces (Vtape, HSM, Tape
Management, Job Scheduler & Restart systems, etc).
(5) Shut down VTAM, TCP/IP
(6) Shut down JES2
This is an over simplification because there are TEST CICS regions
dependent on a TEST DB2 environment and PROD CICS regions dependent on a
PROD DB2 requirement, as well as a interdependency ordering of the CICS
reqions themselves. There are also some other dependency ordering among
server address spaces not explicitly mentioned, but you get the idea.
If you just tell all address spaces to start termination in parallel
without regard to proper sequencing, many will not go down normally or
possibly even hang, and you may even end up with more confusion than if
you just "pulled the plug" by deactivating the entire LPAR abruptly
(from which things like CICS and DB2 are designed to recover) with no
attempt at orderly termination.
The only way to get a "normal" shut down is for each installation to
determine the order of address space shut down that makes sense in their
environment; and to minimize the time involved to shut down, use some
automation tools to implement that shut down ordering.
J. C. Ewing
07/22/2012 05:45 PM, Scott Ford wrote:
Gil,
I am with you and zMan what's so difficult about an orderly shutdown on OMVS
and z/os address spaces..z/Pdt has vtamappl, everything shutdown fine...
Scott ford
www.identityforge.com
On Jul 22, 2012, at 6:37 PM, Paul Gilmartin <[email protected]> wrote:
On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote:
Some years ago, I suggested in MVS-OE that MVS shutdown should
send SIGTERM to all dubbed processes so that processes coded to
UNIX conventions could perform orderly shutdown. The suggestion
was not well received.
Can you elaborate? Why would orderly shutdown not be A Good Thing?
"They" didn't say. Too UNIXy for them. But I'll conjecture: Many address
spaces get dubbed nowadays by incidental use of UNIX services such as
TCP/IP. The default action for SIGTERM if a process doesn't handle it
is that the process is terminated. This would be unwelcomed by a process
that was waiting rather for a legacy MODIFY command to shut itself down.
-- gil
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
