PDSPROGM

PDSPROGM provides the same functions for Partitioned Data Sets as the IBM utility IEHPROGM, but the control statements are simpler to code.

It is located in File #316 of the CBT tape and is part of the large suite of batch utility programs contributed by Jim Marshall of the U.S. Treasury.  The program was originally written by Bill Godfrey at the Planning Research Corporation.  

 

Installation

I have extracted the JCL to assemble PDSPROGM and the Assembler source from the CBT tape.  The resulting jobstream - pdsprogm.jcl - is contained in the archive pdsprogm.tgz [MD5: 9EE99322A3DB00E279ECF6FF145DF036].  Download the archive and extract the jobstream (WinZip on Windows/?? or tar on Linux).  Submit the jobstream to assemble and link the single load module for PDSPROGM into SYS2.LINKLIB.  If you don't have SYS2.LINKLIB defined, you will need to modify the jobstream to specify a target load library.

For those running OS/360 (MVT/MFT):  the above jobstream cannot be assembled with the Assembler F included with MVT.  Chris Cheney has modified the source to yield a version that will correctly assemble for the MVT/MFT community and made it available for distribution by me as pdsprogm-mvt.jcl.gz [MD5: 6456D7D7BA5F44257B14FA78866FFE74]. The changes he has made to the program are:

  1. commented out the card containing the BNER opcode, following it with a card containing the equivalent BCR 7, instruction;
  2. commented out the card containing DC CL16 ' &SYSDATE &SYSTIME ' and, for good measure, adding a card DC CL16' DATE TIME ' so that none of the offsets are altered;
  3. replaced uses of EQU with two parameters with the equivalent ORGs.

All of the statements changed by Chris are marked by the initials CJC.

 

PDSPROGM User's Guide (from the program source)

PDSPROGM is a utility program used for deleting or renaming one or more members of a Partitioned Data Set (PDS).

The IBM utility IEHPROGM can delete and rename members, but PDSPROGM has these advantages over it:

PDSPROGM requires the following ddnames:

Control statements are 80-character records, in which only the first 72 characters are scanned.  The last 8 positions are ignored, not listed on the log, and may be used for any purpose, such as sequence numbers.            

A control statement consists of an operation and one or more operands.  The operation may begin in column 1 or may be preceded by one or more blanks.                            

One or more operands follow the operation, separated from it and from each other by one or more blanks.  Any commas found will be treated as blanks.                       

Statements may not be continued.                                  

A statement containing all blanks will be treated as a comment and merely logged.  If the first nonblank character on a statement is an asterisk (*), the statement will be treated as a comment and merely logged.         

The DELETE statement consists of the operation DELETE (or DEL, D, SCRATCH, or SCR) followed by one operand, the name of the member to be deleted.                             

The RENAME statement contains the operation RENAME (or REN or R) followed by two operands.  The first operand is the current name of the member, and the second operand is the new name of the member.                     

The ALIAS statement contains the operation ALIAS (or ALI or A) followed by two operands.  The first operand is the name of an existing member, and the second operand is the alias to be assigned to it.                 

The OPTION statement contains the operation OPTION (or OPT or O) followed by one to three operands. The operands may be any of the following keywords, in any order: 

LOG, NOLOG, MSG, NOMSG, FLUSH, NOFLUSH.

These keywords control logging of control statements, appearance of normal messages, and action to be taken in the event of an error.  Initial setting is LOG, MSG, FLUSH.    

The FILE statement contains the operation FILE (or FIL or F) followed by one operand, which is a DDNAME.  This statement causes all subsequent RENAME, DELETE, and ALIAS activity to be directed against the PDS associated with the DDNAME specified, instead of DDNAME SYSLIB.  This allows more than one PDS to be processed in the same job step.                                             

An example of some JCL that would be used to run PDSPROGM.       

//STEP1   EXEC PGM=PDSPROGM
//SYSPRINT DD  SYSOUT=A
//SYSLIB   DD  DSN=DSN1,DISP=OLD
//MYLIB    DD  DSN=DSN2,DISP=OLD
//SYSIN    DD  *
DELETE BACKUP
DELETE CALIAS
RENAME CURRENT BACKUP
RENAME TESTED CURRENT
ALIAS CURRENT CALIAS
FILE MYLIB
DELETE BACKUP

A note of warning about load modules.  PDSPROGM can be used to delete or rename a load module but is not designed to assign an alias to one.  Only the linkage editor should be used to accomplish that properly.  Even renaming a load module with PDSPROGM (or anything other than the linkage editor) could cause problems, because if the module has an alias, the alias entry contains the original name of it's associated member.  Renaming a load module alias could cause problems if the module is later re-linked, because load module aliases are closely tied to entry-point names coded in the programs.                       

The parm field may contain the following keywords:


I hope that you have found my instructions useful.  If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:


Return to Site Home Page 


This page was last updated on January 17, 2015 .