Re: FTP PUT of a temporary dataset
The DD: option can be useful for solving other problems as well. We had case recently where an application occasionally failed in FTPing a 'normally named' data set. The message would be something like 'file not available'. I looked at syslog for a few instances and found each time that a full volume backup was just starting up around the time of the job failure. We had them replace 'FTP dsn...' with 'FTP DD:file...' . Their problem seems to have cleared. The trouble with most dynamic allocation processes is that they are coded for a one shot try: they either work immediately or they fail. JCL allocation, on the other hand, is capable of waiting for a resource (depending on the conflict). A batch job by nature is not usually troubled by a modest wait--as long as the process supports waiting. Walt Farrell [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 04/24/2006 05:41 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: FTP PUT of a temporary dataset On 4/24/2006 7:28 AM, Steve Flynn wrote: Can I PUT a temporary dataset using FTP... For example, I have a job where the last thing it should do is slap some results over to a GDG on another machine. I'd really like to be able to: ...snipped... PUT DD:REPFILE 'SOME.REMOTE.GDG.BASE(+1)' I can't find anything in TCP/IP manuals indicating I can do this, but I thought I'd ask the collective before I start cataloging transient datasets. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.2.4?SHELF=EZ2ZO10GDT=20050708142126 or http://makeashorterlink.com/?F6DD2610D Walt Farrell, CISSP -- 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: FTP PUT of a temporary dataset
The //DD: option also supports DD * and SYSOUT, and all of those other wonderful little features of JCL like DEFER and RLSE and so forth. The temporary file problem is actually a subset of a larger problem - FTP requires that all (non-DD) existing datasets be cataloged, and catalogs all (non-DD) datasets that it creates. Good in most cases, but may not be what you want in all cases. //DD: lets you support PASS and VOL=SER= and so forth. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Skip Robinson Sent: Thursday, April 27, 2006 11:22 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP PUT of a temporary dataset The DD: option can be useful for solving other problems as well. We had case recently where an application occasionally failed in FTPing a 'normally named' data set. The message would be something like 'file not available'. I looked at syslog for a few instances and found each time that a full volume backup was just starting up around the time of the job failure. We had them replace 'FTP dsn...' with 'FTP DD:file...' . Their problem seems to have cleared. -- 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: FTP PUT of a temporary dataset
In a recent note, Charles Mills said: Date: Thu, 27 Apr 2006 11:40:24 -0700 The //DD: option also supports DD * and SYSOUT, and all of those other wonderful little features of JCL like DEFER and RLSE and so forth. I know I had a lot of trouble when //DD: referred to an allocation of PATH='/dev/fd/n'. FTP didn't want to respect the attributes I specified on the DD statement. It seems if it can't find them in the DSCB, it doesn't believe they're there, or it really has cognitive difficulty with //DD: referring to an HFS file. Some of this was fixed by APAR, but not quite to my satisfaction. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: FTP PUT of a temporary dataset
I think the IBM FTP development team, z/OS, and the HFS file system make for an uneasy menage-a-trois. Like many people who did not grow up with MVS's atypical indirect file reference system (i.e., a program opens a DD name that will ultimately point to an actual dataset rather than the dataset name itself) I think the FTP team doesn't quite get it how z/OS dataset references are supposed to work. Why else would the documentation treat DD references as a weird afterthought, and the product designers think DD references were an oddball niche feature that could be left out of the API with no harm done? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Thursday, April 27, 2006 12:27 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP PUT of a temporary dataset In a recent note, Charles Mills said: Date: Thu, 27 Apr 2006 11:40:24 -0700 The //DD: option also supports DD * and SYSOUT, and all of those other wonderful little features of JCL like DEFER and RLSE and so forth. I know I had a lot of trouble when //DD: referred to an allocation of PATH='/dev/fd/n'. FTP didn't want to respect the attributes I specified on the DD statement. It seems if it can't find them in the DSCB, it doesn't believe they're there, or it really has cognitive difficulty with //DD: referring to an HFS file. Some of this was fixed by APAR, but not quite to my satisfaction. -- 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: FTP PUT of a temporary dataset
Walt's link is all you need, but the short version is //DD:REPFILE The earlier (current?) versions of the FTP manual manage to hide this feature like they were ashamed of it or something, but as a result of my grumbling in this forum I was contacted by the head of IP documentation and they have changed the organization of the manual so the DD support is now more obvious - but I don't know if the changes made it into V1R7 or not. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Monday, April 24, 2006 8:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP PUT of a temporary dataset On 4/24/2006 7:28 AM, Steve Flynn wrote: Can I PUT a temporary dataset using FTP... For example, I have a job where the last thing it should do is slap some results over to a GDG on another machine. I'd really like to be able to: ...snipped... PUT DD:REPFILE 'SOME.REMOTE.GDG.BASE(+1)' I can't find anything in TCP/IP manuals indicating I can do this, but I thought I'd ask the collective before I start cataloging transient datasets. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.2.4?SH ELF=EZ2ZO10GDT=20050708142126 or http://makeashorterlink.com/?F6DD2610D -- 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: FTP PUT of a temporary dataset
In a recent note, Walt Farrell said: Date: Mon, 24 Apr 2006 08:41:59 -0400 On 4/24/2006 7:28 AM, Steve Flynn wrote: ...snipped... PUT DD:REPFILE 'SOME.REMOTE.GDG.BASE(+1)' Is FTP GDG-savvy? There's a long litany of problems accessing GDG generations by any method other than JCL DD allocation. I see: 4.8 z/OS V1R7.0 Comm Svr: IP User's Guide and Commands 4.8 Generation data group support ... You cannot use FTP to create a new GDG, ... And, in the next paragraph: ... Therefore, when creating a new GDG [ ... ], at least one of the following must be true: ... ??? So, they tell me I can't do it, then proceed to tell me the rules for doing it? Needs editorial revision. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.2.4?SHELF=EZ2ZO10GDT=20050708142126 Wherein I note: 4.2.4 z/OS V1R7.0 Comm Svr: IP User's Guide and Commands 4.2.4 DD name support The FTP Client API does not support DD name transfers. The DD names associated with a batch job that invokes an application program using the FTP Client API are not available to the spawned FTP client process. That's pretty harsh. What was the design rationale for spawning the client process rather than using a more DD name friendly mechanism such as ATTACH? Is there any security concern that would preclude running an FTP server task in the same address space as the caller? But, I wondered, could one use DYNALLOC (BPXWDYN) to capture the volume and provide that to FTP? So, in the same publication: 5.34 z/OS V1R7.0 Comm Svr: IP User's Guide and Commands 5.34 LOCSIte subcommand--Specify site information to the local host VOLume Specifies the volume serial number for allocation of new data sets. Alas, the operant word is new. What was the design rationale for not applying LOCSITE VOLUME likewise to existing data sets? I note that the API restriction does not apply to invoking FTP in a batch job step. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: FTP PUT of a temporary dataset
In a recent note, Steve Flynn said: Date: Mon, 24 Apr 2006 12:27:51 +0100 PUT TEMPDSN 'SOME.REMOTE.GDG.BASE(+1)' However, TEMPDSN doesn't appear to get resolved to it's real temporary name. I had believed the name construct is a JCL interpreter facility, available in no other context. Is there anywhere other than a JCL DD statement where name is effective? -- gil -- StorageTek INFORMATION made POWERFUL -- 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: FTP PUT of a temporary dataset
Are you/they perhaps confusing create a new GDG [new group] with create a new generation of an existing GDG? I *think* FTP can do the latter but not the former. All of the why questions are valid but as useless as many why questions. Why did they do it that way? Because they did. Why they didn't bring the DD support over into the new API is utterly beyond me also, but I gave up questioning these IBM design decisions back about 1972. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, April 24, 2006 10:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP PUT of a temporary dataset -- 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: FTP PUT of a temporary dataset
On Monday 24 April 2006 08:58, Charles Mills wrote: ... the short version is //DD:REPFILE The earlier (current?) versions of the FTP manual manage to hide this feature like they were ashamed of it or something, . My understanding (I may be wrong) is that support for //DD:ddname was a by-product of a change in one of the C routines used by the FTP client, i.e. it's not something that resulted from a change in the code for the FTP client itself. ISTR //DD:ddname was introduced in OS/390 R9 or R10. A few releases later (z/OS 1.2 IIRC), VSAM support became available in the FTP client through the same mechanism, but it's neither documented not supported. Again, this is my understanding, don't take my word for it. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[EMAIL PROTECTED] -- 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: FTP PUT of a temporary dataset
In a recent note, Gilbert Saint-Flour said: Date: Mon, 24 Apr 2006 12:03:42 -0400 My understanding (I may be wrong) is that support for //DD:ddname was a by-product of a change in one of the C routines used by the FTP client, i.e. it's not something that resulted from a change in the code for the FTP client itself. ISTR //DD:ddname was introduced in OS/390 R9 or R10. A few releases later (z/OS 1.2 IIRC), VSAM support became available in the FTP client through the same mechanism, but it's neither documented not supported. Again, this is my understanding, don't take my word for it. It may have originated that way, but nowadays it's not that simple. The behavior is discernibly (and irritatingly) different depending on whether ddname is allocated to a Classic data set or to a UNIX file. Apparently FTP doesn't simply OPEN and QSAM GET/PUT on the ddname. Another unwarranted deviation from the S/360 model of I/O abstraction. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
