On Thu, 1 May 2008 17:00:57 -0400, David Boyes <[EMAIL PROTECTED]> wrote:
>> >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. No offense taken. The data transfered is stored into members of a pre- allocated PDSE. Naming conventions for the member names eventually overwrite old members so it's self-cleaning and PDSE's do not required periodic compressing like normal PDS's do. The FTP userid is dedicated t o this internal process. Changing its password would require human intervention in the first place, but would be a problem if it was done without planning and communication. Resending of data is accomplished by the z/OS side putting a REQUEST member in the PDSE with the dates of the data that need to be resent. Th e sending side always tried to download this member and includes any requested data along with any data it hasn't already tried to send. This process also works identically from non-VM platforms (ie. sending VMWARE accounting data to z/OS) for which using RSCS is not an option. >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. Brian Nielsen
