NetEx EFT213 Reference Manual Rel 5.4

RECLENGTH is not checked against BLOCKSIZERegular z/OS users should note that for variable length records RECLENGTH represents the length of userdata not including record or block headers. That is, RECLENGTH is really (LRECL-4).These same validations are also done on existing data sets that are to be read or overwritten by NetEx/eFT.IBM z/OS Data Set Organizations Supported byNetEx/eFTNetEx/eFT supports two types of z/OS data set organizations, Sequential and Partitioned. Entire sequentialdata sets may be transferred from an z/OS host to any other host on the network. Partitioned data sets on theother hand cannot be transferred as a single file. A member name must be specified. However, using wildcarding,an entire partitioned data set may be transferred member-by-member. Partitioned data set directoryinformation is not processed by NetEx/eFT for IBM z/OS, and will not be transferred when a member is sent.There is currently no support in z/OS NetEx/eFT for transferring concatenated data sets or for transferringVSAM data sets in native format. VSAM data sets can be unloaded to a sequential format (IDCAMS Export),transferred to another host, and reloaded (IDCAMS Import).IBM z/OS Record Formats Supported by NetEx/eFTNetEx/eFT supports data sets of Fixed, Variable and Undefined length records. In addition, these data setsmay have record characteristics such as Spanned, Blocked, ANSI or Machine code control characters. Whencreating a new data set, you declare its record format (RECFM) by setting the SEND or RECEIVE qualifierRECFORMAT. This value must also be compatible with the qualifier values for BLOCKSIZE andRECLENGTH. See SEND/RECEIVE qualifiers for more information on specifying record formats toNetEx/eFT in “File Handling Under IBM z/OS NetEx/eFT” on page 41.REF-eFT213-R5.4-08 File Handling Under IBM z/OS NetEx/eFT Page 59