In later versions of MVS (OS/390 and z/OS) a pair of TSO commands evolvedthat can be used to package datasets into a compact form for sharing(transmission) between TSO users. It has since become a standard formoving collections of datasets between systems.
The TRANSMIT command packages sequential (DSORG=PS) or partitioned (DSORG=PO)datasets into a format that may be sent as a stream of 80 characterrecords. Partitioned datasets are first unloaded using the IEBCOPY utilitybefore being packaged into the 80 character format.
Onthe other end of the process, the RECEIVE command reverses the process reproduce the copy of the original datasets.
In 2002 Jim Morrison wrote a couple of programs - XMIT370 and RECV370 - thatmay be used to provide the same functions as TRANSMIT and RECEIVE, although theyrun in batch, not under TSO. These programs are present in the SYSCPKvolume of compilers and tools that is available from my site. Jim'sdistribution file, including the source code and documentation is available onthe SYSCPK volume in the dataset SYSC.RECV370.ASM. The PROCedures forexecuting XMIT370 and RECV370 are available in SYSC.PROCLIB.
Using RECV370 to Reconstruct XMIT Contents on MVS
There are two methods that may be used to import an XMIT file into MVS andreconstruct the datasets that they contain. The first method utilizes aHercules emulated card reader to transfer the XMIT to MVS and extract itscontents into the recreated datasets in a single step. The second methoduses IND$FILE to transfer the XMIT to MVS and then a batch job is run to extractit* contents into the recreated datasets.
Emulated Card Reader
If you have a card reader defined on your MVS system that is not controlledby JES2, it may be used to read the XMIT file and process it directly withRECV370. If all of your card readers are controlled by JES2, it ispossible to use JES2 commands to drain a card reader so that it is free to use,but I prefer not to enter the morass of changing JES2 operations and will not bedescribing that process here; so if you have a system with a free reader (whichis the case if you generated your system following my instructions) you areready to go. This is the process described in my MVS installation(customization) instructions for installing REVIEW.
The records in the XMIT file on the PC are in EBCDIC format, so you do notwant Hercules to attempt to translate them from ASCII to EBCDIC as it readsthem. So on the Hercules command window, you will use the ebcdicoperand when you devinit the card reader to open the XMIT file. Inan MVS system generated following my instructions, I use the card reader atx'01c', so the Hercules command is:
devinit 01c <XMIT file on the PC> ebcdic
and substitute the name of the file on your host PC for <XMIT file on thePC>.
The load module for RECV370 is in SYSC.LINKLIB on SYSCPK and the cataloguedprocedure for RECV370 is in SYSC.PROCLIB on SYSCPK, so it is necessary for youto have SYSCPK installed and integrated into your MVS system. With thecatalogued procedure, the JCL required to process the XMIT file is minimal:
//RECEIVE JOB (1),'UNPACK XMIT',CLASS=A,MSGCLASS=X //RECV01 EXEC RECV370 //XMITIN DD UNIT=01C,DCB=(RECFM=FB,LRECL=80,BLKSIZE=80) //XMITOUT DD DSN=JAY01.XEPHON.PDS,DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,SPACE=(TRK,(60,15,10)),VOL=SER=PUB000//
The XMITIN DD points to the binary XMIT file loaded into the Hercules virtualcard reader at address x'01c', which Hercules will process as an EBCDIC file.
The XMITOUT DD defines the dataset which will be created from the unpackedXMIT data. Unless you have specific knowledge about the size of thedataset packed into the XMIT file, you will have to estimate the amount of spaceto allocate for the receiving dataset.
IND$FILE
Using IND$FILE to transfer the XMIT from the host Operating System (Windows,Linux, MacOS) requires two steps.
In the first step, IND$FILE is used to transfer the binary XMIT to asequential dataset under MVS. For detailed instructions about usingIND$FILE to transfer files to/from MVS, see IND$FILE: Transferring Files BetweenMVS and the Host OS. When you specify the transfer parameters, youmust specify Transfer binary file and the LRECL must be 80.I have achieved the most consistent success with XMIT files when I also specify BLKSIZEas 80. The dataset into which the XMIT will be placed on MVS is not apermanent dataset, so inefficiencies in blocking factor are not an issue.
In the second step, RECV370 is used to unpack the XMIT dataset that wasuploaded. The JCL is almost identical to that used for unpacking an XMITvia the emulated card reader:
//RECEIVE JOB (1),'UNPACK XMIT',CLASS=A,MSGCLASS=X //RECV01 EXEC RECV370 //XMITIN DD DSN=JAY01.UPLOAD.XMIT,DISP=SHR //XMITOUT DD DSN=JAY01.XEPHON.PDS,DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,SPACE=(TRK,(60,15,10)),VOL=SER=PUB000//
The XMITIN DD points to the Host File Name you used when you upload the fileusing IND$FILE.
The XMITOUT DD defines the dataset which will be created from the unpackedXMIT data, just as it is when using the emulated card reader. Again,unless you have specific knowledge about the size of the dataset packed into theXMIT file, you will have to estimate the amount of space to allocate for thereceiving dataset.
Using XMIT370 to Create an XMIT Containing MVS Datasets
There are also two methods that may be used to create an XMIT dataset andexport it to the host OS. The first method utilizes a Hercules emulatedcard punch to create the XMIT and the output will be transferred to the host PCusing an emulated card punch. In the second method an XMIT is firstcreated in an MVS sequential dataset and then IND$FILE is used to transfer theXMIT dataset from MVS to the host PC.
Emulated Card Punch
If you have a card punch defined on your MVS system that is not controlled byJES2, it may be used to write the XMIT file onto the host PC file as it iscreated by XMIT370. If all of your card punches are controlled by JES2, itis possible to use JES2 commands to drain a card punch so that it is free touse, but I prefer not to enter the morass of changing JES2 operations and willnot be describing that process here; so if you have a system with a free punch(which is the case if you generated your system following my instructions) youare ready to go.
The records XMIT370 writes to the XMIT file are in EBCDIC format, so you donot want Hercules to attempt to translate them to ASCII as it writes them.So on the Hercules command window, you will use the ebcdic operand whenyou devinit the card punch to open the output file on the host PC.In an MVS system generated following my instructions, I use the card punch atx'01d', so the Hercules command is:
devinit 01d <file on the host PC to receive the XMIT content> ebcdic
and substitute the name of the file to be created on your host PC for<file on the host PC to receive the XMIT content>.
The load module for XMIT370 is in SYSC.LINKLIB on SYSCPK and the cataloguedprocedure for XMIT370 is in SYSC.PROCLIB on SYSCPK, so it is necessary for youto have SYSCPK installed and integrated into your MVS system. With thecatalogued procedure, the JCL required to create the XMIT file is minimal:
//TRANSMIT JOB (1),'CREATE XMIT',CLASS=A,MSGCLASS=X //XMIT01 EXEC XMIT370 //XMITIN DD DSN=SYS2.CMDLIB,DISP=SHR //XMITOUT DD UNIT=01D,DCB=(RECFM=FB,LRECL=80,BLKSIZE=80)//
The XMITIN DD points to the sequential (DSORG=PS) or partitioned (DSORG=PO)dataset to be placed into the XMIT file.
The XMITOUT DD points to the virtual card punch at address x'01d', whichHercules will process as an EBCDIC file.
After the job completes, use the Hercules devinit command to close the fileon the host OS:
devinit 01d pch01d.txt ascii
The output file you specify in the command has no relevance to the XMIT thatwas written, so I usually use pch01d.txt and I also specify the asciioperand to leave the emulated punch file in translation mode.
IND$FILE
Just as with transferring an XMIT file to MVS from the host OS, you cancomplete the process in two steps, first using XMIT370 to create the XMITdataset on MVS and then use IND$FILE to transfer the XMIT from MVS to the hostOS (Windows, Linux, MacOS).
In the first step, XMIT370 is used to create the binary XMIT dataset:
//TRANSMIT JOB (1),'CREATE XMIT',CLASS=A,MSGCLASS=X //XMIT01 EXEC XMIT370 //XMITIN DD DSN=SYS2.CMDLIB,DISP=SHR //XMITOUT DD DSN=JAY01.CMDLIB.XMIT,DISP=(NEW,CATLG,DELETE),// UNIT=SYSDA,VOL=SER=PUB001,SPACE=(TRK,(60,30))//
The XMITIN DD points to the sequential (DSORG=PS) or partitioned (DSORG=PO)dataset to be placed into the XMIT file.
The XMITOUT DD defines a sequential dataset that will contain the createdXMIT dataset.
In the second step, IND$FILE is used to transfer the XMIT dataset created byXMIT370 above - JAY01.CMDLIB.XMIT - to an XMIT file on the host OS. Fordetailed instructions about using IND$FILE to transfer files to/from MVS, see IND$FILE: Transferring Files BetweenMVS and the Host OS. When you specify the transfer parameters, youmust specify Transfer binary file.
I hope that you have found my instructions useful. If you havequestions that I can answer to help expand upon my explanations and examplesshown here, please don't hesitate to send them to me:
Return to Site Home Page Frequently Asked Questions
This page was last updated on July 10, 2020.
