Transmit and Receive

In later versions of MVS (OS/390 and z/OS) a pair of TSO commands evolved that can be used to package datasets into a compact form for sharing (transmission) between TSO users.  It has since become a standard for moving 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 character records.  Partitioned datasets are first unloaded using the IEBCOPY utility before being packaged into the 80 character format.

On the 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 - that may be used to provide the same functions as TRANSMIT and RECEIVE, although they run in batch, not under TSO.  These programs are present in the SYSCPK volume of compilers and tools that is available from my site.  Jim's distribution file, including the source code and documentation is available on the SYSCPK volume in the dataset SYSC.RECV370.ASM.  The PROCedures for executing 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 and reconstruct the datasets that they contain.  The first method utilizes a Hercules emulated card reader to transfer the XMIT to MVS and extract its contents into the recreated datasets in a single step.  The second method uses IND$FILE to transfer the XMIT to MVS and then a batch job is run to extract its contents into the recreated datasets.

Emulated Card Reader

If you have a card reader defined on your MVS system that is not controlled by JES2, it may be used to read the XMIT file and process it directly with RECV370.  If all of your card readers are controlled by JES2, it is possible 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 be describing that process here; so if you have a system with a free reader (which is the case if you generated your system following my instructions) you are ready 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 not want Hercules to attempt to translate them from ASCII to EBCDIC as it reads them.  So on the Hercules command window, you will use the ebcdic operand when you devinit the card reader to open the XMIT file.  In an MVS system generated following my instructions, I use the card reader at x'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 the PC>.

The load module for RECV370 is in SYSC.LINKLIB on SYSCPK and the catalogued procedure for RECV370 is in SYSC.PROCLIB on SYSCPK, so it is necessary for you to have SYSCPK installed and integrated into your MVS system.  With the catalogued 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 virtual card 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 unpacked XMIT data.  Unless you have specific knowledge about the size of the dataset packed into the XMIT file, you will have to estimate the amount of space to 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 a sequential dataset under MVS.  For detailed instructions about using IND$FILE to transfer files to/from MVS, see IND$FILE: Transferring Files Between MVS and the Host OS.  When you specify the transfer parameters, you must specify Transfer binary file and the LRECL must be 80.  I have achieved the most consistent success with XMIT files when I also specify BLKSIZE as 80.  The dataset into which the XMIT will be placed on MVS is not a permanent dataset, so inefficiencies in blocking factor are not an issue.

In the second step, RECV370 is used to unpack the XMIT dataset that was uploaded.  The JCL is almost identical to that used for unpacking an XMIT via 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 file using IND$FILE.

The XMITOUT DD defines the dataset which will be created from the unpacked XMIT 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 the XMIT file, you will have to estimate the amount of space to allocate for the receiving dataset.

Using XMIT370 to Create an XMIT Containing MVS Datasets

There are also two methods that may be used to create an XMIT dataset and export it to the host OS.  The first method utilizes a Hercules emulated card punch to create the XMIT and the output will be transferred to the host PC using an emulated card punch.  In the second method an XMIT is first created in an MVS sequential dataset and then IND$FILE is used to transfer the XMIT 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 by JES2, it may be used to write the XMIT file onto the host PC file as it is created by XMIT370.  If all of your card punches are controlled by JES2, it is possible to use JES2 commands to drain a card punch so that it is free to use, but I prefer not to enter the morass of changing JES2 operations and will not 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) you are ready to go.

The records XMIT370 writes to the XMIT file are in EBCDIC format, so you do not 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 when you 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 at x'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 catalogued procedure for XMIT370 is in SYSC.PROCLIB on SYSCPK, so it is necessary for you to have SYSCPK installed and integrated into your MVS system.  With the catalogued 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', which Hercules will process as an EBCDIC file.

After the job completes, use the Hercules devinit command to close the file on the host OS:

devinit 01d pch01d.txt ascii

The output file you specify in the command has no relevance to the XMIT that was written, so I usually use pch01d.txt and I also specify the ascii operand 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 can complete the process in two steps, first using XMIT370 to create the XMIT dataset on MVS and then use IND$FILE to transfer the XMIT from MVS to the host OS (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 created XMIT dataset.

In the second step, IND$FILE is used to transfer the XMIT dataset created by XMIT370 above - JAY01.CMDLIB.XMIT - to an XMIT file on the host OS.  For detailed instructions about using IND$FILE to transfer files to/from MVS, see IND$FILE: Transferring Files Between MVS and the Host OS.  When you specify the transfer parameters, you must specify Transfer binary file.

I hope that you have found my instructions useful.  If you have questions that I can answer to help expand upon my explanations and examples shown 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 .