technical: Why You Need a One-Pack System
A One Pack System can save your z/OS system when a disaster strikes. This
article explains what a One Pack System is, and why you need one.
Every time I start as a z/OS Systems Programmer at a new site, one of the first
things I do is to create a 'One Pack System.' I'm always amazed when I find
sites that don't have one ready to go.
What is a One Pack System?
A One Pack System is exactly that - a 'mini' z/OS system that takes up just one
pack or DASD unit. Everything needed to IPL (Initial Program Load, or boot) a
z/OS system to the point where you can logon to TSO is on this one volume: JES
spool, security database - everything. But why do you need one? So you can IPL
z/OS when everything else is crashing around your ears.
Why Do You Need One?
One of the basic truths with z/OS is that if you have no z/OS system - there's
nothing you can do. You can't edit datasets, submit jobs, or view system logs.
There's nothing you can do. OK, all operating systems are the same, but with Windows,
you just take that failing disk to another Windows system, and you can get at
your data. But if you have a site with no z/OS system available, then you're stuck.
And as a Systems Programmer, this is my worst nightmare - where none of my z/OS
systems will IPL to a point where I can logon to TSO and fix things.
This could happen for all sorts of reasons - for example:
In fact the list is endless.
- A critical system DASD unit crashes.
- A security administrator changes a rule that prevents anyone from doing
- A junior Systems Programmer deletes a critical user catalog.
- A parmlib update was incorrect, and the system won't IPL.
- A network change stops anyone from accessing z/OS.
- You're restoring your entire system at a disaster recovery site.
So if your z/OS system won't IPL - you've got a couple of choices:
- Backout any change - by IPLing from a different pack. But this will only
work in some situations. If for example your security database dies, this
won't help you.
- Use another z/OS system in the same Parallel Sysplex. You can use this system
to edit datasets, submit jobs, and generally fix your problems. However if
you don't have another z/OS up and running in the same Parallel Sysplex, then
this won't work.
- Use Standalone DFSMSdss (or similar software) to restore your packs from
a backup. If you've ever gone through the process of a standalone restore
you'll know it takes a lot of time. And you still have to find:
- The disk that's causing the problem.
- The unit to restore to.
- How to IPL the Standalone restore program.
- A backup for that pack.
- IPL your One Pack System, find the problem, and fix it. I like this last
But a One Pack System isn't just for disasters. It can be very handy for systems
management tasks like:
- Moving system packs from one disk unit to another.
- Catalog maintenance, like splitting a catalog into two.
If I haven't' convinced you yet, creating a One Pack System has to be one
of the best training exercises for any Systems Programmer. You get a first hand
understanding of what a z/OS system needs to run, and you'll get a lot of experience
IPLing and fixing IPL problems.
What Does it Contain?
This is a difficult question - what to include in the One Pack System. You don't
have a lot of room on one DASD unit, so you need to minimise what goes on as much
as possible. But think about what you'll be doing. You need to:
- Startup z/OS. So you'll need system datasets, a catalog, JES spool, security
- Access the system. Today this means TN3270 access. So you'll need OMVS,
TCPIP and TN3270 up and running.
- Logon to the system. You need a logonid that can do anything. This sounds
simple, but is very important. Your One Pack System is no good if the only
logonid has an expired or forgotten password. I always have three logons that
can do absolutely anything. I also like to have a Started Task that runs every
time my One Pack System is IPLed. This Started Task:
- Resumes these three RACF logons - in case they've been suspended
- Resets the password of these logons - in case someone's gone and changed
- WTOs the logons and passwords to the z/OS console - in case people
have forgotten the logons or passwords.
- Access production DASD. You'll need:
- ISPF and DFSMS.
- All production DASD mounted.
- All production catalogs connected as user catalogs to your One Pack
master catalog - complete with aliases.
- Restore packs, datasets, catalogs and databases. So you need:
- DFSMSdss or other product that backs up and restores data. This may
possibly include DFSMShsm or something similar.
- Sample restore/recover jobs ready to go. You don't want to start coding
JCL during a disaster.
- The ability to mount HFS datasets and edit them.
- Access to your tape management software catalog (so you can find the
backup tapes you need) and tape drives.
- Define hardware. So you need HCD and access to your SYSx.IODFxx datasets.
- Other disaster related tasks. I like to have a PDS with a tested job ready
to go for every conceivable disaster I can think of. For example:
- Catalog restore and forward recover.
- Security database restore.
- Create JES SPOOL, Page and SMF datasets.
- Create Coupling Facility structures.
Creating Your One Pack System
So how do you create a One Pack System? That's something that is too detailed
for this article; however here are two places that can help:
- Mark Zelden's Website.
Mark Zelden is well known in the z/OS Systems Programming community. He's
created JCL to create a One Pack System, and also a Two Pack System (with
more features that won't fit on one pack).
- Feb 2000 issue
of Xephon z/OS. Xephon Updates are no longer being written, however you
can find past issues at http://www.cbttape.org/xephon/xephonm/
But once created, there are four things you MUST do:
- Test your One Pack System. After creating your system, IPL it and perform
the z/OS D U,,ALLOC,xxxx,5 command - where xxxx is the lowest DASD unit address
in your site. This will show you all the allocations. You should see no allocations
except for the unit holding your One Pack System. You don't want to find out
in a disaster that your One Pack System is really a Five Pack System.
- Document Your One Pack System. It's not much use if no-one knows how to
IPL it. I like have complete documentation in the machine room that states:
- IPL address and parms
- How to logon to the system
- The name of that PDS with all the sample disaster recovery JCL.
- Retest your One Pack System. Systems are always changing. So you must retest
your One Pack System regularly - I like to do it at least every couple of
- Rebuild your One Pack System. I like to completely rebuild my One Pack
System every year. This way it includes software upgrades and maintenance,
as well as other important things that may have changed.
So there you have it. Everything you need to know to go and create a One Pack
System. If you don't have one, you might want to start thinking about getting