REPRO
Copies records from one file into another.
Also written IDCAMS REPRO
Why it matters. A new VSAM file is empty. REPRO is how the accounts get into it.
See it
The source is a sequential file.
Syntax
REPRO INDATASET(entry) OUTDATASET(entry) REPRO INFILE(ddname) OUTFILE(ddname) [COUNT(n)] [SKIP(n)] [REPLACE]
- INDATASET (IDS)
- The file to read.
- OUTDATASET (ODS)
- The file to write. It must already exist.
- INFILE / OUTFILE
- The same, but named through a DD in the job.
- COUNT(n)
- Copy only n records.
- SKIP(n)
- Skip the first n records.
- REPLACE
- If a key already exists, replace that record instead of skipping it.
Try it REPRO
- 1
The empty keyed file ZBANK.DATA.ACCTMAST already exists. You're in the SYSIN lines of job LOADMAST, under EXEC PGM=IDCAMS. Write the command that copies the records of ZBANK.DATA.ACCOUNTS into it. Type it on one line.
SYSIN REPRO INDATASET(ZBANK.DATA.ACCOUNTS) OUTDATASET(ZBANK.DATA.ACCTMAST) - 2
Submit the job LOADMAST from your DEV JCL library.
SUBMIT 'ZB0001.DEV.JCL(LOADMAST)' - 3
Read the output of the job, and find how many records were copied.
OUTPUT LOADMAST
Remember
- REPRO INDATASET(from) OUTDATASET(to).
- DEFINE CLUSTER makes the file. REPRO fills it.
- Read IDC0005I: it is the number of records copied.
The usual mistake
Putting REPRO before DEFINE CLUSTER
The commands run in the order you wrote them. Before the cluster exists, REPRO has nowhere to put the records.
DEFINE CLUSTER first, then REPRO
On real z/OS
MF/OS copies all the records of the input. COUNT and SKIP are not supported on REPRO here, and the key-order rule for loading an empty keyed file is not modelled. On real z/OS, loading an empty KSDS needs ascending key order. The target file must already exist in both.
Where can I practise REPRO?
Right here, at ZedBank. You take a junior job at a simulated bank and use REPRO in real work, with Zed beside you. There's nothing to install.
Start at ZedBankRelated
- IDCAMSThe utility used to create, list, copy and delete datasets, and the standard tool for anything involving VSAM.
- KSDSThe most common VSAM dataset type, where every record has a unique key used to find it directly.
- VSAMA family of dataset types built for fast record access by key, used where applications need to look records up rather than read them in order.
- Job stepOne program execution within a job. A job is simply a sequence of steps that run in order.
- DatasetWhat a mainframe calls a file: a named collection of records with a defined structure, rather than a loose stream of bytes.