> On 10/3/2005 8:42 AM, Chase, John wrote:
> > Here's the output from an FTP GET (userID and DSNs changed to protect
> > privacy):
> >
> > ..230 USERID is logged on. Working directory is "USERID.".
> > ..EZA1460I Command:
> > ..EZA1736I LOCSITE LRECL=80 BLOCKSIZE=27920 CYLINDERS PRIMARY=2
> > SECONDARY=1 ..EZA1460I Command:
> > ..EZA1736I GET 'AAA.BBB.CCC.DDD' +
> > ..EZA1736I 'EEE.FFF.GGG.HHH(+1)' (REPLACE
> > ..EZA1685W Invalid local file identifier ..EZA1735I Std Return Code =
> > 16000, Error Code = 00018
> >
> > Problem seems to be with GET to a GDG. Programmer says this transfer
> > works if it's a PUT. I've already checked the RACF dataset profiles,
> > and USERID has the requisite access to both dataset names.
OK, here's what appears to be the answer: The same job that normally runs
successfully on LPAR A connecting to LPAR B using the FTP PUT command, was
run on LPAR A using the GET command, but the GDG base EEE.FFF.GGG.HHH does
not exist on LPAR A. When the job is run on LPAR B (where GDG base
EEE.FFF.GGG.HHH exists) and connects to LPAR A using the GET command, it
completes successfully.
As Shmuel Metz is wont to say, "The Devil [was] in the details."
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
