MVS TOOLS AND TRICKS OF THE TRADE
                          June 1990

                                      Sam Golob
                                      MVS Systems Programmer
                                      sbgolob@cbttape.org

      THE EFFECT OF CHANGING SOME OF THE FIELDS IN THE VTOC

      This month, I'd like to talk about an important area of
system knowledge.  Some familiarity in this area is necessary for
every practitioner of our trade to have.  We shall discuss a few
aspects of the Format 1 DSCB, otherwise known as the VTOC Entry for
a dataset.  It is extremely important for a systems programmer to
understand the effects of the VTOC Entry fields on how a dataset is
going to behave.

      We shall not give an elaborate treatise on the subject of VTOC
fields, but I want to introduce some tools for changing these fields,
and to give reasons why we would find it necessary to change them
under certain circumstances.

      Changes to VTOC fields may be made by ordinary jobs which are
run.  These changes occur during the "opening" and "closing"
processes on a dataset.  For our purposes, it may not be desirable to
open the dataset and make a VTOC change, and under some circumstances
the cleanest effect will be obtained by directly changing a VTOC
field in the VTOC, using a specialized tool.

      In order to make direct changes to a VTOC, without opening or
closing the dataset, it is necessary to have APF program
authorization for the program which does the work.  IBM created the
Authorized Program Facility (APF) to prevent user programs from
causing system damage.  As most of you probably know, a program can
run APF authorized if:  it resides in a load library authorized by
the system APF table (defined by an IEAAPFxx member in SYS1.PARMLIB)
or it is in the system linklist concatenation (if those libraries
are authorized by default), AND if it has been linkedited with the
parameters SETCODE AC(1).  In addition, if the program is a TSO
command, its name must be authorized to TSO.  Our specialized tools,
usually TSO commands, must be so authorized in order to do their
work.  Many of you know of special tricks which we use to obtain APF
authorization for our tools.  These tricks do help, but I don't have
space to discuss them here.

      The two software tools we shall use are readily available on
the CBT MVS Tape which can be found at www.cbttape.org.  These are:
the CDSCB (Change the DSCB) TSO command from File 300, and the PDS
program product (Versions 8.3 or 8.4) from Files 182, 296, and 112.
CDSCB will be the principal tool whose actions we shall illustrate.
CDSCB must run authorized.

      The multipurpose "PDS" command will be our other tool.  "PDS"
by its design, does NOT run authorized.  PDS can indeed change
certain VTOC fields, such as record format (RECFM), record length
(LRECL), or block size (BLKSIZE), but it does this by quickly
opening and closing the dataset while writing a dummy output record
to it.  Although in practice, PDS is very handy for a "quick fix"
to a dataset through this function of its "FIXPDS" subcommand, our
use of it here will be primarily for demonstration and illustration
purposes, employing its "USAGE" subcommand.

      The "USAGE" subcommand of the PDS program product (or its
vendor-supported descendant, PDS/E) provides the best display of
Format 1 VTOC fields that I know of.  (You can make your own choice
after seeing the illustrations.)  We shall use the PDS USAGE display
to keep track of the VTOC fields and changes to them.

      Let's start by examining Figures One and Two.  These figures
graphically show VTOC fields for real datasets.  Figure One comes
from a source-type dataset.  Figure Two comes from a load library.

      Please notice that at the top of each USAGE report, dataset
statistics are reported, similarly to the ISPF 3.2 display, but in
more detail.  Below that display is a TTR and CCHHR report of each
dataset extent.  Further below is a HEX display of the entire
Format 1 VTOC entry for the dataset.  And finally at the bottom,
is formatted interpretation of all of the VTOC fields, as displayed
in the hex display.  Some of these fields are reformatted in the
field display for clearer interpretation, being translated from hex
to decimal numbers.  It is clear that most of the numbers in an ISPF
3.2 display of a dataset come from values stored in the Format 1 VTOC
entry for the dataset.

      Let's try to make our picture more specific with a case.
Let's say that the library from Figure One, TSTBSSG.A.CNTL, which
contains card-image source, is blocked at 3120 bytes per block, as is
evident from the figure.  Someone wants to write a new member to the
library, using the following JCL:

//OUTWRITE DD DISP=SHR,DSN=TSTBSSG.A.CNTL(NEWMEMBR),
//    DCB=(RECFM=FB,LRECL=80,BLKSIZE=80)

What will happen as a result of running this JCL, is that the library
TSTBSSG.A.CNTL will be opened for output with the DCB blocksize of
80 instead of 3120, and the effect will be permanent.  If we try now
to read the member NEWMEMBR with an editor, the default blocksize
that the editor assumes, will be 80 bytes per block.  NEWMEMBR can
be read by the editor, because it was written out with a blocksize
of 80.  But what if the user wants to edit another member?  He'll
get an ABEND S001 for "wrong length record", which will come from
the BSAM or QSAM access method, because the other library members
will have longer physical block sizes than 80 bytes.  Running that
JCL has in effect rendered the old members of TSTBSSG.A.CNTL
inaccessible.

      How can we fix this?  One way is to run another job with the
opposite JCL, that will write out a dummy member to the library
as follows:

//OUTWRITE DD DISP=SHR,DSN=TSTBSSG.A.CNTL(DUMMEMBR),
//    DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)

      After this job is run, the VTOC blocksize of the dataset is
reset back to 3120 bytes per block, and an edit program that is trying
to read a member, will now expect that member to be blocked at 3120
bytes per block.  Shorter-blocked members will be accessible also,
since the record format was specified as FB, and not as FBS (which
prohibits short blocks).  Thus, by restoring the VTOC blocksize of
the library, we have rendered all the members accessible once again.

      We could have done the same action in other ways.  The PDS
program, with its "FIXPDS" subcommand, accomplishes the above task
without our having to bother to code JCL and run a job.  We could
have entered under TSO:

      PDS  'TSTBSSG.A.CNTL'

followed by:

      FIXPDS BLKSIZE(3120)

followed by:

      YES  .

At this point, the PDS command will have opened the dataset for
output, written a tiny dummy member out to the library TSTBSSG.A.CNTL,
and then erased it, effecting our permanent VTOC change.

      There is a third way of accomplishing this same task that is
fundamentally different in concept.  Under TSO, one could have
entered (if the command CDSCB were properly installed, authorized
and available):

      CDSCB  'TSTBSSG.A.CNTL'  BLKSIZE(3120) SHR

      The CDSCB command, which has to run authorized, would not open
the dataset at all--not for input and not for output.  Instead, it
would go directly to the DS1BLKL field of the VTOC entry for
TSTBSSG.A.CNTL.  As shown in the display, DS1BLKL is at displacement
+56 from the beginning of the VTOC Format 1 entry.  CDSCB would then
change the halfword of HEX 0050 at +56, equal to decimal 80, to the
halfword quantity of HEX 0C30, which translates to decimal 3120.  The
SHR keyword assures that the change will be made, even if another
user has shared access to this dataset.  Thus, CDSCB accomplishes
the tricky task cleanly and directly, translating "our numbers" into
"the VTOC's numbers" and back again, and assuring that the correct
displacement values in the VTOC are zapped by its action.

      CDSCB effectively "zaps" the VTOC, but does it cleanly and
accurately under our control.

      Please refer to Figure Three for the TSO HELP member showing
the particulars of the CDSCB command.  For a full description of all
Format 1 VTOC fields, see the IBM manual:  "MVS Debugging Guide" that
comes in several volumes.  Look up the control block DSCB1 for the
full explanation of fields in the Format 1 VTOC entry.

      This brings us to the main point that I want to make.  Zapping
the Format 1 VTOC entry is familiar practice for "old-timers" in our
profession.  It is obvious that many errors could have been made in
the process, rendering the dataset temporarily unusable (until the
VTOC fields were zapped properly back).  Programs such as CDSCB, which
will hit the proper fields when triggered by our keyword values, make
the VTOC-zapping process more foolproof and error-free.  The "USAGE
ALL" display of the PDS program shows us all the VTOC fields for our
own dataset at the current time, formatted out, and further reduces
the chance of error in this process.  Thus, a tricky and error-prone
system programmer activity has been reduced to a routine and
relatively error-free job.

      We shall finish out this month's column with several case
histories showing the usefulness of VTOC-zapping to simplify the
unraveling of difficulties with datasets.

      The case of "lost VSAM Catalog passwords" is one famous case
where VTOC zapping comes in handy for the authorized systems person.
I once had a situation in which I had to delete an old VSAM
usercatalog whose entries had been moved into a new ICF catalog.
The current installation standard did not require any passwords
for usercatalogs, but this old catalog, the first usercatalog defined
at the installation in ancient days of system creation, was mistakenly
given a master password that was forgotten with the passage of time.
All of the old system programmers were long gone.  I wanted to delete
the catalog cleanly.  What was I to do?

      For sure, I did not want to change the dataset at all.  I am
no expert on old VSAM catalogs, and I certainly did not want to break
this one in the process of trying to look at it.  I did want to browse
it, however.

      VSAM prevents "outsiders" (programs other than IDCAMS) from
nosing around in KSDS clusters and usercatalogs through a standard
MVS mechanism.  IDCAMS turns on the "password read-write bit" which
is X'10' of +5D (the DS1DSIND field) of the VTOC entry for the VSAM
dataset.  With this bit on, MVS only allows access to the dataset if
a password entry in the "MVS PASSWORD" dataset exists and matches.
Since, for the VSAM dataset, no password was entered into the PASSWORD
dataset--VSAM can exist even if there isn't a PASSWORD dataset defined.
So in effect, ALL ACCESS IS DENIED to the dataset, except of course
to IDCAMS, which is authorized, and which gets into the VTOC to turn
the password bit off when it wants to do its stuff.

      The password read-write bit is what stops me from browsing
the VSAM catalog.  Therefore, I can use CDSCB to get in and turn it
off.  I have not attempted to open the dataset nor access it for
output.  Therefore, I have not done any harm.  I can then browse the
catalog as a dataset, using its full VTOC name.  After having nosed
around, discovering what I need to discover, I merely use CDSCB
again and turn the password bit back on, to restore protection.
With master password in hand, I then delete the usercatalog with
IDCAMS in the ordinary way.  For the systems programmer, this is
neat, clean, and within bounds.  Other attempts at access would have
possibly done irreparable harm, or have been futile.  End case one.

      Case two is even stranger than case one, but I'm including it
to show the power of the method.  I don't suspect that a sysprog will
encounter this exact case very often, if even once in a career.

      What has happened is that an important old load library has
been deleted by mistake, with no backup of the most recently linkedited
modules that were in it.  (Such an event is highly unlikely in a normal
shop that does adequate backups.)  A new source library has been
allocated in its place, and overlays the extents of the old library.
The new source library has only a few members in it, so that most
of the data in its allocated extents has not been touched.  Therefore,
the data of most of the old modules is still intact from the
encroaching source library.  Problem is, how do we recover as many of
the old modules as possible, or how do we recover one important module
that we no longer have the source for?

      This is not so hard, with our equipment (CDSCB and the PDS
product).  There are three problems to be overcome.  Number one, is
that a load module is relatively useless, without a directory entry
that properly describes its attributes.  Number two, is that the
new source-type library that has been allocated, marks its "high-water
point" of valid data at a very low TTR location within its allocated
extents.  If any "member restore" activity is to occur, this must
happen for TTR locations that are much higher than the currently
registered "high-water line".  Problem number three is that the
currently defined dataset is a source-type library, with record
format, record length, and block size reflecting this usage.  If
load modules are to be restored on the existing dataset directory,
the record format must equal "U", the block size must be large enough,
and the logical record length should be zero.

      No problem for us.  First, we must attempt to allocate a ddname
on our TSO session to this dataset with DISP=OLD, to prevent other
jobs and users from trying to write new source members while we are
working.  After this has been done, we use CDSCB to change the
dataset attributes of the existing library to RECFM=U, LRECL=0,
and BLKSIZE equal to some large number, greater than the physical
blocksize of any of the old modules.  We must first have noted the
original dataset attribute values, so they could be restored later.
The PDS "USAGE ALL" command is super, for preserving records of the
old values.

      Next comes the raising of the "high-water line" in the VTOC.
The old high-water line should be carefully noted.  CDSCB can be used
to boost the DS1LSTAR field of the VTOC entry (three bytes at +62
in the Format 1 DSCB) to a high value.  An alternative method is
the "FIXPDS MAXSPACE" subcommand of the PDS product, to set the high
water mark for valid data, to its maximum possible value within the
dataset's current allocated extents.

      That having been done, we then proceed to the member restore
process.  The PDS product comes in very handy here, because it
contains a flexible mechanism for restoring deleted library members.
This is the "RESTORE" subcommand of PDS.  Please bear in mind at this
point that the dataset attributes of the currently allocated
partitioned dataset are those of a load library.  To a newly created
member, the library would no longer appear as a source library.  The
old source or JCL members still have their old directory entries, and
will not be altered by the creation of many new load members.  Later,
the new members will be copied off and deleted, and the current
library will be restored to its old dataset characteristics and
high-water mark for good data.

      At this time, we use the PDS "RESTORE" subcommand to create
new load modules corresponding to all intact physical load module
members that haven't been overlaid.  These members will be
sequentially named.  For example, the commands:

      PDS  'current.dataset.name'

followed by:

      RESTORE $ABC REPEAT NOPROMPT

will restore all deleted members, in TTR order, with the member
names:  $ABC0001, $ABC0002, $ABC0003, and so forth.  Load module
attributes such as module authorization can be re-created at restore
time if deemed appropriate, or they can be supplied by the ATTRIB
command of PDS later, after the modules have been copied away to
a legitimate new load library.

      At RESTORE time, PDS logs the CSECT structure of the deleted
CSECT being restored.  This will help in the renaming process later,
and will also aid in the process of trying to figure out what the
re-entrancy properties and other special characteristics of the
original modules were.

      The PDS "COPY" subcommand, or the IEBCOPY program, can now be
used to move the restored modules to another load library for further
manipulation with the PDS "ATTRIB" subcommand, or with other utilities,
if needed.

      After the restored modules have been copied, the extra member
names should be deleted from the current library.  CDSCB or the PDS
"FIXPDS" capability should be used to bring back the source-library
dataset characteristics that the library originally had.  Finally,
a dataset compress should be done, to bring the high-water mark back
to its original value.  Case number two is now ended, with everything
having been set back to its original condition, and the load modules
having been saved.  YEEHAAA.

      Hope this month's trip has been useful to you.  Good luck.
See you next month.

   *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

FIGURE ONE.   VTOC-Oriented description of a Source-type partitioned
               dataset.  This display is from the USAGE subcommand
               of the PDS program product, describing the dataset
               characteristics.  It will be noticed that the numbers
               at the top are mostly obtained from the format-1 DSCB
               fields that are on display below.



ENTER OPTION -- DSN=TSTBSSG.A.CNTL,VOL=SER=TSO001  MEM=MOVSYSTM
>usage all
DISP UNIT OPT RECFM LRECL BLKSIZE   ALLOCTRK FREETRK SECONDARY FREEDIR
SHR  3380 W   FB       80    3120   1X   394       3    75 TRK      64

Data set: CREATED  EXPIRES  LAST USE  UPDATED  SECURITY
          3/16/87  0/00/00   3/30/90  YES      NONE

Extents in tracks: 394

Tracks: ALLOCATED    USED    FREE  EXTENTS
              394     391       3        1

Directory: BLOCKS    USED    FREE   TRACKS  MEMBERS  ALIASES
              413     349      64        9     2098        1

EXTENT  UCB  LO TT-HI TT  TRACKS     LOW CCHH-HIGH CCHH    BOUNDARY
------  ---  ----- -----  ------  ----------- -----------  --------
     0  9B7  00.00 01.89     394  03.19.00.03 03.33.00.06  TRK


Format 1 DSCB:
0   4   8   C  10  14  18  1C  20  24  28  2C  30  34  38  3C  40  44
TSTBSSG.A.CNTL                              1TSO001...........IBMOSVS2
EEECEEC4C4CDED444444444444444444444444444444FEEDFFF00504000000CCDDEEEF
3232227B1B353300000000000000000000000000000013260010170B00010092462522

 48  4C  50  54  58  5C  60  64  68  6C  70  74  78  7C  80  84  88
     !.............&...b.....f........................................
4444450500000098030500088004081180000010003000000000000000000000000000
00000A0900002000C0000002000B16FB00010390333060000000000000000000000000


LOC NAME     VALUE        DESCRIPTION
--- ----     -----        -----------
00  DS1DSNAM TSTBSSG.A.CNTL
2C  DS1FMTID F1           FORMAT IDENTIFIER
2D  DS1DSSN  TSO001       DATA SET SERIAL NUMBER
33  DS1VOLSQ 1.           VOLUME SEQUENCE NUMBER
35  DS1CREDT 57004B       CREATION DATE
38  DS1EXPDT 000000       EXPIRATION DATE
3B  DS1NOEPV 1.           NUMBER OF EXTENTS ON VOLUME
3C  DS1NOBDB 0.           NUMBER OF BYTES USED IN LAST DIRECTORY BLOCK
3D           00           RESERVED (ONE BYTE)
3E  DS1SYSCD C9C2D4D6E2E5E2F24040404040
4B  DS1REFD  5A0059       DATE LAST REFERENCED
4E           00000000     RESERVED (FOUR BYTES)
52  DS1DSORG 0200         DATA SET ORGANIZATION
54  DS1RECFM 90           RECORD FORMAT
55  DS1OPTCD 80           OPTION CODE
56  DS1BLKL  3,120.       BLOCK LENGTH
58  DS1LRECL 80.          LOGICAL RECORD LENGTH
5A  DS1KEYL  0.           KEY LENGTH
5B  DS1RKP   0.           RELATIVE KEY POSITION
5D  DS1DSIND 82           DATA SET INDICATORS
5E  DS1SCALO 8000004B     SECONDARY ALLOCATION
62  DS1LSTAR 01861F       TTR OF LAST USED TRACK AND BLOCK ON TRACK
65  DS1TRBAL 7,040.       BYTES REMAINING ON LAST TRACK USED
67           0000         RESERVED (TWO BYTES)
69  DS1EXT1  0100.03190003.03330006  FIRST EXTENT DESCRIPTION
73  DS1EXT2  0000.00000000.00000000  SECOND EXTENT DESCRIPTION
7D  DS1EXT3  0000.00000000.00000000  THIRD EXTENT DESCRIPTION
87  DS1PTRDS 0000000000   CCHHR OF ANY ASSOCIATED FORMAT 2 OR 3 DSCB


   *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *


FIGURE TWO.   VTOC-oriented description of a Load Library.
               Again please note the close relationship between
               the dataset description numbers in the upper part
               of the display, and the obvious relationship of most
               of them to the VTOC fields at the bottom of the
               picture.


ENTER OPTION -- DSN=TSTBSSG.LOAD,VOL=SER=TSO001  MEM=MOVSYSTM
>usage all
DISP UNIT     RECFM LRECL BLKSIZE   ALLOCTRK FREETRK SECONDARY FREEDIR
SHR  3380     U         0   19069   3X   240      19    60 TRK     113

Data set: CREATED  EXPIRES  LAST USE  UPDATED  SECURITY
          2/03/87  0/00/00   3/29/90  YES      NONE

Extents in tracks: 180, 34, 26

Tracks: ALLOCATED    USED    FREE  EXTENTS
              240     221      19        3

Directory: BLOCKS    USED    FREE   TRACKS  MEMBERS  ALIASES
              137      24     113        3      144        5

EXTENT  UCB  LO TT-HI TT  TRACKS     LOW CCHH-HIGH CCHH    BOUNDARY
------  ---  ----- -----  ------  ----------- -----------  --------
     0  9B7  00.00 00.B3     180  02.C9.00.01 02.D5.00.00  TRK
     1  9B7  00.B4 00.D5      34  01.20.00.02 01.22.00.05  TRK
     2  9B7  00.D6 00.EF      26  02.F0.00.01 02.F1.00.0B  TRK


Format 1 DSCB:
0   4   8   C  10  14  18  1C  20  24  28  2C  30  34  38  3C  40  44
TSTBSSG.LOAD                                1TSO001...........IBMOSVS2
EEECEEC4DDCC44444444444444444444444444444444FEEDFFF00502000000CCDDEEEF
3232227B36140000000000000000000000000000000013260010170200030092462522

 48  4C  50  54  58  5C  60  64  68  6C  70  74  78  7C  80  84  88
     !........{.я'.....b..............I...N...............0...1.......
44444505000000C04700000880030D05000000C000D000002000200000F000F0000000
00000A0800002001AD000002000C0CF400010290125001110021205122001210B00000


LOC NAME     VALUE        DESCRIPTION
--- ----     -----        -----------
00  DS1DSNAM TSTBSSG.LOAD
2C  DS1FMTID F1           FORMAT IDENTIFIER
2D  DS1DSSN  TSO001       DATA SET SERIAL NUMBER
33  DS1VOLSQ 1.           VOLUME SEQUENCE NUMBER
35  DS1CREDT 570022       CREATION DATE
38  DS1EXPDT 000000       EXPIRATION DATE
3B  DS1NOEPV 3.           NUMBER OF EXTENTS ON VOLUME
3C  DS1NOBDB 0.           NUMBER OF BYTES USED IN LAST DIRECTORY BLOCK
3D           00           RESERVED (ONE BYTE)
3E  DS1SYSCD C9C2D4D6E2E5E2F24040404040
4B  DS1REFD  5A0058       DATE LAST REFERENCED
4E           00000000     RESERVED (FOUR BYTES)
52  DS1DSORG 0200         DATA SET ORGANIZATION
54  DS1RECFM C0           RECORD FORMAT
55  DS1OPTCD 01           OPTION CODE
56  DS1BLKL  19,069.      BLOCK LENGTH
58  DS1LRECL 0.           LOGICAL RECORD LENGTH
5A  DS1KEYL  0.           KEY LENGTH
5B  DS1RKP   0.           RELATIVE KEY POSITION
5D  DS1DSIND 82           DATA SET INDICATORS
5E  DS1SCALO 8000003C     SECONDARY ALLOCATION
62  DS1LSTAR 00DC0F       TTR OF LAST USED TRACK AND BLOCK ON TRACK
65  DS1TRBAL 21,504.      BYTES REMAINING ON LAST TRACK USED
67           0000         RESERVED (TWO BYTES)
69  DS1EXT1  0100.02C90001.02D50000  FIRST EXTENT DESCRIPTION
73  DS1EXT2  0101.01200002.01220005  SECOND EXTENT DESCRIPTION
7D  DS1EXT3  0102.02F00001.02F1000B  THIRD EXTENT DESCRIPTION
87  DS1PTRDS 0000000000   CCHHR OF ANY ASSOCIATED FORMAT 2 OR 3 DSCB


   *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *


FIGURE THREE.   This is the Help member for the CDSCB
                 TSO command, that can change any field
                 in a dataset's Format 1 DSCB.  CDSCB must
                 run authorized, because any program which
                 directly changes VTOC fields must have
                 APF authorization under the MVS operating
                 system.


)F FUNCTION -
  THE CDSCB (CHANGE DSCB) COMMAND MODIFIES A DATA SET'S
  FORMAT-1 DSCB IN A VTOC.

  SINCE THE FORMAT-1 DSCB CONTAINS INFORMATION CRUCIAL TO
  A DATA SETS' SECURITY AND INTEGRITY, (AND IN FACT TO THE
  WHOLE SYSTEM'S SECURITY AND INTEGRITY), THIS COMMAND
  MUST BE RESTRICTED TO SYSTEMS SUPPORT PERSONNEL.

  NOTE: THIS IS AN APF-AUTHORIZED COMMAND, AND THEREFORE
  WILL NOT RUN PROPERLY UNDER SPF.  YOU MUST EXIT SPF TO
  'READY' MODE BEFORE USING THIS COMMAND.

  (Author's note.  There are ways of authorizing TSO commands
   that are run out of an ISPF screen.  I actually use this
   command while working under ISPF, but it takes a trick.
   Consult your local TSO guru.)

)X SYNTAX  -
         CDSCB  'DSNAME'   EXPDT('YYDDD')  SHR  VOL(VOLUME) UNIT(UNIT)
                           CREATE('YYDDD') REFDT('YYDDD')
                           DSORG(XX) RECFM(XX) LRECL(XX) BLKSIZE(XX)
                           ALLOC(TR/CYL/BL)  SPACE(SECONDARY-AMOUNT)
                           PWR/PWW/NOP/RACF/NORACF
                           ZAP(OFFSET VERDATA REPDATA)
  REQUIRED - 'DSNAME'
  DEFAULTS - NOTHING WILL HAPPEN IF NO CHANGES ARE SPECIFIED.
  ALIAS    - NONE

)O OPERANDS -
  'DSNAME'  -  THE NAME OF THE DATA SET WHOSE FORMAT-1 DSCB
             IS TO BE MODIFIED.
))UNIT(UNIT) - FOR UNCATALOGED DATA SETS, THE UNIT TYPE OF THE
             VOLUME WHERE THE DATA SET RESIDES.
))VOL(VOLUME) - FOR UNCATALOGED DATA SETS, THE VOLUME SERIAL
             OF THE DATA SET.
))SHR      - THIS KEYWORD INDICATES THAT THE DSCB IS TO BE
             MODIFIED EVEN IF ANOTHER JOB OR TSO SESSION
             IS USING THE DATA SET.
))EXPDT('YYDDD') - THE EXPIRATION DATE IS TO BE SET TO THE SPECIFIED
             JULIAN DATE.  (FOR JULIAN DATE CONVERSION, SEE HELP FOR
             THE 'JULIAN' COMMAND).  'YYDDD' MUST BE EITHER A FIVE
             DIGIT JULIAN DATE OR A ZERO.
))CREATE('YYDDD') - THE CREATION DATE IS TO BE SET TO THE SPECIFIED
             JULIAN DATE.  (FOR JULIAN DATE CONVERSION, SEE HELP FOR
             THE 'JULIAN' COMMAND).  'YYDDD' MUST BE EITHER A FIVE
             DIGIT JULIAN DATE, A ZERO, OR AN ASTERISK (TODAY'S DATE).
))REFDT('YYDDD') - THE REFERENCE DATE IS TO BE SET TO THE SPECIFIED
             JULIAN DATE.  (FOR JULIAN DATE CONVERSION, SEE HELP FOR
             THE 'JULIAN' COMMAND).  'YYDDD' MUST BE EITHER A FIVE
             DIGIT JULIAN DATE, A ZERO, OR AN ASTERISK (TODAY'S DATE).
))DSORG(DSORG) - THE DSORG IS TO BE CHANGED TO THE SPECIFIED TYPE.
))RECFM(RECFM) - THE RECFM IS TO BE CHANGED TO THE SPECIFIED TYPE.
))LRECL(LRECL) - THE LRECL IS TO BE CHANGED TO THE SPECIFIED VALUE.
))BLKSIZE(VALUE) - THE BLKSIZE IS TO BE CHANGED TO THE SPECIFIED VALUE.
))PWR      - THE PROTECTION FLAGS ARE TO BE SET FOR PWREAD, MEANING
             A PASSWORD IS REQUIRED TO READ OR WRITE.
))PWW      - THE PROTECTION FLAGS ARE TO BE SET FOR PWWRITE, MEANING
             A PASSWORD IS REQUIRED TO WRITE BUT NOT TO READ.
))NOP      - THE PROTECTION FLAGS ARE TO BE SET OFF, MEANING
             A PASSWORD IS NEVER REQUIRED.
))RACF     - THE DATA SET IS TO BE MARKED RACF PROTECTED.
))NORACF   - THE DATA SET IS TO BE MARKED NOT RACF PROTECTED.
))ZAP(OFFSET VERDATA REPDATA) - THIS KEYWORD MAY BE USED TO MODIFY
             FIELDS WITHIN THE DSCB BY SPECIFYING (IN HEX) THE
             FIELD OFFSET, THE FIELD'S CURRENT VALUE (IN HEX), AND
             THE REPLACEMENT VALUE (IN HEX).  IF THE CURRENT VALUE
             DOES NOT VERIFY CORRECTLY, THE DATA IS NOT REPLACED.
             THE REPDATA MAY BE OMITTED IF YOU JUST WANT TO VERIFY.