Quota Problems

[Joseph Drozdz]

I have a housekeeping job running in batch that purges, deletes and zips up files. I'm getting the below error message in my log file

adding: mpac_zip/do_not_delete/mpact63.log_archive;22 (in=5256356) (out=357828) (deflated 93%)
adding: mpac_zip/do_not_delete/mpactc64.log_archive;27 (in=53129486) (out=3546187) (deflated 93%)
adding: mpac_zip/do_not_delete/mpactc70.log_archive;22

%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

[Dale A. Marcy]

Unfortunately, the message does not tell you which quota. Based on what is happening prior to the error, I would look at the FILLM and BYTLM quotas for the account the batch job is running under. We have an executable called quotamon here that will watch a running process and show the minimum values for the quotas to identify which one is running out, but I do not remember where we obtained it from.

[Steven Schweda · Accepted solution]

Has this been working until now, or is the
whole job something new?

EXQUOTA is always something of a mystery, but
the usual shortage is in page file quota.

SHOW PROCESS /QUOTA, and look for "Paging
file quota:". If it looks small:

SET DEFAULT SYS$MANAGER:
MCR AUTHORIZE
SHOW user
and look for "Pgflquo:". Then:
MODIFY user /PGFLQUO =

Mine (possibly excessive):

alp $ pipe show process /quota | search sys$input paging
Paging file quota: 1718880 Subprocess quota: 6


> [...] (in=5256356) (out=357828)

Are you using Zip's "-v" when you really want
"-V"?

[Hein van den Heuvel]

>> I'm getting the below error message in my log file

I don't think so.
THat error message is not IN your log file, but caused BY the log file.

That's a MAXBUF problem.

There is a record in that log file whcih exceeds sysgen param MAXBUF. Maybe a record with lots of dots?

Use dump/recor to check, or a program or somethign like: $convert/fdl="record; size 2000"/trun x.log tt:


Check this...


$ conv/fdl="record; size 30000; format fixed"/pad/trun tt: tmp.tmp
aap
noot
mies
$ conv/fdl=nl: tmp.tmp tmp.tmp
$ cre tmp.txt
toon
vuur
$ appen tmp.tmp tmp.txt
$ type tmp.txt
toon
vuur
%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded
$
$ mcr sysgen show maxbuf
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
MAXBUF 8192 8192 4096 64000 Bytes D

Good luck!

Hein.

[Steven Schweda]

> I don't think so.

Whoa. I blew right past the "%TYPE", and
assumed (always a mistake) that Zip was
having the problem.

My next question would be, "What are you
trying to TYPE?"

[Hein van den Heuvel]

Steven>> My next question would be, "What are you trying to TYPE?"

Uh... the log file !?


In other words...


$ dir tmp.tmp

Directory EISNER$DRA3:[DECUSERVE_USER.HEIN]

TMP.TMP;1

Total of 1 file.


$ type tmp.tmp
%TYPE-W-SEARCHFAIL, error searching for DRA3:[HEIN]TMP.TMP;
-RMS-E-FNF, file not found

Uh?

:

$ dump/reco tmp.tmp/wid=80
Dump of file DRA3:[HEIN]TMP.TMP;1 on 16-OCT-2007 18:10:21.18

File ID (112207,189,0) End of file block 1 / Allocated 3

Record number 1 (00000001), 59 (003B) bytes, RFA(0001,0000,0000)

41464843 52414553 2D572D45 50595425 %TYPE-W-SEARCHFA 000000
68637261 65732072 6F727265 202C4C49 IL, error search 000010
45485B3A 33415244 20726F66 20676E69 ing for DRA3:[HE 000020
3B504D 542E504D 545D4E49 IN]TMP.TMP;..... 000030

Record number 2 (00000002), 26 (001A) bytes, RFA(0001,0000,003E)

656C6966 202C464E 462D452D 534D522D -RMS-E-FNF, file 000000
646E 756F6620 746F6E20 not found...... 000010

Record number 3 (00000003), 0 (0000) bytes, RFA(0001,0000,005A)

Ah!

Hein.

[John Gillings]

Joseph,

I concur with Hein, I suspect this isn't in the log file, but instead is a result of trying to TYPE the log file.

If you're getting this message as a result of attempting to TYPE the log file,
try EDIT/TPU/READ the log file instead, then scroll down to the ZIP commands and see what lies beyond. EDIT may fail with a similar error. If so, then you need to DUMP the log file in the region of the error.

If that doesn't help, please post the output of DIRECTORY/FULL of the log file.

[kari salminen]

From VMS source listings I can find following quota problems
causing EXQUOTA:

- AST count
- Byte count
- Open file count
- Buffered I/O count
- Direct I/O count
- CPU time limit
- Common event flag block creation
- Pagefile quota
- CXB Buffers (NETDRIVER)
- PORT$W_xBUF_MAX (PEDRIVER)
- Too many Watch Points (WPDRIVER)


You can try the PQUOTA (Process Quota Display, V1.15) tool, found on

- OpenVMS Freeware CDs V4.0

It will show you the quota you are running out.

Depending on your VMS version, you may need to recompile it.

BTW.
The latest PQUOTA is V2.0 with Itanium support, unfortunately it
didn't manage for some reason to the latest freeware CD.
If somebody has a good home for it, please contact me.

[Hoff]

kari: send the package over to Hunter Goatley at Process Software. Hunter's contact info is at http://www.process.com/openvms/index.html

I do not know of anyone at HP that is presently collecting OpenVMS Freeware.

[Hein van den Heuvel]

Kari,

I appreciate your contribution, but please help me understand how it could possibly help in the situation on hand.

This is not a mistery quota problem. It's MAXBUF. Period. No ifs or buts.
It's not running out slowly.
It's a hard stop. One instruction all st well, then next (QIO) and it is all over.

My first reply explains the problem and offers an exact reproducer for you exploration.

Cheers.
Hein.

[Willem Grooters]

Joseph,

Given the moment of the message, it might be a problem with the processing of the last file accessed.
Are you using info-Zip's ZIP, be aware that there is a limit to the size of the ZIP file it can handle. it might simply become too big. (may depend on the ZIP version).
Have you checked the attributes of the last file accessed ( mpac_zip/do_not_delete/mpactc70.log_archive;22). It might well be that the record size of this file exceeds the proces buffer or RMS's abilities (32K max).

It might be a LOGFILE problem, depending how ZIP outoputs the log. I had a similar problem in checking a MySQL database and allow logging. It might sound stupid but if this can be reproduced on the fly, consider disabling verbose processing (if possible). The content can be shown when done (using UNZIP -l, for instance).

@Hein,
DIR succeeds, TYPE fails, DUMP works?

Rings a bell.

It may, or may not be applicable, but have you changed UIC or device protection? I encountered this weird behaviour after changing the process UIC, causing either SYS$OUTPUT - the terminal - to be inaccessable, or similar problems with the files (I cannot tell now - i don't have access to the log where this is described)

[Hein van den Heuvel]

Willem>> @Hein,
Willem>> DIR succeeds, TYPE fails, DUMP works?

Willem, it was a trap I planted for the readers.
A feeble attempt at a joke, yet educational.
Not all things are what they appear to be.
Check again carefully.
The TYPE did NOT fail.
Check the contents of teh records dumped.

Like it?

:-) :-)

Hein.

[Jan van den Ende]

@Hein,

regrettably I have been rather inactive of late.

But indeed, many moons ago I had a similat issue, which I resolved by accident when I EDITed the file (tmp.tmp in your case).

I rather regret not reading this before having it smashed in my face. Now I never know if I WOULD have spotted it without warning... :-(

All the same, _I_ like such jokes!

Proost.

Have one on me.

jpe

[kari salminen]

Hein,

>>> I appreciate your contribution, but please help me understand
>>> how it could possibly help in the situation on hand.

I prefer to give more detailed information about EXQUOTA error message,
which actually is "an error did happen, but I don't tell you which one".

Yes, my information is more general, as you want to concentrate into this
particular case. But, as said, I've seen so many users sitting in the
dark with this error message.


PQUOTA tool helps even unexperienced users to find out easily quota problems.
You can continuously monitor a process to detect diverse quota problems,
like memory leaks etc.


Hoff,
Thanks for the pointer, Hunter has added it to Hunter Goatley's VMS-Freeware FILESERV

http://vms.process.com/scripts/fileserv/fileserv.com?PQUOTA

[Hein van den Heuvel]

Right. And I do appreciate that. Honestly.
I did see the announcement in c.o.v already.

It's just that it woudl not have helped this particular case, and only delays getting to a full understanding, adding confusion.

btw... OpenVMS 8.3 now covers 95% of the quota monitoring needs in SHOW PROC/CONT
Just hit the 'q' on your keyboard and you'll get:

Process _FTA3: 09:37:35
State CUR Working set 377
PID 208008A5 Page faults 517
UIC [HEIN] Event flags C0000007 80000000

# open files remaining 99/100 ( 99%)
Direct I/O count/limit 150/150 (100%)
Buffered I/O count/limit 150/150 (100%)
BUFIO byte count/limit 127616/127616 (100%)
ASTs remaining 248/250 ( 99%)
Timer entries remaining 10/10 (100%)
PGFL quota count/limit 31568/32000 ( 98%)
ENQ quota count/limit 1994/2000 ( 99%)

$8$DKA100:[SYS0.SYSCOMMON.][SYSEXE]SHOW.EXE

Enjoy!
Hein.