Operating System - OpenVMS
1752592 Members
2847 Online
108788 Solutions
New Discussion юеВ

Re: CREPRC and LOGINOUT and QUOTAS

 
SOLVED
Go to solution
Alessandro Colavizza
Occasional Advisor

CREPRC and LOGINOUT and QUOTAS

I need to start a detached, non-interactive application using the $creprc call and the loginout.exe, in a way like this:
...
status = sys$creprc(&pid, &imagename,
&inputname, &outputname, &errorname,
&prvmask, &quota, &procname, priority,
uic, 0, stsflag);
...
imagename is set to "sys$system:loginout.exe" and inputname points to a .com file with some DCL commands (including a RUN command). Stsflag is also set to PRC$M_DETACH.
Everything works fine, but I don't see in the running process the quotas, as set (increased) by the quota list parameter! They are still the same of the user that run the service.
Is it possible to start a CLI via loginout with different quotas from the creator ones? Does it depend on a correct combination of privileges, uic, status or any other $creprc parameter that I misused?
12 REPLIES 12
Volker Halle
Honored Contributor

Re: CREPRC and LOGINOUT and QUOTAS

Alessandro,

welcome to the OpenVMS ITRC forum.

Please check the documentation of $CREPRC, especially the chapter about 'Use of Quota List'.

http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_025.html#jun_147

This explains, that the creating process needs IMPERSONATE or CMKRNL privilege to create a detached process with higher quota values than itself.

Volker.
Alessandro Colavizza
Occasional Advisor

Re: CREPRC and LOGINOUT and QUOTAS

Thank you Volker, for your prompt reply!
Anyway, I forgot to specify that -just to avoid such troubles with privileleges- we always give our application all priv's:

/* initialize process privileges */
prvmask[0] = 0xFFFFFFFF;
prvmask[1] = 0xFFFFFFFF;

This is because our server is dedicated to a single application (there are not interactive users working on it), so the security is not an issue.
The point for me was -if it was at still _possible_ to do that call, because I was not sure this kind of quota setting could work with the "loginout" feature.
Volker Halle
Honored Contributor

Re: CREPRC and LOGINOUT and QUOTAS

Alessandro,

the process calling the $CREPRC system service needs those privs, not the created detached process running LOGINOUT.EXE.

Volker.
Alessandro Colavizza
Occasional Advisor

Re: CREPRC and LOGINOUT and QUOTAS

Well, you're right!
I'd to list my own privileges (which are the privileges for all the application users):

Authorized (and default) Privileges:
ALTPRI BYPASS CMEXEC CMKRNL DIAGNOSE GROUP
GRPNAM IMPERSONATE LOG_IO NETMBX PHY_IO PRMCEB
PRMMBX SETPRV SYSGBL SYSLCK SYSNAM SYSPRV
TMPMBX VOLPRO WORLD
Volker Halle
Honored Contributor

Re: CREPRC and LOGINOUT and QUOTAS

Alessandro,

if it still doesn't work, consider checking the use of the PRC$M_NOUAF stsflg.

Volker.
Wim Van den Wyngaert
Honored Contributor

Re: CREPRC and LOGINOUT and QUOTAS

Also remember that your quotas will not go below the values specified in system parameters PQL_M*.

Wim
Wim
Alessandro Colavizza
Occasional Advisor

Re: CREPRC and LOGINOUT and QUOTAS

Following Wim suggestions, I checked the PQL_M params, and actually found some "strange" values (PQL_M > PQL_D). After adjusting those ones, I also tried with PRC$M_NOUAF, but I got this error for the process run by $creprc:

%SYSTEM-F-EXLNMQUOTA, logical name table is full

But this is not a PQL parameter...!
Volker Halle
Honored Contributor
Solution

Re: CREPRC and LOGINOUT and QUOTAS

Alessandro,

check PQL_DJTQUOTA and PQL_MJTQUOTA or also specify the required values for PQL$_JTQUOTA in yiour quota list - this would be the preferred way !

Volker.
John Gillings
Honored Contributor

Re: CREPRC and LOGINOUT and QUOTAS

Alessandro,

The quota list (PQL) is a complex entity, please read the description in the System Services Reference Manual very carefully.
In addition to the interactions beyween supplied, default and minimum values, the calling process needs IMPERSONATE or CMKRNL to grant a quota higher than their own.

Another potential issue is the PQL structure itself. Since it's unaligned, you need to explicitly disable member alignment when declaring it, like this:

#pragma __member_alignment __save
#pragma __nomember_alignment
typedef struct _pqls
{ char item;
int value;
} pqls;

pqls quota[10];
#pragma __member_alignment __restore

It's difficult to alignment detect errors, as examining the source code, or even the structure under DEBUG, everything will look OK, but $CREPRC will see something very odd because the value field will (by default) be aligned on a longword boundary, rather than immediately following the item code byte. Try examining your quota structure with DBG> EXAMINE/LONG/HEX and make sure all the fields are exactly where you want them to be.

I recommend you experiment with a detached process executing a procedure that just lists the actual process quotas and privileges with F$GETJPI and convince yourself that you can specify precisely what you want.
A crucible of informative mistakes