> On Sep 4, 2016, at 4:56 PM, Ed Jaffe <[email protected]> wrote: > > On 9/4/2016 10:45 AM, Jesse 1 Robinson wrote: >> All of this is why I default to the often disparaged XMIT/RECEIVE when going >> MVS to MVS. I can almost always get a data set moved that way in less time >> than it takes to (re)correct FTP syntax. XMIT/RECEIVE also works to/from >> z/VM RSCS. > > XMIT is slow and has the _major_ disadvantages of requiring NJE connectivity > between systems and having to issue a RECEIVE command on the target system. > It's OK for a one-off transfer between known NJE partners, but IMHO FTP's > speed, universal connectivity, and MGET/MPUT functionality make it well worth > the relatively small investment in time to learn how to use its options to > get your transfers to work right the first time... > > —
Ed: When I set up a NJE network 25++ years ago. IBM had a utility called BDT (not the expensive one) that was orderable for $85 (??) a month for 12 months. It was reasonably simple to set up for VM and DOS and of course MVS. It was a precursor to send/receive but you could do it in batch. It also had (IIRC) the ability to encrypt the files. Of course it went from dsn-> spool -> NJE -> spool -> to dsn. Great product and at a cheap price. I set up a network of 200+ connections. During the the time I was there there was never a corrupted file whether it was SNA or bisync . It was easily implemented in a batch system and was easily understood by support people who actually did the day to day production. BM came out with the expensive $$ BDT and only supported VTAM (I guess they were trying to get rid of 37xx boxes that ran PEP. Ed ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
