process quota exceeded

[Lokesh_2]

I am running a DCL command procedure having the following lines ( among other lines ):

___________________________________________
$defin sys$output sys$manager:a.out
$pipe ucx sho host "''host1'" | searc tt: "''host1'"/nohead
$deassign sys$output
____________________________________________

When I checked the log file of the command procedure, I found the following:
_________________________________________
$defin sys$output sys$manager:a.out
%SYSTEM-F-EXQUOTA, process quota exceeded
__________________________________________


Any idea which quota got exceeded ??

Thanks & regards,
Lokesh Jain

[Antoniov.]

Hard to say!
You could from another terminal use SH PROC TargetProc /CONT where TargetProc is process executing DCL command procedure.
Also you could use SH PROC TargetProc /QUOTA continuously.
I don't known any utility can help you for this scope.

Bye
Antoniov

[Willem Grooters]

Likely to be JTQUOTA (Job table logical name tables, but it will add up process logical names as well) given your output.
If it's the result of the piped command it could be BIOLM (buffered IO); check DIOLN (Direct IO) as well, since PIPE _may_ use a mailbox as well.
Another is PGFLQUOTA - pagefile quota, but in that case you're likely to have run into it earlier.
To check it: see Antonio's response. Be sure to have verification enabled (SET VERIFY)

[Martin P.J. Zinser]

Hello,

you might want to have a look at
http://www.decus.de:8080/www/vms/sw/show_quota.htmlx

Greetings, Martin

[Lokesh_2]

Hi Atoniov & William,

This command procedure is called by a detached process ( which executes this command procedure, whenever a trigger happens ). So, I am not running it interactively ( and that is why cannot use the tricks like sho proc/cont ) . I cannot gererate triggers manually which causes this command procedure to execute. But , now I have modified my command procedure and added the following lines
___________________________________________
$set verify
$sho process/quota
$defin sys$output sys$manager:a.out
$pipe ucx sho host "''host1'" | searc tt: "''host1'"/nohead
$deassign sys$output
$sho process/quota
____________________________________________

I hope, next time when the trigger happens , and the command procedure executes, I will get a good log file to start investigations.

Thanks for the response & regards,
Lokesh

[Willem Grooters]

Lokesh:
Suggestion for enhancement:

$set verify
$sho process/quota
$defin sys$output sys$manager:a.out
$on error then goto shoquo
$pipe ucx sho host "''host1'" | searc tt: "''host1'"/nohead
$deassign sys$output
$exit
$shoquo:
$sho process/quota
$deassign sys$output
$exit

will get into show of quota the moment it goes wrong...

Willem

[Lokesh_2]

Hi Marin,

I cannot open the link:

http://www.decus.de:8080/www/vms/sw/show_quota.htmlx

Is the link correct ??

Thanks & regards,
Lokesh

[Ian Miller.]

re link - the use of port 8080 may be blocked by your firewall.

Re quota problem - may also be BYTLM quota. check accounting record for the process as this may help to indcate which process.

[Martin P.J. Zinser]

Hi,

try

http://zinser.no-ip.info/vms/sw/show_quota.htmlx

instead. This is my private server at home and
unfortunatly tends to be more stable than the
Decus server :-(

Greetings, Martin

[Antoniov.]

Congratulation Lokesh;
Until today I believe a detached process cannot execute DCL command shell.
Willen hint is a very good idea because you can look at quota after error.
Hi Willen, perhaps you wrong to write:
$set verify
$sho process/quota
$defin sys$output sys$manager:a.out
$on error then goto shoquo
$pipe ucx sho host "''host1'" | searc tt: "''host1'"/nohead
$deassign sys$output
$exit
$shoquo:
$deassign sys$output
$! This is outside a.out
$sho process/quota
$exit

Good Luck
Antoniov

[John Gillings]

Lokesh,

Beware of detached processes and quotas. By default, quotas come from the PQL SYSGEN parameters, which tend to be very low.

I recommend always specifying all quotas on your RUN command or $CREPRC call. See examples of RUN/DETACHED commands from procedures in SYS$STARTUP.

Only for the specific case where you're running LOGINOUT.EXE, use RUN/AUTHORIZE qualifier to inherit the quotas from your UAF entry.

That said, since it's a PIPE command that's failing, which involves the creation of subprocesses, my money would be on PRCLM.

Regarding your DCL fragment, rather than DEFINE and DEASSIGN, why not use output redirection? I also prefer to use SYS$PIPE rather than TT:

$pipe ucx sho host "''host1'" | search sys$pipe "''host1'"/nohead /OUTPUT=A.OUT

or, more generally (will work for commands that don't have a /OUTPUT qualifier):

$pipe ucx sho host "''host1'" | searc sys$pipe "''host1'"/nohead > A.OUT

[Willem Grooters]

Antonio,
I _deliberately_ put "show quota" immediately on the label, just because of the assignemtn of SYS$OUTPUT. Deassign would possibly influence the state, where JTQUOTA is involved. That the output will be written in A.OUT, doen't matter.
Another adjustment would however make sense: ON ERROR _before_ DEFINE SYS$OUTPUT would have been better....


John: I forget about that - you're right.

[Antoniov.]

Hi Willen,
you are reasonable; I've only thought file a.out gets from another application that could read quotas as valid data.

Bye
Antoniov

[Lokesh_2]

Hi all,

Many thanks for the overwhelming response I got for my query . Now I have modified my command procedure to the following.
______________________________________
$set verify
$sho process/quota
$pipe ucx sho host "''host1'" | searc sys$pipe "''host1'"/nohead/out=sys$manager:a.out
$sho process/quota
_______________________________________

I am still waiting for the trigger to happen which executes this command procedure. As soon as I receive that I will check the log file again and investigate further about which quota got exceeded.

Best regards,
Lokesh

[Lokesh_2]

Hi Martin,

I am now running command procedure SHOW_QUOTA.COM provided by you. It is very good command procedure. Many thanks for the same. ( I already submitted the point to your answer earlier without running the command procedure, else you deserve more points :) )

Best regards,
Lokesh

[Willem Grooters]

Last thing:

If there is a quota problem in the PIPEd command, it will stop immediately and you'll miss the second SHO PROCESS/QUOTA

add

$ SET NOON

just before or after $ SET VERIFY, so in case of error it WILL get on - showing porcess quota AT THAT MOMENT (what might NOT be what you want)

Yet another suggestion came into my mind:
If accounting is enabled on your system, that _may_ contain info as well, on the moment the process ends - and it's status. However, you _may_ have to enable image accounting for that (which is default OFF, it will generate huge amounts of output. You could consider to eventually enable it explicitly, chech documentation on aaccounting how to do that (HELP ACCOUNTING will do, I think)...
Sorry that this comes so late, it's a tool that's often forgotten (even by me ;-))

[Joseph P. Smith]

Good Morning,

As stated in previous message the default values are very low, and interfere with normal operations. The default values were set when 12 MB of RAM was big news. This is a time of cheap, bountiful RAM. Therefore, I recommend, and have practiced for the past 10 years, modifying PQL_MIN* and PQL_D* parameters to the highest amount demanded by the applications installed on the system.

This is admittedly meatball system management, but has reduced by 99% any mucking about like you are experiencing.

I learned this lesson after Oracle startup failed several times with the EXQUOTA errors during startup, and discovered that the startup process uses the PQL parameters. They were too far anemic for any use.

Although PQL parameters are dynamic, you should modify and document the changes in sys$system:modparams.dat, and run SYS$UPDATE:AUTOGEN in accordance with the documentation to set the parameters permanently.

Hope this helps. ,,, Joe Smith

[Antoniov.]

Lokesh, do you solved?

[Lokesh_2]

Hi Antoniov,

Thanks for asking. Yes, the problem seems to be solved now. I have done following modification in my com procedure:

$open/read/share a dsa0:[nodename]'host1'.dat
$read a hostname
$host := 'hostname
$close a


Here , my file HOST1.DAT contains the host FQDN . I am not searching in UCX hostdata now for nodes FQDN.

Best regards,
Lokesh