HISTORICAL MANUALS
+----------------------------------------------------------------------------+
| |
| |
| |
| |
| DDDDDDD IIIIII SSSSSS KK KK SSSSSS |
| DDDDDDDDD IIIIII SSSSSSSS KK KK SSSSSSSS |
| DD DD II SS SS KK KK SS SS |
| DD DD II SS KK KK SS |
| DD DD II SSSSSSS KK KK SSSSSSS |
| DD DD II SSSSSSS KKKKK SSSSSSS |
| DD DD II SS KKK KK SS |
| DD DD II SS SS KK KK SS SS |
| DDDDDDDDD IIIIII SSSSSSSS KK KK SSSSSSSS |
| DDDDDDD IIIIII SSSSSS KK KK SSSSSS |
| |
| |
| |
| |
| A User's Guide to Disks at the University of Kentucky |
| |
| |
| |
| |
| May 26, 1988 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Computing Center |
| 128 McVey Hall |
| University of Kentucky |
| Lexington, Ky. 40506-0045 |
| Phone: (606) 257-2900 |
| |
| |
| |
+----------------------------------------------------------------------------+
Introduction
A large amount of information can be stored on a magnetic disk at a fairly
low cost. Each piece of information can be accessed directly (it is not
necessary to read the preceding pieces), and information can be easily added
or modified. It is usually cheaper to store data on a tape, but information
on the tape must be processed sequentially (any preceding information must be
read), and information can only be added or modified at the end of the tape.
In addition, the tape must be mounted by an operator each time it is used,
incurring a $.50 mount charge. All of our disks are permanently mounted; the
datasets on them are immediately available without operator intervention.
Disk storage is essential for:
CMS (terminal) accounts,
program (load module) and procedure libraries,
frequently used datasets,
data that must be frequently updated, or updated in place,
data that must be accessed non-sequentially (direct access datasets).
Magnetic disk devices come in a wide variety of sizes, speeds, and storage
capabilities. The UKCC currently supports only 3380 type disk drives for OS
and CMS applications. The disk drives are used for all permanently mounted
disks. Some are used for paging and spooling, some are used for system
datasets, some are used for scratch datasets, and some are used for rental
datasets. Private disks may not be used at the UKCC.
Anatomy of a Disk
Each disk is made up of several rigid aluminum platters. (Sometimes a
single platter is called a disk, then the entire assembly is called a disk
pack.) Each platter resembles a phonograph record with a large hole in the
middle. The platters are stacked about 1/2" apart, with a spindle down the
middle; the entire assembly spins rapidly. Both surfaces of each platter are
coated with a magnetic material similar to the coating used on magnetic tape.
The read/write heads are mounted on an assembly like a large-toothed comb.
Two heads are mounted on each "tooth", one for the surface above it, and one
for the surface below it. The "comb" moves the heads in and out so that
different parts of the platters may be accessed. With the comb in a given
position, each head traces a circle on the surface rotating above or below it.
As the head assembly moves in and out, a number of concentric circles are
described on the platters. Each circle is called a track. The group of
tracks that can be accessed with the head assembly in one position is called a
cylinder. The heads are pushed toward the disk surfaces, but aerodynamic
forces keep them flying about 100 micro-inches from the coating. (For
comparison, a human hair is about 2500 micro-inches in diameter.)
USING DISKS AT THE UKCC - 1 -
platters comb
v v
====================|====================
| heads -> I-----+
====================|==================== |
| I-----+
====================|==================== |
| I-----+
====================|==================== |
| I-----+
====================|==================== |
| |
| <- spindle |
Side view of portion of a disk.
There are several models of 3380 disk drives. The model used at the UKCC
has 15 tracks per cylinder. Each track can contain up to 47476 bytes. There
are 2655 cylinders per disk, for a total of about 1981 million bytes (1890 mb)
per drive.
CMS Disk Space
All CMS disk space is allocated on permanently mounted 3380 disks. At
least one cylinder must be rented when an account is opened, and space must be
rented in full cylinder units. The charge is $2.00 per cylinder per month.
One cylinder can hold more than 8000 fixed-length 80-character records (4
boxes of cards). (Using variable-length records usually allows an even
greater number of records to be stored.) A charge is made for all of the
space rented, regardless of how much data is actually stored.
To set up a CMS account, or to modify the amount of disk space for an
existing account, contact the Computing Center Project Accounting 105 McVey
Hall. For more information on manipulating CMS datasets, see the XEDIT
Reference Guide, or the CMS Introductory Guide and the CMS Reference. These
may be printed using the CMS MANUAL command.
Permanent OS(RENTAL) Datasets
To rent OS disk space, obtain a form from the Computing Center Project
Accounting Office, 105 McVey Hall. Complete this form and return it to the
office; an identifying prefix will then be assigned (e.g., "UK.XYZ01"). The
first qualifier (UK) identifies the institution, and the second (XYZ01)
identifies the department and account.
The discussion that follows assumes a general familiarity with IBM's Job
Control Language (JCL). See IBM's JCL Reference Guide (GC28-1350-3) for a
more complete discussion. Examples of the JCL used to manipulate disk
datasets are given in the section "Managing OS Disk Datasets" later in this
document.
USING DISKS AT THE UKCC - 2 -
Five parameters are normally given on the DD statement used to allocate a
disk dataset: DSN, DISP, UNIT, SPACE and DCB. (Some programs allow the DCB to
be omitted.)
The DSN parameter must specify a dataset name beginning with a valid
accounting prefix (e.g., DSN=UK.XYZ01.MYDATA). Datasets stored under an
invalid or illegal prefix will be deleted without warning. All permanent
datasets should be cataloged, so use DISP=(NEW,CATLG) when creating a disk
dataset. Use UNIT=RENTAL (and omit the VOL=SER parameter) to allocate the
dataset on a rental volume with sufficient room to hold it.
The SPACE parameter tells the operating system how much space to allocate.
SPACE=(TRK,(5,2),RLSE), for example, will allocate 5 tracks for the primary
extent, and 2 tracks for each secondary extent up to 16 extents. Any unused
space will be released. A charge will be made for all of the space allocated
(in tracks per day), even if the dataset is only partially full. (The RLSE
subparameter will not work for certain programs, including the GO step of
FORTRAN programs.)
The DCB parameter specifies the physical attributes of the dataset (e.g.,
DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160). See the section "Choosing a Block Size
for a Disk Dataset" later in this document for more information on the DCB
parameter.
Users are responsible for maintaining and deleting their own datasets. OS
datasets are not automatically deleted when the funding project number is
closed. You will still be charged until the datasets are deleted. The
Computing Center backs up (copies to tape) rental disks on a regular basis;
the monthly backup tapes are kept for about six months. However, users should
maintain copies of important datasets themselves.
Permanent datasets on scratch disks will be deleted without warning.
Temporary OS (Scratch) Datasets
To allocate a temporary dataset (one that will exist only for the duration
of the job), use a dataset name beginning with "&&" (e.g., "DSN=&&TEMP").
Omit the VOL=SER= parameter and specify UNIT=SYSDA; a scratch volume will be
assigned. Use DISP=(NEW,DELETE) or DISP=(NEW,PASS). A SPACE parameter must
be given, and sometimes a DCB parameter, as described earlier for RENTAL
datasets.
When referring to a dataset passed from a preceding step, give only the DSN
and DISP=(OLD,PASS). Please don't allocate temporary datasets on the rental
volumes; this ties up space that may be needed by other users.
The System Catalog
The system catalog is a dataset on a system disk. It contains certain
information about other datasets, and it is structured so that this
USING DISKS AT THE UKCC - 3 -
information can be retrieved rapidly. When a dataset is cataloged, an entry
is made in the system catalog. This entry contains the name of the dataset
(DSN), the type of device on which it resides (UNIT), and the name of the
volume (VOL=SER). This allows a job to access the dataset by name; the
programmer need not know which disk or which type of disk the dataset is on.
(The dataset could even be on a tape; however, at the UKCC only special system
datasets are cataloged on tapes. In general, please do not catalog tape
datasets.) This is particularly useful when allocating RENTAL datasets. The
operating system can pick out a volume with enough room to hold the dataset
and then catalog it; it's not necessary to know which volume was chosen. A
job that accesses a cataloged dataset can continue to run correctly even if
the dataset is moved to another volume and recataloged.
The operating system must search the catalog for a job's cataloged datasets
each time the job is run. To make this searching efficient, the catalog is
given a hierarchical structure. Each dataset name is composed of one or more
levels. Each level may be one to eight characters. The levels are separated
by periods, and there may be a total of 44 characters, including the periods
(e.g., DSN=UK.XYZ01.DATA). The first level points to the section of the
catalog that contains all of the dataset names beginning with UK. Within this
section there is a pointer to the group of dataset names that also have a
second level of XYZ01, and so on. The process continues until the entire name
is located or found to be missing.
Managing OS Disk Datasets
Most disk dataset problems occur when the datasets are allocated and
cataloged, or when they are uncataloged and deleted. If this processing is
not performed correctly, the datasets may not be cataloged, or the catalog
entries may point to the wrong place. Subsequent jobs will then fail or give
incorrect results.
The operating system allocates space for all of a job step's new datasets
before the step begins execution and after the previous step (if any) is
finished. After the step completes execution, its datasets will be cataloged
or uncataloged if specified, then deleted if specified. This will be done
whether the step executes correctly or not. In fact, the utility program
IEFBR14 (also known as DUMMY) does absolutely nothing! It contains only two
instructions: one to clear the condition code register, and one to return (BR
14). Its only purpose is to serve as a dummy job step so that the operating
system allocation routines can perform the DISP processing for the step's
datasets.
Suppose a job is run to allocate and catalog a disk dataset. Even if the
job does not execute correctly (even if it does not write a single record to
the dataset), space for the dataset will be allocated and a catalog entry
made. Suppose then, that the job is corrected and rerun without changing the
DISP=(NEW,CATLG) to DISP=OLD. The operating system, doing exactly as it is
told, will allocate a NEW dataset (on another volume). When the job finishes
(perhaps correctly this time), the operating system will try to catalog the
second dataset. However, it can't, because there is already a catalog entry
pointing to the first dataset. The message "NOT CATLGED 2" is produced in the
allocation messages at the beginning of the printout, but this is easily
USING DISKS AT THE UKCC - 4 -
overlooked. The job could be re-run until every rental disk has a copy of the
dataset. After that the job would fail with the message "DUPLICATE NAME ON
VOLUME". Any job that tried to access the dataset (as a cataloged dataset)
would get the first (incorrect) one. The others would be ignored. Charges
are incurred for all of the space allocated. Be careful!
The allocation messages that follow the condition code messages for a step
indicate whether or not the step's datasets have been cataloged correctly.
The following example illustrates a dataset that has NOT been cataloged
correctly.
IEF142I - STEP WAS EXECUTED - COND CODE 0000************
IEF287I UK.XYZ01.MYDATA NOT CATLGD 2
IEF287I VOL SER NOS= UKC801.
Listing the Names of your Disk Datasets:
To list all of the datasets with a particular prefix on any rental disk,
cataloged or not, use the MAPRENT utility
//A EXEC MAPRENT,NAME='UK.XYZ01'
If MAPRENT flags the dataset name with a "-", then the dataset is not
cataloged. If the name is flagged with a "*", then the dataset is not
cataloged, but another dataset with the same name IS cataloged.
Allocating a dataset:
You may allocate a dataset in the step that first uses it, or you may pre-
allocate it with the IEFBR14 utility:
//A EXEC PGM=IEFBR14
//DISK DD DSN=UK.XYZ01.MYDATA,DISP=(NEW,CATLG),
// SPACE=(TRK,(30,1)),UNIT=RENTAL
You may need to add DCB information (RECFM, LRECL, and BLKSIZE) to the DD
statement. If the dataset is to be a PDS (partitioned dataset, e.g. a
procedure or load module library), you must allocate at least one directory
block in the SPACE field (e.g., SPACE=(TRK,(30,1,5))). Several datasets may
be allocated by supplying several DD statements. The ddnames used are
arbitrary.
The actual volume selected for the dataset will be listed in the OS
allocation messages. For example, the following messages indicate a correctly
cataloged data set:
USING DISKS AT THE UKCC - 5 -
IEF142I - STEP WAS EXECUTED - COND CODE 0000***********
IEF285I UK.XYZ01.MYDATA CATALOGED
IEF285I VOL SER NOS= UKC801.
Each time you allocate a permanent dataset, check to see that it has been
allocated and cataloged correctly.
Referring to a cataloged dataset:
Code only the DSN and DISP. Use DISP=OLD for a dataset that is to be
rewritten, and DISP=SHR for a dataset that is to be read only.
//A EXEC FORTGCG
//FORT.SYSIN DD *
FORTRAN program
/*
//GO.FT10F001 DD DSN=UK.XYZ01.MYDATA,DISP=SHR
Deleting a dataset:
USE the DELETE cataloged procedure:
//A EXEC DELETE,DSN='UK.XYZ01.MYDATA'
or use the IEFBR14 utility:
//A EXEC PGM=IEFBR14
//D DD DSN=UK.XYZ01.MYDATA,DISP=(OLD,DELETE)
Be careful! If you specify the UNIT and VOL=SER information when referring
to a cataloged dataset, the catalog is not used to locate the dataset. The
dataset will be deleted, but the catalog entry will not be removed. The
following dataset illustrates a dataset that has been correctly uncataloged
and deleted:
IEF142I - STEP WAS EXECUTED - COND CODE 0000***********
IEF285I UK.XYZ01.MYDATA UNCATALOGED
IEF285I VOL SER NOS= UKC801.
IEF285I UK.XYZ01.MYDATA DELETED
IEF285I VOL SER NOS= UKC801.
Each time you delete a permanent dataset, check to see that it was
uncataloged and deleted properly.
USING DISKS AT THE UKCC - 6 -
Deleting an uncataloged dataset:
//A EXEC PGM=IEFBR14
//ANY DD DSN=UK.XYZ01.MYDATA,DISP=(OLD,DELETE),
// UNIT=3380,VOL=SER=UKC801
(fill in the proper VOL=SER and DSN)
This bears repeating: when deleting a permanent (cataloged) dataset,
specify only the DSN and DISP=(OLD,DELETE). If the UNIT and VOLume parameters
are given, the operating system will not use the catalog to locate the
dataset, and it will not remove the catalog entry when the dataset is deleted.
Cataloging an uncataloged dataset:
//A EXEC PGM=IEFBR14
//ABC DD DSN=UKU.@XYZ01.MYDATA,DISP=(OLD,CATLG),
// UNIT=3380,VOL=SER=UKC801
(fill in the proper VOL=SER and DSN)
Conditionally allocating a dataset:
The UKCHKCAT program checks the catalog for a dataset name, and returns a
condition code of zero if an entry exists, and eight if it doesn't. (Other
condition codes indicate errors.) You can use this condition code to bypass
an allocation step if a dataset already exists:
//CHK EXEC PGM=UKCHKCAT,PARM='UK.XYZ01.MYDATA'
//ALLOC EXEC PGM=IEFBR14,COND=(8,NE,CHK)
//DD1 DD DSN=UK.XYZ01.MYDATA,DISP=(NEW,CATLG),
// SPACE=(TRK,(19,1)),UNIT=RENTAL
Releasing extra space:
If you allocate too much space to a dataset, and you don't want to be
charged for the extra space, you can use the RELEASE procedure to return
unused space to the system.
//A EXEC RELEASE,DSN='UK.XYZ01.MYDATA'
USING DISKS AT THE UKCC - 7 -
Renaming a dataset:
To rename a cataloged dataset, use the RENAME procedure. It will uncatalog
the dataset, rename it, and then re-catalog it under the new name.
//S EXEC RENAME,OLD='UK.XYZ01.NOW',NEW='UK.XYZ01.THEN'
For More Information:
If you need more information about these or other utilities, see the UKCC
Users' Guide. A reference copy is available in the Consulting Room, 110 McVey
Hall. It contains examples for copying cards to disk, tape to disk, etc. If
you need help using these utilities, see a consultant in 110 McVey Hall.
Choosing a Block Size for a Disk Dataset
The block size used for a disk dataset can affect the amount of main
storage used for buffers, the amount of space needed on a disk, and the number
of I/O operations (EXCPs). Each open dataset will need twice the block size
of main storage for buffers. If the block size is large, these buffers can
occupy a substantial amount of main storage. On the other hand, since each
block has some system information associated with it, small block sizes will
not only increase the number of I/O operations, but reduce the number of
actual data bytes stored on each track. In addition, the block size is
limited to the disk's track size (except in certain peculiar cases), and an
integral number of blocks must fit onto a track. Therefore, the block size
must be chosen carefully, or part of each track will be wasted. The formulas
for calculating the number of blocks of a given size that will fit onto a
track are fairly complicated, because allowances must be made for the system
overhead information included with each block and track. This information has
been summarized in the table on the next page. A block size of less than 3120
bytes is usually a good compromise. Variable-length records allow for
considerable flexibility in choosing the block size. The only requirement is
that it must be at least four bytes longer than the logical record length.
Fixed-length records must have a block size that is an integral multiple of
the record length.
The following table lists recommended blocksizes (and some poor but
customarily used blocksizes) for common record lengths. For example, assume
that fixed-length, 80-byte records (card images) are to be stored on a 3380
disk. Using "SPACE=(11840,(20,10),RLSE)" will allocate 20 blocks of 148
records each (11840/80=148 records per block or 2,960 records per extent). If
more space is needed another 10 blocks or 1480 records will be allocated. Up
to 15 secondary extents can be allocated in this way. If only one box of
cards (2000 records) were to be stored, only 14 (ROUND(2000/148)) blocks would
be required. With this blocksize 4 blocks will fit on a track.
USING DISKS AT THE UKCC - 8 -
+----------------------------------------------------------------------+
| DISK CAPACITY TABLE |
+----------------------------------------------------------------------+
| 3380 DISKS |
+-------+-------------+----------+----------+------------+-------------+
|Record | Recommended | Blocks | Bytes per| Records | Notes &/or |
|Length | Blocksize |per Track | Track | per Block | % disk used|
+-------+-------------+----------+----------+------------+-------------+
| 80 | 11840 | 4 | 47360 | 148 | card image |
| 132 | 2244 | 21 | 47124 | 17 | printline |
| 133 | 11837 | 4 | 47348 | 89 | " image|
| 256 | 9472 | 5 | 47360 | 37 | 99.7% |
| 800 | 800 | 58 | 46400 | 1 | 97.7% |
| 1600 | 1600 | 29 | 46400 | 1 | 97.7% |
| 2012 | 2012 | 23 | 46276 | 1 | 97.4% |
| 3120 | 3120 | 15 | 46800 | 1 | 98.6% |
| 3200 | 3200 | 14 | 44800 | 1 | 94.4% |
| 6233 | 6233 | 7 | 43631 | 1 | 91.9% |
| 6400 | 6400 | 7 | 44800 | 1 | 94.4% |
| 7294 | 7294 | 6 | 43764 | 1 | 92.2% |
|13030 | 13030 | 3 | 39090 | 1 |* 82.33% |
|19069 | 19069 | 2 | 38138 | 1 |* 80.33% |
|23476 | 23476 | 2 | 46952 | 1 | use for SAS |
+-------+-------------+----------+----------+------------+-------------+
An * indicates a poor choice, do not use.
USING DISKS AT THE UKCC - 9 -