Adding new disk volumes

When we discuss new disk volumes, we intend this to cover any of the types of disk volumes that can be added to these systems. These include:

򐂰 Emulated I/O drives for P/390, R/390, S/390 Integrated Server, or MP3000.

򐂰 Channel-attached drives. For the MP3000, these could be through ESCON or parallel channels. For the P/390E-based machines, it could be through ESCON channels.

򐂰 Primary logical volumes in the MP3000.

򐂰 FLEX-ES emulated disks for Netfinity/EFS machines. (ESCON channel attachment for “real” drives is expected for Netfinity/EFS machines, but was not available at the time of writing.)

The drives could be 3380 or 3390 device types, but we will assume they are 3390s. Older drive types (such as 3350s) may be emulated, but are not supported by the current OS/390. The emulated I/O functions can support “odd size” drives, with an arbitrary number of cylinders.1 Small emulated drives may be appropriate in some cases (such as a 50-cylinder 3390 devoted to RACF or a JES2 checkpoint), but our discussions generally assume that standard size 3390 volumes will be used. This means 3390-1 (.9 GB), 3390-2 (1.8 GB), or 3390-3 (2.8 GB). 3390-9 volumes may also be used where they are supported.

You will probably need to add several disk volumes to your AD system. There are many reasons for doing this:

򐂰 You should use dedicated scratch volume(s). The distributed AD system uses OS39M1 for scratch space. This is not good because (a) there are too many important data sets on this volume, (b) there is only a limited amount of space remaining on the volume, and (c) performance should be better with several scratch volumes.

򐂰 You should define one or more volumes for your data sets: your source code, your data files, your libraries, and so forth. By default, the distributed system will place new data sets you create on OS39M1. This is not suitable for the reasons just mentioned.

򐂰 You will probably want to allocate a larger spool data set for JES2, since the space and associated control parameters on the distributed system is limited. Most OS/390 installations have dedicated volume(s) for JES2 spool. You might place a new (larger) JES2 checkpoint data set on the same volume and the backup checkpoint data set on a system volume, such as OS3RAA or Z1RES2.

򐂰 If you are working with substantial VSAM data sets, you will probably want dedicated volumes for these. Likewise, if you are using DB2 or another database, you will probably want dedicated volumes for this.

򐂰 If you are using UNIX System Services, you will certainly want additional hierarchical file systems. The space available for /u, in the OS/390 release 10 and z/OS 1.1 AD system, is extremely limited, and is intended only for defining mount points.

򐂰 You may want a volume for additional paging data sets. There is room for additional paging data sets on the OS39M1 volume, but this is a “busy” volume and performance considerations may dictate a separate volumes.

In the ideal situation, all the volumes mentioned here (plus others, such as dedicated volumes for RACF, for catalogs, for all paging data sets, and so forth) would be separate volumes on separate channels. This is the case in very large S/390 installations, but is not a practical goal for most AD users.2 We cannot recommend a particular goal because different

1 _{The maximum is the largest possible 3380 drive, or 3339 usable cylinders for a 3390 drive.}

2 _{It can be a reasonable goal, with slight performance advantages, using emulated I/O and odd-sized volumes. The general trend is away}

installations have very different usage patterns. A group working almost completely in UNIX System Services might need expanded HFS volumes and paging space, but have no use for OS/390 scratch volumes, spool space, or catalogs. Another installation working only with traditional MVS applications might never use additional HFS files, not need any more paging space, but heavily use spool and scratch volumes.

Making some arbitrary choices, a very small system might be expanded by adding three volumes (probably 3390-1s, but they could be larger if appropriate):

򐂰 LOCAL1 containing scratch space (50-75% of volume) and paging space (remainder).

򐂰 LOCAL2 containing scratch space (50% of volume) and spool space (remainder).

򐂰 LOCAL3 containing a user catalog, an HFS data set (for /u), and space for batch and TSO user data sets.

The volsers (LOCALx) are arbitrary names. A volume is made a scratch volume by specifying PUBLIC or STORAGE for the mount attribute; this is easiest done in the VATLSTxx member of PARMLIB. For more details:

򐂰 See “How to add additional emulated disk volumes” on page 127 for details of adding volumes.

򐂰 See “How to use OS/390 volume use attributes” on page 129 for setting mount attributes, such as PUBLIC or STORAGE.

򐂰 See “How to increase SPOOL space” on page 174 for changing the spool data set.

򐂰 See “How to provide more paging space” on page 187 for adding paging data sets.

򐂰 See “How to use a local RACF database” on page 158 for moving the RACF data base.

򐂰 See “How to add an HFS file system” on page 92 for adding a new /u file system. A slightly larger example, appropriate for smaller MP3000 installations, might be:

򐂰 WORK01 containing scratch space.

򐂰 WORK02 containing scratch space.

򐂰 SPOOL1 containing JES2 spool (and leaving the JES2 checkpoint on its original volume).

򐂰 HFS001 containing /u and other local file systems.

򐂰 VSAM01 containing additional paging space, a user catalog, user data sets, and perhaps the RACF data base.

򐂰 USER01 containing TSO and batch data sets.

This has the advantage that the two scratch volumes should contain only scratch data sets and can be completely cleared, when appropriate. Large data bases, whether DB2 or in some other format, would probably have their own volumes.

You will undoubtedly add volumes throughout your use of OS/390. However, you should establish your pattern of disk usage and expansions as soon as possible. Notice that both examples here mention a user catalog. Establishing a user catalog is important for many AD installations, and should be done before you add any local users to your system.

For several of the examples in this chapter we created a volume named LOCAL1 at address AAF. We did this on a P/390, using a 400 cylinder 3390. You could use an MP3000 logical volume, or any other method of obtaining a 3390 volume. We used address AAF because it was already in the AD system IODF as a 3390 (see“IODFs and addresses” on page 33) and we had not used the address for anything else.