F$GETSYI("","BYTLM) is not BYTLM in AUTHORIZE

[Kortlandt]

Hiya,

I stumbled over the following, while checking for BYTLM's:
The BYTLM from the GETJPI is NOT the initial BYTLM from the authorize file.

The F$GETJPI BYTLM seems to be the same as BYTCNT.

What is shown in F$GETJPI's BYTLM?

----------------------------------------------------------------------------------------------
$ write sys$output f$fao(" BYTLM: !SL" ,F$GETJPI("","BYTLM") )
BYTLM: 163808

$ pipe mc authorize sh user1 |sea sys$pipe "Bytlm"/exact
Maxjobs: 0 Fillm: 100 Bytlm: 164000
----------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------
$ write sys$output f$fao(" PQL_MBYTLM : !SL",F$GETSYI("PQL_MBYTLM") )
PQL_MBYTLM : 100000

$ write sys$output f$fao(" BYTCNT: !SL",F$GETJPI("","BYTCNT") )
BYTCNT: 163808
----------------------------------------------------------------------------------------------

Thnx,
Bob Kortlandt

[Kris Clippeleyr]

Hi Bob,
Your observation is correct.
The initial BYTLM (from the UAF or from the PQLs) is stored in the field JIB$L_ORG_BYTLM.
The value returned by F$GETJPI("","BYTLM") is the one stored in JIB$L_BYTLM.
The latter has a value somewhat less than the former since for "long term" allocations from non paged pool, like creating mailboxes, the allocation is debited from BYTCNT and BYTLM; for "short term" allocations like buffered I/O, the allocation is debited only from BYTCNT.
Regards,
Kris (aka Qkcl)
PS: There is no "ORG_BYTLM" item for F$GETJPI. You can see the different values by formatting the JIB of a process using SDA.

[Kris Clippeleyr · Accepted solution]

Bob,
Forgot to mention that if you want to have the different values for BYTCNT & BYTLM returned in DCL-symbols, then check out the newest version of QJPI at

http://www.quadratrix.be/qjpi.html

Regards,
Kris (aka Qkcl)

[Kortlandt]

Hi Kris,

Thnx for explanation, looked a bit further and found http://h71000.www7.hp.com/wizard/wiz_7083.html which explains how to acquire the "real" initial value.

Rgds, Bob

(I did remember your QJPI from a couple of yesrs ago)

[John Gillings]

Bob,

Since I don't trust HP to keep the Wizard site online into the future, I'll repost that answer here to reduce the chances it will get lost.

Back when I wrote that response, there was a minor difference in opinion about the "normalization" (in the data base sense) of answers to questions. One of the Wizards, with a VMS engineering background, believed that there should be only ONE copy of each answer, most likely in the FAQ, and all responses to the same question should reference "THE" answer. (The logical extreme of which would be to reduce all Wizard answers to "It's in the FAQ")

My experience, as a support engineer, was that the more copies of a (correct!) answer, the easier it was for people to find it, the less chance it would get lost, and less frustration from customers who know the answer is "out there" but all the links they find are broken.

---------- Repost from Wizards ------------

The Question is:

When the PQL_MBYTLM is set to 100000, why does a $GETJPI or F$GETJPI show the BYTLM for a process as being some value below 100000 ? (eg. 98000).

The Answer is :

For all process quotas except BYTLM, there is a "xxxLM" value and a "xxxCNT" value. The xxxLM value is a constant determined from the system authorization file and/or the PQL SYSGEN parameters and/or the values specified when the process was created. The corresponding "xxxCNT" value is debited and credited as the resource is consumed and released.

BYTLM is different. For non-paged pool, the resource controlled by BYTLM, there are two classes of allocation: "permanent" and "transient". For "transient" allocations, like buffered I/Os, BYTCNT is debited when memory is allocated and credited when the I/O completes and the memory is released.

For "permanent" (more precisely, "long term") allocations, like the creation of mailboxes, the allocation is debited from BOTH BYTCNT and BYTLM. When the mailbox is deleted, both values are credited.

There is a field in the JIB -- JIB$L_ORG_BYTLM -- which stores the original value of BYTLM for the process. In your example case, the ORG_BYTLM value will be 100000. If BYTLM is 98000, that indicates that the process has 2000 bytes of NPAGEDYN on long term allocation.

There is no $GETJPI item to return JIB$L_ORG_BYTLM for a process. It can be examined from SDA by formatting the JIB. For example:

$ ANALYZE/SYSTEM
SDA> READ SYSDEF
%SDA-I-READSYM, 9243 symbols read from SYS$COMMON:[SYS$LDR]SYSDEF.STB;1
SDA> SET PROCESS/INDEX=pid
SDA> FORMAT JIB
FFFFFFFF.80EBB240 JIB$L_MTLFL 80EBB240 JIB
FFFFFFFF.80EBB244 JIB$L_MTLBL 80EBB240 JIB
...

FFFFFFFF.80EBB260 JIB$L_BYTCNT 0001B880
FFFFFFFF.80EBB264 JIB$L_BYTLM 0001BB00
FFFFFFFF.80EBB268 JIB$L_PBYTCNT 00000000
...

FFFFFFFF.80EBB2B4 JIB$L_ODAYHOURS 00000000
FFFFFFFF.80EBB2B8 JIB$L_JOBTYPE 00000000
FFFFFFFF.80EBB2BC JIB$L_FLAGS 00000000
FFFFFFFF.80EBB2C0 JIB$L_ORG_BYTLM 00020000
FFFFFFFF.80EBB2C4 JIB$L_ORG_PBYTLM 00000000
FFFFFFFF.80EBB2C8 JIB$L_JTQUOTA 00000000
JIB$C_LENGTH

SDA> EVALUATE 00020000
Hex = 00000000.00020000 Decimal = 131072 CPU$M_IO_START_AFF
SDA> EVALUATE 0001BB00
Hex = 00000000.0001BB00 Decimal = 113408 CSP+1BB00
SDA> EVALUATE 0001B880
Hex = 00000000.0001B880 Decimal = 112768 CSP+1B880

In this case, the original BYTLM value is 131071, BYTLM is 113405, and BYTCNT is 112768. This indicates that there are 640 bytes outstanding in "short term" allocations and 17664 bytes in "long term" allocations.

[Kortlandt]

Hi John,

The articel you wrote was very usefull, thnx!

I will keep your remark on the Wizard in mind, and will start copying relevant information here, in stead of referencing it by http link.

Thnx, Bob.

[Hoff]

The entire contents of the OpenVMS Ask The Wizard area shipped out on the OpenVMS Freeware V7.0 kit in the directory Ask_The_Wizard and in the Ask directory on the Freeware V8.0 kit.

The entire Wizard archive is also available for direct downloaded from the existing site:

ftp://ftp.hp.com/pub/openvms/WIZARD.ZIP

In general, I'd not assume postings anywhere around to be maintained; if you need it, download yourself a local copy.