Who has enqueue on ISPF table?

[Bob Bridges]

The admins of a department I'm doing work for depend on a complex REXX/ISPF application that someone wrote for them years ago. The author is now departed. The app has a common problem: Sometimes one of the admins ties up a table, then forgets and goes to lunch or something and the other admins trying to do the same thing get ISPT036 ("Table in use / TBOPEN issued for table xxxxxxx that is in use, ENQUEUE failed.").

Usually when they run across this problem they give it 30 minutes and then contact a system programmer to bump the offending party. Mostly they hired me to work on other tasks, but they're wondering whether I can modify the app to let the admins do the bumping instead. Whether to grant that authority is of course a separate issue, not related to REXX. But it occurs to me they might be very pleased if I could intercept ISPT036 and display a panel than identifies ~who~ has the table.

It's been a few years since I last did any major work in ISPF, and even then I avoided tables; my memories of enqueue problems are pretty vague. As I recall there's a way to get ISPF to display who's holding an enqueue, but I don't remember whether it works for tables, and I don’t know how I would get REXX to look it up. Can anyone steer me in a useful direction for this?

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* ....Now some of you are scratching your heads and wondering "How does a person with an IQ higher than pastry get Super Glue in his ear and not know it?" But you parents out there are no doubt nodding your heads and saying "It would not surprise me to learn that this man has a three-year-old son." -Dave Barry, _Children May Be Hazardous to Your Health_ */

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Gary Green]

It's been years for me too, but if it were me, I would see if there is
an enqueue MAJOR name associated with ISPF tables. If so, perhaps the
table name could be the minor name?

I found this. Maybe it's what you need?

Member name enqueue (ibm.com) [1]

Links:
------
[1]
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.f54pc00/isppcmmnamen.htm

[Frank Clarke]

Well, you could PROHIBIT enqueues on the table altogether.  Snapshot the table entry that is being worked on; release the table; when an update is requested, compare the snapshot with the current condition of the table; if equal, allow the update (because nothing has changed in the interim); if not equal, issue a "quel domage" message and suggest that the update be re-tried.
In most cases, the update will be allowed.In a few cases, the update will be denied.In a very few cases, the update will be redundant.
This should be standard practice.

[Willy Jensen]

The enqueue looks like so:
SPFEDIT datasetname tablename user

There are various ways to find it, I am using the MXI freeware product. You
probably have a product inhouse.

Willy

-----Oprindelig meddelelse-----
Fra: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> På vegne af Gary
Green
Sendt: 11. marts 2021 04:06
Til: TSO-...@VM.MARIST.EDU
Emne: Re: [TSO-REXX] Who has enqueue on ISPF table?

--
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

[Seymour J Metz]

And what happens when two tasks get equality on the compare concurrently?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Frank Clarke [rexx...@YAHOO.COM]
Sent: Thursday, March 11, 2021 12:09 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Who has enqueue on ISPF table?

Well, you could PROHIBIT enqueues on the table altogether. Snapshot the table entry that is being worked on; release the table; when an update is requested, compare the snapshot with the current condition of the table; if equal, allow the update (because nothing has changed in the interim); if not equal, issue a "quel domage" message and suggest that the update be re-tried.
In most cases, the update will be allowed.In a few cases, the update will be denied.In a very few cases, the update will be redundant.
This should be standard

[Seymour J Metz]

You could modify the application to accept and parse a MODIFY command and authorize admins to issue the MODIFY.

You could modify the application to issue ISGQUERY and put out a better message when TBOPEN gives a return code of 12.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Bob Bridges [robhb...@GMAIL.COM]
Sent: Wednesday, March 10, 2021 7:09 PM
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] Who has enqueue on ISPF table?

[Frank Clarke]

Time is Nature's way of keeping everything from happening at once ;-)

[Bob Bridges]

From: ga...@evergreen-systems.com <ga...@evergreen-systems.com>
Sent: Wednesday, March 10, 2021 22:06



G2> It's been years for me too, but if it were me, I would see if there is an enqueue MAJOR name associated with ISPF tables. If so, perhaps the table name could be the minor name?



R3> I don’t follow this. Is there an ISPF service to call for this, or...?



G2> I found this. Maybe it's what you need? Member name enqueue (ibm.com) <https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.f54pc00/isppcmmnamen.htm>



R3> Nah, thanks but that tells me what the OS generates (an assembler macro, I guess) to do the enqueue in the first place. What I want is a way to find out WHO is holding the table.

---

Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* It is well to remember that the entire universe, with one trifling exception, is composed of others. -John Andrew Holmes */

--- On 2021-03-10 19:09, Bob Bridges wrote:

The admins of a department I'm doing work for depend on a complex REXX/ISPF application that someone wrote for them years ago. The author is now departed. The app has a common problem: Sometimes one of the admins ties up a table, then forgets and goes to lunch or something and the other admins trying to do the same thing get ISPT036 ("Table in use / TBOPEN issued for table xxxxxxx that is in use, ENQUEUE failed.").

Usually when they run across this problem they give it 30 minutes and then contact a system programmer to bump the offending party. Mostly they hired me to work on other tasks, but they're wondering whether I can modify the app to let the admins do the bumping instead. Whether to grant that authority is of course a separate issue, not related to REXX. But it occurs to me they might be very pleased if I could intercept ISPT036 and display a panel than identifies ~who~ has the table.

It's been a few years since I last did any major work in ISPF, and even then I avoided tables; my memories of enqueue problems are pretty vague. As I recall there's a way to get ISPF to display who's holding an enqueue, but I don't remember whether it works for tables, and I don't know how I would get REXX to look it up. Can anyone steer me in a useful direction for this?

[Bob Bridges]

MODIFY: This is the command that the sysprog might use to bump the other
admin off the system? I'm going to leave that question up to IT management,
but if ~I~ were IT management I'd have to think about that a while before
accepting it as a long-term solution.

ISGQUERY: I looked it up, but from what I found, that's an assembler macro.
No way to call that from REXX, surely?

If I don't mind reïnventing the wheel (and I don't, mostly), I could create
a PDS and an external REXX routine that depending on the argument would
write the operator's ACID into a member named after the table, remove it
afterward, or display the current ACID. I wouldn't want the admins to
notice a slowdown, though.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* The road to the promised land runs past Sinai. The moral law may exist
to be transcended; but there is no transcending it for those who have not
first admitted its claim upon them, and then tried with all their strength
to meet that claim, and fairly and squarely faced the fact of their failure.
-C S Lewis, _The Problem of Pain_ */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Seymour
J Metz
Sent: Thursday, March 11, 2021 08:53

You could modify the application to accept and parse a MODIFY command and
authorize admins to issue the MODIFY.

You could modify the application to issue ISGQUERY and put out a better
message when TBOPEN gives a return code of 12.

________________________________________
From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Bob
Bridges [robhb...@GMAIL.COM]
Sent: Wednesday, March 10, 2021 7:09 PM

The admins of a department I'm doing work for depend on a complex REXX/ISPF
application that someone wrote for them years ago. The author is now
departed. The app has a common problem: Sometimes one of the admins ties
up a table, then forgets and goes to lunch or something and the other admins
trying to do the same thing get ISPT036 ("Table in use / TBOPEN issued for
table xxxxxxx that is in use, ENQUEUE failed.").

Usually when they run across this problem they give it 30 minutes and then
contact a system programmer to bump the offending party. Mostly they hired
me to work on other tasks, but they're wondering whether I can modify the
app to let the admins do the bumping instead. Whether to grant that
authority is of course a separate issue, not related to REXX. But it occurs
to me they might be very pleased if I could intercept ISPT036 and display a
panel than identifies ~who~ has the table.

It's been a few years since I last did any major work in ISPF, and even then
I avoided tables; my memories of enqueue problems are pretty vague. As I
recall there's a way to get ISPF to display who's holding an enqueue, but I
don't remember whether it works for tables, and I don’t know how I would get
REXX to look it up. Can anyone steer me in a useful direction for this?

[ITschak Mugzach]

There are several easy ways to know who holds the table:

1. ISPEXEC TBSTAT will tell who last updated the table.
2. SDSF ENQ *; filter major eq SPFEDIT (minor is the table library name).
3. operator command

ITschak

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *

[Seymour J Metz]

MODIFY is the command that an operator can use to pass a request to an application that is expecting it, without the need for the application to do a WTOR. The interface code would have to be written in assembler, but it's not very complicated.

Similarly, it wouldn't be difficult to write an assembler program to issue ISGQUERY and pass results back in REXX variables.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Bob Bridges [robhb...@GMAIL.COM]

Sent: Thursday, March 11, 2021 3:13 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Who has enqueue on ISPF table?

[Bob Bridges]

I've long had an ambition to add HLASM to my repertoire. I've written in
other assemblers, just not on IBM mainframes. I'm not convinced it's a good
idea to subject my client to my first foray into that arena, though. I
should at least be able to write a hello-world program first, no :)?

(This is partly a dejected sign-off - I do have a pure-REXX alternative,
after all - and partly a hint that I could conceivably be talked into it.
Just not sure which is the better idea.)

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* You know it's time to diet when...
...you dance and it makes the band skip.
...your driver's license photo says "Continued on other side".
...you are diagnosed with the flesh-eating virus and the doctor gives you
only 22 years to live. */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Seymour
J Metz
Sent: Thursday, March 11, 2021 15:37

MODIFY is the command that an operator can use to pass a request to an
application that is expecting it, without the need for the application to do
a WTOR. The interface code would have to be written in assembler, but it's
not very complicated.

Similarly, it wouldn't be difficult to write an assembler program to issue
ISGQUERY and pass results back in REXX variables.

________________________________________
From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Bob
Bridges [robhb...@GMAIL.COM]
Sent: Thursday, March 11, 2021 3:13 PM

MODIFY: This is the command that the sysprog might use to bump the other
admin off the system? I'm going to leave that question up to IT management,
but if ~I~ were IT management I'd have to think about that a while before
accepting it as a long-term solution.

ISGQUERY: I looked it up, but from what I found, that's an assembler macro.
No way to call that from REXX, surely?

If I don't mind reïnventing the wheel (and I don't, mostly), I could create
a PDS and an external REXX routine that depending on the argument would
write the operator's ACID into a member named after the table, remove it
afterward, or display the current ACID. I wouldn't want the admins to
notice a slowdown, though.

[Bob Bridges]

1) Unless enqueueing the table updates its stats, I'd rather not depend on TBSTAT. Seems to me it's as likely as anything else that the admin might ~start~ to do an update, and then get distracted and leave his workstation before making any changes.

2) They do use SDSF at this installation. Where would I look up this ENQ command? Is it one of the REXX-interface features?

3) Operator command, now, there's an idea too. We'd have to make sure the admins have the authority to issue that command, but once that question is settled I can write a routine that issues the command, captures the feedback and display the message. But what command would it be? (I was never an operator; their commands are mostly opaque to me.)

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Cats consent to love us. Dogs beg to love us. -Cathryn Michon, Grrl Genius */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of ITschak Mugzach
Sent: Thursday, March 11, 2021 15:25

There are several easy ways to know who holds the table:

1. ISPEXEC TBSTAT will tell who last updated the table.
2. SDSF ENQ *; filter major eq SPFEDIT (minor is the table library name).
3. operator command

--- On Thu, Mar 11, 2021 at 10:13 PM Bob Bridges <robhb...@gmail.com> wrote:
> MODIFY: This is the command that the sysprog might use to bump the
> other admin off the system? I'm going to leave that question up to IT
> management, but if ~I~ were IT management I'd have to think about that
> a while before accepting it as a long-term solution.
>
> ISGQUERY: I looked it up, but from what I found, that's an assembler macro.
> No way to call that from REXX, surely?
>
> If I don't mind reïnventing the wheel (and I don't, mostly), I could
> create a PDS and an external REXX routine that depending on the
> argument would write the operator's ACID into a member named after the
> table, remove it afterward, or display the current ACID. I wouldn't
> want the admins to notice a slowdown, though.
>

> -----Original Message-----
> From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Seymour J Metz
> Sent: Thursday, March 11, 2021 08:53
>
> You could modify the application to accept and parse a MODIFY command
> and authorize admins to issue the MODIFY.
>
> You could modify the application to issue ISGQUERY and put out a
> better message when TBOPEN gives a return code of 12.
>
> ________________________________________
> From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of
> Bob Bridges [robhb...@GMAIL.COM]
> Sent: Wednesday, March 10, 2021 7:09 PM
>
> The admins of a department I'm doing work for depend on a complex
> REXX/ISPF application that someone wrote for them years ago. The
> author is now departed. The app has a common problem: Sometimes one
> of the admins ties up a table, then forgets and goes to lunch or
> something and the other admins trying to do the same thing get ISPT036
> ("Table in use / TBOPEN issued for table xxxxxxx that is in use,
> ENQUEUE failed.").
>
> Usually when they run across this problem they give it 30 minutes and
> then contact a system programmer to bump the offending party. Mostly
> they hired me to work on other tasks, but they're wondering whether I
> can modify the app to let the admins do the bumping instead. Whether
> to grant that authority is of course a separate issue, not related to
> REXX. But it occurs to me they might be very pleased if I could

> intercept ISPT036 and display a panel that identifies ~who~ has the

[ITschak Mugzach]

Just to add to your signature, Bob ...

/* You know it's time to diet when...

you stand on the weighing scale and it response with "please weight one
at a time */

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *

[Johnson, Steve]

At the ISPF version available with z/OS v2r4, there are two ISPF services that may provide you with the information that you need. They are QTABOPEN and QUERYENQ.

The short description for the QTABOPEN is -
The QTABOPEN service allows an ISPF dialog to obtain a list of currently open ISPF tables. The TBSTATS
or TBQUERY service can then be used to obtain more detailed information about each table.

QUERYENQ -
The QUERYENQ service allows an ISPF dialog to obtain a list of all system enqueues, or all system
enqueues that match the specified criteria.

Steve Johnson

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bob Bridges
Sent: Thursday, March 11, 2021 3:06 PM
To: TSO-...@VM.MARIST.EDU
Subject: [EXTERNAL] Re: [TSO-REXX] Who has enqueue on ISPF table?

1) Unless enqueueing the table updates its stats, I'd rather not depend on TBSTAT. Seems to me it's as likely as anything else that the admin might ~start~ to do an update, and then get distracted and leave his workstation before making any changes.

2) They do use SDSF at this installation. Where would I look up this ENQ command? Is it one of the REXX-interface features?

3) Operator command, now, there's an idea too. We'd have to make sure the admins have the authority to issue that command, but once that question is settled I can write a routine that issues the command, captures the feedback and display the message. But what command would it be? (I was never an operator; their commands are mostly opaque to me.)

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Cats consent to love us. Dogs beg to love us. -Cathryn Michon, Grrl Genius */

This message may contain confidential information. If you are not the intended recipient, please notify the sender immediately and delete this email from your system.

[Bob Bridges]

That'll be perfect - just as soon as we get 2.4 installed. Just now we're working through snafus. Maybe I'll wait, though. Thanks, Steve.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* There is nothing more painful to me at this stage in my life than to walk down the street and hear footsteps and start thinking about robbery, then look around and see somebody white and feel relieved. -Jesse Jackson, 1993 */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Johnson, Steve
Sent: Thursday, March 11, 2021 16:31

At the ISPF version available with z/OS v2r4, there are two ISPF services that may provide you with the information that you need. They are QTABOPEN and QUERYENQ.

The short description for the QTABOPEN is - The QTABOPEN service allows an ISPF dialog to obtain a list of currently open ISPF tables. The TBSTATS or TBQUERY service can then be used to obtain more detailed information about each table.

QUERYENQ -
The QUERYENQ service allows an ISPF dialog to obtain a list of all system enqueues, or all system enqueues that match the specified criteria.

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bob Bridges
Sent: Thursday, March 11, 2021 3:06 PM

1) Unless enqueueing the table updates its stats, I'd rather not depend on TBSTAT. Seems to me it's as likely as anything else that the admin might ~start~ to do an update, and then get distracted and leave his workstation before making any changes.

2) They do use SDSF at this installation. Where would I look up this ENQ command? Is it one of the REXX-interface features?

3) Operator command, now, there's an idea too. We'd have to make sure the admins have the authority to issue that command, but once that question is settled I can write a routine that issues the command, captures the feedback and display the message. But what command would it be? (I was never an operator; their commands are mostly opaque to me.)

[Peter Van Dyke]

Bob,

QTABOPEN and QUERYENQ were made available in ISPF many releases before z/OS
2.4.

Regards,
Peter Van Dyke
HCL Software

[Willy Jensen]

As Peter mentioned, QUERYENQ has been around for a while. And I believe that there are no security requirements using it.

I did a quick test:



table='T'left(space(translate(time('l'),' ','.:'),0),7,0)

Address ispexec

"control errors return"

qtable='DDN2DSN'

zerrlm=''

qname='SPFEDIT'

"QUERYENQ TABLE("table") QNAME(QNAME) XSYS"

if rc>2 then say 'enq rc' rc zerrlm

else do

"tbtop" table

"tbquery" table "rownum(rows)"

do rows

"tbskip" table

if word(zenrname,2)=qtable then,

say left(zenjob,8) left(zenqname,8) left(zendisp,1) zenrname

end

end

"tbend" table



I could not make the REQ operand work, the documentation is not consistent on whether it must be a value or a variable name. I tried both without success.



Willy





-----Oprindelig meddelelse-----
Fra: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> På vegne af Bob Bridges
Sendt: 11. marts 2021 23:18
Til: TSO-...@VM.MARIST.EDU
Emne: Re: [TSO-REXX] [EXTERNAL] Re: [TSO-REXX] Who has enqueue on ISPF table?

That'll be perfect - just as soon as we get 2.4 installed. Just now we're working through snafus. Maybe I'll wait, though. Thanks, Steve.



---

Bob Bridges, <mailto:robhb...@gmail.com> robhb...@gmail.com, cell 336 382-7313

/* There is nothing more painful to me at this stage in my life than to walk down the street and hear footsteps and start thinking about robbery, then look around and see somebody white and feel relieved. -Jesse Jackson, 1993 */



-----Original Message-----

From: TSO REXX Discussion List < <mailto:TSO-...@VM.MARIST.EDU> TSO-...@VM.MARIST.EDU> On Behalf Of Johnson, Steve

Sent: Thursday, March 11, 2021 16:31



At the ISPF version available with z/OS v2r4, there are two ISPF services that may provide you with the information that you need. They are QTABOPEN and QUERYENQ.



The short description for the QTABOPEN is - The QTABOPEN service allows an ISPF dialog to obtain a list of currently open ISPF tables. The TBSTATS or TBQUERY service can then be used to obtain more detailed information about each table.



QUERYENQ -

The QUERYENQ service allows an ISPF dialog to obtain a list of all system enqueues, or all system enqueues that match the specified criteria.



-----Original Message-----

From: TSO REXX Discussion List < <mailto:TSO-...@VM.MARIST.EDU> TSO-...@VM.MARIST.EDU> On Behalf Of Bob Bridges

Sent: Thursday, March 11, 2021 3:06 PM



1) Unless enqueueing the table updates its stats, I'd rather not depend on TBSTAT. Seems to me it's as likely as anything else that the admin might ~start~ to do an update, and then get distracted and leave his workstation before making any changes.



2) They do use SDSF at this installation. Where would I look up this ENQ command? Is it one of the REXX-interface features?



3) Operator command, now, there's an idea too. We'd have to make sure the admins have the authority to issue that command, but once that question is settled I can write a routine that issues the command, captures the feedback and display the message. But what command would it be? (I was never an operator; their commands are mostly opaque to me.)



----------------------------------------------------------------------

For TSO-REXX subscribe / signoff / archive access instructions, send email to <mailto:LIST...@VM.MARIST.EDU> LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

--
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

[Jeremy Nicoll]

On Thu, 11 Mar 2021, at 21:36, Frank Clarke wrote:
> The real easy solution is 'education'. 

Agreed...

> I have a third-best solution that I used ...

After reformatting that to make it comprehensible ... I wonder how
reliable it was?

There's no logic to allow for anyone else attempting simultaneous
access to the pds member that contains info on who is using a
specific table.

Updating that list is likely to fail when multiple users are trying to
write to it (or empty it) at the same time.

I'm surprised, considering it was writing to a pds(member) that's
only allocated SHR, that you didn't use an edit macro to do the
updates to the member, so at least there'd have been SPFEDIT (or
was it SPFDSN - I don't remember) ENQ protection of that member.



--
Jeremy Nicoll - my opinions are my own.