Support programs for OS/360 and successors

Last updated

This article discusses support programs included in or available for OS/360 and successors. IBM categorizes some of these programs as utilities [1] [lower-alpha 1] and others as service aids; [2] the boundaries are not always consistent or obvious. Many, but not all, of these programs match the types in utility software.

Contents

The following lists describe programs associated with OS/360 and successors. No DOS, TPF or VM utilities are included.

History/Common JCL

Many of these programs were designed by IBM users, through the group SHARE, and then modified or extended by IBM from versions originally written by a user.

These programs are usually invoked via Job Control Language (JCL). They tend to use common JCL DD identifiers (in the OS, now z/OS operating systems) for their data sets:

DDNAMEUsual function
SYSINinput file for the 'commands' for the utility. Often set to DUMMY if the default action is desired
SYSUT1input file
SYSUT2output file
SYSUT3work (spill) file for input (SYSUT1) (often not used)
SYSUT4work (spill) file for output (SYSUT2) (often not used)
SYSPRINToutput file for printed output from the utility
SYSOUToutput file for messages from the utility
SYSUDUMPoutput file for a system 'dump' if the program fails

Dataset utilities

IDCAMS

IDCAMS ("Access Method Services") generates and modifies Virtual Storage Access Method (VSAM) and Non-VSAM datasets. IDCAMS was introduced along with VSAM in OS/VS; the "Access Method" reference derives from the initial "VSAM replaces all other access methods" mindset of OS/VS. IDCAMS probably has the most functionality of all the utility programs, performing many functions, for both VSAM and non-VSAM files.

The following example illustrates the use of IDCAMS to copy a dataset to disk. The dataset has 80-byte records, and the system will choose the block size for the output:

//XXXXXXXWJOBXXXXXXX,AAAA,CLASS=G,MSGCLASS=1,NOTIFY=&SYSUID//STEP001EXECPGM=IDCAMS//SYSIN    DD *   REPRO INFILE(FILE01) OUTFILE(FILE02) /*//FILE01   DD DSN=PROD.FILE1.INPUT,disp=shr.....//FILE02   DD DSN=PROD.FILE2.OUTPUT,//DISP=(NEW,CATLG,DELETE),//UNIT=DASD,//SPACE=(TRK,(100,10),RLSE),//DCB=(RECFM=FB,BLKSIZE=0,LRECL=80)//SYSPRINT DD SYSOUT=*//SYSOUT   DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//*

In the example above, SYSIN control cards are coming from an in-stream file, but you can instead point to any sequential file or a PDS member containing control cards or a temporary data-set, if you wish. Example of using SYSIN files would be something like this:

//SYSIN    DD DSN=PROD.MYFILE.REPRO,DISP=SHR

or this:

//SYSIN    DD DSN=PROD.MYLIB.CNTLLIB(REPRO),//DISP=SHR

IEBCOMPR

IEBCOMPR compares records in sequential or partitioned data sets.

The IEBCOMPR utility is used to compare two sequential or partitioned datasets. This data set comparison is performed at the logical record level. Therefore, IEBCOMPR is commonly used to verify that a backup copy of a data set is correct (exact match to the original).

During processing, IEBCOMPR compares each record from each data set, one by one. If the records are unequal, IEBCOMPR lists the following information in the SYSOUT:

When comparing sequential data sets, IEBCOMPR considers the data sets equal if the following conditions are met:

  • The data sets contain the same number of records.
  • The corresponding records and keys are identical.

For partitioned data sets, IEBCOMPR considers the data sets equal if the following conditions are met:

  • The directory entries for the two partitioned data sets match - that is, the names are the same, and the number of entries are equal.
  • The corresponding members contain the same number of records.
  • The corresponding records and keys are identical.

If ten unequal comparisons are encountered during processing, IECOMPR terminates with the appropriate message.

//XXXXXXXWJOBXXXXXXX,AAAA.A.A,CLASS=G,MSGCLASS=1,NOTIFY=XXXXX//STEP01EXECPGM=IEBCOMPR,ACCT=PJ00000000//INCLUDEMEMBER=@BATCHS//*SYSIN    DD DUMMY//SYSIN DD *   COMPARE TYPORG=PO/*//SYSUT1   DD DSN=XXXXXXX.OLDFILE,UNIT=DASD,DISP=SHR//SYSUT2   DD DSN=XXXXXXX.NEWFILE,UNIT=DASD,DISP=SHR//SYSUT#   DD

Note: IEBCOMPR is not a very flexible or user-friendly compare program. It can't restrict the comparison to only certain columns, it can't ignore differences in white space, it doesn't tell you where in the record the difference occurs, and it halts after 10 differences. On the other hand, it is fast, and it is present on all IBM mainframes. So it is very useful when an exact match is expected, such as comparing load modules that have not been reblocked, or checking that a copy worked properly. For comparisons of programs or reports, the ISPF SuperC (ISRSUPC) compare program is often used instead.

IEBCOPY

IEBCOPY copies, compresses and merges partitioned data sets. It can also select or exclude specified members during the copy operation, and rename or replace members.

Some of the tasks that IEBCOPY can perform include the following:

For the IEBCOPY utility, the required job control statements for a copy are as follows:

//stepnameEXECPGM=IEBCOPY//SYSPRINT DD SYSOUT=class//MYDD1    DD DSN=xxxx.ppp.psps,DISP=SHR//MYDD2    DD DSN=xxxx.ppp.pssp,DISP=SHR//SYSIN    DD *    COPY INDD=MYDD1,OUTDD=MYDD2                           SELECT MEMBER=(MEM1,MEM2,MEM3)/ EXCLUDE MEMBER=(SF,DF,SA)

The MYDD1 and MYDD2 DD statements are names chosen by the user for the partitioned input and output data sets, respectively; The defaults are SYSUT1 and SYSUT2. You can use any valid DDNAME for these two DD statements. These DDNAMEs are specified in the utility control statements to tell IEBCOPY the name of the input and output data sets. You only need one DD statement for a PDS to be compressed.

IEBDG

IEBDG ('Data Generator') creates test datasets consisting of patterned data. Control statements define the fields of the records to be created, including position, length, format, and initialization to be performed. IEBDG can use an existing dataset as input and change fields as specified in the control statements, for example replacing a name field by random alphabetic text. The contents of each field may be varied for each record, for example by rotating the characters in an alphanumeric field left or right for each subsequent record.

Example:

//XXXXXXXWJOBXXXXXXX,AAAA,CLASS=G,MSGCLASS=1,NOTIFY=&SYSUID//**********************************************************************//* CREATION OF A DATASET To BE USED LATER ON//**********************************************************************    //CRSTEPEXECPGM=IEFBR14//DDCREA   DD DSN=&SYSUID..MVSUT.SEQOUT,DISP=(NEW,CATLG)//**********************************************************************//* CREATION OF THE TESTDATA//**********************************************************************              //STEP1EXECPGM=IEBDG//SYSPRINT DD SYSOUT=*//SEQOUT   DD DSN=&SYSUID..MVSUT.SEQOUT,DISP=OLD//SYSIN    DD DATA      DSD OUTPUT=(SEQOUT)                                                     FD  NAME=FIELD1,LENGTH=30,STARTLOC=1,FORMAT=AL,ACTION=TL                FD  NAME=FIELD2,LENGTH=30,STARTLOC=31,FORMAT=AL,ACTION=TR               FD  NAME=FIELD3,LENGTH=10,STARTLOC=71,PICTURE=10,                X                  P'1234567890',INDEX=1                                       CREATE QUANTITY=500,NAME=(FIELD1,FIELD2,FIELD3),FILL=X'FF'              END                                                               /*//**********************************************************************//* PRINTING THE TEST DATA TO SYSOUT//**********************************************************************    //STEP2EXECPGM=IEBGENER//SYSPRINT DD SYSOUT=*//SYSUT1   DD DSN=*.STEP1.SEQOUT,DISP=SHR//SYSIN    DD DUMMY//SYSUT2   DD SYSOUT=*//**********************************************************************//* DELETE THE CREATED DATASET, EVEN IF PREVIOUS STEPS ABENDED//**********************************************************************                                           //DLSTEPEXECPGM=IEFBR14,COND=EVEN//DDDEL    DD DSN=&SYSUID..MVSUT.SEQOUT,DISP=(OLD,DELETE,DELETE)//

IEBEDIT

IEBEDIT selectively copies portions of JCL.

An example of an IEBEDIT program:

//IEBEDITJJOBACCT,'',CLASS=P,MSGCLASS=T,MSGLEVEL=(1,1),NOTIFY=&SYSUID//STEP0001EXECPGM=IEBEDIT//SYSPRINT DD SYSOUT=*//SYSUT1   DD DSN=xxxxx.yyyyy.zzzzz,DISP=SHR//SYSUT2   DD SYSOUT=(*,INTRDR)//SYSIN    DD *    EDIT TYPE=INCLUDE,STEPNAME=(STEP10,STEP5,STEP15)/*//

In this example, data set xxxxx.yyyyy.zzzzz should contain job(s) (which should include steps named STEP5, STEP10, and STEP15). This IEBEDIT routine copies the selected steps of the job onto the SYSUT2 output file (in this example, the internal reader).

The syntax of the EDIT statement is:

[label] EDIT [START=jobname] [,TYPE={POSITION|INCLUDE|EXCLUDE}] [,STEPNAME=(namelist)] [,NOPRINT]

START=jobname specifies the name of the input job to which the EDIT statement applies. Each EDIT statement must apply to a separate job. If START is specified without TYPE and STEPNAME, the JOB statement and all job steps for the specified job are included in the output.

Default: If START is omitted and only one EDIT statement is provided, the first job encountered in the input data set is processed. If START is omitted from an EDIT statement other than the first statement, processing continues with the next JOB statement found in the input data set.

TYPE={POSITION|INCLUDE|EXCLUDE} specifies the contents of the output data set. These values can be coded:

POSITION specifies that the output is to consist of a JOB statement, the job step specified in the STEPNAME parameter, and all steps that follow that job step. All job steps preceding the specified step are omitted from the operation. POSITION is the default.

INCLUDE specifies that the output data set is to contain a JOB statement and all job steps specified in the STEPNAME parameter.

EXCLUDE specifies that the output data set is to contain a JOB statement and all job steps belonging to the job except those steps specified in the STEPNAME parameter.

STEPNAME=(namelist) specifies the names of the job steps that you want to process.

namelist can be a single job step name, a list of step names separated by commas, or a sequential range of steps separated by a hyphen (for example, STEPA-STEPE). Any combination of these may be used in one namelist. If more than one step name is specified, the entire namelist must be enclosed in parentheses.

When coded with TYPE=POSITION, STEPNAME specifies the first job step to be placed in the output data set. Job steps preceding this step are not copied to the output data set.

When coded with TYPE=INCLUDE or TYPE=EXCLUDE, STEPNAME specifies the names of job steps that are to be included in or excluded from the operation. For example, STEPNAME=(STEPA,STEPF-STEPL,STEPZ) indicates that job steps STEPA, STEPF through STEPL, and STEPZ are to be included in or excluded from the operation.

If STEPNAME is omitted, the entire input job whose name is specified on the EDIT statement is copied. If no job name is specified, the first job encountered is processed.

NOPRINT specifies that the message data set is not to include a listing of the output data set.

Default: The resultant output is listed in the message data set.

See here for more info:

IEBGENER

IEBGENER copies records from a sequential dataset, or creates a partitioned dataset.

Some of the tasks that IEBGENER can perform include the following:

An example of an IEBGENER program to copy one dataset to another:

//IEBGENERJOBACCT,'DATA COPY',MSGCLASS=J,CLASS=A//STEP010EXECPGM=IEBGENER//SYSUT1   DD DSN=xxxxx.yyyyy.zzzzz,DISP=SHR//SYSUT2   DD DSN=aaaaa.bbbbb.ccccc,DISP=(,CATLG),//UNIT=SYSDA,SPACE=(TRK,(5,5),RLSE),//DCB=(RECFM=FB,LRECL=1440)//SYSPRINT DD SYSOUT=*//SYSIN    DD DUMMY

For straight copy tasks, the sort program can often do these faster than IEBGENER. Thus many mainframe shops make use of an option that automatically routes such tasks to the sort ICEGENER program instead of IEBGENER.

On some systems it is possible to send email from a batch job by directing the output to the "SMTP" external writer. On such systems, the technique is as follows:

//IEBGENERJOBACCT,'DATA COPY',MSGCLASS=J,CLASS=A//NORMRCEXECPGM=IEBGENER//SYSPRINT DD SYSOUT=*//SYSUT1   DD *,LRECL=80HELO <SYSTEMID>MAIL FROM:<USERID@SYSTEMID>RCPT TO:<USERID@SYSTEMID>DATAFrom: <USERID@SYSTEMID>To: <USERID@SYSTEMID>Subject: Test MailTEST MAIL FROM MAINFRAME.QUIT/*//SYSUT2   DD SYSOUT=(B,SMTP),LRECL=80//SYSIN    DD DUMMY

It is also possible to attach files while sending the email from Mainframe.

IEBIMAGE

IEBIMAGE manipulates several types of definitions (AKA images) for the IBM 3211 printer, IBM 3800 laser printing subsystem and the IBM 4248 printer. Common uses are for forms control buffers (FCBs), character arrangement tables, character definitions and images of forms to be printed on the output along with the text, for company logos to be printed on the page, or just to print 'graybar' pages (alternating gray & white horizontal backgrounds, to match the previous greenbar paper). With this utility, many different forms or logos could be stored as images, and printed when needed, all using the same standard blank paper, thus eliminating the need to stock many preprinted forms, and the need for operators to stop the printer and change paper.

IEBISAM

IEBISAM unloads, loads, copies and prints ISAM datasets.

Extracted from IBM manual SC26-7414-08 z/OS DFSMSdfp Utilities: The IEBISAM program is no longer distributed. Starting in z/OS V1R7, ISAM data sets can no longer be processed (created, opened, copied or dumped). ISAM data sets that are still in use must be converted to VSAM key-sequenced data sets.

Prior to z/OS V1R7, you could use access method services to allocate a VSAM key-sequenced data set and copy an ISAM data set into it.

IEBPTPCH

IEBPTPCH ("PrinT and PunCH") prints or punches records from a sequential or partitioned dataset.

Some of the tasks that IEBPTPCH can perform include the following:

//IEBPTPCHJOB//EXEC PGM=IEBPTPCH//SYSIN    DD * PRINT     MAXFLDS=2 TITLE     ITEM=('Name',22),           ITEM=('GPA',50) TITLE     ITEM=(' ',1) RECORD    FIELD=(25,1,,22),           FIELD=(4,51,,50)/*//SYSPRINT DD SYSOUT=*//SYSUT1   DD *Person 1                 307 C Meshel Hall        3.89Second person            123 Williamson Hall      2.483rd person               321 Maag Library         1.52/*//SYSUT2   DD SYSOUT=*//

Empty dataset check: If dataset to be checked is empty then RC=4 else 0.

//IEBPTPCHJOB//EXEC PGM=IEBPTPCH//SYSUT1   DD DSN=<filename>,DISP=SHR//SYSUT2   DD DUMMY,//DCB=(BLKSIZE=<blocksize>,RECFM=FA)        //SYSIN    DD * PRINT TYPORG=PS /*//SYSPRINT DD SYSOUT=*//

IEBTCRIN

Read records from a 2495 Tape Cartridge Reader.

IEBUPDAT

Changes records in a sequential dataset or in a member of a partitioned dataset, replaced by, but not compatible with, IEBUPDTE.

IEBUPDTE

IEBUPDTE ("UPDaTE") incorporates changes to sequential or partitioned datasets. The UNIX patch utility is a similar program, but uses different input format markers (e..g, "./ INSERT ..." in MVS becomes "@@..." in Unix Patch).

Some programmers pronounce it "I.E.B. up-ditty".

The IEBUPDTE utility is used to maintain source libraries. Some of the functions that IEBUPDTE can perform include the following:

IEBUPDTE is commonly used to distribute source libraries from tape to DASD.

IEBUPDTE uses the same job control statements required by most IEB-type utilities. The only exceptions are as follow:

The job control used by IEUPDTE are as follows:

//stepnameEXECPGM=IEUPDTE,PARM=NEW//SYSPRINT DD SYSOUT=class//SYSUT1   DD ...//SYSUT2   DD ...//SYSIN    DD ...

Scheduler utilities

IEFBR14

IEFBR14 is a dummy program, normally inserted in JCL when the only desired action is allocation or deletion of datasets.

An example of an IEFBR14 step:

//IEFBR14JOBACCT,'DELETE DATASET'//STEP01EXECPGM=IEFBR14//DELDD    DD DSN=xxxxx.yyyyy.zzzzz,//DISP=(MOD,DELETE,DELETE),UNIT=DASD

The calling sequence for OS/360 contained the return address in Register 14. A branch to Register 14 would thus immediately exit the program. However, before and after executing this program, the operating system would allocate & deallocate datasets as specified in the DD statements, so it is commonly used as a quick way to set up or remove datasets.

It consisted initially as a single instruction a "Branch to Register" 14. The mnemonic used in the IBM Assembler was BR and hence the name: IEF BR 14. IEF is the "prefix" of OS/360's "job management" subsystem.

This single instruction program had an error in it — it didn't set the return code. Hence a second instruction had to be added to clear the return code so that it would exit with the correct status.

There was an additional error reported and fixed by IBM on this now two instruction program. This error was due to the IEFBR14 program not being link-edited as reenterable (simultaneously usable by more than one caller).

Some hackers have taken IEFBR14 and changed the BR 14 instruction to BR 15, thereby creating "the shortest loop in the world", as register 15 contains the address of the IEFBR14 module itself, and a BR 15 instruction would simply re-invoke the module, forever.

System utilities

These utilities are normally used by systems programmers in maintaining the operation of the system, rather than by programmers in doing application work on the system.

ICKDSF

ICKDSF ("Device Support Facility") installs, initializes and maintains DASD, either under an operating system, or standalone.

IEHATLAS

Assign alternate tracks to defective tracks.

IEHDASDR

IEHDASDR [1] :161–187 can performs several operations for direct access storage devices [lower-alpha 2] (DASD)

IBM eventually stopped adding support for new device types to IEHDASDR and directed customers to the free DSF for initializing volumes and to the chargeable DASDR (5740-UT1) and Data Facility/Data Set Services (5740-UT3, DF/DSS) for dump/restore.

IBM removed IEHDASDR in MVS/XA. [3]

IEHINITT

IEHINITT ("INITialize Tape") initializes tapes by writing tape labels. Multiple tapes may be labeled in one run of the utility. IBM standard or ASCII labels may be written.

An example of an IEHINITT program:

//IEHINITTJOBACCT,'LABEL TAPES',MSGCLASS=J,CLASS=A//STEP0001EXECPGM=IEHINITT,REGION=8M//SYSPRINT DD SYSOUT=A//LABEL    DD DCB=DEN=2,UNIT=(3490,1,DEFER)//SYSIN    DD *LABEL INITT SER=123450,NUMBTAPE=3 /*

This example will label 3 tapes on a 3490 magnetic tape unit. Each tape will receive an IBM standard label. The VOLSER will be incremented by one for each tape labeled. Each tape will be rewound and unloaded after being labeled.

IEHIOSUP

IEHIOSUP updates relative track addresses (TTR) links for type IV Supervisor Call (SVC) routines in SYS1.SVCLIB. IEHIOSUP is no longer supported in OS/VS2 and later. [4]

OPEN, CLOSE, and EOV functions are performed by a series of SVC modules that execute sequentially. Some modules contain tables used by the XCTL macro to link to the next in the series. For performance reasons, to avoid a directory search each time, these tables contain the disk addresses of the modules rather than the names. Updates to SYS1.SVCLIB may cause these addresses to change, so IEHIOSUP needs to be run to install the correct addresses. [5]

This is an example of the JCL required to run IEHIOSUP. [1]

//IHEIOSUPJOB//EXEC PGM=IEHIOSUP//SYSUT1 DD DSNAME=SYS1.SVCLIB~DISP=OLD,UNIT=2311,//VOLUME=SER=111111//SYSPRINT DD SYSOUT=A//

IEHLIST

IEHLIST is a utility used to list entries in a Partitioned Dataset (PDS) directory or to list the contents of a Volume Table of Contents (VTOC).

The IEHLIST utility is used to list the entries contained in any one of the following:

An example of an IEHLIST program:

//IEHLISTJOBACCT,'LIST PDS',MSGCLASS=J,CLASS=A//STEP0001EXECPGM=IEHLIST,REGION=8M//SYSPRINT DD SYSOUT=A//PDS1     DD DSN=xxxx.yyyy.zzzz,DISP=OLD//SYSIN    DD *  LISTPDS DSNAME=xxxx.yyyy.zzzz,FORMAT/*

This job will produce a formatted listing of the PDS directory of the PDS named xxxx.yyyy.zzzz.

An example of an IEHLIST program to list a VTOC is very similar:

//IEHLISTJOBACCT,'LIST VTOC',MSGCLASS=J,CLASS=A//STEP0001EXECPGM=IEHLIST,REGION=8M//SYSPRINT DD SYSOUT=A//VOL1     DD VOL=SER=vvvvvv,DISP=OLD//SYSIN    DD *  LISTVTOC VOL=SER=vvvvvv,FORMAT/*

IEHMOVE

IEHMOVE moves or copies collections of data. However, DFSMS (System Managed Storage) environments are now common, and IBM does not recommend using the IEHMOVE utility in those. A move differs from a copy in that following a move the original data set is deleted, or scratched. Some of the tasks that IEHMOVE can perform include the following:

On the surface, IEHMOVE may seen redundant to the IEBGENER and IEBCOPY utilities. However, IEHMOVE is more powerful. The main advantage of using IEHMOVE is that you do not need to specify space or DCB information for the new data sets. This is because IEHMOVE allocates this information based on the existing data sets.

Another advantage of IEHMOVE is that you can copy or move groups of data sets as well as entire volumes of data. Because of the ease in moving groups of data sets or volumes, the IEHMOVE utility is generally favored by systems programmers.

A sample IEHMOVE job:

//stepnameEXECPGM=IEHMOVE,PARM='LINECNT=xx,POWER=n'//SYSPRINT DD SYSOUT=class//SYSUT1   DD UNIT=aaaa,VOL=SER=bbbbbb,DISP=OLD//anyname1 DD UNIT=cccc,VOL=SER=dddddd,DISP=OLD//anyname2 DD UNIT=eeee,VOL=SER=ffffff,DISP=OLD//SYSIN    DD ...

The DD statements for IEHMOVE, other than SYSPRINT and SYSIN, refer to DASD or magnetic tape volumes instead of individual data sets. However, referencing volumes can pose a problem, since specifying DISP=OLD gains exclusive access to a volume. Therefore, while your IEHMOVE job runs, that entire volume (and all datasets on it) is unavailable to other users. This is acceptable for private volumes, such as tape or mountable DASD volumes, but unacceptable public volumes.

The SYSUT1 DD statement specifies a DASD volume where three work data set required by IEHMOVE are allocated. You must specify unit and volume information for this DD statement.

IEHMOVE was one of the first systems to be developed in PL/S.

In this example, three sequential data sets (SEQSET1, SEQSET2, and SEQSET3) are moved from one disk volume to three separate disk volumes. Each of the three receiving volumes is mounted when it is required by IEHMOVE. The source data sets are not cataloged. Space is allocated by IEHMOVE.

//MOVEDSJOB...//STEP1EXECPGM=IEHMOVE//SYSPRINT DD  SYSOUT=A//SYSUT1   DD  UNIT=disk,VOLUME=SER=333333,DISP=OLD//DD1      DD  UNIT=(disk,,DEFER),DISP=OLD,//VOLUME=(PRIVATE,,SER=(222222))//DD2      DD  UNIT=(disk,,DEFER),DISP=OLD,//VOLUME=(PRIVATE,,SER=(222333))//DD3      DD  UNIT=(disk,,DEFER),DISP=OLD,//VOLUME=(PRIVATE,,SER=(222444))//DD4      DD  VOLUME=(PRIVATE,RETAIN,SER=(444444)),//UNIT=disk,DISP=OLD//SYSIN    DD  *     MOVE   DSNAME=SEQSET1,TO=disk=222222,FROM=disk=444444     MOVE   DSNAME=SEQSET2,TO=disk=222333,FROM=disk=444444     MOVE   DSNAME=SEQSET3,TO=disk=222444,FROM=disk=444444/*

IEHPROGM

IEHPROGM builds and maintains system control data. It is also used for renaming and scratching (deleting) a data set.

Some of the tasks that IEHPROGM can perform include the following:

For cataloging:

//SYSIN DD *   CATLG DSNNAME=data-set-name,   VOL=device-name=volume-number/*//

IFHSTATR

Select and format SMF records for tape errors.

Independent Utilities

These programs do not run under the control of an operating system

IBCDASDI

Format direct access volumes and assign alternate tracks.

IBCDMPRS

Dump and restore direct access volumes.

IBCRCVRP

Assign alternate tracks, recover and replace data.

ICAPRTBL

Load Forms Control Buffer (FCB) and Universal Character Set (UCS) buffer on printer.

Service Aids

These are utility program that IBM documents in service aids or diagnosis [6] manuals. The original OS/360 Service aids had names beginning with IFC and IM*, but IBM changed the naming convention to HM* for OS/VS1 and to AM* for OS/VS2. IBM did not change the IFC convention.

IFCDIP00

Initializes the SYS1.LOGREC data set.

IFCEREP0

Summarizes and prints records from the SYS1.LOGREC error recording data set.

GTF (Generalized Trace Facility)

Traces selected system events such as SVC and I/O interruptions.

IMAPTFLE

Generates JCL needed to apply to a PTF and/or applies the PTF. The functions of this program have been subsumed by SMP.

IMASPZAP

Verifies and/or replaces instructions and/or data in a load module, program object, or disk file.

IMBLIST

Formats and prints object modules, load modules, program objects and CSECT identification records.

IMBMDMAP

Maps load modules. The functions of this program have been subsumed by IMBLIST.

IMCJQDMP

Stand-alone program to format and print the system job queue. Not applicable to MVS.

IMCOSJQD

Format and print the system job queue. Not applicable to MVS.

IMDPRDMP

Formats and prints core dumps, TSO swap data set, and GTF trace data.

IMDSADMP

Stand-alone program to produce a high-speed or low-speed dump of main storage.

Miscellaneous supporting programs

SORT

The Sort/Merge utility is a program which sorts records in a file into a specified order, or merge pre-sorted files. It is very frequently used; often the most commonly used application program in a mainframe shop. Modern sort/merge programs also can select or omit certain records, summarize records, remove duplicates, reformat records, and produce simple reports. Sort/merge is important enough that there are multiple companies each selling their own sort/merge package for IBM mainframes.

IBM's original OS/360 sort/merge program, 360S-SM-023, program name IERRCO00 (alias SORT), supported only IBM's first-generation direct-access storage devices (DASD) [lower-alpha 4] and tapes (2400). Support for second-generation disk drives was provided by IBM program products such as 5734-SM1 and the later 5740-SM1 (DFSORT, alias ICEMAN, also SORT).

SORT is frequently executed as a stand-alone program, where it normally reads input from a file identified by DD SORTIN and writes sorted output to a file identified by DD SORTOUT. It is also often called from another application, via the COBOL SORT verb or calls to PL/I PLISRTx routines, where it may use either SORTIN or SORTOUT files or be passed records to be sorted by the caller and/or pass sorted records back to the caller one at a time.

The operation of SORT is directed by control statements, which are largely compatible among various IBM and third-party sort programs. The SORT or MERGE statement defines the sort keys— the fields on which the data is to be sorted or merged. This statement identifies the position, length, and data type of each key. The RECORD statement describes the format and length of the records in the input file. Other statements allow the user to specify which records should be included or excluded from the sort and specify other transformations to be performed on the data.

Keys can be any combination of EBCDIC or ASCII character data, zoned or packed-decimal, signed or unsigned fixed-point binary, or hexadecimal floating-point. Keys can be located anywhere in the record and do not have to be contiguous. Sorting can be specified on any combination of ascending and descending sequence by key. [7]

The OS/360 sort program, IERRCO00, operates by dividing the input data into sections, sorting each section in main memory, and writing the sorted section to intermediate datasets on either direct-access storage devices (DASD) or magnetic tape. Final merge phases then merge the sections to produce the sorted output. SORT uses one of a number of techniques for distributing the sections among secondary storage devices. Usually SORT can choose the optimal technique, but this can be overridden by the user. [8] SORT has three techniques that can be used if the intermediate storage is tape, and two if disk. [9]

The tape techniques are:

The disk techniques are:

Linkers

OS/360 had only the Linkage editor, available in several configurations. DFSMSdfp added the Binder as an alternatives for load modules, and as the only option for program objects.

Linkage Editor

The Linkage editor creates and replaces load modules in a partitioned data set from a combination of control cards, object modules other load modules. It can rename or replace a control section (CSECT) and perform several other miscellaneous functions. It was originally available in several configurations depending on storage requirement, but the E level Linkage Editor is no longer available and the F level Linkage Editor is now known simply as the Linkage Editor. In z/OS the Linkage Editor is only present for compatibility.

Binder

The binder, added in DFSMS, performs the same functions as the Linkage Editor. In addition, it supports a new format, the program object, which is the functional equivalent of a load module in Partitioned Data Set Extended (PDSE), with many additional capabilities.

Assemblers

One assembler was usually standard, because it was required for system generation (SYSGEN) and customization.

IETASM

Assembler (E) was intended for OS/360 running in very small machines.

IEUASM

Assembler (F) was intended for normal OS/360 installations.

IFOX00

Assembler (XF) was the system assembler for OS/VS1 and OS/VS2, replacing Assembler (E) and (F), although it was not fully compatible with them. IBM soon made Assembler (XF) the system assembler for DOS and VM as well.

IEV90

Assembler (H) and Assembler (H) Version 2 are program product assemblers that are generally faster than Assemblers E, F, and XF, although not fully compatible with any of them.

ASMA90

IBM High Level Assembler (HLASM) is essentially a new version of Assembler (H) Version 2 and is the only assembler that IBM supports on z/OS and z/VM. It replaces all of the older assemblers, although it is not fully compatible with them.

Compilers

Each programming language used in a computer shop will have one or more associated compilers that translate a source program into a machine-language object module. Then the object module from the compiler must be processed by the linkage editor, IEWL, to create an executable load module.

IGYCRCTL is a common example of a compiler; it is the compiler for the current IBM Enterprise COBOL for z/OS product. (There have been several previous IBM COBOL compilers over the years, with different names, although users might provide an alias COBOL for the current version.) There are many other compilers for various other programming languages.

Compilers available from IBM included ALGOL, COBOL, FORTRAN, PL/I, and RPG.

System Modification Program (SMP)

System Modification Program (SMP) is the vehicle for installing service on OS/360 and successors, replacing, e.g., stand-alone assembly, link edit and IMAPTFLE jobs. Originally an optional facility, it is mandatory for MVS/SP and later, and the program product version, SMP/E, is included in the more recent systems, e.g., z/OS.

Notes

  1. subdivided into Data Set Utilities, System Utilities and Independent Utilities.
  2. Initially supported DASD were disks, drums and data cells; currently they are disks and SSDs simulating disks.
  3. The PASSWORD dataset is obsolete and has been supplanted by security subsystems working through the System authorization facility (SAF), e.g., ACF2, RACF.
  4. The manual lists capacity information for 2311 and 2314 disks and 2301 drum, but does not state that those are the only DASD supported.

Related Research Articles

<span class="mw-page-title-main">MVS</span> Operating system for IBM mainframes

Multiple Virtual Storage, more commonly called MVS, is the most commonly used operating system on the System/370, System/390 and IBM Z IBM mainframe computers. IBM developed MVS, along with OS/VS1 and SVS, as a successor to OS/360. It is unrelated to IBM's other mainframe operating system lines, e.g., VSE, VM, TPF.

z/OS 64-bit operating system for IBM mainframes

z/OS is a 64-bit operating system for IBM z/Architecture mainframes, introduced by IBM in October 2000. It derives from and is the successor to OS/390, which in turn was preceded by a string of MVS versions. Like OS/390, z/OS combines a number of formerly separate, related products, some of which are still optional. z/OS has the attributes of modern operating systems but also retains much of the older functionality that originated in the 1960s and is still in regular use—z/OS is designed for backward compatibility.

A direct-access storage device (DASD) is a secondary storage device in which "each physical record has a discrete location and a unique address". The term was coined by IBM to describe devices that allowed random access to data, the main examples being drum memory and hard disk drives. Later, optical disc drives and flash memory units are also classified as DASD.

Virtual Storage Access Method (VSAM) is an IBM direct-access storage device (DASD) file storage access method, first used in the OS/VS1, OS/VS2 Release 1 (SVS) and Release 2 (MVS) operating systems, later used throughout the Multiple Virtual Storage (MVS) architecture and now in z/OS. Originally a record-oriented filesystem, VSAM comprises four data set organizations: key-sequenced (KSDS), relative record (RRDS), entry-sequenced (ESDS) and linear (LDS). The KSDS, RRDS and ESDS organizations contain records, while the LDS organization contains a sequence of pages with no intrinsic record structure, for use as a memory-mapped file.

Job Control Language (JCL) is a scripting language used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem. The purpose of JCL is to say which programs to run, using which files or devices for input or output, and at times to also indicate under what conditions to skip a step. Parameters in the JCL can also provide accounting information for tracking the resources used by a job as well as which machine the job should run on.

Disk Operating System/360, also DOS/360, or simply DOS, is the discontinued first member of a sequence of operating systems for IBM System/360, System/370 and later mainframes. It was announced by IBM on the last day of 1964, and it was first delivered in June 1966. In its time, DOS/360 was the most widely used operating system in the world.

In the context of IBM mainframe computers in the S/360 line, a data set or dataset is a computer file having a record organization. Use of this term began with, e.g., DOS/360, OS/360, and is still used by their successors, including the current z/OS. Documentation for these systems historically preferred this term rather than file.

IEFBR14 is an IBM mainframe utility program. It runs in all IBM mainframe environments derived from OS/360, including z/OS. It is a placeholder that returns the exit status zero, similar to the true command on UNIX-like systems.

In the IBM System/360 storage architecture, the Volume Table of Contents (VTOC) is a data structure that provides a way of locating the data sets that reside on a particular DASD volume. With the exception of the IBM Z compatible disk layout in Linux on Z, it is the functional equivalent of the MS/PC DOS File Allocation Table (FAT), the NTFS Master File Table (MFT), and an inode table in a file system for a Unix-like system. The VTOC is not used to contain any IPLTEXT and does not have any role in the IPL process, therefore does not have any data used by or functionally equivalent to the MBR. It lists the names of each data set on the volume as well as size, location, and permissions. Additionally, it contains an entry for every area of contiguous free space on the volume. The third record on the first track of the first cylinder of any DASD volume is known as the volume label and must contain a pointer to the location of the VTOC. The location of the VTOC may be specified when the volume is initialized. For performance reasons it may be located as close to the center of the volume as possible, since it is referenced frequently. A VTOC is added to a DASD volume when it is initialized using the Device Support Facilities program, ICKDSF, in current systems.

The IBM Basic assembly language and successors is a series of assembly languages and assemblers made for the IBM System/360 mainframe system and its successors through the IBM Z.

The Sort/Merge utility is a mainframe program to sort records in a file into a specified order, merge pre-sorted files into a sorted file, or copy selected records. Internally, these utilities use one or more of the standard sorting algorithms, often with proprietary fine-tuned code.

An access method is a function of a mainframe operating system that enables access to data on disk, tape or other external devices. Access methods were present in several mainframe operating systems since the late 1950s, under a variety of names; the name access method was introduced in 1963 in the IBM OS/360 operating system. Access methods provide an application programming interface (API) for programmers to transfer data to or from device, and could be compared to device drivers in non-mainframe operating systems, but typically provide a greater level of functionality.

In IBM mainframe operating systems, basic partitioned access method (BPAM) is an access method for libraries, called partitioned datasets (PDSes) in IBM terminology. BPAM is used in OS/360, OS/VS2, MVS, z/OS, and others.

In IBM mainframe operating systems, such as OS/360, MVS, z/OS, a Data Control Block (DCB) is a description of a dataset in a program. A DCB is coded in Assembler programs using the DCB macro instruction. High level language programmers use library routines containing DCBs.

In IBM mainframe operating systems, Execute Channel Program (EXCP) is a macro generating a system call, implemented as a Supervisor Call instruction, for low-level device access, where the programmer is responsible for providing a channel program—a list of device-specific commands (CCWs)—to be executed by I/O channels, control units and devices. EXCP for OS/360 and successors is more specifically described in the OS System Programmer's Guide.; EXCP for DOS/360 and successors is more specifically described in DOS Supervisor and I/O Macros. This article mostly reflects OS/360 through z/OS; some details are different for TOS/360 and DOS/360 through z/VSE.

<span class="mw-page-title-main">OS/360 and successors</span> Operating system for IBM S/360 and later mainframes

OS/360, officially known as IBM System/360 Operating System, is a discontinued batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was influenced by the earlier IBSYS/IBJOB and Input/Output Control System (IOCS) packages for the IBM 7090/7094 and even more so by the PR155 Operating System for the IBM 1410/7010 processors. It was one of the earliest operating systems to require the computer hardware to include at least one direct access storage device.

<span class="mw-page-title-main">System Generation (OS)</span> Process for configuring some IBM operating systems

System Generation (SysGen) is a two-stage process for installing or updating OS/360, OS/VS1, OS/VS2 (SVS), OS/VS2 (MVS) and chargeable systems derived from them. There are similar processes for, e.g., DOS/360, which this article does not cover. Also, some of the details have changed between releases of OS/360 and many details do not carry over to later systems.

<span class="mw-page-title-main">OS/VS2 (SVS)</span> Operating system

Single Virtual Storage (SVS) refers to Release 1 of Operating System/Virtual Storage 2 (OS/VS2); it is the successor system to the MVT option of Operating System/360. OS/VS2 (SVS) was a stopgap measure pending the availability of MVS, although IBM provided support and enhancements to SVS long after shipping MVS.

TERSE is an IBM archive file format that supports lossless compression. A TERSE file may contain a sequential data set, a partitioned data set (PDS), partitioned data set extended (PDSE), or a large format dataset (DSNTYPE=LARGE). Any record format (RECFM) is allowed as long as the record length is less than 32 K. Records may contain printer control characters.

Data Facility Storage Management Subsystem (DFSMS) is a central component of IBM's flagship operating system z/OS. It includes access methods, utilities and program management functions. Data Facility Storage Management Subsystem is also a collective name for a collection of several products, all but two of which are included in the DFSMS/MVS product.

References

  1. 1 2 3 IBM System/360 Operating System: Utilities (PDF) (Twelfth ed.), IBM Corporation, June 1970, GC28-6586-11
    OS Utilities - Program Numbers 360S-UT-506 360S-UT-507 (PDF) (Sixteenth ed.), IBM Corporation, April 1973, GC28-6586-15
  2. IBM System/360 Operating System: Service Aids OS Release 21 (PDF) (Third ed.), IBM Corporation, March 1972, GC28-6719-2
  3. MVS/Extended Architecture Conversion Notebook (PDF) (Third ed.), May 1984, p. 1-1, GC28-1143-2
  4. OS/VS2 Planning Guide (PDF). IBM Corporatopn. July 1972. p. 79. Retrieved January 5, 2024.
  5. IBM System/360 Operating System Utilities Program Logic Manual (PDF). IBM Corporation. November 1968. pp. 47–49. Retrieved January 4, 2024.
  6. z/OS MVS Diagnosis: Tools and Service Aids Version 2 Release 3 (PDF), IBM Corporation, July 20, 2018, GA32-0905-30
  7. IBM Corporation. DFSORT Application Programming Guide (PDF). Retrieved March 28, 2017.
  8. OS Sort/Merge Program Program Number 360S-SM-023 OS~Release 21 (PDF) (Ninth ed.). IBM Corporation. February 1973. p. 17. GC28-6543-8. If you find that for a particular sort/merge application, the sort/merge program does not choose the most efficient technique, you can request sort to use another technique.
  9. IBM Corporation (1973). OS Sort/Merge Program Program Number 360S-SM-023 OS~Release 21 (PDF). Retrieved April 2, 2018.

See also