IBM User's Guide, Thirteenth Edition


11 Magnetic Disk Storage on MVS

Direct access storage for MVS data sets is provided on IBM 3380 and IBM 3390 magnetic disk storage units. These permanently mounted units provide storage for the operating system and system programs as well as temporary and non-temporary for user programs and data. In order to assist users in planning the most efficient use of disk resources, the following table summarizes the storage capabilities of each of the IBM disk storage units in use at UTCC.

Unit Bytes/Track Tracks/Cyl. Cyls./Vol. Megabytes/Vol.

3380A 47,476 15 885 630 3380E 47,476 15 1,770 1,260 3380K 47,476 15 2,655 1,890 3390 56,664 15 2,226 1,892

MVS disk data sets are allocated and managed either through job control language (JCL) statements contained in an MVS batch job stream or from TSO using the dataset utilities menu. In addition, UTCC has established local conventions regarding disk usage which are described in this chapter.

Disk organization

At UTCC, the following names have been assigned to groups and subgroups of disk storage units that are of the same type or perform some specific function. The group name is coded in the UNIT= keyword parameter of the DD statement when referencing a data set. For example,

Group Name     Storage Unit

UNIT=ONLINE IBM 3380 UNIT=SYSDA IBM 3390 UNIT=VMSHR IBM 3380 UNIT=VIO See section 11.1.3

Within the ONLINE group, specific disk units, called volumes, are assigned a volume serial identification.

UNIT=          VOL=SER=

ONLINE ONLINx where "x" is 1, 2, 3, 4, 5, 6 or 7

Data on a disk volume are organized into data sets, each of which has a data set name (DSN). A volume table of contents (VTOC) records information about each data set including its name, organization, and location on the volume, and the amount of available space on the volume. When the data set name and volume are specified, the operating system is able to retrieve complete information about a data set. To avoid the necessity of keeping track of the volume and units on which data sets are stored, users are urged to catalog their data sets at creation. Then, for subsequent access, only the data set name (DSN=) and status or disposition (DISP=) parameters are required.

Disk data set location

The location of a disk data set depends on its characteristics. Temporary data sets are allocated to a SYSDA unit or in Virtual Input/Output (VIO) disk paging space (see section 11.1.3). Non-temporary space is allocated to UNIT=ONLINE for the ONLINx volumes or UNIT=VMSHR. For example:

//SHARE    DD UNIT=VMSHR,DISP=(,CATLG),
//         SPACE=(800,(500,100),RLSE),DSN=J999991.SHARED

It should be noted that VMSHR disk data sets can be read by any CMS user, even if RACF protection does not allow MVS users to read them. See section 4.24.3 for more information about VMSHR; see section 11.6 for more information about RACF protection on MVS. Space on ONLINx may be allocated by allowing the system to choose an online pack depending on the space available. This is the recommended method of allocation. To invoke this facility, UNIT=ONLINE should be specified, and the VOL parameter should be omitted. For example:

//ONLIN    DD UNIT=ONLINE,DISP=(,CATLG),
//         SPACE=(TRK,(20,10),RLSE),DSN=J999991.MYDISK

The system will automatically select an appropriate ONLINx disk pack. After execution, the online pack that was used can be identified by examining the JCL listings of the job, provided the second positional parameter of the MSGLEVEL field is specified as "1" (see section 7.2.1), or the data set can be cataloged, identifying the disk pack for future use. The use of the system catalog is recommended in most cases. The parameters required on DD statements for allocating disk data sets are given in MVS/ESA JCL Reference , GC28-1829.

Data set names

The format for a valid data set name depends on whether the data set is temporary or non-temporary: temporary data sets are deleted at the end of the job; non-temporary data sets are kept at the end of a job and may be used in subsequent jobs.

Temporary data set names Data set names for temporary data sets are optional; however, if a name is specified for a temporary data set, it must be of the form &&cccccccc, where "cccccccc" represents a one- to eight-character name. If no data set name is specified, the operating system will assign one.

Non-temporary data set names Data set names of the following form are required for all non-temporary data sets at UTCC:

Jprojcode.rem

where "projcode" is a valid project code, without leading zeros, and "rem" is the remainder of the data set name specified by the user. The "rem" portion of the name cannot be null, and the whole name, including the high level index "Jprojcode" and all periods may not exceed 44 characters. For each group of eight characters or less there must be a period, and the first character of the name and the character following a period must be an alphabetic or national ($#@) character. Permanent disk data sets on all volumes and catalog entries will be deleted if the high level indices for their data set names do not conform to the naming convention or if the project code in the high level index is invalid.

The balance of the data set name may contain any valid character string. Examples of permissible data set names are

DSN=J999991.SOURCE.ZLEV.PT3.MOD5
DSN=J999991.MOD15
DSN=J999991.PT8
Users may rename and recatalog disk data sets with the IDCAMS or IEHPROGM utility program (see section 14.2.1 or 14.2.6).

Virtual input/output data sets

VIO data sets are temporary data sets that reside within the MVS paging space, but appear to reside on a real direct access storage device. Execution time for some MVS jobs can be improved through the use of VIO. Compile and link processing and jobs which pass several small temporary data sets from step to step are good applications for VIO data sets. However, VIO may not be used when running IEHMOVE, will not improve performance when used with very large records, and cannot be used with ISAM and BDAM. In addition, to avoid performance problems inherent in the overuse of VIO, VIO space requests for more than four 3390 cylinders (about 3.2 megabytes) will be directed to a 3390 disk (SYSDA).

Automatic release of unused disk space

Disk space which is allocated to a sequential disk data set on an ONLINE or VMSHR disk storage unit but is not used is automatically released on a weekly basis by UTCC. More disk space than is required for a data set is usually allocated for one of the following reasons:

1. The data set will be built up gradually using the DISP=MOD technique.

2. A non-temporary data set is recreated periodically with varying amounts of data based on run conditions. Automatically releasing unused space should not affect either of these applications, however, because of the way the MVS operating system handles disk space allocation. When a disk data set is initially allocated, the operating system sets aside the primary amount of space requested in the SPACE parameter on the DD statement. If the size of the data set increases beyond the primary allocation, the operating system will allocate secondary space quantities as many as 15 times. Therefore, instead of overallocating the primary space amount, secondary space allocations should be used to provide for data set growth. Even when a data set has used the limit of 15 secondary space allocations, it should not be affected by releasing unused space. This is because during the weekly process of releasing space, multi-extent data sets are reorganized into a single primary space extent. As a result, disk data sets are allowed to use up to 15 secondary allocations per week without requiring any action on the user's part. Although the majority of sequential data sets will not be affected by releasing unused space, there are two problem situations of which users should be aware.

1. If the disk on which a data set resides does not contain enough free space to satisfy a secondary allocation request, data set growth could cause abnormal termination of the program requesting the additional space.

2. Data sets originally allocated with a zero secondary space quantity will have no automatic growth path. The first situation is only a potential problem, whereas the second situation is an actual problem. There is a JCL technique which can be used to provide growth for data sets originally allocated with a zero secondary space quantity. This technique is demonstrated as follows:

//DDNAME   DD DSN=J999991.DATASET,DISP=OLD,
//         SPACE=(mode,(primary,secondary))

or

//DDNAME DD DSN=J999991.DATASET,DISP=MOD, // SPACE=(mode,(primary,secondary))

where "mode" and "primary" are specified exactly as originally specified for the data set and "secondary" indicates the amount of secondary allocation space desired for the data set. This technique must be repeated each time the data set is to be extended or enlarged. UTCC realizes that there are a few critical applications for which even the possibility of not being able to obtain secondary space is unacceptable. Data sets used for these applications require the ability to overallocate disk space in anticipation of future needs. To retain this ability for critical applications, UTCC can provide a facility in which specified sequential data sets do not participate in the automatic release of unused data set space. Users are required to contact their UTCC consultant in order to have a sequential data set registered to participate in this No Space Release facility. Requests for this facility will be reviewed on a case-by-case basis.

Data set responsibility

Users are responsible for backing up their data sets. UTCC makes a weekly dump to tape of all disk packs which it maintains; however, the contents of disk data sets are not verified in the backup process, and the backup version of an online disk data set cannot be guaranteed to be free of error. Tape data sets are not backed up by UTCC. Whether on tape or disk, data sets which were costly or difficult to create should be backed up by a second copy stored in a separate place. Although UTCC will credit a user's project code for a job which fails due to hardware, software, or operator error as explained in section 2.7, credits will not be given for jobs required to recreate data sets. Disk space may be allocated for valid project codes by any user who has a valid userid. The programmer who allocates a data set is responsible for all use and maintenance of the data set, but only the project administrator can change the default access protection (see section 11.6). The director is responsible for all rental charges incurred by the data set; therefore, it is assumed that a programmer allocating a permanent disk data set has the approval of the project director to do so. Users with project codes ending in the digit "5" (university classes) generally are not authorized to create permanent disk data sets unless explicitly instructed to do so by the project director.

System catalog

The system catalog permits reference to data sets by name alone without identifying the unit and volume in the JCL. It may be used to catalog any disk or tape data set which has a standard UTCC name. The catalog will be periodically analyzed, and any data set names for expired project codes or names that do not conform to UTCC data set naming conventions (see section 11.1.2) will be removed.


DSLIST

DSLIST is a cataloged procedure which lists all online disk data sets for the MVS group which appears on the JOB statement. The information given includes the data set name, volume, date last used, record length and format, and block size. DSLIST for the MVS group, J999991, is invoked by the following JCL:

//jobname  JOB ,name,GROUP=J999991,USER=Pusercode,
//         PASSWORD=?
/*ROUTE    PRINT RMTn
//stepname EXEC DSLIST

Disk data set restrictions

Proper disk pack maintenance requires that all disk data sets be movable. In order to assure that a data set is movable, the following conventions must be observed:

` Data sets must not be declared unmovable. ` The DSORG, BLKSIZE, and RECFM must be set in the VTOC entry for the data set name to properly describe the data set. ` Indexed sequential data sets must have enough information in their VTOC entries to allow manual reconstruction of the allocating DD statements and the execution of the IEBISAM utility program to move the data set. ` Allocation by absolute track is not permitted.
` The PASSWORD parameter may not be used. (Data set security is provided by RACF; see section 11.6.) ` Generation data sets must not use partitioned data sets as their model data set label.


Controlling access to MVS disk data sets (RACF)

The Resource Access Control Facility (RACF) is an IBM program product that controls access to all protected MVS resources. The protected resources include the MVS operating system, the identification of group (project) membership, the identification of the group (project) administrator, and disk data sets. Therefore, the RACF (pronounced "rack-F") database includes USER, GROUP and DATASET profiles. At this time tape data sets are not protected by RACF. A USER profile defines an individual user and stores, in an encrypted form, that user's current password plus the four most recent passwords. The profile name is of the form Pnnnn, where nnnn is the UTCC-assigned programmer code. Only UTCC can create or delete a USER profile. A GROUP profile defines a UTCC project code for MVS and identifies the users connected to that project code. There is one GROUP profile for each project code. The profile name is of the form Jnnnn, where nnnn is the UTCC-assigned project code. Only UTCC can create, modify or delete a GROUP profile. However, the project administrator may access statistics about MVS jobs which were run under that group. In the GROUP profile, the universal access (UACC) setting controls access; the initial value is NONE. That is, no access to a group's data sets is given to users not belonging to the group. That setting will carry over to DATASET profiles of the group if the UACC is not specifically set to some other value. A DATASET profile controls access to data sets belonging to a group. A DATASET profile name is of the form 'Jxxxxxx.yyy', where yyy either (1) completes an individual data set name to control access to a single data set, or (2) contains one or more wildcards, * or %, to control access to a group of data sets. A particular DATASET profile specifies information about which groups and/or users have access, the type of access they have, and what information should be recorded about accesses.

DATASET profile access settings A DATASET profile controls access by users in one or more of the following categories:

        owner group
        other groups
        individual users
        all MVS users (universal access)

Possible access settings are:

NONE allows no access to the data set READ allows user to read the contents of the data set UPDATE allows user to read or write to the data set ALTER allows user to read, write to, create, or delete the data set

DATASET profile access settings for user or group The project director is, by default, the project administrator, and as such, has sole authority to grant others access to the group's MVS disk data sets. Project directors may request that UTCC designate someone else in the group as the project administrator by contacting their UTCC consultants. The project administrator is made the owner of the group's DATASET profiles. This also means that after the group profile is created, only the project administrator may create, modify and delete any of the group's DATASET profiles. So that the research workers assigned to a particular group (the "owner group") can create, delete, update or read MVS disk data sets associated with that group, a PERMIT command was issued by UTCC when the initial DATASET profile for the group was created. This gives the entire group ALTER access to data sets not otherwise protected. Auditing was set to record all accesses, both successful and unsuccessful, to data sets protected by the profile. The "list of groups" access checking feature of RACF has been turned on. This means that access to a protected resource is granted if the user has access through any of the groups to which he/she is connected and is not just based on the group under which the user's job or TSO session is running. To allow access to a group's data sets by other groups or individual users outside that group, the project administrator of the owner group must issue a PERMIT command. An alternative is to change the UACC setting from the default of NONE to either READ, UPDATE, or ALTER, thereby giving all MVS users that level of access. The UTCC User Services consultants have had a PERMIT command issued by UTCC to allow them to continue offering assistance with MVS disk data sets. A project administrator may change that access permission. When a new project code is opened, GROUP and DATASET profiles are created; e.g., if project code 999991 is opened, GROUP profile J999991 and DATASET profile 'J999991.*' are created. The DATASET profile will include access permission for the User Services consultant unless the project administrator requests that such access be denied.

Universal access settings The universal access (UACC) setting in each RACF DATASET profile determines what access level all MVS users and groups other than the owner group have to a data set or group of data sets. The UACC settings that can be assigned are NONE, READ, UPDATE and ALTER. The initial DATASET profile created by UTCC for each group's data sets (profile name 'Jxxxxxx.*') has a UACC setting of NONE. Users may use RACF Report Writer (see below) to obtain information about accesses and attempts to access their projects' MVS data sets. With this information, a project administrator can tailor RACF data set protection to meet the group's particular needs. With the settings of NONE, READ, UPDATE, and ALTER, different levels of access can be provided.

Examples The following examples illustrate the syntax of RACF commands for several common tasks. The RACF commands are discussed further in "Resource Access Control Facility (RACF)," U01-0576, available through the PRTDOC facility. Note that the project administrator must modify existing or create new DATASET profiles only if users who are not connected to the owner group are to be given access to one or more of a group's MVS disk data sets or a user who is connected to the owner group is to be denied ALTER access. The initial DATASET profile for each group's data sets, established by UTCC, grants ALTER access to all users included in the group and denies access to all others except group J2200 (UTCC User Services). All examples assume the project administrator for group J999994 is user P999998.

Example MVS batch job The following example gives the JCL required to issue RACF commands within an MVS batch job. RACF commands can also be issued by using the RACF panels in TSO/ISPF (select R from the local panel). Using the procedure BATCHTSO, submit a standard MVS batch job with the appropriate RACF control statements (see sample statements below).

//jobname  JOB  ,name,GROUP=J999994,USER=P999998,
//         PASSWORD=?
/*ROUTE    PRINT  RMTn
//stepname EXEC BATCHTSO
//SYSIN DD *
  (RACF control statements)

Example RACF control statements The format of RACF control statements is

operation [positional_operand] keyword_operands

The operation (RACF command) must be coded first and need not begin in column 1. Some statements have a positional operand, a DATASET profile name of the form 'profile_name' (note that the profile name is enclosed in apostrophes), which must follow the operation. Keyword_operands may be in any order, separated by one or more spaces. In Example 1, PERMIT must occur first, 'J999994.*' is positional and must be coded second. The other operands each contain a keyword and may be listed in any desired order. The following examples show several RACF control statements required to alter access authority.

Example 1: To allow programmer P123458 READ access to your group's MVS disk data sets.

PERMIT  'J999994.*'  ID(P123458)  ACCESS(READ)  GENERIC

Example 2: To allow all programmers in group J999992 READ access to your group's MVS disk data sets.

PERMIT  'J999994.*'  ID(J999992)  ACCESS(READ)  GENERIC

Example 3: To allow programmer P888888 ALTER access to read/write/create/delete your group's MVS disk data sets.

PERMIT  'J999994.*'  ID(P888888)  ACCESS(ALTER)  GENERIC

Example 4: To allow programmer P89898 READ access to J999994.GOOD.STUFF only. (You must add a data set description of a fully qualified data set name before the permit is issued.)

ADDSD  'J999994.GOOD.STUFF'  UACC(NONE)  GENERIC  AUDIT(ALL)
PERMIT  'J999994.GOOD.STUFF'  ID(P89898)  ACCESS(READ)  GENERIC

Example 5: To revoke permit access granted in Example 4.

PERMIT  'J999994.GOOD.STUFF'  ID(P89898)  DELETE  GENERIC
The following examples show the RACF control statements necessary to set access authority for your MVS disk data sets for ALL users of the MVS system.

Example 6: To allow all MVS users READ access to your group's MVS disk data sets.

ALTDSD  'J999994.*'  UACC(READ)  GENERIC

Example 7: To allow all MVS users ALTER access to read/write/create/delete your group's MVS disk data sets.

ALTDSD  'J999994.*'  UACC(ALTER)  GENERIC

Example 8: To allow all MVS users READ access to your group's MVS disk data sets and to give programmer P89898 UPDATE access to read and write.

ALTDSD  'J999994.*'  UACC(READ)  GENERIC
PERMIT  'J999994.*'  ID(P89898)  ACCESS(UPDATE)  GENERIC

Example 9: To allow all MVS users READ access to all MVS disk data sets with data set names that start with J999994.GOOFY.

ADDSD  'J999994.GOOFY.*'  UACC(READ)  GENERIC
Up to this point the * has been used in the examples as a wild card for any level of a data set name. You can also use the % as a wild card for any single character.

Example 10: To allow all MVS users READ access to all MVS disk data sets with a data set name that starts with J999994.FUDGE.DATA and ends with any two characters.

ADDSD  'J999994.FUDGE.DATA%%'  UACC(READ)  GENERIC

Example 11: The next example shows how to find out which groups or individual users have access to each of your MVS disk data sets.

LISTDSD  ID(J999994)  ALL  GENERIC

Example 12: The same as Example 11, but provides access information for the single data set J999994.GOOD.STUFF only.

LISTDSD  DA('J999994.GOOD.STUFF')  ALL  GENERIC

RACF report writer

A program called RACF Report Writer allows users to retrieve recorded information about who has accessed their data sets. By default, when users run RACF Report Writer, they will receive a short summary of one line per data set about accesses to their data sets. If they need more specific information, such as a breakdown of who has accessed a particular data set, they can then request it. The following example shows the JCL needed to request the short summary.

//jobname  JOB ,name,GROUP=Jprojcode,USER=Pusercode,CLASS=T,
//         TIME=(1,0),
//         PASSWORD=?
/*ROUTE    PRINT destination
//stepname EXEC RACFRW
To override the default parameter RPT=SUM and request more detailed information, the last line (the EXEC statement) would be changed to show the appropriate command. For example,

//stepname EXEC RACFRW,RPT=USR

The summary will be for the current month in the current year unless otherwise requested. MONTH='(0)' is the default parameter. Changing this to MONTH='(-1)' will request the previous month; MONTH='(-2)' will request the next previous month, etc. For example, if the February summary is requested during March, MONTH='(-1)' is the parameter used to override the default:

//stepname EXEC RACFRW,MONTH='(-1)' To request reports from a previous year, YEAR='YRnn' must be specified, where 'nn' is a two-digit abbreviation for the year, e.g., '86'. The default parameter of MONTH='(0)' will generate the December summary for that year. To request reports from earlier months in the year, set the parameter as discussed above. For example, the October 1986 summary can be requested with the following:

//stepname EXEC RACFRW,YEAR='YR86',MONTH='(-2)'

August 1986 is the earliest month for which RACF reports can be requested at UTCC.

Additional information "Resource Access Control Facility (RACF)," U01-0576, has further information, including RACF commands. Users may access this document by using the PRTDOC facility on CMS (section 4.11).


[ Top of Page | Previous Page | Next Page | Table of Contents ]