| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 47.1 | bulova::docd$:[gryphon_final...]OVMS_71_VAX_INSTALL.* | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Jan 14 1997 10:06 | 8 |
| 47.2 | | METSYS::THOMPSON | | Mon Jan 20 1997 05:00 | 24 |
| 47.3 | See Upgrade Manual, As Well As Release Notes, New Features... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Jan 20 1997 09:26 | 37 |
| 47.4 | | QUARK::LIONEL | Free advice is worth every cent | Mon Jan 20 1997 10:08 | 9 |
| 47.5 | | METSYS::THOMPSON | | Mon Jan 20 1997 12:27 | 14 |
| 47.6 | | BSS::JILSON | WFH in the Chemung River Valley | Mon Jan 20 1997 12:42 | 7 |
| 47.7 | | QUARK::LIONEL | Free advice is worth every cent | Mon Jan 20 1997 13:01 | 7 |
| 47.8 | You want _another_ LOCKDOWN? :-) | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Jan 20 1997 13:16 | 25 |
| 47.9 | | QUARK::LIONEL | Free advice is worth every cent | Mon Jan 20 1997 14:01 | 6 |
| 47.10 | don't blame Inspect | AUSS::GARSON | DECcharity Program Office | Mon Jan 20 1997 17:16 | 39 |
| 47.11 | Inspect Not Common At Customer Sites | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Jan 20 1997 17:54 | 61 |
| 47.12 | | AUSS::GARSON | DECcharity Program Office | Mon Jan 20 1997 22:40 | 52 |
| 47.13 | Inspect isn't the problem, it's the *solution* | GIDDAY::GILLINGS | a crucible of informative mistakes | Mon Jan 20 1997 23:17 | 23 |
| 47.14 | enqlm | METSYS::THOMPSON | | Tue Jan 21 1997 13:56 | 26 |
| 47.15 | | ORAREP::LASTOVICA | Comparisons are as bad as cliches | Tue Jan 21 1997 14:24 | 27 |
| 47.16 | | AUSS::GARSON | DECcharity Program Office | Tue Jan 21 1997 17:33 | 41 |
| 47.17 | enqlm and sys$creprc | METSYS::THOMPSON | | Tue Jan 28 1997 07:12 | 27 |
|
Regarding the new enqlm limits ...
I find that interactive process login does inherit the 16M lock quota, which
is great!
However - I also gave the same enqlm to an account which is dedicated to an
application. The code reads the sysuaf (via $getuai) and uses the value
returned in $creprc (the PQL$_ENQLM tag) to set enqlm for the process.
The resultant processes do appear to have picked up the 32767 enqlm [they
usually run with about 32650, i.e. 32k less a few locks] but not the 16M.
Where does the magic translation from 32767 as a quota to a code for 4M get
performed?
I would guess that this in LOGINOUT and we do run this image to pick up
the new quota's.
Is it possible that if the process has an enqlm supplied that the switch
does not get done?
Thanks
Mark
|
| 47.18 | | METSYS::THOMPSON | | Wed Jan 29 1997 06:36 | 23 |
|
I managed to resolve this.
We were creating detached processes that ran LOGINOUT with the PRC$_NOUAF
flag. In the quota item list to $creprc we did supply 32767 for enqlm
however it was not interpreted as the unlimited code value.
So it does look as though the switch to large enqlm occurs in the part
of LOGINOUT that reads the UAF and sets up a process - rather than in
the executive process creation mechanism.
That does leave one question, for others who may encounter this, i.e. what
would happen if I supplied a 32 bit value in the item list $creprc? Would
it accept the larger value or just use the lower 16bits?
We can't use this as we want to support VMS 6.1 for a while so V7.1
specific code is off limits..
It also means that not all applications will benefit from the raised
enqlm, particularly those that do their process creation.
Mark
|