We had this same problem with CA-RUNTCP. The FTP in that originally did the FTP in the RUNTCP address space itself. We had jobs which would create a DSN, try to FTP it, then use it in a later step. The FTP failed because all it did was tell RUNTCP to FTP the dataset, which it could not allocate. We had to break the job in two. Create & FTP in one job, then continue processing in a second, dependent, job. We did this with CA-7. RUNTCP was later enhanced to have an "in line" ftp process (FTP3 as I recall). But we had already decided to convert to IBM's stack.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of NIGEL WOLFENDALE > Sent: Tuesday, August 09, 2011 7:44 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Allocation Conflict with Job > > Now I understand what is going on ! > > The allocation messages IKJ56225I were against the connect > direct address space > (I has assumed they were against the batch job - but didn't > look carefully > enough) The DMBATCH program send the details of what you want > transferred to the > Connect :Direct address space, which actually does the > transfers (and therefore > needs to allocate the dataset) - so as is said below the C:D > address space can't > get hold of the dataset as the ENQ has not been released. I > hope the solution is > twofold - put a delay value into the c:d statements - this > says don't complete > the step in the batch job until the transfer is complete - or > until the delay > value has been exceeded. Then as the next step is APL (why > I've no idea !) - > running under TSO, I can precede it with a TSO Alloc > statement - which will be > hidden from the JCL - so should allow the C:D step to run unhindered. > > > Nigel Wolfendale > nigel.wolfend...@btinternet.com > > > > > ________________________________ > From: Shmuel Metz (Seymour J.) <shmuel+ibm-m...@patriot.net> > To: IBM-MAIN@bama.ua.edu > Sent: Tuesday, 9 August, 2011 12:10:25 > Subject: Re: Allocation Conflict with Job > > In <0598249933121044.wa.nigel.wolfendalebtinternet....@bama.ua.edu>, > on 08/08/2011 > at 09:17 AM, Nigel Wolfendale <nigel.wolfend...@btinternet.com> > said: > > >When we run the job we get message IKJ56225I - dataset is allocated > >to another job or user - try again later (or words to that effect), > >now the job won't run. > > Does CD use Unix System Services? Could the IKJ56225I message be > coming from a process running in another address space? Does CD hand > off requests to a server in another address space? > > >This behaviour seems intuitively wrong - but is it normal - am I > >missing something ? > > It is normal for the Initiator to retain the ENQ until the last step > allocating the dataset has completed. The message is normal only if > the allocation is taking place in another address space, hence the > questions above. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
