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.

Introduction

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:

• A critical system DASD unit crashes.
• A security administrator changes a rule that prevents anyone from doing anything.
• 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:

1. 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.
2. 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.
3. 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.
4. IPL your One Pack System, find the problem, and fix it. I like this last option.

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 databases.
• 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 them.
  • 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:

1. 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). http://home.flash.net/~mzelden/mvsutil.html
2. 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:

1. 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.
2. 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.
3. 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 months.
4. 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.

Conclusion

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 one. Soon.

David Stephens