Re: z/OS FTP woes - Resolved (maybe)
Hi, You cannot use FTP to create new GDG base, GDG base must exist on the target system before You use FTP to create new versions of GDS (GDG datasets). -- Robert Borkowski BRE Bank SA - DIN Łódź (S/390 Team) Chase, John wrote: 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 -- 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
Re: z/OS FTP woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibbons, Mark Get of a +1 generation of a GDG? I expect that the data set just doesn't exist. Try it with (0) or (-1). No; GET *into* a +1 generation of a GDG (at least that's how I read the syntax of the failing command: GET remote_file local_file (replace ). Do I have the syntax backward (wouldn't be the first time)? -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
Re: z/OS FTP woes
Hi, check if the GDG base EEE.FFF.GGG.HHH exist in Your system. -- Robert Borkowski BRE Bank SA - DIN Łódź (S/390 Team) Chase, John wrote: Hi, All, 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. Messages manual says to see the IP User's Guide and Commands for info about the return and error codes, but I must be blind or worse: I can't find them in that manual. Further, in reading thru all the examples for GET, there isn't one showing a GET into a GDG. The explanations preceding the examples appear to suggest that GETting to a GDG is supported; perhaps there's a hoop or two that we haven't jumped thru correctly? Any ideas appreciated. -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 -- 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
Re: z/OS FTP woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Borkowski Hi, check if the GDG base EEE.FFF.GGG.HHH exist in Your system. It exists. -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
Re: z/OS FTP woes
Do *you* have the syntax backward? I thought you were just helping a programmer with this issue. :-) Anyway, the syntax is correct. I notice, however, going back to your original post, that you mention the working directory is USERID, but the data set name is in single quotes. If the HLQ is supposed to be the USERID, then the quotes should be removed... Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Chase, John Sent: Tuesday, October 04, 2005 10:05 AM No; GET *into* a +1 generation of a GDG (at least that's how I read the syntax of the failing command: GET remote_file local_file (replace ). Do I have the syntax backward (wouldn't be the first time)? -- 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
Re: z/OS FTP woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Greg Shirey Do *you* have the syntax backward? I thought you were just helping a programmer with this issue. :-) Anyway, the syntax is correct. I notice, however, going back to your original post, that you mention the working directory is USERID, but the data set name is in single quotes. If the HLQ is supposed to be the USERID, then the quotes should be removed... Thanks, but the apostrophes are necessary because USERID is the user ID of our automation software which submits the jobs. BTW, I'm still awaiting feedback from the programmer. :-) -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
Re: z/OS FTP woes
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. Messages manual says to see the IP User's Guide and Commands for info about the return and error codes, but I must be blind or worse: I can't find them in that manual. Further, in reading thru all the examples for GET, there isn't one showing a GET into a GDG. The explanations preceding the examples appear to suggest that GETting to a GDG is supported; perhaps there's a hoop or two that we haven't jumped thru correctly? Do you get any ICH408I messages from RACF, or any other messages in the SYSLOG that seem related to the failure? Does the user have authority to both the GDG base name and to the GDG member he's trying to create? Have you made sure that at least one of the conditions documented at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.8?SHELF=EZ2ZO10FDT=20050708142126 or http://makeashorterlink.com/?Z26835BEB is satisfied? Walt -- 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
Re: z/OS FTP woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Walt Farrell On 10/3/2005 8:42 AM, Chase, John wrote: [ snip ] ..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 [ snip ] Do you get any ICH408I messages from RACF, or any other messages in the SYSLOG that seem related to the failure? No. Does the user have authority to both the GDG base name and to the GDG member he's trying to create? USERID has ALTER permission to generic dataset profile EEE.FFF.* (NOEGN; I don't know why). Have you made sure that at least one of the conditions documented at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a 1b950/4.8?SHELF=EZ2ZO10FDT=20050708142126 or http://makeashorterlink.com/?Z26835BEB is satisfied? Yes, a model GDG.MODEL exists on each LPAR involved. Again, I'm still awaiting feedback from the programmer whether any of the other suggestions offered has been tried, and worked or failed. -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
Re: z/OS FTP woes - Resolved (maybe)
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
Re: z/OS FTP woes
I found the Client Error Codes in the IP User's Guide Commands, chapter 4. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.11.2?S HELF=F1A1BK60DT=20050708142126 18 FTP_FILE_ACCESS Data set allocation failure, recall failure, open failure. Not much help, IMO. For what it's worth, we seem to do GET's to +1 GDG's every day at my shop, so it is possible, and I don't see any additional hoop jumping in the jobs that do it. I don't see any example here that includes the (REPLACE parm, so Larry Gray's advice to remove it sounds reasonable. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Chase, John Sent: Monday, October 03, 2005 7:42 AM snip .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. Messages manual says to see the IP User's Guide and Commands for info about the return and error codes, but I must be blind or worse: I can't find them in that manual. Further, in reading thru all the examples for GET, there isn't one showing a GET into a GDG. The explanations preceding the examples appear to suggest that GETting to a GDG is supported; perhaps there's a hoop or two that we haven't jumped thru correctly? -- 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
Re: z/OS FTP woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Greg Shirey I found the Client Error Codes in the IP User's Guide Commands, chapter 4. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.11.2?S HELF=F1A1BK60DT=20050708142126 18 FTP_FILE_ACCESS Data set allocation failure, recall failure, open failure. Not much help, IMO. Yeah, about as precise as using a jackhammer for gem-cutting. :-/ For what it's worth, we seem to do GET's to +1 GDG's every day at my shop, so it is possible, and I don't see any additional hoop jumping in the jobs that do it. I don't see any example here that includes the (REPLACE parm, so Larry Gray's advice to remove it sounds reasonable. I've forwarded that, along with the other suggestions, to the programmer and am awaiting feedback. -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
Re: z/OS FTP woes
I was able to experiment with one of our production FTP jobs. Specifying REPLACE or not specifying it had the same result - a new generation was created. (In my test, the data sets were SMS-managed.) So, that doesn't seem to be the causer, sorry. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Chase, John Sent: Monday, October 03, 2005 10:49 AM I don't see any example here that includes the (REPLACE parm, so Larry Gray's advice to remove it sounds reasonable. I've forwarded that, along with the other suggestions, to the programmer and am awaiting feedback. -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
Re: z/OS FTP woes
In my experience with z/OS FTP, REPLACE never seems to do any harm. It seems to be permissive. It does not say the dataset must pre-exist, just that it may. Any command that will succeed without REPLACE will succeed with REPLACE, apparently. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Greg Shirey Sent: Monday, October 03, 2005 10:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS FTP woes I was able to experiment with one of our production FTP jobs. Specifying REPLACE or not specifying it had the same result - a new generation was created. (In my test, the data sets were SMS-managed.) So, that doesn't seem to be the causer, sorry. -- 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
