Support programs for OS/360 and successors
| Company type | Software utilities |
|---|---|
| Industry | Computer software |
| Founded | 1964 |
| Headquarters | Armonk , United States |
| Products | OS/360 utilities, including IDCAMS, IEBCOMPR, IEBCOPY, IEBDG, IEBEDIT, IEBGENER, IEBIMAGE, IEBISAM |
| Parent | IBM |
This article discusses support utilities that are either bundled with or accessible for OS/360 and successors. IBM categorizes some of these as utilities—divided into Data Set Utilities, System Utilities, and Independent Utilities—while others are designated as service aids; however, the distinction between these groups is not always definitive. Many of these programs align with conventional utility software classifications.
The lists provided here concentrate on utilities associated with OS/360 and successors, deliberately excluding those designed for DOS, TPF, or VM environments.
Naming convention
IBM assigns module names beginning with three letters that identify the module’s "component." Within OS/VS, the majority of IMx message codes were updated to AMx for OS/VS2 and HMx for OS/VS1.
History/Common JCL
Numerous utilities originated from contributions by IBM users through the SHARE organization and were subsequently refined by IBM itself. These programs typically execute via Job Control Language (JCL), employing standard DD names within OS and z/OS systems:
| DDNAME | Common purpose |
|---|---|
| SYSIN | input stream for utility commands; often set to DUMMY if default processing is used |
| SYSUT1 | primary input dataset |
| SYSUT2 | output dataset |
| SYSUT3 | optional auxiliary input dataset |
| SYSUT4 | optional auxiliary output dataset |
| SYSPRINT | printed output generated by the utility |
| SYSOUT | messages produced by the utility |
| SYSUDUMP | system dump created upon program failure |
IDCAMS
IDCAMS (Access Method Services) is responsible for managing and manipulating both VSAM and non-VSAM datasets. Introduced alongside VSAM in OS/VS, IDCAMS provides a broad range of dataset operations that surpass those offered by other utilities.
For instance, to copy a dataset consisting of 80-byte records with the system automatically selecting the block size:
<syntaxhighlight lang="jcl"> //XXXXXXXW JOB XXXXXXX,AAAA,CLASS=G,MSGCLASS=1,NOTIFY=&SYSUID //STEP001 EXEC PGM=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=*
//* </syntaxhighlight>
Control statements can be sourced from inline data or any sequential file, PDS member, or temporary dataset, for example:
<syntaxhighlight lang="jcl"> //SYSIN DD DSN=PROD.MYFILE.REPRO,DISP=SHR </syntaxhighlight> or alternatively: <syntaxhighlight lang="jcl"> //SYSIN DD DSN=PROD.MYLIB.CNTLLIB(REPRO),DISP=SHR </syntaxhighlight>
IEBCOMPR
IEBCOMPR performs record-by-record comparisons between sequential or partitioned datasets, ensuring exact matches at the logical record level. It is frequently utilized to verify the integrity of backup copies.
The utility compares records sequentially and outputs any differences found, including details such as record or block numbers, DD names involved, and the differing records themselves. For sequential datasets to be considered identical, they must have matching record counts and identical records or keys. Partitioned datasets require matching directory entries, equal member record counts, and identical corresponding records.
IEBCOMPR ceases operation after detecting ten discrepancies.
Example usage:
<syntaxhighlight lang="jcl"> //XXXXXXXW JOB XXXXXXX,AAAA.A.A,CLASS=G,MSGCLASS=1,NOTIFY=XXXXX //STEP01 EXEC PGM=IEBCOMPR,ACCT=PJ00000000 //*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 </syntaxhighlight>
Although IEBCOMPR lacks advanced features like column-specific comparisons or ignoring whitespace and stops after ten errors are found, its speed and universal presence on IBM mainframes running OS/360 and successors make it a valuable tool for verifying exact matches such as load modules or dataset replications. For more detailed program or report comparisons, the ISPF SuperC (ISRSUPC) compare utility is generally preferred.
IEBCOPY
IEBCOPY is a utility designed to copy, compress, and combine partitioned data sets. It offers the capability to include or exclude particular members during the copy process, as well as to rename or overwrite members when necessary.
Primary capabilities of IEBCOPY encompass:
- Extracting a partitioned data set (PDS) into a sequential (PS) dataset for backup or transfer purposes.
- Compressing a PDS by copying it back onto itself to recover space from deleted members.
- Copying selected members or renaming them into another PDS.
- Combining multiple PDSs into a single consolidated PDS.
- Modifying, copying, and reblocking load modules.
- Preventing overwriting of existing members in the target PDS unless the replace (R) option is explicitly specified.
Sample job control statements illustrating IEBCOPY usage:
<syntaxhighlight lang="jcl"> //stepname EXEC PGM=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)
/*
</syntaxhighlight>
Here, MYDD1 and MYDD2 represent user-defined DD names for input and output partitioned datasets; their default names are SYSUT1 and SYSUT2 respectively. To perform compression of a PDS, specifying only one DD statement suffices.
IEBDG
IEBDG ('Data Generator') is utilized to create test datasets containing structured data patterns. Its control statements specify record fields by their position, size, format, and initialization values. The tool can also alter existing datasets by modifying designated fields—for instance, substituting a name field with randomly generated alphabetic characters. Field values may vary across records, such as rotating characters within alphanumeric fields.
Example of IEBDG execution:
<syntaxhighlight lang="jcl"> //STEP1 EXEC PGM=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,
P'1234567890',INDEX=1
CREATE QUANTITY=500,NAME=(FIELD1,FIELD2,FIELD3),FILL=X'FF'
END
/*
</syntaxhighlight>
IEBEDIT
IEBEDIT facilitates selective copying of segments within JCL jobs by extracting specific job steps as needed.
Illustrative IEBEDIT job example:
<syntaxhighlight lang="jcl"> //IEBEDITJ JOB ACCT,,CLASS=P,MSGCLASS=T,MSGLEVEL=(1,1),NOTIFY=&SYSUID //STEP0001 EXEC PGM=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)
/*
</syntaxhighlight>
In this case, the dataset xxxxx.yyyyy.zzzzz contains jobs with steps named STEP5, STEP10, and STEP15. The IEBEDIT program extracts these specified steps and sends them to the SYSUT2 output (the internal reader).
The syntax for the EDIT statement is as follows:
<syntaxhighlight lang="jcl"> [label] EDIT [START=jobname] [,TYPE={POSITION|INCLUDE|EXCLUDE}] [,STEPNAME=(namelist)] [,NOPRINT] </syntaxhighlight>
- START=jobname: Indicates which job to process. If omitted and only one EDIT statement exists in the input stream, processing begins with the first job encountered; otherwise processing resumes from the next job.
- TYPE determines the selection criteria for output:
-POSITION(default): Outputs the JOB statement along with the step named in STEPNAME plus all subsequent steps; preceding steps are excluded. -INCLUDE: Outputs the JOB statement and only those steps explicitly listed in STEPNAME. -EXCLUDE: Outputs the JOB statement and all steps except those specified in STEPNAME.
- STEPNAME=(namelist): Specifies which job steps to include or exclude. This can be a single step name, multiple names separated by commas, or a range indicated by two step names separated by a hyphen (e.g., STEPA-STEPE). Multiple entries must be enclosed in parentheses.
If STEPNAME is not provided, the entire designated job is copied; if no job name is supplied via START parameter, processing defaults to the first job found.
- NOPRINT: When specified, suppresses printing of output listings in the message dataset (by default output listings are generated).
This feature allows precise extraction and manipulation of JCL job steps to streamline batch workflows and system administration tasks.
IEBGENER
IEBGENER is used to duplicate records from sequential datasets or to produce partitioned datasets.
Its primary capabilities include:
- Creating backups of sequential data sets or members within a PDS.
- Adjusting the physical block size or the logical record length in sequential datasets.
- Producing datasets with applied edits.
- Outputting sequential data sets or PDS members in printed form.
- Transforming sequential inputs into partitioned output datasets.
For simple copying operations, many mainframe environments favor the sort utility due to its superior speed. In some setups, tasks like these are automatically redirected to the sort program rather than being handled by IEBGENER.
On select platforms, IEBGENER supports sending email from batch jobs by routing output through the external writer labeled "SMTP". This feature facilitates automated email dispatches and file attachments directly from the mainframe system.
IEBIMAGE
IEBIMAGE is responsible for managing image definitions tailored for IBM printers such as the 3211, 3800 laser printer, and 4248 models. It processes forms control buffers (FCBs), character mapping tables, and form images including logos or graybar backgrounds. This tool enables printing diverse forms and logos on plain paper, thereby decreasing dependence on preprinted forms and reducing printer downtime.
IEBISAM
IEBISAM provides functionalities to unload, load, copy, and print ISAM datasets.
Important: IEBISAM has been discontinued since z/OS V1R7. ISAM datasets require conversion to VSAM key-sequenced datasets as ISAM support has ceased. Earlier versions included access method services that permitted allocation of VSAM datasets and facilitated copying ISAM data into them.
IEBPTPCH
IEBPTPCH ("PrinT and PunCH") is designed for printing or punching records sourced from sequential or partitioned datasets.
Its key features include:
- Printing or punching entire sequential or partitioned (PDS) datasets.
- Selecting specific PDS members or records for printing or punching.
- Producing printed or punched copies of PDS directory listings.
- Outputting edited versions of sequential datasets or PDS members.
- Detecting empty datasets (returns RC=4 if empty; otherwise returns 0).
<syntaxhighlight lang="jcl"> //IEBPTPCH JOB // 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.89 Second person 123 Williamson Hall 2.48 3rd person 321 Maag Library 1.52 /* //SYSUT2 DD SYSOUT=* // </syntaxhighlight>
Checking for empty dataset: <syntaxhighlight lang="jcl"> //IEBPTPCH JOB // EXEC PGM=IEBPTPCH //SYSUT1 DD DSN=<filename>,DISP=SHR //SYSUT2 DD DUMMY, // DCB=(BLKSIZE=<block size>,RECFM=FA) //SYSIN DD *
PRINT TYPORG=PS
/* //SYSPRINT DD SYSOUT=* // </syntaxhighlight>
IEBTCRIN
IEBTCRIN reads data from IBM 2495 Tape Cartridge Readers. Support for this device was terminated with z/OS version 1.3.0 in 2002.
IEBUPDAT
IEBUPDAT is utilized to update records within sequential datasets or PDS members; however, it has been superseded by IEBUPDTE.
IEBUPDTE
IEBUPDTE, often referred to as "UPDaTE," is utilized for updating sequential or partitioned datasets and is frequently employed to manage and distribute source libraries, particularly when transferring data from tape to DASD.
Its capabilities include:
- Building and modifying libraries.
- Updating sequential datasets or members within partitioned datasets.
- Converting dataset formats between sequential and partitioned organizations.
The program accepts a PARM parameter on the EXEC statement with the following options:
- NEW: both control statements and input data are provided via SYSIN; SYSUT1 is not required.
- MOD: control statements reside only in SYSIN; input data is specified through SYSUT1.
Input datasets can be sourced from either SYSUT1 or SYSIN.
Example of job control:
<syntaxhighlight lang="jcl"> //stepname EXEC PGM=IEUPDTE,PARM=NEW //SYSPRINT DD SYSOUT=class //SYSUT1 DD ... //SYSUT2 DD ... //SYSIN DD ... </syntaxhighlight>
IEFBR14
IEFBR14 serves as a placeholder program commonly used in JCL when the objective is purely to allocate or delete datasets.
Sample 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>
Within OS/360, its calling convention involved placing the return address in Register 14. Executing a branch to Register 14 causes an immediate program exit. The operating system performs dataset allocation or deallocation as specified in DD statements before and after the program runs, making IEFBR14 an efficient utility for dataset creation or removal.
Initially implemented as a single machine instruction—"Branch to Register 14" (BR 14)—its name originates from this assembler mnemonic. The prefix IEF identifies it as part of OS/360's job management components.
Early versions did not set the return code properly, so a second instruction was introduced to clear it, ensuring accurate exit status. Additionally, modifications addressed its lack of reentrancy to allow safe concurrent execution by multiple processes.
Some users altered IEFBR14 by replacing BR 14 with BR 15, causing an endless loop since Register 15 contains the module's own address.
System utilities
These tools assist systems programmers in system upkeep tasks rather than application development.
ICKDSF
ICKDSF ("Device Support Facility") is responsible for installing, initializing, and maintaining DASD devices under operating systems or as standalone utilities.
IEHATLAS
This utility reallocates alternate tracks to replace defective ones on storage devices.
IEHDASDR
IEHDASDR handles various DASD-related tasks for disks and SSDs emulating disk drives:
- Initializing DASD volumes with optional surface scanning
- Allocating alternate tracks to substitute faulty ones
- Printing DASD track contents
- Backing up DASD volumes onto tape
- Restoring DASD volumes from backup tapes
IBM discontinued adding new device support in IEHDASDR, recommending customers use the free Device Support Facility (DSF) for volume initialization. For dump and restore operations, chargeable products such as DASDR (5740-UT1) and Data Facility/Data Set Services (5740-UT3, DF/DSS) are advised.
IEHDASDR was removed starting with MVS/XA releases.
IEHINITT
IEHINITT ("INITialize Tape") is designed to prepare tapes by inscribing either IBM standard or ASCII labels. It supports labeling multiple tapes within a single execution, automatically incrementing the VOLSER for each tape processed. Upon completion of labeling, every tape is rewound and ejected.
Sample JCL demonstrating labeling of three tapes on a 3490 device:
<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>
IEHIOSUP
IEHIOSUP updates the relative track address (TTR) pointers used by type IV Supervisor Call (SVC) routines located in SYS1.SVCLIB. This tool has become obsolete starting with OS/VS2 and later versions.
SVC modules responsible for OPEN, CLOSE, and EOV operations rely on tables containing disk addresses to streamline linking. When SYS1.SVCLIB is modified, these addresses may change; IEHIOSUP ensures the correct addresses are installed accordingly.
Example JCL to execute IEHIOSUP:
<syntaxhighlight lang=jcl> //IHEIOSUP JOB // EXEC PGM=IEHIOSUP //SYSUT1 DD DSNAME=SYS1.SVCLIB,DISP=OLD,UNIT=2311, // VOLUME=SER=111111 //SYSPRINT DD SYSOUT=A // </syntaxhighlight>
IEHLIST
IEHLIST provides listings of entries from Partitioned Dataset (PDS) directories, Volume Table of Contents (VTOC), or OS CVOL catalogs.
Below is an example JCL to display a PDS directory:
<syntaxhighlight lang="jcl"> //IEHLIST JOB ACCT,'LIST PDS',MSGCLASS=J,CLASS=A //STEP0001 EXEC PGM=IEHLIST,REGION=8M //SYSPRINT DD SYSOUT=A //PDS1 DD DSN=xxxx.yyyy.zzzz,DISP=OLD //SYSIN DD *
LISTPDS DSNAME=xxxx.yyyy.zzzz,FORMAT
/* </syntaxhighlight>
To list a VTOC, a similar syntax applies:
<syntaxhighlight lang="jcl"> //IEHLIST JOB ACCT,'LIST VTOC',MSGCLASS=J,CLASS=A //STEP0001 EXEC PGM=IEHLIST,REGION=8M //SYSPRINT DD SYSOUT=A //VOL1 DD VOL=SER=vvvvvv,DISP=OLD //SYSIN DD *
LISTVTOC VOL=SER=vvvvvv,FORMAT
/* </syntaxhighlight>
IEHMOVE
IEHMOVE facilitates transferring or duplicating groups of data sets as well as entire volumes. Despite the widespread adoption of DFSMS (System Managed Storage) environments where IBM discourages IEHMOVE usage, this utility remains useful for relocating or copying sequential, partitioned, and multi-volume data sets without requiring explicit space or DCB definitions. It automatically assigns these attributes based on the source data sets.
In contrast with other utilities such as and , IEHMOVE supports handling collections of data sets or full volumes simultaneously, making it a preferred choice among systems programmers for managing large-scale data transfers.
Jobs using IEHMOVE specify DASD or magnetic tape volumes rather than individual data sets. Specifying DISP=OLD on volumes grants exclusive control over them during processing—ideal for private volumes but unsuitable for shared public volumes.
The SYSUT1 DD statement identifies a DASD volume where IEHMOVE creates three essential work data sets; unit and volume details must be provided.
Originally written in PL/S, IEHMOVE streamlines moving multiple sequential data sets across volumes by mounting destination volumes as needed and automatically allocating space.
Example job transferring three sequential data sets from one disk volume to three distinct private volumes:
<syntaxhighlight lang="jcl"> //MOVEDS JOB ... //STEP1 EXEC PGM=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
/* </syntaxhighlight>
IEHPROGM
IEHPROGM handles system control information, including the renaming and removal of data sets.
Its principal capabilities encompass:
- Removing (scratching) data sets or members within a PDS
- Changing the names of data sets or PDS members
- Cataloging or removing catalog entries for data sets
- Administering data set passwords stored in the system's PASSWORD dataset
Example of cataloging:
<syntaxhighlight lang="jcl"> //SYSIN DD *
CATLG DSNNAME=data-set-name, VOL=device-name=volume-number
/* // </syntaxhighlight>
IFHSTATR
This utility extracts and formats SMF records specifically for analyzing tape errors.
Independent Utilities
These are self-contained programs designed to function independently of any operating system:
Service Aids
These are IBM-documented utilities intended for diagnostics and maintenance support. The original OS/360 Service Aids bore IFC and IM* prefixes; these were later changed to HM* for OS/VS1 and AM* for OS/VS2, while the IFC prefix remained in use.
SORT
The Sort/Merge utility arranges records within files into a defined sequence or combines already sorted files. It ranks among the most widely utilized tools in mainframe settings. Contemporary sort/merge utilities also provide functionality such as filtering records, aggregating data, eliminating duplicates, reformatting entries, and producing straightforward reports. Several vendors supply sort/merge solutions for IBM mainframes, including Computer Associates' CA-SORT and SYNCSORT.
IBM’s initial OS/360 sort/merge tool, 360S-SM-023 (IERRCO00), supported first-generation direct-access storage devices (DASD) and magnetic tapes. Subsequent IBM products like 5734-SM1 and 5740-SM1 (DFSORT) expanded compatibility to second-generation disk drives. Typically, environments create an alias named SORT to invoke their chosen Sort/Merge program.
SORT operates as a standalone application that reads input from DD SORTIN and writes results to DD SORTOUT. It can also be called through the COBOL SORT verb or PL/I PLISRTx routines, facilitating integration within application processes.
Control over SORT functions is exercised via statements compatible with both IBM and third-party products. The SORT or MERGE statements specify sort keys by defining their position, length, and data type. The RECORD statement outlines the format of input records. Additional statements allow filtering and modification of data during processing.
Sort keys may consist of EBCDIC or ASCII characters, zoned or packed-decimal numbers, signed or unsigned binary values, or hexadecimal floating-point numbers, positioned anywhere within the record. Sorting supports both ascending and descending orders based on these keys.
The OS/360 sorting algorithm divides input into segments sorted in memory before writing intermediate sorted runs to DASD or tape. Final merging steps produce the fully sorted output. SORT automatically selects optimal distribution methods for these segments across storage devices but permits manual overrides by users.
Tape-based distribution methods include:
- Balanced (BALN) – optimized for multiple tape drives
- Polyphase (POLY) – effective with fewer tape drives
- Oscillating (OSCL) – requires knowledge of input size and more memory resources
Disk-based distribution methods include:
- Balanced Direct Access (BALN) – utilizes 3 to 6 intermediate datasets
- Crisscross Direct Access (CRCX) – employs 6 to 17 datasets and demands roughly twice the memory of BALN
Linkers
Originally, OS/360 offered only the Linkage editor in several configurations. With the introduction of DFSMSdfp, the Binder emerged as an alternative for load modules and became the exclusive method for handling program objects.
Linkage Editor
The Linkage editor is responsible for creating and updating load modules within a partitioned data set by linking together control cards, object modules, and other load modules. It has the capability to rename or substitute control sections (CSECT) and execute additional editing tasks. Initially, it was provided in different versions tailored to memory requirements: the E level included IEWLE150 and IEWLE180, operating with 15KB and 18KB of memory respectively, while the F level comprised IEWLF440 and IEWLF880, requiring 44KB and 88KB. The E level has since been retired; the F level is now simply known as the Linkage Editor. In the context of z/OS, it remains available solely for backward compatibility.
Fred Brooks highlighted the System/360 Linkage Editor as a classic case of the second system effect:
Beyond its fundamental functions, it manages program overlays through one of the most sophisticated overlay mechanisms ever developed. However, it belongs to a system designed for multiprogramming and dynamic memory allocation, which contrasts with static overlays. The linkage editor itself demands considerable memory and contains numerous overlays, resulting in slower performance than most system compilers even when used only for linkage purposes. Ironically, its aim is to eliminate the need for recompilation.
Binder
Introduced alongside DFSMS, the Binder encompasses all functions of the Linkage Editor while additionally supporting program objects—the equivalent of load modules within Partitioned Data Set Extended (PDSE)—providing enhanced functionality.
Assemblers
Typically, a single assembler was standard since it was essential for system generation (SYSGEN) and system customization.
Compilers
Each programming language supported in a computing environment has one or more dedicated compilers that convert source code into machine-language object modules. These object modules are subsequently linked by the linkage editor (IEWL) to produce executable load modules.
A notable example is IGYCRCTL, which acts as the compiler for IBM Enterprise COBOL on z/OS. Over time, IBM has released multiple COBOL compilers often referenced simply as COBOL. Additionally, IBM offers compilers for languages such as ALGOL, FORTRAN, PL/I, and RPG.
System Modification Program (SMP)
The System Modification Program (SMP) is IBM’s primary utility for applying and managing system updates on OS/360 and its successors. It replaced separate processes involving assembly, link editing, and IMAPTFLE jobs. Initially optional, SMP became compulsory starting with MVS/SP releases. The current iteration, SMP/E, is bundled with modern operating systems like z/OS.