What are logical name table ACLs charged against?

[David Jones_21]

I am considering having an application squirrel away some data in appliation ACE's on the job logical name table. I was concerned about consuming the job table quota on LNM$JOB, but did a test and found it wasn't affected. Creating the ACL doesn't seem to make any of the expected quots go down. Am I missing something?

This is on OpenVMS alpha 8.2.

[Wim Van den Wyngaert]

The acl information is kept in sys$system:vms$objects.dat ...

Wim

[Wim Van den Wyngaert]

but not for files (in file headers) and for temporary stuff (in internal structures). And logicals are temp stuff ...

Wim

[Ian Miller. · Accepted solution]

I had a quick wander though the code that updates ORB structures and can't see any updating of quotas.

[Hoff]

If the quota gets charged anywhere, I'd tend to assume that would (eventually?) be JTQUOTA.

[labadie_1]

and monitoring jtquota is easy
$ sh log /job/fu

(LNM$JOB_81663E00) [kernel] [shareable] [Quota=(9664,10240)]

[John Gillings]

David,

Excellent question! You may have discovered a kind of "hole" into which you can store information without being constrained by any quotas.

The only reliable means I can think of for determining an answer is either by reading the source code, or experiment. Your ACEs on a logical name table will be added to the ORB, which I'd expect to be stored in PAGEDYN. Since you observe it doesn't affect JTQUOTA, and it's a shareable structure, so it can't be stored in process private dynamic memory. That really only leaves NPAGEDYN and PAGEDYN. It doesn't need to be non pageable, that narrows it down to PAGEDYN.

To confirm or deny, I'd suggest finding a very quiet system and try adding lots of ACEs while monitoring all types of memory.

If you have a "crash and burn" test system I'd also try adding ACEs until something breaks. (though as some customers of a well known data base product can attest, it can take a very long time to break a system with a PAGEDYN leak). If you find you can store unlimited data from a non-privileged account, I'd definitely be reporting it back to HP as a potentially serious bug.

[David Jones_21]

"If you have a "crash and burn" test system I'd also try adding ACEs until something breaks. ... If you find you can store unlimited data from a non-privileged account, I'd definitely be reporting it back to HP as a potentially serious bug."

I made a test program on an AS800 I have, running 8.2. The ACL can't seem to grow to any more than around 128 8K pages, you start getting 292 errors (INSFMEM, Insufficient Dynamic Memory). I can load 4111 application aces of length 244, 8610 of size 124, and 17684 aces of size 60. It is a per-job limit.

It runs really slow as the list get long, several CPU minutes. Interactive response for other processes gets very bad while it is running (98% kernel mode).

[Jon Pinkley]

Dave,

After you've run your program until it returns INSFMEM, do other things still work?
Are the ACE's being charged against BYTLM/BYTCNT?

Jon

[John Gillings]

David,

INSFMEM possibly means process dynamic memory. Check SHOW PROCESS/MEMORY to see if the depletion is visible.

This region can be made larger with combinations of CTLPAGES and PIOPAGES, but I wouldn't recommend it.

However, this might make sense for LNM$PROCESS, but not for LNM$JOB, which is globally shareable (given sufficient privilege). Are the ACEs visible from other processes?

What happens if you contribute ACEs from multiple processes? Do they each get your apparent limit, or is it pooled between them?

[David Jones_21]

There are a lot of things to investigate. In one test, I ran the program to exhaustion, redefined LNM$JOB to point to the group table (privileged account) and was able to run the program to add the ACES to that table. I'll have to check, but I don't think it was able to add as many.

I suspect that the INSMEM me be from $SET_SECURITY not being able to get working memory to edit the ACL than a limit on ACL itself. It's a limit either way. I may try raising CTLPAGES to see what happens, but I'm inclined to leave PIOPAGES alone.

Another thing to try is set resource wait mode to see if I can get the process in MWAIT and diagnose the resource shortage from there.

[Volker Halle]

David,

ACEs for job logical names are definitely stored in paged pool.

You can obtain the LNMB and LNMX addresses by SDA> CLUE SYSTEM/LOGICALS - look for your LNM$JOB_xxxxxxxx logical name table (xxxxxxxx is the hex system space address of your JIB - Job Information Block in nonpaged pool).

In case of a logical name describing a logical name table, the LNMX is a LNMTH (logical name table header). It's field LNMTH$_ORB points to the ORB, which has a listhead of ACL structures. As can be shown with SDA> CLUE MEM/LAYOUT, those data structure addresses are definitely in paged pool.

Volker.

[David Jones_21]

"ACEs for job logical names are definitely stored in paged pool."

That's good to know, but it begs of question of why that pool consumption isn't being charged against the table quota the same as the logical names.

On my AS800, I did an AUTOGEN when experimented with bumping CTLPAGES from 288 (default) to 360 (1.25*default). The max. number of entries my test program could load per table actually went down sustantially, the drop in MAXPROCESSCNT affected some other relevant parameter.

[Volker Halle]

David,

the $SET_SECURITY system service description lists:

Required Quota
None

Maybe we can bring up this question during the OpenVMS Advanced technical bootcamp next month.

ACEs (for logical name tables) are stored in ACL segments (max. 512 bytes each) in paged pool. Each ACE has a size of max. 256 bytes.
You can see the ACL segments with:

SDA> SHOW POOL/PAGED/TYPE=ACL/SUMM or
SDA> SHOW POOL/PAGED/TYPE=ACL/HEADER

Volker.