- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- JIB$L_FLAGS
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2011 01:50 AM
тАО02-17-2011 01:50 AM
JIB$L_FLAGS
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2011 02:17 AM
тАО02-17-2011 02:17 AM
Re: 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
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2011 05:31 AM
тАО02-17-2011 05:31 AM
Re: JIB$L_FLAGS
$ 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 ...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2011 12:40 PM
тАО02-17-2011 12:40 PM
Re: JIB$L_FLAGS
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2011 01:10 PM
тАО02-17-2011 01:10 PM
Re: JIB$L_FLAGS
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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-18-2011 01:57 AM
тАО02-18-2011 01:57 AM
Re: JIB$L_FLAGS
I also wrote PWAIT$SDA - an SDA extension for looking at waiting processes which attempts to diagnose this sort of thing.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-18-2011 05:22 AM
тАО02-18-2011 05:22 AM
Re: JIB$L_FLAGS
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