Andrew Rowley wrote, in part: >I don't think IBM provides anything that does variable length records >in binary mode correctly for a round trip
To tie this back to the Pipes thread (which nobody asked me to do!): over 30 years ago, I solved one version of this problem on z/VM (VM/ESA at the time) with MAILABLE, a Rexx program that used Pipes to encode one or more files into an email-safe format. It prepended the payload with the code to extract it, so it was sort of like a self-extracting ZIP. Of course this meant you had to trust that I was sending you what I said I was--not something that would abuse your system--but at the time that was a much more reasonable bet than today (not that *I* would send you such a thing, of course, but that you would trust something you'd been sent). Although of course it was just Rexx, so you could prove it to yourself if you wanted. We used this back at Sterling VMD to distribute fixes, load modules, etc. to customers and it worked great. It was even self-healing to the extent that, while it was sending 80-byte records, it would first reflow the payload, so perverse email clients that considered 80 bytes to be too long for one record didn't break it. Didn't even send it as an attachment: just pasted it into the body of the note. This was important because many customers were still on PROFS and so attachments from the Intertubes could be a problem for them. MAILABLE was even used by either Red Hat or SuSE for a while to distribute their VM bootstrapper. A z/OS version would probably XMIT the file(s) first, encode that blob, and then on extraction reverse the process. IF Pipes were universally available, of course, which it is/was on VM. It wasn't very bandwidth-friendly, but the human time saved far outweighed any transmission costs! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
