z/OS (OS/390) Disk Data Sets At CNS

To determine whether disk or tape is cheaper, you must compare the cost of storing your data on disk for the length of time your system or project will exist with the cost of having a tape mounted the number of times you will have to access your data.

The formula below may be used to give you a good estimate of the relative costs:

(DxS)/U is less than 12

where D is the number of days the system (or project) will exist, S is the size of the data (in megabytes), and U is the number of times the data will be accessed. If the result of the calculation is "true", that is, if D x S / U is less than 12, disk storage is less expensive. If the result of the calculation is "false", tape storage is less expensive.

For example, suppose a 3-month project accesses the data twice a day and the size of the data is 5 megabytes. Thus, D = 90, S = 5, U = 180, and D x S / U = 2.5, which is less than 12. Disk will be cheaper to use for this project.

As a second example, consider an ongoing project for which the number of days is indefinite. The formula can still be used by setting D to 1 and U to the number of times the data will be used per day. If the data will be accessed once per week, then U = 1/7. For a 3-megabyte data set to be accessed weekly, the formula yields 21, which is greater than 12. In this case, tape storage would be cheaper.

The value of 12 holds if all runs are made at normal priority and assumes that disk storage is on one of the public (USER9x) packs. If disk storage is to be on one of the bulk (BLK9xx) packs, use 56 instead of 12 in all calculations. To account for priority adjustments, multiply 12 (or 56) by the appropriate priority factor: 3 for urgent priority, 0.5 for low priority, and 0.25 for standby priority. Thus, for a data set on a public pack that will be accessed using only low priority, you should use 12(0.5) = 6.

The value of 12 (or 56) also assumes that a tape is available at no charge for use during the life of a project. This is often not the case, and you might need to purchase a new tape. To incorporate this one-time cost, rewrite the formula as follows:

(DxS)/(U + 2C) is less than 12 (or 56)

where C is the cost of the tape, in dollars. As the length of the project increases, the cost of the tape will become an insignificant part of the cost of storage. For a 3 megabyte data set that will exist for 2 years and be accessed weekly, the formula calculation is as follows:

730x3 / (104 + 15) = 18.40

assuming use of a tape which costs $7.50. Since 18.40 is greater than 12, tape storage would be cheaper in this case. In addition, when the project ends, the tape may still have residual value.

The first option is to use your userid as the second qualifier in the data set name. Your userid implicitly specifies both an access number and a sequence number. The following examples show qualified names for the userid "STARTRK".

STARTRK.other.simple.names 
UF.STARTRK.other.simple.names 

The second option is to explicitly code your 8-digit access number as the second qualifier in the data set name. Since the first character cannot be numeric, you must change the first digit of the access number to the corresponding letter of the alphabet, that is, you must change

and so on. An explicit access number implies sequence number 1. You need do nothing further if sequence number 1 is intended. If your data set charges should be billed to a sequence number other than 1, include that sequence number, prefaced by the letter S, as the third qualifier in the data set name.

For example, a data set named UF.STARTRK.DATA would be charged to the access number and sequence number associated with userid STARTRK. A data set named UF.A0069401.PROGLIB would be charged to access number 10069401, sequence number 1. A data set named U.G0057314.S3.PLOT would be charged to access number 70057314, sequence number 3.

If you contract to use the bulk-rate volumes, you provide a list of data set name qualifiers which you intend to use and a single userid or access/sequence number to which the data sets will be charged. No other data sets are allowed on the bulk-rate volumes. Specifically, the naming conventions for data sets given above for the public volumes do not apply to the bulk-rate volumes.

You use the BLKSIZE keyword parameter on the DD statement to specify how large a block you wish to create. Some guidelines are needed for choosing a block size. The basic consideration is making efficient use of the track capacity of the disk. For example, if you block 80-byte card images at 27920 on a 3390 disk, you will get 2 blocks per track with an efficiency of around 99%. If you add one more card image to the block (increasing the block size to 28000), you will get only one block per track and less than 50% efficiency.

While track capacity needs to be considered, you should avoid block sizes which are tailored to a specific device. Even if you specifically allocate your data set on a particular device, it could be moved to a different device in the future. We recommend that you choose a block size from one of two ranges of block sizes that will give reasonable efficiency with either device:

between 9077 and 10796

or

between 11477 and 13682.

For fixed-length records (RECFM=FB or FBS), the block size must be an exact multiple of the logical record length. This means selecting the largest multiple of your logical record length that falls within one of the ranges. For example, 80-byte card images should be blocked at 10720 or 13680. For variable-length records (RECFM=VB or VBS) or unspecified-length records (RECFM=U), use the upper bound of one of the ranges, 10796 or 13682.

You need to be aware that main storage is used for buffers in which to process blocked records, usually five buffers per data set. This can affect the size of the region in which your job runs. The block sizes suggested above are intended to provide good track efficiency without excessive main storage use. They will result in from three to five blocks per track, depending on which range you select and on which device type the data set resides.

The preceding discussion, which applies specifically to sequential data sets, also applies to partitioned data sets with some additional considerations. A partitioned data set (PDS) contains many sequential data sets, called members, placed one after another in the data set.

Like any sequential data set, the last block of a member may vary in length, containing anywhere from one logical record to the maximum number of logical records the block can hold. If there is insufficient space on a track for a full block following the short block, the next member will be started on the next track. This wastes the remainder of the previous track, an amount equal, on the average, to half the block size.

If the PDS contains many small members, this waste can occur on almost every track. In this case, choose a smaller block size to reduce the amount of wasted space at the ends of the tracks. Use a block size that is approximately one-half the average member size but still within one of the two recommended ranges.

With a PDS that contains mostly large members that span several tracks each, the potential for waste is reduced and you can choose a block size as if it were a sequential data set.

For load module libraries (RECFM=U), use the upper bound of one of the ranges. The linkage editor will attempt to make the most efficient use it can of the space.

Some programs may impose limitations on block size while others may make default assumptions. The linkage editor allows a maximum block size of 3200 for its primary input data set and for data sets containing object modules, although 3120 is a more efficient block size to use in these cases.

If a block size is not specified for a data set created by a Fortran program, the default value is 800. Since a block size of 800 has an efficiency of around 55%, you should avoid the default by providing a larger block size.

There is, in all cases, an upper limit of 32760 for block sizes, imposed not by hardware limitations but by the design of the operating system.

Space may be requested in units of average block length, tracks, or cylinders. To be more device-independent you should specify an average block length, in bytes, rather than TRK or CYL in the "unit" parameter above.

The primary quantity requests the initial number of units of allocation needed. This number should be as close to the total requirement as possible.

For example, you can specify the following:

SPACE=(12000,380)

to request enough space to store 380 blocks of 12000 bytes each. The system will use this information and the physical characteristics of the device selected to compute an appropriate number of tracks or cylinders to allocate.

If you are unsure exactly how much space you need, it is better to slightly overestimate your allocation than to underestimate it and cause secondary allocation. Releasing any overallocated space is discussed below (see "Releasing Unneeded Space").

The secondary quantity is a safeguard that will be used only if your data set exceeds the space that you allocated with the primary quantity. The system does not guarantee that the space for a secondary allocation will be available.

Generally, you should specify a secondary allocation quantity to avoid wasteful ABENDs in the event that the initial size estimate was insufficient. For example,

SPACE=(12000,(380,38))

allows up to 15 additional 38-block extents of space to be added to the original allocation if it is needed and if space is available.

When you create a partitioned data set (PDS), you must specify the number of directory blocks you will need. The directory holds the names of the members of the data set, along with other needed information. If you do not allocate enough directory blocks, you might restrict the growth of the PDS and have to re-create it later to enlarge the directory. Therefore, it might be wise to anticipate growth by allocating 10-15 percent more directory blocks than required.

The operating system uses the directory of a PDS to locate its members. Each member has a unique entry in the directory. The size of the entry varies depending on what kind of data set is involved and how the data set has been maintained.

Directory entries for members of a library containing source code, macros, object modules or data can require the least space because only the name of the member and its relative location in the data set need to be stored. However, if one of these data sets has been maintained by the ISPF editor with the STATS option turned on, additional space is needed to hold the requested statistics.

Directory entries for load modules created by the linkage editor also require more space because the system must include additional information for use at execution time (such as the size of the module and its entry point address.)

As a guideline for determining the number of directory blocks you will need for a PDS, figure on 6 entries per directory block if the data set is a load module library or if it will be edited with the ISPF editor. Otherwise, allow for 16 entries per directory block.

To specify the number of directory blocks, use the directory allocation on the space parameter. For example, to specify five directory blocks, you could use:

SPACE=(12000,(380,38,5))

To check the status of partitioned data sets, use the PDSLIST utility program described in CNS document D0068, Utilities for Partitioned Data Sets.

Since data sets which have unneeded space allocated to them cost you unnecessary storage charges--in addition to tying up space which could be used productively by others--you should release unused space back to the system. One common situation where you want to release unused space is when you have intentionally overallocated a new data set because you were unsure exactly how much space was needed. A second common problem is a PDS which has waste space in it due to the manner in which a PDS grows.

The following sample DD statement shows how to create a sequential data set on one of the user public volumes. It will be billed to userid "STARTRK."

//MYDATA DD DSN=UF.STARTRK.PHASER.DATA, 
//       UNIT=SYSDA, 
//       SPACE=(13680,(50,5),RLSE), 
//       DCB=(LRECL=80,RECFM=FB,BLKSIZE=13680), 
//       DISP=(NEW,CATLG)

This example shows how to create a load module library. It will be stored on a bulk disk volume for which the user has indicated that "STRFLEET" is the high-level index to be used on the bulk volume.

//MYLOAD DD DSN=STRFLEET.KLINGON.LOAD, 
//       UNIT=SYSDA, 
//       SPACE=(13682,(300,30,10),RLSE), 
//       DCB=(RECFM=U,DSORG=PO,BLKSIZE=13682,LRECL=0), 
//       DISP=(NEW,CATLG)