process quota exceeded

[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