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.

Bob Polmanter has written NJE38, which allows transmission of datasets, by way of bisync adapters managed by MVS 3.8j, between two MVS 3.8j systems. The RECEIVE and TRANSMIT TSO commands implemented by NJE38 may also be used to package partitioned or sequential datasets into XMI format, or extract from XMI format partitioned or sequential datasets. The RECEIVE and TRANSMIT TSO commands may be utilized to unpack or create XMI format archives regardless of whether NJE38 is fully active/utilized on the MVS3.8j system for communication with another MVS3.8j system. These RECEIVE and TRANSMIT commands may be used either from the TSO command prompt or in a batch TSO job.

The following topics are covered below:

Using RECV370 to Reconstruct XMIT Contents on MVS 3.8j
Using XMIT370 to Create an XMIT Containing MVS Datasets
Using RECEIVE from NJE38 to Reconstruct XMIT Contents on MVS 3.8j
Using TRANSMIT from NJE38 to Create an XMIT Containing MVS Datasets

Using RECV370 to Reconstruct XMIT Contents on MVS 3.8j

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.

Using RECEIVE from NJE38 to Reconstruct XMIT Contents on MVS 3.8j

The RECEIVE command from NJE38 may be used to extract a dataset from an XMI format archive, regardless of whether NJE38 is fully active/utilized on the MVS3.8j system for communication with another MVS3.8j system. The syntax of the RECEIVE command is:

RECEIVE DATASET( ) [VOLSER( )] [UNIT( )] [DIR( )] INDATASET( ) [PROMPT | NOPROMPT] [QUIET]

The required operands are DATASET and INDATASET.

The DATASET operand specifies the dataset to be created.

The INDATASET operand specifies the XMI dataset from which to extract the dataset. The dataset specified via INDATASET may be a sequential dataset or a single member of a partitioned dataset, ie: dataset(member).

The VOLSER operand specifies the DASD volume where the extracted dataset is to be created. If omitted, a PUBLIC or STORAGE volume will be selected based upon the attributes of the INDATASET.

The UNIT operand specifies a unit name where the extracted dataset is to be created. If omitted, SYSDA is the default unit name.

The DIR operand specifies the number of directory blocks if the incoming partitioned dataset was PDSE.

The PROMPT operand specifies that RECEIVE is to prompt the TSO user to respecify the DATASET or VOLSER after learning the incoming dataset name. PROMPT is the default. If NOPROMPT is specified and there is an existing dataset with the same name as one contained in the XMI dataset, RECEIVE terminates with no opportunity to specify a different name for the target dataset.

The QUIET operand suppresses all informational messages. Error messages will be displayed regardless of the inclusion of the QUIET operand. QUIET also forces NOPROMPT.

Example 1 - Retrieving all members of a partitioned dataset from an XMI contained in a sequential dataset:

Example 2 - Retrieving all members of a partitioned dataset from an XMI contained in a member of a partitioned dataset:

Example 3 - Retrieving a sequential dataset from an XMI contained in a sequential dataset:

Using TRANSMIT from NJE38 to Create an XMIT Containing MVS Datasets

The TRANSMIT command (alias XMIT) from NJE38 may be used to package a dataset into an XMI format archive, regardless of whether NJE38 is fully active/utilized on the MVS3.8j system for communication with another MVS3.8j system. The syntax of the TRANSMIT command is:

TRANSMIT DATASET( ) OUTDATASET( ) [VOLSER( )] [UNIT( )] [MEMBERS(membername-1,membername-n)] [PDS | SEQUENTIAL] [QUIET]

The required operands are DATASET and OUTDATASET.

The DATASET operand specifies the dataset to be encoded into the XMI format dataset to be created. The dataset specified via DATASET may be a sequential dataset, a parititioned dataset, or a single member of a partitioned dataset, ie: dataset(member).

The OUTDATASET operand specifies the dataset into which the XMI format data is to be written. The dataset specified via OUTDATASET may be a sequential dataset or a member of a partitioned dataset. If the dataset specified for OUTDATASET exists, it will be reused, otherwise it will be created.

The VOLSER operand specifies the DASD volume where the XMI dataset is to be created. If omitted, a PUBLIC volume will be selected.

The UNIT operand specifies a unit name where the XMI dataset is to be created. If omitted, SYSDA is the default unit name.

The MEMBERS operand specifies one or more members to be included from DATASET. Use of MEMBERS forces PDS (below). The TSO command line parser enforces a limit of 230 chacters; member names specified that exceed that limit will be truncated and not included in the OUTDATASET.

The PDS operand, if utilized, indicates the single member specified for DATASET is to be transmitted with IEBCOPY unload, thereby preserving the directory information along with the member contents. PDS has no meaning if the DATASET is not specified as a single member of a partitioned dataset.

The SEQUENTIAL operand, if utilized, indicates that the single member specified for DATASET is to be transmitted as a sequential dataset.

The QUIET operand suppresses all informational messages. Error messages will be displayed regardless of the inclusion of the QUIET operand.

Example 1 - Storing all members of a partitioned dataset into an XMI contained in a sequential dataset:

Example 2 - Storing a single member of a partitioned dataset into an XMI contained in a sequential dataset:

Example 3 - Storing all members of a partitioned dataset into an XMI contained in a member of a partitioned dataset:

Example 4 - Storing selected members of a partitioned dataset into an XMI contained in a sequential dataset:

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 April 21, 2025 .