Embedded Files
MAINFRAME / JCL /
1. OVERVIEW
1.1. CHECK EXISTENCE OF DATASET
Determine whether a dataset (PS, PDS/PDSE, VSAM) exists in the catalog.
Recommended utilities:
IDCAMS LISTCAT (universal, works for PS, PDS/PDSE, VSAM)
IEHLIST (PDS/PDSE directory check; members not included)
1.2. LIST DATASET CONTENT
Display the actual contents of a dataset.
PS (Sequential):
SORT OPTION COPY (recommended, VSCode‑compatible)
IDCAMS PRINT (physical dump, for diagnostics)
IEBGENER (classic copy, PS only)
PDS/PDSE:
IEHLIST LISTPDS (list members)
SORT OPTION COPY (list content of a specific member)
VSAM (KSDS/ESDS/RRDS):
IDCAMS REPRO OUTFILE (recommended)
SORT OPTION COPY (fast and universal)
IDCAMS PRINT (ESDS only)
1.3. PRINT METADATA OF DATASET
Retrieve catalog information and attributes.
Recommended utilities:
IDCAMS LISTCAT ALL (universal metadata)
IEHLIST (PDS/PDSE directory metadata)
1.4. CREATE DATASET
Allocate new datasets of any type.
PS, PDS/PDSE, VSAM:
IDCAMS DEFINE (universal)
IEBCOPY (create PDS via copy)
IEBGENER (create PS via copy; classic)
1.5. ALLOCATE TEMPORARY DATASET
Create temporary datasets for intermediate steps.
Recommended utilities:
IEFBR14 with DISP=(NEW,PASS) (PS, PDS, VSAM)
IDCAMS DEFINE + DISP=PASS (VSAM temporary clusters)
1.6. RENAME DATASET
Change the name of an existing dataset.
Recommended utilities:
IDCAMS ALTER NEWNAME (PS, PDS, VSAM)
1.7. COPY DATASET
Duplicate datasets or members.
PS to PS:
IEBCOPY, SORT, IEBGENER, IDCAMS REPRO
PDS to PDS, PDS to PS, PS to PDS:
IEBCOPY (recommended)
VSAM to VSAM, VSAM to PS, PS to VSAM:
IDCAMS REPRO (recommended)
1.8. MOVE DATASET
Relocate datasets to new names or volumes.
Recommended utilities:
COPY + DELETE — PS, PDS
REPRO + DELETE — VSAM
IDCAMS ALTER — rename‑based move
1.9. CONCATENATE DATASETS
Combine multiple datasets into a single input stream.
Recommended utilities:
JCL concatenation (multiple DD statements, only first has a DD name, there is no physical record copying; PS)
IEBCOPY MERGE (PDS members)
SORT (multiple DD statements, only first has a DD name; PS)
IEBGENER (classic concatenation)
1.10. REORGANIZE PDS
Fix fragmentation and rebuild directory structures.
Recommended utilities:
IEBCOPY REORG (recommended)
IEBCOPY REBUILD (directory repair)
1.11. JOIN DATASETS
Perform relational joins between datasets.
Recommended utilities:
SORT JOINKEYS (universal; PS, VSAM)
IDCAMS REPRO + SORT JOINKEYS (VSAM join workflow)
1.12. DELETE DATASET
Remove datasets from the catalog.
Recommended utilities:
IDCAMS DELETE (PS, PDS, VSAM)
IDCAMS DELETE CLUSTER (VSAM cluster removal)
2. IDCAMS
2.1. IDCAMS OVERVIEW
IDCAMS: Integrated Data Set Control Access Method Services.
Primary z/OS utility for dataset management and VSAM operations. Fully compatible with modern VSCode + Zowe + IBM Z Open Editor environments.
Handles:
PS (sequential datasets)
PDS/PDSE (partitioned datasets)
VSAM (KSDS, ESDS, RRDS, VRRDS)
catalog operations
record‑level operations (REPRO, WRITE, PRINT)
Pros:
universal, for PS, PDS, VSAM
fully compatible with VSCode + Zowe
no DD * issues
supports record-level operations
supports metadata operations
supports VSAM operations
very stable and predictable
Cons:
PRINT is not human‑friendly (diagnostic only)
DEFINE syntax is verbose
REPRO cannot join or sort (SORT needed)
2.2. CAPABILITIES
Dataset operations:
CREATE (DEFINE)
DELETE
RENAME (ALTER)
LIST metadata (LISTCAT)
PRINT (diagnostic dump)
VERIFY (VSAM structure check)
Record operations:
COPY (REPRO)
WRITE (PS append)
PRINT (ESDS dump)
VSAM operations:
DEFINE CLUSTER / DATA / INDEX
DELETE CLUSTER
ALTER attributes
REPRO between VSAM and PS
PRINT VSAM ESDS
2.3. SYNTAX AND PARAMETERS
EXAMPLE FOR SYNTAX OF IDCAMS:
NAME():
specifies the dataset name
case‑sensitive in modern catalogs
VOLUMES():
target volume(s); Optional for SMS-managed datasets
LINEAR / NONVSAM:
LINEAR (PS dataset)
NONVSAM (PDS/PDSE or VSAM components)
RECORDSIZE():
primary and secondary record sizes
KEYS():
VSAM key length and offset
FREESPACE():
free space allocation for VSAM
SHAREOPTIONS():
sharing rules across systems
ALL:
show full catalog information
INFILE/OUTFILE:
DD names used for REPRO
INDATASET / OUTDATASET:
direct dataset names used for REPRO
HEX:
prints hex dump
CHARACTER:
list in ASCII/EBCDIC
KEY:
list VSAM key fields
DATA:
list VSAM data component
INDEX:
list VSAM index component
COUNT():
number of records to write
IDCAMS REPRO:
the OUTFILE dumps all records to SYSOUT
both the source and the target must exist a-prior
the source and target dataset types and record formats are read from these datasets
IDCAMS PRINT:
printing contents of PD
printing VSAM KSDS/ESDS record
creating hex dump
testing records
checking VSAM indexes
In case of VSAM KSDS, the data will be listed in the key order.
The hex dump is very useful upon testing binary fields.
In case of PS, records will be listed by lines.
The IDCAMS can not list PDS members, use IEHLIST instead.
2.4. VSAM CONSIDERATIONS
VSAM expressions:
Control Interval (CI)
Control Area (CA)
Key Length
Record Length
Free Space
Index (KSDS only)
Catalog (metadata)
VSAM types:
INDEXED (KSDS)
NONINDEXED (ESDS)
NUMBERED (RRDS)
KEYS parameters:
length (in bytes)
offset (starting position inside the record in bytes)
RECORDSIZE parameters:
average (in bytes)
maximum (in bytes)
If they are equal, fix record size.
CISZ parameter:
Control Interval SiZe, the physical storage unit of VSAM; the records are organized into CIs; typically 4096 or 8192 B (rarely 16384 or 32768 B) per CI, this number has effect on the speed, the fragmentation, the size of the Control Area (CA), ultimately the periodicity of re-organization
higher CISZ means more record in CI, less I/O, higher search speed
too large CISZ means the index is greater, slower index traversal
too small CISZ means it fills up faster, many CA split, higher speed of fragmentation
large CISZ means rare splits, less fragmentation
smaller CISZ means re-organization is needed with shorter periodicity which means high CISZ leads to rare need of re-organization
Conclusion for choosing CISZ:
4096 B (small index, fast index traversal, more splits, more de-fragmentations)
8192 B (larger index, less splits, less fragmentation)
16384+ B (too large index, slower search, rare splits)
in bank systems the common is 4096 and 8192 B
2.5. SAMPLES
EXAMPLE FOR CHECKING EXISTENCE:
EXAMPLE FOR CREATING PS DATASET:
EXAMPLE FOR CREATING VSAM KSDS:
EXAMPLE FOR CREATING VSAM ESDS:
EXAMPLE FOR CREATING VSAM RRDS:
EXAMPLE FOR RENAMING DATASET:
EXAMPLE FOR COPYING ALL RECORDS FROM A DATASET TO ANOTHER, CLASSIC FORM:
EXAMPLE FOR COPYING ALL RECORDS FROM A DATASET TO ANOTHER, VSCODE COMPATIBLE:
EXAMPLE FOR APPENDING RECORD TO PS:
EXAMPLE FOR DELETING DATASET:
EXAMPLE FOR DELETING PDS MEMBER:
EXAMPLE FOR LISTING DATASET:
3. IEBCOPY
3.1. IEBCOPY OVERVIEW
IEBCOPY: Partitioned Dataset Copy Utility.
Primary z/OS utility for copying, reorganizing, merging, and managing PDS/PDSE datasets and members.
Fully compatible with modern VSCode + Zowe + IBM Z Open Editor environments.
Handles:
PDS to PDS
PDS to PDSE
PDSE to PDS
PDS member to PS
PS to PDS member
PDS reorganization (REORG)
PDS directory rebuild (REBUILD)
PDS member replacement (REPLACE)
Pros:
best tool for PDS/PDSE operations
fully compatible with VSCode + Zowe
supports selective member operations
supports PDS compression (REORG)
supports directory repair (REBUILD)
very stable and predictable
Cons:
cannot operate directly on VSAM
cannot sort or join (SORT needed)
syntax is older and less intuitive than IDCAMS
requires SYSIN control cards (indentation matters)
3.2. CAPABILITIES
Dataset-level operations:
copy entire PDS/PDSE datasets
merge multiple PDS datasets
reorganize fragmented PDS datasets
rebuild damaged PDS directories
Member-level operations:
copy individual members
replace existing members
select members by name
exclude members
copy members to sequential datasets
copy sequential datasets into members
Special operations:
compress PDS (REORG)
repair directory (REBUILD)
copy with selective INCLUDE/EXCLUDE
3.3. SYNTAX AND PARAMETERS
EXAMPLE FOR SYNTAX OF IEBCOPY:
INDD/OUTDD:
DD names for input and output datasets
SELECT MEMBER=(...):
copy only the listed members
EXCLUDE MEMBER=(...):
copy all members except the listed ones
REPLACE:
overwrite existing members in the output dataset
MERGE:
combine multiple PDS datasets into one
REORG:
compress PDS by removing deleted member remnants
REBUILD:
rebuild damaged PDS directory structures
3.4. SAMPLES
EXAMPLE FOR COPYING ENTIRE PDS:
EXAMPLE FOR COPYING SELECTED MEMBERS:
EXAMPLE FOR REPLACING MEMBERS IN TARGET PDS:
EXAMPLE FOR COPYING PDS MEMBER TO PS:
EXAMPLE FOR COPYING PS TO PDS MEMBER:
EXAMPLE FOR REORGANIZING/COMPRESSING PDS:
EXAMPLE FOR MERGING 2 DATASETS:
4. SORT
4.1. SORT OVERVIEW
SORT: DFSORT Data Processing Utility.
DFSORT (invoked as PGM=SORT) is the most powerful and versatile data‑processing utility on z/OS.
The DFSORT instructions are defined in SYSIN in-stream DD.
Fully compatible with VSCode + Zowe + IBM Z Open Editor.
Handles:
PS (sequential datasets)
PDS/PDSE members
VSAM datasets (KSDS, ESDS, RRDS)
temporary datasets
SYSOUT streams
Pros:
universal: PS, PDS member, VSAM
fully compatible with VSCode + Zowe
no DD * issues
fast and highly optimized
supports complex record logic
supports joins and summarization
supports report generation
supports validation
supports transformations
Cons:
syntax can be complex
requires careful field positioning
JOINKEYS requires two SORT steps
not suitable for dataset creation (IDCAMS needed)
4.2. CAPABILITIES
Dataset-level operations:
copy dataset content (OPTION COPY)
read PS, PDS member, VSAM directly
write to PS, PDS member, SYSOUT
Record-level operations:
filter (INCLUDE, OMIT)
modify (INREC)
transform (OUTREC)
sort (SORT FIELDS)
join (JOINKEYS)
summarize (SUM FIELDS)
validate (VERIFY)
generate reports (OUTFIL)
produce custom output (BUILD)
Special operations:
create synthetic records
produce multi-section reports
format output for printing
convert data types
pad, truncate, overlay fields
create CSV-like output
4.3. SYNTAX AND PARAMETERS
EXAMPLE FOR SYNTAX OF SORT:
SORTIN:
input dataset (PS, PDS member, VSAM)
SORTOUT:
output dataset or SYSOUT (the records in processable fashion)
SYSOUT:
diagnostic messages (required)
OPTION COPY:
copy records without sorting
FIELDS:
defines sort keys
INCLUDE / OMIT:
record filtering conditions
INREC:
input record modification
OUTREC:
output record transformation
JOINKEYS:
relational join between datasets
SUM:
aggregation (sum, count, etc.)
OUTFIL:
custom output formatting
VERIFY:
record structure validation
4.4. ALGORITHMIC STRUCTURE OR SORT
The SORT program is for merging, filtering, sorting, transforming, joining data.
When using the SORT program:
the original dataset to sort is defined in the SORTIN DD
before any other commands, concatenation is executed by following multiple given datasets in SORTIN
the result is stored in a new dataset or member, defined in the SORTOUT DD
the SYSIN DD contains commands as main arguments for sorting (SORT), filtering (e.g. INCLUDE) etc., in in-stream fashion
the order of the commands define the operation chain (the order in which the operations will be executed)
a command contains command card(s)s which define parameters of the given operation
the order of the command cards define the order of using the command cards
using any command is not obligatory (concatenation does not need that)
sorting when using other commands is not obligatory
The SORT does not recognize record structure, it follows byte chains passed within command cards. Therefore all fields in the record structure must have fix length (in case of FB) or must have fix offset (in case of VB).
In case of VB records the first 4 bytes are the Record Descriptor Word (RDW), therefore the fields start from the 5th byte.
If the length overshoots the end of the actual line or record, inserts blanks (for characters) or zeros (for numbers) temporarily, resulting a normal sorting behaviour.
For the given byte chain, a type is rendered which will tell SORT how to use that byte chain.
A defined datetime field must contain numeric bytes.
4.5. SORTING
When the in-stream contains the SORT FIELDS argument that contains one or more sort cards. Sort card parameters:
start (byte position; the first byte of the record is 1)
length (what length the data has)
type (of the field)
order (ascending or descending)
Sort directions:
A (ascending)
D (descending)
When using more sort cards:
ordering by first card
in case of equality, ordering by second card
and so on
4.6. FILTERING
Filtering replaces the corresponding IF logic in COBOL. It can happen:
before sorting
By behaviour, filtering can:
letting through valid data only (INCLUDE)
exclude forbidden data (OMIT)
Filter card parameters:
start (byte position; the first byte of the record is 1)
length (what length the data has)
type (of the field)
relation
value
The condition understands these relations:
AND
OR
LT (less than)
LET (less or equal than)
EQ (equal)
NE (not equal)
GET (greater or equal than)
GT (greater than)
The string value is given in this format:
C'value'
A filtering card can define a complex condition, in such case the parts of the condition must be separated by commas.
4.7. TRANSFORMING
Transforming is for converting to upper- or lowercase, changing numeric format, merging multiple fields, building fix-length records etc. This operation also replaces other corresponding logic in COBOL. It can happen:
before sorting (INREC)
after sorting (OUTREC)
Transformation card parameters can be given in any order; parameter groups:
value (e.g. C'NAME=')
position, length
TRAN=LTOU (uppercase)
etc.
EXAMPLE FOR TYPICAL USAGE OF TRANFORMATION COMMANDS:
4.8. CREATING JOIN, SUMMARIZING, CREATING REPORT
Creating join:
can happen before and-or after sorting (JOINKEYS)
acts as SQL JOIN
is for data comparison, duplicate checking, doing audits
Summarizing:
can happen after sorting (SUM)
creates values based on the same key values in the given field
is for generating financial, statistical, batch reports
Creating report:
can happen after sorting (OUTFIL)
is able to format, create header and footer, insert page breaks
4.9. SAMPLES
EXAMPLE FOR LISTING DATASET CONTENT:
EXAMPLE FOR COPYING DATASET:
EXAMPLE FOR CONCATENATING DATASETS:
EXAMPLE FOR FILTERING RECORDS:
EXAMPLE FOR MODIFYING RECORDS:
EXAMPLE FOR TRANSFORMING OUTPUT:
EXAMPLE FOR SORTING RECORDS:
EXAMPLE FOR JOINING 2 DATASETS:
EXAMPLE FOR SUMMARIZING RECORDS:
EXAMPLE FOR GENERATING REPORT:
EXAMPLE FOR VALIDATING RECORD STRUCTURE:
EXAMPLE FOR FILTERING AND SORTING:
EXAMPLE FOR JOINING, SORTING AND CREATING REPORT:
5. IEHLIST
5.1. IEHLIST OVERVIEW
IEHLIST: Partitioned Dataset Listing Utility.
A z/OS utility used for listing PDS/PDSE directories and members.
IEHLIST is the only utility that can list PDS/PDSE members directly.
The IEHLIST instructions are defined in SYSIN in-stream DD.
Fully compatible with VSCode + Zowe + IBM Z Open Editor.
VTOC: Volume Table of Contents.
Pros:
only tool that lists PDS/PDSE members
fully compatible with VSCode + Zowe
clear return codes for IF logic
shows fragmentation indicators
shows member types and lengths
Cons:
cannot list PS or VSAM
cannot copy or modify members
syntax is strict (indentation required)
TTR values are less relevant for PDSE (the dynamic directory is not fragmentated)
5.2. CAPABILITIES
Dataset-level operations:
list PDS/PDSE directory
display member metadata
display free directory space
display TTR addresses
display dataset attributes
Member-level operations:
check member existence
display member type
display member length
display member TTR
display fragmentation indicators
Special operations:
hex dump of PDS directory
fragmentation analysis (via TTR spread)
TTR address: Track-Track-Record address:
points to a physical space on DASD
in case of PDS, the place of the member in the dataset
usable for testing agains existing fragmentation
In case the TTRs of many members are spread, the PDS is fragmented, and it needs IEBCOPY REORG.
5.3. SYNTAX AND PARAMETERS
EXAMPLE FOR SYNTAX OF IEHLIST:
DSNAME:
specifies the PDS/PDSE dataset name
case‑sensitive
TTR:
displays Track‑Track‑Record addresses for each member
useful for fragmentation analysis
not for PDSE
VOL:
specifies the DASD volume for VTOC listing
5.4. RETURN CODES
5.5. SAMPLES
EXAMPLE FOR LISTING PDS DIRECTORY:
EXAMPLE FOR LISTING PDS DIRECTORY WITH TTR ADDRESSES:
EXAMPLE FOR CHECKING MEMBER EXISTENCE VIA RETURN CODE:
EXAMPLE FOR LIST VTOC OF A VOLUME:
6. IEBGENER
6.1. IEBGENER OVERVIEW
IEBGENER: Generalized Data Set Copy Utility.
Classic z/OS utility used primarily for copying data between datasets or SYSOUT streams.
Widely used in older JCL examples.
IEBGENER is compatible with VSCode + Zowe, but only if DD * in‑stream input is avoided.
Pros:
very simple
very stable
works for PS and PDS members
works for SYSOUT copying
good for message generation (with caution)
Cons:
DD * input is unreliable in VSCode + Zowe
no filtering, sorting, joining, or transformation
no VSAM support
no metadata operations
no record modification
largely superseded by SORT and IDCAMS
6.2. CAPABILITIES
Dataset-level operations:
copy sequential datasets
copy PDS members
copy SYSOUT streams
copy SYSIN literal data (with limitations)
Record-level operations:
IEBGENER does not modify records
it performs a straight copy only
Special operations:
generate messages using SYSIN literal text
copy JES SYSOUT to datasets
copy datasets to printers (legacy)
6.3. SYNTAX AND PARAMETERS
EXAMPLE FOR SYNTAX OF IEBGENER:
SYSUT1:
input dataset or stream
SYSUT2:
output dataset or stream (the records in processable fashion)
SYSPRINT:
diagnostic output
SYSIN:
control statements or literal text
in modern environments: use DD DUMMY
6.4. SAMPLES
EXAMPLE FOR COPYING PS TO PS:
EXAMPLE FOR COPYING PDS MEMBER TO PS:
EXAMPLE FOR COPYING PS TO PDS MEMBER:
EXAMPLE FOR GENERATING MESSAGE (VSCODE-COMPATIBLE):
EXAMPLE FOR COPYING SYSOUT TO DATASET:
7. IEFBR14
7.1. IEFBR14 OVERVIEW
IEFBR14: the “Do Nothing” Utility for Dataset Allocation.
A minimal z/OS utility whose program literally does nothing and immediately returns RC=0.
Use it when the DD statements define the task, not the program.
Fully compatible with VSCode + Zowe environment.
Pros
simplest method to create or delete datasets using DD statements
fully compatible with VSCode + Zowe REST API
no SYSIN or SYSOUT required
always returns RC=0, ideal for IF/THEN branching (IEFBR14 program block goes into 1 or both branches)
reliable for PS, PDS, and temporary dataset allocation
no DD \* issues (unlike some older utilities)
fast and predictable, since the program itself does nothing
Cons:
cannot copy, list, or modify datasets
cannot handle VSAM (IDCAMS required)
all logic must be expressed in DD parameters, which can be verbose
no metadata output, unlike LISTCAT
no record‑level operations (SORT or IDCAMS needed)
not suitable for workflows requiring dynamic input or transformation
7.2. CAPABILITIES
Dataset-level operations (based on DD DISP):
create dataset (DISP=NEW)
delete dataset (DISP=OLD,DELETE)
reallocate dataset (with new parameters)
allocate temporary datasets (DISP=(NEW,PASS))
Program-level behavior:
RC=0
no input
no output
no SYSIN needed
no SYSOUT needed
7.3. SYNTAX AND PARAMETERS
EXAMPLE FOR SYNTAX OF IEFBR14:
DSN:
name of the dataset to be created or deleted
DISP=NEW:
new dataset
DISP=OLD,DELETE:
delete dataset
UNIT=SYSDA:
definition of DASD device (usually SYSDA)
SPACE:
allocation (TRK, CYL, or BLK; obligatory upon new dataset)
DCB:
dataset attributes (obligatory in case of PS)
Dataset attributes:
RECFM
LRECL
BLKSIZE
7.4. SAMPLES
EXAMPLE FOR CREATING PS DATASET:
EXAMPLE FOR DELETING DATASET:
EXAMPLE FOR REALLOCATING DATASET (DELETE + CREATE):
EXAMPLE FOR CREATING TEMPORARY DATASET:
Google Sites
Report abuse