Re: Why EZA1685W Invalid local file identifier ?
I don't know. I don't know UNIX (z or otherwise) well enough to have a "feeling" for what is going on. LCD '' fixes it, so my *guess* is that it just somehow has "UNIX paths on the brain" and //DD: looks wrong to it. That's my mental model. No real idea. If it is not documented behavior I would say it feels like a bug to me, too. Too bad I'm a red-headed stepchild (otherwise known as a Dallas customer) rather than a z/OS licensee, and therefore cannot open PMRs. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, August 7, 2020 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why EZA1685W Invalid local file identifier ? On Fri, 7 Aug 2020 14:34:03 -0700, Charles Mills wrote: >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. > Is it possible that when LCD is a UNIX path, GET forks a new address space to facilitate resolution of relative paths, but this loses DDNAMEs? Feels like a bug. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why EZA1685W Invalid local file identifier ?
On Fri, 7 Aug 2020 14:34:03 -0700, Charles Mills wrote: >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. > Is it possible that when LCD is a UNIX path, GET forks a new address space to facilitate resolution of relative paths, but this loses DDNAMEs? Feels like a bug. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why EZA1685W Invalid local file identifier ?
> Doesn’t Filetype=JES try to get JES output from spool? Basically yes. Local file name is still the local file name. The particular syntax shown submits 'legacy.dataset' as a job and retrieves the output into //DD: (when it's working!). That part of the code is all working and has been working for years. And thanks, but we crossed in the mail, I hacked at it until I found it. See my subsequent e-mail. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Michael Babcock Sent: Friday, August 7, 2020 2:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why EZA1685W Invalid local file identifier ? Doesn’t Filetype=JES try to get JES output from spool? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why EZA1685W Invalid local file identifier ?
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:SYS2 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. SYS2 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. SYS2 is definitely allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS2 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:SYS1 '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
Re: Why EZA1685W Invalid local file identifier ?
Doesn’t Filetype=JES try to get JES output from spool? On Fri, Aug 7, 2020 at 3:15 PM Charles Mills wrote: > 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:SYS2 > 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. > SYS2 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. SYS2 is definitely > allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS2 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:SYS1 '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 > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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:SYS2 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. SYS2 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. SYS2 is definitely allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS2 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:SYS1 '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