Increasing logical name table

[Robert Young_13]

How does one increase the system and user logical name table size on VMS? I have done this years ago, but don't recall the appropriate params to change

[labadie_1]

I do not think you need to do it, as I seem to recall that it expands automagically, but I think you are talking about lnmshashtbl and lnmphashtbl

[Martin P.J. Zinser]

Hello Robert,

for users the number of logicals is most of the time limited by the jtquota setting in authorize.

Greetings, Martin

[Craig A Berry]

I don't think I ever knew all the details on what logical name tables at what modes use which resources, nor am I entirely sure what you mean by "table size". However, dynamic memory definitely comes into play and can limit how many logical names you can define. Do a

$ SHOW MEM/POOL

Then create a search list logical with lots of very long equivalence names (up to 128 equivalence names of 255 characters each):

$ DEFINE FOO VERYLONGEQUIVALENCE1,VERYLONGEQUIVALENCE2, ...

Then again do

$ SHOW MEM/POOL

and observe how dynamic memory usage has changed.

Then chech the values of your NPAGEDYN and PAGEDYN system parameters as follows:

$ pipe mcr sysgen show /all | search sys$input dyn

and adjust if necessary.

[labadie_1]

Craig, I would tend to disagree

I think
$ show process/memory
will be lowered if you define a bunch of logicals.

[Hein van den Heuvel]

What logical name table? Process/job/system?
How do you know it needs to be increased? An error message? ("INSFMEM, insufficient dynamic memory"?) Care to share the exact error?

As Martin already indicated, for the popular Job Table one you need to increase the prcoess quota with AUTHORIZE (or the SYS$CREPRC param). Form the AUTHORIZE HELP:
/JTQUOTA=value

"Specifies the initial byte quota with which the jobwide logical
name table is to be created. By default, the value is 4096 on VAX
systems and 4096 on Alpha systems."


You many also try tweaking the (dynamic) SYSGEN Param CLISYMTBL and log in again.

hth,
Hein.

[Jan van den Ende]

Hi,

I tend to agree with Hein:
whenever you get to a logical name table limit it will be the JOB or PROCESS table..
-- Because a job table is available to multiple processes (the master-parent & all subprocesses) it must reside in SYSTEM space. And because there can be MAXPROCESCNT processes, a BIG default value would require BIG (remember, in 1980's perspective) physical memory. Therefore, the default is smallish, governed by PQL_DJTQUOTA, but adjustable by each UAF /JTQUOTA value.

Process logicals are allocated in process space, and together with DCL symbols and DCL labels the available space is governed by CLISYMTBL.
All other tables are allocated from SYSTEM Dynamic memory (can't say out of my head whether Dynamic or NonDynamic), but they constitute a so small fraction of that, you will have run into a host of other problemsd before ever noticing a problem with available space for them. (Maybe Craig HAS found a way though).

So, like Hein wrote, SYSGEN CLISYMTBL for Process logicals, per-account UAF /JTQUOTA
for processes that log in normally (using SYSUAF), SYSGEN PQL_DJTQUOTA for non-SYSUAF, non-processcreation specified processess.
For completeness: SYSGEN PLQ_MJTQUOTA specifies a minimum value that might overrule the SYSUAF or process-creation value.
(not sure if I spelled the PQL params correct, at home now, vannot check)

hth,

Jan

[Himanshu_3]

Hi Robert,

In continuation to many of the previous replies, there is one way which can increase table quota, use show logical/job/full ---- here you will see something which looks like
Quota=(rrr,mmm)
mmm is the table quota, which is set from the UAF value.
rrr is the remaining quota, which decreases as you add names to the table

Now, regarding your problem , if your problem is related to ""logical name table is full"" you can increase JTQUOTa as follows

AUTHORIZE MODIFY username/JTQUOTA=n

The variable n is the size of the job logical name table in
bytes. The default for the job logical name table size is 1024
bytes. The new value takes effect the next time you log in.

The rule of thumb would be to double the current value.

For a detached process, increase the SYSGEN parameter PQL_
DJTQUOTA.
Job Logical Names Require More JTQUOTA on AXP Than VAX Systems

Regards,
Himanshu

[Steve Reece]

I'd agree with Hein and also with Himanshu. The crux of the solution relies on where the problem is occurring. If it's happening to an interactive process then the quotas found in the UAF record will need to be altered. If, on the other hand, it's part of startup that's failing (as it used to on a pair of AlphaServer 8400s and a VAX 7850 that I took over at one point) then the sysgen parameters for those quotas will need to be modified.

Remember - startup "ignores" UAF values to start with as the system has no idea what they might be as it starts to boot.

[Wim Van den Wyngaert]

"Remember - startup "ignores" UAF values to start with as the system has no idea what they might be as it starts to boot."

That's why it is better to start a real process (e.g. batch) that does the startup of your site.

The process STARTUP is created with quotas coming from the pql minimum values. If you increase these, you increase them for other processes too.