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.