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. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* He that can have patience can have what he will. -Poor Richard */ -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, March 31, 2020 18:49 A "race condition" would refer in this case to two tasks both allocating the same "unused" DD name at the same time. I would assume that SVC 99 uses ENQ to prevent this from happening; your Rexx relies on luck (with mighty good odds in its favor). -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Tuesday, March 31, 2020 3:21 PM No, much less efficient (I assume). It's an external REXX exec; the caller feeds it a prefix, and it appends random numbers after the prefix until it hits a string that doesn't represent a DD that is currently allocated. It cannot be very fast, but then I need to call it only once or thrice in any given program. Here's the program in its entirety: /* This REXX tries to return a free DD name of the form <pfx><nnnnn>. Supply a character string as prefix, and optionally a length, and TEMPDD will truncate the prefix to the length and try concatenating various random numbers to the end, looking for one that's not already allocated. After ten tries it gives up, but so far that's never happened to me. */ arg pfx,stemlen /* DDN prefix and trunc length */ if pfx='' then pfx='TEMP' else pfx=strip(pfx) if datatype(stemlen)<>'NUM' then stemlen=7 else stemlen=min(stemlen,8) lpfx=length(pfx) if lpfx>stemlen then do; pfx=left(pfx,stemlen); lpfx=stemlen; end if lpfx=8 then return pfx lsfx=min(8-lpfx,5) sfxmax=copies('9',lsfx) /* Now look for a free DD */ do 10; testdd=pfx||right(random(0,sfxmax),lsfx,'0') if \dsdd(testdd,'DD') then return testdd; end return '!NoFree' /* Call tree: DSDD */ The external call to DSDD uses LISTDSN to check whether the DD exists. It checks up to ten DDs before giving up, but I've never had it fail. Really, I'd expect nothing else; if a routine asks for a DD name starting with "TEST", what are the odds that TEST4914 is already used? I could execute such a command dozens of times without it having to look for a second choice, much less a tenth. Still, I get that this is truly ugly. It just works. Actually I haven't looked at it in some years; now that I do, I notice a bug in it, one I've never triggered so it never came to my attention before. I'll have to fix it; maybe I can improve the ugliness at the same time. What's a "race condition"? -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 31, 2020 17:57 I suspect that uses SVC 99 (what else?) Is that easier than BPXWDYN( 'ALLOC RTDDN(name) ...')? (But do you want finer control of the name space, as GIMSMP does?) What about race conditions? --- On Tue, 31 Mar 2020 17:35:52 -0400, Bob Bridges wrote: >I have a TEMPDD routine that returns a DD name guaranteed to be unused; >otherwise many of my routines would end up conflicting whenever I use them >recursively (sort of). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
