process quota exceed on child process

[Paul Coviello]

I have a PERL script that runs and it kicks off a child process, and we get the following message... I have tried bumping up settings in UAF all to no avail, I have tried AM and show_quota.com... but with it being a child process. I can't find it...
thanks
Paul
Epic::Cache->get_databases_cstat() returned no data or unexpected data while querying Cache instance SPG. Please investigate immediately.

This is likely because the cstat file at ($1$DGA800:[EPIC.SPG.CACHESYS].bin]cstat) is not executable.

--------------------------------------------------------------------------------
This is the raw data that was returned from Cache:

%DCL-W-ACTIMAGE, error activating image $1$DGA800:[EPIC.SPG.CACHESYS.BIN]CSTAT
-CLI-E-IMGNAME, image file $1$DGA800:[EPIC.SPG.CACHESYS.BIN]CSTAT.EXE;1
-SYSTEM-F-EXQUOTA, process quota exceeded


$data = {
'TIMESTAMP' => '1179829468'
};

[Wim Van den Wyngaert]

Try accountng. The messahge is given zhen activating the image. I would suspect pgflq.

How did you activate the process and what did it execute ?

If you do run /input without usage of loginout, the values are derived from pql_d* in sysgen.

Wim

[Paul Coviello]

Try accountng. The messahge is given zhen activating the image. I would suspect pgflq.

How did you activate the process and what did it execute ?

perl [.bin]scheduler.pl -j

If you do run /input without usage of loginout, the values are derived from pql_d* in sysgen.

we have this line which our support person wants us to add in qualifiers for quotas...
print PIPE "RUN/DETACH SYS\$SYSTEM:LOGINOUT.EXE /INPUT=$com_file/OUTPUT=NLA0:/PROCESS=\"$process_name\"";



Wim

[Paul Coviello]

ok some more info I know it works on another node we call Epicn6 which is out of the cluster. Nodes 3,4,5,6 are all ES47's with about 16gb of memory, nodes 1 & 2 are ES40's and have about 4gb of memory. so can I bump up the values on 1 & 2 and not have an affect?

they go left to right... 1-6


PQL_DWSDEFAULT
10064 10336 35424 35424 35424 35600

internal value
629 646 2214 2214 2214 2225

PQL_DWSQUOTA
20128 20672 70848 70848 70848 71200

internal value
1258 1292 4428 4428 4428 4450

PQL_DWSEXTENT
817152 1091584 1595392 1595392 1595392 1763328

[Wim Van den Wyngaert · Accepted solution]

Try increasing PQL_DPGFLQUOTA for a test. It's dynamic, all you need to do is restart the process (best restart father process too).

"we have this line which our support person wants us to add in qualifiers for quotas... "
-> is this the command actually used or a drweam of the support operson ?

If it is, add /page_file=1000000 to the RUN command.

Wim

[Paul Coviello]

well adding that param into the run command looks like it worked!

thanks

[John Gillings]

Paul,

> RUN/DETACH SYS\$SYSTEM:LOGINOUT.EXE

This is NOT a "child" process, it's a DETACHED process (that's what you asked for). Detached processes get their quotas from PQL_Dxxx, which are typically very low - often too low to do anything useful.

You can specify individual quotas with qualifiers (see HELP RUN process). Try:

$ SEARCH SYS$STARTUP:*.COM "/DETACHED" /WINDOW=20

to find examples of fully populated RUN/DETACHED commands.

Special case... since you're running LOGINOUT.EXE you can specify /AUTHORIZE to request your UAF quotas.

[Paul Coviello]

sorry for the wording I was going by our support persons wording... so if I wanted to change the sysgen params is it doable with the memory config I have?

thanks
Paul

[Ian Miller.]

It would be best to change the RUN command to specify the appropriate quotas rather than affecting the default values for all processes.

[John Gillings]

Paul,

>if I wanted to change the sysgen params is
>it doable with the memory config I have?

Although you could change the SYSGEN parameters, that's probably the worst possible solution for type of issue, for several reasons.

First, you're setting system wide parameters to suit a single process. If you have more than one such process, how do you resolve any conflicts?

Second, and more important, you create an application dependence on SYSGEN parameters. The result is invariably that if you ever move the application to another system, it will fail, and someone else wastes time diagnosing the failure. (I've seen this scenario many times) It's always MUCH better to build any dependencies into the application itself.

As a general rule, I strongly recommend against setting any PQL_D* SYSGEN parameters to anything other than their default values.