Amen to that.
However I understood Steve's word as a sarcasm. Maybe I was wrong.
Obviously I don't like CANCEL, FORCE ARM and FORCE in normal procedures.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 25.08.2020 o 04:10, Joel C. Ewing pisze:
It's part of that generic MVS principle from at least the 1970's, if not
earlier, that things that can be shut down cleanly before an IPL should
be, to minimize partially completed transactions, partial updates to a
collection of related data sets, database updates that haven't yet
reached a commit point, records written to output data sets but not yet
flushed from buffers to DASD, subsystems left in a state which makes
restart more difficult, etc, etc.
When you have no idea what some system address space is doing under the
covers, you have no way to know whether it has potential to be a problem
or not, unless lack of exposure is explicitly stated somewhere, or it is
just impossible to terminate. And obviously you don't want system
address spaces that you can't easily terminate if they could in turn
prevent the normal shutdown of JES or some other system address space
that benefits from a controlled shutdown.
Yes, a forced IPL or "pulling the plug" with things still running
certainly resets all running address spaces, but the potential for
increased DB2 recovery time and potential need to recover damaged or
inconsistent tables and data sets, and the possibility of JES job output
on DASD not even accurately reflecting what batch job step was running
at the point of interruption when restarting rudely interrupted jobs
makes that a less-than-optimum approach that can potentially delay by
many minutes the availability of a system for production usage after an
IPL. At a minimum you want to be able to quiesce any address spaces
that are processing end-user transactions or jobs, or processing service
requests in support of that workload (and the number of z/OS address
spaces in that latter category seems to be continually growing).
Every SysProg I've known always believed you minimized your pain by
always doing a controlled shutdown of as much as possible before
"pulling the plug", but I suspect most have also encountered occasional
cases where some software, hardware, or environmental issue didn't offer
much of a choice.
Joel C Ewing
On 8/24/20 11:05 AM, Steve Smith wrote:
I'm not clear on why you all would care about shutting them down for an
IPL. IPL is 100% effective in removing unwanted processes.
sas
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2020 r. wynosi 169.401.468 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.401.468 as at 1 January 2020.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
