W dniu 07.03.2025 o 18:49, Jeremy Nicoll pisze:
On Fri, 7 Mar 2025, at 16:57, Radoslaw Skorupka wrote:
So, what's the problem with keeping some tech LPAR up and running?
It does consume very few CPU cycles, few memory, same disk space.
If this "tech LPAR" is specifcially limited to emergency use that might be
ok, but where I worked the sysprog LPARs had no access to any of the
disks used by live systems - so I can't see how one could use such an
LPAR to fix anything.
It is up to you how the tech LPAR is set up. Including I/O definition.
However you can have "emergency" IODF or OS config just for emergency
purpose. Note: the disk can be online, unavailable *or offline*. Note2:
in fact we're talking about IPL problems, so one does not need access to
production data, just system disks (PARMLIB, VTAMLST, IODF, etc.).
W dniu 07.03.2025 o 19:00, Mike Schwab pisze:
RACF? Just the Emergency IDs to restore from (V)Tape.
Users won't have any datasets, may need a different production RACF
database.
What's wrong with RACF db on tech LPAR? Is it procedural impediment?
Except that there is no problem here.
Last, but not least: none of mentioned issues has relationship to online
LPAR with tech system. Same problems can occur for "one-pack: or any
other offline system. More, it is *much* easier to detect in case of
online system. To detect *before* the system is needed as a recovery tool.
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
