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

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

Naming convention

IBM uses a naming convention for modules where the first three letters identify the "component" to which a module belongs.

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 <code>patch</code> utility is a similar program, but uses different input format markers (e.g., 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:

  • Creating and updating libraries
  • Modifying sequential data sets or PDS members
  • Changing the organization of a data set from sequential to partitioned or from partitioned to sequential.

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:

  • IEBUPDTE accepts a parameter coded on the statement, or . indicates that the utility control statements and the input data are contained in the <code> DD</code> statement, so no <code> DD</code> statement is needed. indicates that the statement contains only utility control statements, without input data. Therefore, the statement is required to define the input data set.
  • IEBUPDTE reads the input data set from either the statement or from the statement.

The job control used by IEUPDTE are as follows:

<syntaxhighlight lang="jcl">

//stepname EXEC PGM=IEUPDTE,PARM=NEW

//SYSPRINT DD SYSOUT=class

//SYSUT1 DD ...

//SYSUT2 DD ...

//SYSIN DD ...

</syntaxhighlight>

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:

<syntaxhighlight lang="jcl">

//IEFBR14 JOB ACCT,'DELETE DATASET'

//STEP01 EXEC PGM=IEFBR14

//DELDD DD DSN=xxxxx.yyyyy.zzzzz,

// DISP=(MOD,DELETE,DELETE),UNIT=DASD

</syntaxhighlight>

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

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:

<syntaxhighlight lang="jcl">

//IEHINITT JOB ACCT,'LABEL TAPES',MSGCLASS=J,CLASS=A

//STEP0001 EXEC PGM=IEHINITT,REGION=8M

//SYSPRINT DD SYSOUT=A

//LABEL DD DCB=DEN=2,UNIT=(3490,1,DEFER)

//SYSIN DD *

LABEL INITT SER=123450,NUMBTAPE=3

/*

</syntaxhighlight>

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.

OPEN, CLOSE, and EOV functions are performed by a series of SVC modules that execute sequentially. Some modules contain tables used by the <code>XCTL</code> 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.

This is an example of the JCL required to run IEHIOSUP. 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.

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, for example Computer Associates' CA-SORT, SYNCSORT.

IBM's original OS/360 sort/merge program, 360S-SM-023, program name IERRCO00, supported only IBM's first-generation direct-access storage devices (DASD) 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), ICEMAN. An installation's preferred Sort/Merge program usually had the alias SORT.

SORT is frequently executed as a stand-alone program, where it normally reads input from a file identified by DD <code>SORTIN</code> and writes sorted output to a file identified by DD <code>SORTOUT</code>. It is also often called from another application, via the COBOL <code>SORT</code> verb or calls to PL/I <code>PLISRTx</code> routines, where it may use either <code>SORTIN</code> or <code>SORTOUT</code> 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 <code>SORT</code> or <code>MERGE</code> 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 <code>RECORD</code> 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.

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.

SORT has three techniques that can be used if the intermediate storage is tape, and two if disk.

The tape techniques are:

  • Balanced (BALN) - more efficient if more tape drives are available for intermediate storage.
  • Polyphase (POLY) - used if fewer tape drives are available for intermediate storage.
  • Oscillating (OSCL) - uses more main storage. The size of the input dataset must be known or closely approximated.

The disk techniques are:

  • Balanced Direct Access (BALN) - uses three to six intermediate storage datasets.
  • Crisscross Direct Access (CRCX) - uses six to seventeen intermediate storage datasets, requires twice the main storage of the Balanced Direct Access technique.

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 requirements.

The E level linkage editor had two versions, IEWLE150 and IEWLE180 capable of operating in 15KB and 18KB of available storage respectively. The F level linkage Editor also had two versions, IEWLF440 and IEWLF880 requiring 44KB and 88KB respectively. 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.

Fred Brooks uses the System/360 Linkage Editor as a prime example of the second system effect.

<blockquote>

Beyond this basic function it also handles program overlays. It is one of the finest overlay facilities ever built. ... Yet it is also the last and finest of the dinosaurs, for it belongs to a system in which multiprogramming is the normal mode and dynamic core allocation the basic assumption. This is in direct conflict with the notion of using static overlays, ... Furthermore the linkage editor requires so much space and itself contains many overlays that even when it is used just for linkage without overlay management, it is slower than most of the system compilers. The irony of this is that the purpose of the linker is to avoid recompilation.

</blockquote>

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.

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 <code>COBOL</code> for the current version.) There are many other compilers for various other programming languages.

Compilers bundled with OS/360 include ALGOL, COBOL, FORTRAN, PL/I, and RPG.

<!-- Other IBM OS lines are out of scope -->

supported compilers available for z/OS are COBOL, FORTRAN, C and C++, PL/I, Python, Go, Node.js (Javascript), and Java.

Some older compilers for, e.g., Ada, may run on z/OS but are no longer supported.

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

References

See also

  • Syncsort
  • Easytrieve
  • DFSMSdfp Utilities
  • DFSMS Access Method Services for Catalogs
  • DFSMSdss Storage Administration Guide
  • MVS UTILITIES