F$GETJPI("","PROCESS_RIGHTS") %DCL-W-BUFOVF, command buffer overflow

[Thomas Ritter]

Most of our VMS accounts have over 130 VMS rights identifiers granted. Using the lexical function F$GETJPI("","PROCESS_RIGHTS") results in
"%DCL-W-BUFOVF, command buffer overflow - shorten expression or command line"

Is there an available technique which will allow the usage of F$GETJPI("","PROCESS_RIGHTS") with such a long list of identifiers ?

Sincerely,
Thomas

[John Abbott_2]

Hi Thomas,

What version of VMS are you on ?

V7.3-2 introduced Extended DCL (EDCL), which increased command size limits of the command line interpreter (CLI) as follows:

Structure Old New Size Limits
Interactive DCL 255 4095 bytes
DCL commands in file 1024 8192 bytes
DCL symbols 1024 8192 bytes

Also, the library routines LIB$DO_COMMAND LIB$GET_COMMAND LIB$GET_FOREIGN LIB$GET_SYMBOL LIB$SET_SYMBOL were increase accordingly.

If you're not planning to upgrade or are no this version and have exceeded these new values, then the only alternative I can think of is to rename some of the PROCESS_RIGHTS identidifers to have shorter names (UAF RENAME/ID), in order to keep the user with the most rights within the current limits.

Regards,
John.

[John Abbott_2]

Hopefully this posted comparision will read better...

Structure Old New Size Limits
-------------------------------------------
Interactive DCL 255 4095 bytes
DCL commands in file 1024 8192 bytes
DCL symbols 1024 8192 bytes

Note that logical limits remain unchanged

J.

[Karl Rohwedder]

To get a stable solution regardless of limits and number of idents granted, you can e.g. use a procedure to read the rights and define DCL symbols. I attached a possible example as a starter.

regards Kalle

[Thomas Ritter]

We run vms 7.3-2. I want to be able to use the lexical function f$getjpi with our long list of rights identifiers. Alternatively I will write a C routine, implemented as a foreign command do what I would prefer f$getjpi do for me.
We cannot change the names or length of the identifiers. That would be an application change. It just a pity that the process_rights argument is limited by the DCL string length. At most we would have to store upto 4,000 characters.

[John Abbott_2]

Hi Thomas, the only other option I can think of (assuming the rights aren't holder hidden (if I remember correctly!) is doing something like

$ pipe show process/id=pid/right | search/nooutput/nowarning sys$input " rights_identifier "
$ if $severity .eqs. "3" then ... rights_identifier_not_present...

or some dcl to that effect.

Hope this helps
John.

[John Abbott_2]

One thing about my last post is that I put a space in front of and after the rights_identifier I'm $SEARCHing on, to prevent a mismatch.

e.g.
User has NET$TRACEALLREMOTE and I search on NET$TRACEALL, I'll get a match unless I use these spaces, simple but not obvious.

J.

[Thomas Ritter]

I was really hoping someone would respond with something like "Hi Thomas, there is a new sysgen parameter for customizing DCL symbol lengths. Change this sysgen parameter DCL_MAX_SYMBOL_LENTH from 1024 to 8192 and reboot. The lexical f$getjpi("","PROCESS_RIGHTS") will be able to store the rights identifiers of any of your processes."

:(

John, thanks for your suggestions.

[John Abbott_2]

:-)

All I can suggest is try emailing Guy Peleg (Mr DCL) at dcl@hp.com your thoughts.

I've always recieved a reply from Guy that's had some thought put into it! You never know, it could be something they're working on!

Best
John.

[Jan van den Ende]

Thomas,

are you SURE that the F$GETJPI the problem is??

On ou system, ( 7.3-2 patches until november 2005)

$ xxx = f$fao("!8000*Y")
generates NO error.
$ show symbol xxx
does, as does
$ write sys$output xxx
but
$ write /symbol sys$output xxx
works fine.
$ yyy = f$extract(7000,1000,xxx)
$ sho sym yyy
is fine
$ xxx = xxx + "ABCDEFG"
is fine
$ f$locate("B",xxx) gives 8001, as expected
but no way to get
$ zzz = xxx - "B"
to work.

Symbols up to just over 8000 simple WORK OK.

But not all manipulations on them do!

If you compose your rights list stream, first just cut it up in 1000 char pieces.
Operate on them
(of course you will have to code around the break.


We had your same problem, way back when strings COULD be 4 K, but most string handling functions were limited to 255 char.
We routinely had rightslist strings over 1 K then.

Nowadays a big portion of our users have RIGHTS_LIST strings of over 1 K, some over 2K
(we were unlucky enough to DISCOVER the 7.3-1 bug that corrupted nonpagedpool if the string grew over 4 K )


hth

Proost.

Have one on me.

jpe