> >It's also your best route to move files, print and monitoring data over > >to other IBM OSes like z/OS (and non-IBM systems with a little help from > >us) without human intervention. > I recently setup an automated process to FTP to z/OS data extracted from > DISKACNT's ACCOUNT files every day. No RSCS or human intervention > required. > Brian Nielsen
You *can* do FTP to solve the problem. It's just a lot more work handling all the possible problems that FTP can have -- which are legion -- in a reliable programmatic way. Without being critical, does your process handle disk full on the other end? Changed password on the remote userid (note that RSCS doesn't need a live user login on the remote system at all, FTP does if you're not using anon FTP)? Allocation failures on z/OS? FTP doesn't give you an easy way to deal with that, and if the FTP fails, you have to worry about retrying later, etc. If you handled all those problems, then you're way ahead of the game, but it's a lot of work, as you already know. Compare with: SENDFILE FOO ACCT A TO BAR AT ZOS. Fire and forget. Immediate feedback (rc ^=0) if you don't have sufficient spool to hold the file. No remote login required. Automatic retry until the file is sent. No remote disk allocation needed. You also don't have to invent ways to detect the file arriving; most job scheduling packages already know how to trigger on NJE file arrival out of the box. I'm not saying NJE is the only way to transfer files. It's sure easier to do than the alternatives, especially now that you can do it to non-IBM systems. -- db
