When you "play" with a TIOT you use an ENQUEUE of SYSZTIOT to
serialize it.
OPEN and CLOSE use SYSZTIOT, ALLOC and SVC99 use it (ALLOC
probably uses SVC99 rather than DAIR these days, but it has been
a long time since I got into that stuff).
SVC 99 is a specific SVC (Supervisor Call) that typically does
ALLOCation type things. But SVC 99 allows you to even do
DISP=(a,b,c) stuff which ALLOC and BPXWDYN do not do (well,
DISP=(NEW|OLD|MOD) or CATALOG|KEEP|DELETE ) but not the
conditional disposition which SVC99 will let you do. BPXWDYN also
does SVC99 and you can even pass it text units (TUs) (Auth ALC
Services REF(?) has all the SVC 99 stuff you will ever want to
know -- well except the deprecated stuff which you can find in
the DSECTs for SVC99 -- e.g. 3330V anyone?).
[I've just been in BPXWDY2 using COBOL and have demonstrated to
support that the doc is a bit light for COBOL programmers, and
I'm still testing with it -- the COBOL program in question is a
replacement for an ALC program written circa 1979 doing all
things SVC99 could do (within reason) at that time.]
The "RACE" in this case is to see if the TIOT contains a certain
DDName, then attempt to allocate it. Two (or more) tasks may
check for the same TIOT entry, and then one gets SYSZTIOT to do
the ALLOC. The next attempts to get SYSZTIOT and fails because it
is "busy".
Reading of a TIOT without using SYSZTIOT is allowed and one does
so at their own risk. But to update, create or delete an entry
requires serialization or the results are unpredictable -- One
might succeed, but then one might suffer a strange ABEND.
I hope this helps you guys...
Regards,
Steve Thompson
On 3/31/20 7:32 PM, Bob Bridges wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
