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 -