Re: SVC99 DEALLOC Failure
>...the TEXT unit logic was using the wrong info. That's another reason to post the exact text units when discussing a dynalloc problem rather than just what was intended And of course that applies to other cases, such as not just showing the source but perhaps the expansion if a macro service isn't doing what you think it ought to. Things like "off by a level of indirection" are often apparent if looking at the expansion but far less so when looking at the source. Peter Relson z/OS Core Technology Design
Re: SVC99 DEALLOC Failure
On 10/31/18 8:16 AM, Peter Relson wrote: So y'all will know how things worked out -- I found the issues and fixed them. Please share the details of "the issues", whether they were coding error(s) or were thing(s) that you figured out. Both could be helpful to others, to avoid whatever pitfalls you ran into. Peter Relson z/OS Core Technology Design Quickly, there was confusion with a label being used in the COBOL code. The COBOL area and the ALC DSECT matched, but the wrong label was used so the wrong value was in the "right place" and the TEXT unit logic was using the wrong info. It was Scott (of IBM) over in IBM-main who pointed out something about what SVC99 was doing and it suddenly occurred to me that I may have finger-checked in the COBOL driver. This little incident uncovered another problem: The original TIOT validation routine, based on how things were done with MVS/SP1 (looks up the DDName to see if it is already allocated) was failing. It was telling us that a DDNAME was not in the table when we know it had to be, because it was defined in the JCL. Regards, Steve Thompson
Re: SVC99 DEALLOC Failure
So y'all will know how things worked out -- I found the issues and fixed them. Please share the details of "the issues", whether they were coding error(s) or were thing(s) that you figured out. Both could be helpful to others, to avoid whatever pitfalls you ran into. Peter Relson z/OS Core Technology Design
Re: SVC99 DEALLOC Failure
So y'all will know how things worked out -- I found the issues and fixed them. Now it will deallocate the DD if the DD had been specified by JCL or SVC99. Thanx, Steve Thompson
Re: SVC99 DEALLOC Failure
How about posting a hex dump of your complete DYNALLOC interface data structures upon return from your Unallocation request: S99RB: the DYNALLOC Request Block S99RBX: the DYNALLOC Request Block Extension S99TUNIT: the complete set of DYNALLOC Text Units IGDMCSMG: the set of SMS/DYNALLOC Message Elements There are a lot of possibilities about why your request isn't working as you would like (or expect). FYI, the DUNUNALC text unit specifies that the resource is to be deallocated even if it has the permanently allocated attribute. This most often applies to resources allocated via JCL. Bob
Re: SVC99 DEALLOC Failure
I’ll give that a try. I had thought about that but was puzzled because it is not listed as being needed. I’ll be back at this in the morning. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 29, 2018, at 5:10 PM, Janko Kalinic wrote: > > Try adding the DUNUNALC text unit (x'0007'). The PDS command uses that > in all of it's deallocations. > > Regards, > John K > >> On Mon, Oct 29, 2018 at 3:29 PM Steve Thompson wrote: >> >> Dunno. I’ve never used it. I’ll go look it up and see. >> >> Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. >> Expct mistaks >> >> >>> On Oct 29, 2018, at 4:16 PM, Paul Gilmartin < >> 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: >>> On 2018-10-29, at 14:02:30, Steve Thompson wrote: I'm testing a special in-house developed utility. So it is designed to >> be invoked by a COBOL program. Now, I come back and test the DEALLOC function, and I get a failure >> from SVC99, ... >>> Can you compare the result with BPXWDYN( ... MSG(WTP) ) which >>> gives pretty good diagnostic text? >>> >>> -- gil >>
Re: SVC99 DEALLOC Failure
Try adding the DUNUNALC text unit (x'0007'). The PDS command uses that in all of it's deallocations. Regards, John K On Mon, Oct 29, 2018 at 3:29 PM Steve Thompson wrote: > Dunno. I’ve never used it. I’ll go look it up and see. > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. > Expct mistaks > > > > On Oct 29, 2018, at 4:16 PM, Paul Gilmartin < > 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > > >> On 2018-10-29, at 14:02:30, Steve Thompson wrote: > >> > >> I'm testing a special in-house developed utility. So it is designed to > be invoked by a COBOL program. > >> > >> Now, I come back and test the DEALLOC function, and I get a failure > from SVC99, ... > >> > > Can you compare the result with BPXWDYN( ... MSG(WTP) ) which > > gives pretty good diagnostic text? > > > > -- gil >
Re: SVC99 DEALLOC Failure
Dunno. I’ve never used it. I’ll go look it up and see. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 29, 2018, at 4:16 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On 2018-10-29, at 14:02:30, Steve Thompson wrote: >> >> I'm testing a special in-house developed utility. So it is designed to be >> invoked by a COBOL program. >> >> Now, I come back and test the DEALLOC function, and I get a failure from >> SVC99, ... >> > Can you compare the result with BPXWDYN( ... MSG(WTP) ) which > gives pretty good diagnostic text? > > -- gil
Re: SVC99 DEALLOC Failure
On 2018-10-29, at 14:02:30, Steve Thompson wrote: > I'm testing a special in-house developed utility. So it is designed to be > invoked by a COBOL program. > > Now, I come back and test the DEALLOC function, and I get a failure from > SVC99, ... > Can you compare the result with BPXWDYN( ... MSG(WTP) ) which gives pretty good diagnostic text? -- gil
SVC99 DEALLOC Failure
I'm testing a special in-house developed utility. So it is designed to be invoked by a COBOL program. I'm going to tell you how I got here and all the stuff I've been doing, and then the effects of the SIS (IBMLink search), etc. before I ask my question. So a test of the code, once fixed to run AMODE=31, works when I do an allocation of one of my own data sets using the DD of SYSUT1. When I do this allocate, I do not specify anything special for the text units. I only use the DDNAME, DSNAME and disposition of SHR. Now, I come back and test the DEALLOC function, and I get a failure from SVC99, and in the RBX I get ERROR CODE 0388 - ALL REQUESTS EXCEPT DSNAME ALLOCATIONS REQUIRED KEY NOT SPECIFIED (I know this because the program has SNAP logic built in so I can SNAP the Text units & pointers before and after the SVC99 execution). This is also associated with IKJ56878I and that message makes no sense. But the doc for that message says go read the text messages in the manual, and basically, pay attention to the text keys that are required. Uh, it appears that only the DDNAME is required, but it doesn't say you can't also specify the DSNAME. It makes no difference, I can't get this to work. So, the message manual also says something about DAIRFAIL. Well I haven't played with DAIR directly for so long that I can't remember what manual(s) even hold that info, if they are even published these days. Ok, so I did a bunch of duckduckgo.com searches, and google, and I can't find anything that matches. So then I went to IBMLink and finally got the web pages to display formatted (Chrome) and searched and got no hits for the message, for dairfail, etc. And I was not just looking for APARs and PTFs, I was including other libraries for info as well. [KC comes into this now, and it locked up IE.] So back to Chrome and I can't find the info I need. Does anyone know if there is something special about SYSUTn as a DD for SVC99? I use these all the time via REXX, and I don't have these problems there. So it would seem that it should be simple as I did not turn on any special flags for doing the allocation (e.g., in-use, or similar). Regards, Steve Thompson
