Does that make a difference? The method for extracting DYNALLOC messages is well-documented, like the rest of DYNALLOC... kudos to IBM on that. There's some intricate code to write, but once you have, it's a nice thing to have in your tool bag. BPXWDYN will conveniently return the messages in a stemvar, and they appear to be exactly the same as what you get from the EM* interface.
I'm not real sure where DAIR fits in... I get the impression it came first, then DYNALLOC was developed out of it. But it (seems to me) probably uses DYNALLOC internally now. sas On Wed, Apr 1, 2020 at 1:02 PM Seymour J Metz <sme...@gmu.edu> wrote: > Don't forget the old ALLOCATE command for those running under TSO. It uses > a routine called Dynamic Allocation Interface Routine (DAIR) that mostly > uses DYNALLOC but does a few things for itself. > > BTW, does BPXWDYN use DAIRFAIL to format error messages? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Charles Mills <charl...@mcn.org> > Sent: Wednesday, April 1, 2020 12:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARM= vs PARMDD= and symbol substitution > > > By the way, what ~is~ SVC 99? > > First, note that three terms are used pretty much interchangeably: SVC 99, > DYNALLOC, and "Dynamic Allocation." I will use the term SVC 99 here. > DYNALLOC is an assembler macro that does not do much of anything except > issue SVC 99. (You know what a supervisor call is? If not, beyond the scope > of this e-mail. It's a low-level interface into z/OS services.) > > Big picture, envision what a DD statement does. It allocates a dataset to > a DD name. You need DD statements because to open a dataset in z/OS you > need a DD name: when you open a DCB it references a DD name, not a dataset > name. Same thing in Rexx. Now picture a subroutine or API that you could > call from a running program that would do what a DD statement does: > allocate a dataset to a DD name, but in the middle of your program, not > before your program starts. (Yes, you can also do other things with SVC 99, > but that's a good start.) In the situation you wrote about earlier, you > could get rid of your DD statement for SORTOUT DISP=OLD and instead use SVC > 99 to accomplish the same thing -- only 4.5 hours later in the process. > > There are three major ways (yes, there are more than three) to access SVC > 99 services: > > - Some higher level languages do it under the covers. In C I can say > fopen("//MY.DATA.SET", "r") and under the covers LE or C allocates (SVC 99) > MY.DATA.SET to some generated DD name and then opens a DCB using that DD > name. COBOL can do something somewhat similar. Perhaps other languages also. > > - The traditional way of using SVC 99 is here: > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa800/sjdynal.htm. > Don't let the title fool you: most SVC 99 services do not require any > special authorization. It's complicated: lots of control blocks pointing to > each other. But if you need access to every SVC 99 feature and facility, > this is the way to go. Not for the feint-hearted. Not recommended as your > first HLASM project. > > - The new, easy way is: > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb600/wdyn.htm. > Pretty well explained. You code CALL BPXWDYN "ALLOC FI(SORTOUT) > DA(target.dataset) OLD" and voila! (Yes, you probably need some return code > checking also.) > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bob Bridges > Sent: Tuesday, March 31, 2020 4:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARM= vs PARMDD= and symbol substitution > > I'm trying to picture what this would involve. I don't know from SVC 99, > but it seems to me nothing very bad would happen. Suppose my TSO session > is running two threads at the same time. (That never happens, although I > get the impression I could make it possible by some exotic coding. We'll > pretend I know how, for the moment.) One thread RR1 calls TEMPDD, which > claims that DDN12345 is available. Then RR2 grabs DDN12345. When (a > millisecond or so later) RR1 tries to use DDN12345, the system says "no, > sorry, no can do" and abends. I, of course, am puzzled (how could such a > thing happen? Practically speaking it can't, although hypothetically I > guess it can), but that's the worst that'll happen; in reality I'll try RR1 > again, it'll work, and I'll shrug and move on. It's not like a deadly > embrace where two routines just freeze up...is it? > > By the way, what ~is~ SVC 99? Some kind of assembler call, I suppose? > I've written in assemblers, but haven't yet learned HLASM. One of my many > ambitions; still trying to get around to it. > > ---------------------------------------------------------------------- > 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 > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
