Solved. Is this documented FTP behavior? Looks like a bug to me. z/OS V2R2 for what it's worth.
Given //MYOUTPUT DD SYSOUT=* GET 'my.pds(member)' //DD:MYOUTPUT Succeeds as it should, but not if it is preceded by LCD /u/usr In which case you get the error message of the subject. Is that what people would expect? Is that documented? You can "fix" it by adding LCD '' between the two commands. In other words, GET to a DD fails if the current local directory is a UNIX path. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, August 7, 2020 1:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why EZA1685W Invalid local file identifier ? I apologize: this is an incomplete question. It is impossible to post "everything." The question: I invoke FTP from a z/OS batch program. The indicated statement fails as shown: EZA1736I Quote Site FileType=JES NoTrail EZA1701I >>> Site FileType=JES NoTrail 200 SITE command was accepted EZA1460I Command: EZA1736I Get 'valid.remote.traditional.dataset.name' //DD:SYS00002 EZA1685W Invalid local file identifier EZA1735I Std Return Code = 16000, Error Code = 00018 I looked at the listing in hex: there are no junk characters in there. SYS00002 is dynamically allocated to VIO. I am not in a position to prove that the allocation is correct, but note that the error is on the "file identifier" not on the file characteristics. SYS00002 is definitely allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS00002 DATACLAS ( ) in the system messages. FWIW, the following works correctly earlier in the same FTP command stream, so basic DD: is not the problem. Put //DD:SYS00001 'remote.dataset.name' There are no intervening LOCSITE subcommands. The problem seems to have something to do with the batch program's earlier processing of z UNIX files. I don't have things diagnosed enough to say "it fails if the program does X." It "used to work" so the problem is something subtle. I'm wondering if anyone has seen this before. Perhaps "oh yeah, you have to Y if you do X, otherwise you get that." I have tried with and without setting a DUB default of 1 before the FTP. The GET subcommand frankly just outright seems correct on its face. Thanks, and again, apologies that all of the *possibly* relevant detail is way too voluminous to include. If anyone has a "what about X?" question I will try to answer it. Charles ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
