topic Re: JIB$L_FLAGS in Operating System - OpenVMS

JIB$L_FLAGS

Mulder_1 — Thu, 17 Feb 2011 09:50:24 GMT

How to find out if a process is depleted of any quota from JIB.

Thanks

Re: JIB$L_FLAGS

Ian Miller. — Thu, 17 Feb 2011 10:17:28 GMT

If a process is waiting for a pooled quota i.e on that is shared between processes and it's subprocess then the event flag wait mask in the PCB contains the address of the JIB and a flag is set in JIB$L_FLAGS

JIB$M_BYTCNT_WAITERS indicates job buffered I/O byte count exhausted

JIB$M_TQCNT_WAITERS indicates waiting for timer quota

The process can also be waiting for open file quota if jib.jib$l_filcnt is 0 or page file quota if jib.jib$l_pgflcnt is 0

Re: JIB$L_FLAGS

Hein van den Heuvel — Thu, 17 Feb 2011 13:31:25 GMT

Like Ian indicates.

$ libr/extr=$jibdef/out=tt: sys$library:lib.mlb

$EQU JIB$V_BYTCNT_WAITERS 0
$EQU JIB$V_TQCNT_WAITERS 1

Recent example I had below. I used some hex values with cut & past, but you can also simply use symbols 'PCB' and 'JIB' and such after SET PROCESS.

Hein

$ ANALYZE/SYSTEM
SDA> set proc/id=20218192
SDA> SHOW PROCESS
PCB address 8868FF0
SDA> read sysdef
SDA> exa 8868FF00+PCB$L_EFWM
PCB+000F8: 00000000.886E2440
SDA> ex 886E2440
JIB: 886E2440.886E2440
SDA> format jib
:
FFFFFFFF.886E2460 JIB$L_BYTCNT 03E8702E
FFFFFFFF.886E2464 JIB$L_BYTLM 03E8702E
:
FFFFFFFF.886E2478 JIB$L_TQCNT 00000000
FFFFFFFF.886E247C JIB$L_TQLM 0000000A
:
FFFFFFFF.886E24BC JIB$L_FLAGS 00000002

SDA> show proc /tq ...

Re: JIB$L_FLAGS

John Gillings — Thu, 17 Feb 2011 20:40:21 GMT

> if a process is depleted of any
> quota from JIB.

Most quotas are PROCESS wide, so you determine depletion from the PCB by looking the remaining quota field PCB$L_*CNT. For example PCB$L_ASTCNT, PCB$L_BIOCNT, PCB$L_DIOCNT etc... When one reaches 0 you've run out of that quota.

The corresponding PCB$L_*LM field is a constant setting the initial quota, derived from the PQL when the process was created. It's irrelevant for measuring depletion, unless you want to express the current state as a percentage.

As Ian and Hein have said, there are two quotas which are shared across the whole job, and therefore tracked in the JIB.

JIB$L_FLAGS is set if any process in the job tree is in a resource wait state, pending the return of job wide quota from elsewhere in the job tree. This is also different treatment from other quotas. If you run out of a process only quota, you just fail with some kind of EXQUOTA error, rather than attempting to wait for it.

A few other things about JIB$L_FLAGS:

$EQU JIB$V_BYTCNT_WAITERS 0
$EQU JIB$V_TQCNT_WAITERS 1

Possible values are 0,1,2 or 3. Don't assume you can't see both flags set.

You can't tell WHICH process in the job tree is waiting just by looking at the JIB. There could be numerous processes in the job tree, each in one of the two possible resource states (or indeed, I believe it's possible for a single process to be in BOTH resource wait states, but it would probably take a seriously demented piece of code to achieve it!).

For an individual process, you will see a non zero JIB$L_FLAGS and the JIB address in PCB$L_EFWM.

All that said, for tracking processes poking around in PCBs and JIBs is a rather large hammer. You're better off using the intended system service $GETJPI. The lexical function F$GETJPI can be used from DCL, but be aware that it can only sample a single value at a time. Gathering multiple quotas is therefore expensive, and potentially misleading as there are timing windows between samples.

Re: JIB$L_FLAGS

Hein van den Heuvel — Thu, 17 Feb 2011 21:10:05 GMT

>> You're better off using the intended system service $GETJPI. The lexical function F$GETJPI can be used from DCL, but be aware that it can only sample a single value at a time. Gathering multiple quotas is therefore expensive, and potentially misleading as there are timing windows between samples.

Sure, and one very convenient way to do so is
$ SHOW PROC/CONT /ID=xxxx.
Then hit 'q' for the quota page.

However, the target process is likely in Mutex wait state, and you may have to 'try' several times to 'get in' without "process is suspended" message.

$ show sys/proc=xxxx*
OpenVMS V8.3-1H1 on node xxxxx 17-FEB-2011 15:56:56.92 Uptime 49 05:12:24
Pid Process Name State Pri I/O CPU Page flts Pages
202210A7 xxxxRESP HIB 4 459516 0 00:00:32.65 3532 3176 B
20221662 xxxxSEND MUTEX 6 1365217 0 00:01:40.22 3512 3189 B
$ show proc/id=20221662
%SYSTEM-F-SUSPENDED, process is suspended

But this works anyway:

$ write sys$output f$getjpi("20221662","TQCNT")
0

After a dozen tries: $show proc/id=20221662/cont

Process xxxxSEND 16:08:06
State MWAIT Working set 3189
PID 20221662
:
ASTs remaining 6038/6138 ( 98%)
Timer entries remaining 0/100 ( 0%)
:

btw... I just wrote a GETJPI tool to go over all processes and check all quotas/use.
Want that?

Output for that tool for the above system:

$ perl GETJPI_QUOTAS.PL getjpi_xxxx.tmp

Name Left PID USERNAME Remaining/Quota Image
------- --- -------- ------------ --------/-------- ------------
Timers 0% 20221662 "xxxxSEND" 0/100

Checked 69 processes for 50% quota usage on node xxxx
Sample taken at 17-FEB-2011 14:51:50.37

Quota Max_Use Pql_Min Pql_Def PID Username Image
-------- -------- -------- -------- -------- ------------ ---------------------
Buf_IO 3 100 32 2020041A SYSTEM SMISERVER;
Dir_IO 1 100 32 2021C43F xxxx_BATCH DTR32
Locks 514 300 2048 2021C43F xxxx_BATCH DTR32
Bytes 640 128000 262144 20200407 SYSTEM n.a.
Procs 5 10 32 20220EBC HEIN T4$HIB;
ASTs 100 100 24 20221662 "xxxxSEND"
Files 67 256 128 202210A7 xxxx_BATCH xxxxRESP;
Timers 100 0 16 20221662 "xxxxSEND"
PagFil 52960 512000 700000 20220EBC HEIN T4$HIB;

Re: JIB$L_FLAGS

Ian Miller. — Fri, 18 Feb 2011 09:57:13 GMT

If you want tools then Availability Manager is very good for process quota issues.

I also wrote PWAIT$SDA - an SDA extension for looking at waiting processes which attempts to diagnose this sort of thing.

Re: JIB$L_FLAGS

Hein van den Heuvel — Fri, 18 Feb 2011 13:22:07 GMT

fwiw.... It appears that the problem TQ quoate being exhausted in the case I was looking into, was caused by an interaction between LIB$WAIT and RDB.
We added LIB$K_NOWAKE as flag argument to LIB$WAIT and it is all quiet now. THe offending process now has just 2 Timers used and is in LEF instead of MUTEX state

Hein