It's not strictly related to the OP question, but it is very important
issue when talking about IPL problems. We pay much attention to avoid
duplicate&online volsers.
BTW: in our case duplicates come from clones performed using PiT copy,
it's not matter of naming convention.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2012-04-29 03:15, Skip Robinson pisze:
As Radoslaw says, IPL failures in production are so rare and so varied
that categorizing them is a an exercise in thrashing. Except for one
cause: duplicate volume serial numbers. The fact that duplicates are the
result of user error does not lessen the blow. In the case of only a
handful of duplicates, the operator can reply a few times and move on. But
we've had cases of dozens or scores of duplicates. NIP provides no
mechanism for handling a flood of duplicates even though the cause may be
obvious, such as volumes copied from one subsystem to another without the
original volumes having yet been CLIPped to unique spares. Or an IODF has
mistakenly connected an LPAR to a DASD subsystem it should not have access
to. Whatever the cause, restarting the IPL is useless as the same
duplicates will be prompted for again and again until they are eliminated.
Take this simple case, Duplicate pairs:
4001 - 8001
4002 - 8002
4003 - 8003
...
The pattern is transparent. The only real question is whether 4xxx is
'current' or 8xxx is. There is currently no way tell NIP that, say, 8xxx
is the range we want to keep online, while the corresponding 4xxx units
should remain offline.
Side irritant: why on earth do we have to tell NIP which volume we do
*not* want online? How would that game plan play on a network quiz show?
Back to the point. Although this stuation does not happen often, it can
take ages to unravel. And best of luck if there's no running system
available to undo the duplicates.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
From: "R.S."<[email protected]>
To: [email protected]
Date: 04/28/2012 12:47 AM
Subject: Re: Early IPL problems
Sent by: IBM Mainframe Discussion List<[email protected]>
W dniu 2012-04-27 23:03, John McDowell pisze:
I'm trying to get a feel for problems that occur in the early stages of
z/OS system start up (e.g. IPL/NIP). Generally problems in these stages
result in a non-restartable wait state, for example wait state x'0B1'
(e.g. LOADxx or IODF problem).
Questions:
1. FREQUENCY: How often do they occur ?
2. DURATION: How long does it take to resolve them (e.g. minutes,
hours, etc.) ?
3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ?
4. CAUSE: What are the underlying sources (e.g. hardware, software,
etc.) ?
5. RECOVERY: How do you recover from them ?
1. Rarely. IPL is performed rarely. In my case I haven't noticed such
problem *on production systems* for years. Such problems do happen
during tests, like new system, PTFs applied (and IPLTEXT not refreshed),
new CPC, new LPAR, DR test, etc.
BTW: I *hate* looking at last 3 digits, then previous digits... ;-)
Since the numbers are available on HMC, it would be nice to have button
Explain which could (under the covers) open the book and perform the
analysis for me.
2. The time depends on two-three elements:
a) time to open the book. It can be few seconds when I'm on my PC (HMC
accessed remotely), it can be minutes when I do it on real HMC and I
have to use another PC for documentation access.
b) time to write down the digits, extract wait state code and reason code.
c) (optional) sometimes I need to check whether description is accurate
or maybe fix something (like LOAD member). I usually logon to TSO on
another system and view/modify the things. It could take 5 min.
3. Lost time, some stress. From business point of view it doesn't affect
my SLA.
4. IODF in multiple extents, OS config with bad offline/online device
set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx,
not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC.
5. See 2.
Regards
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 22 829 00 00, fax +48
22 829 00 33, www.brebank.pl, e-mail: [email protected]
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
