Re: Why EZA1685W Invalid local file identifier ?

2020-08-07 Thread Charles Mills
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 ?

2020-08-07 Thread Paul Gilmartin
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 ?

2020-08-07 Thread Charles Mills
> 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 ?

2020-08-07 Thread Charles Mills
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 ?

2020-08-07 Thread Michael Babcock
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 ?

2020-08-07 Thread Charles Mills
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