> Earlier in the thread, SENDFILE and TRANSMIT/XMIT modify the file sent by > packing it into "NETDATA format", and then unpack it at the receiving end. > Regardless of the actual maximum LRECL, the file will be broken down into > 80 byte records for its journey. Of the 80 bytes, there are prefixes on > at least some, perhaps all (been a while since I looked at Netdata format) > records.
At least 8 bytes/data record (one or more INMR05 and possibly a INMR06 record, plus some flag bytes). There are also some setup records transmitted at the front of a job and before each file within a transmission (that's one of the NJE features I mentioned earlier that VM doesn't understand -- multi-file transmissions destined to a VM user. VM splits a multi-file transmission into separate spool files on delivery to a VM user, sometimes in a non-obvious way). > There can be "significant overhead " doing that for large files > -- on both sides of the transmission (whether they are both VM, TSO, or a > mix). Consider whether FTP might be a better alternative (especially if > using the scripting VMFTP package). On the other hand, getting the automation right for using FTP can take far, FAR more time and effort than using NJE if both are available. People time is much more expensive than system resources these days. FTP is also a much larger resource consumer than NJE. Given that most NJE links are either real CTCs or TCPNJE these days (SNANJE is still out there, but getting rarer all the time), and are orders of magnitude faster than the classic BSC or SDLC links, the overhead of NETDATA is pretty trivial these days compared to the annoyance of dealing with automating FTP, particularly between consenting systems.
