| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
A customer running MCC V1.3 has reported a problem with the export job
dying for no apparent reason. The accounting record for the job is as
follows. I could not translate the process final status code of
%X10408014. Could someone translate this code for me?
BATCH Process Termination
-------------------------
Username: NETMAN UIC: [NETMAN]
Account: Finish time: 28-NOV-1993 01:41:05.15
Process ID: 2460042D Start time: 24-NOV-1993 15:56:34.75
Owner ID: Elapsed time: 3 09:44:30.40
Terminal name: Processor time: 1 18:59:06.23
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: DFFFFFFF
Remote ID: Privilege <63-32>: FFFFFFFF
Queue entry: 858 Final status code: 10408014
Queue name: EXPORT$BATCH
Job name: Faulding_Export
Final status text: <no text>
Page faults: 18971531 Direct IO: 385397
Page fault reads: 267094 Buffered IO: 3564088
Peak working set: 25000 Volumes mounted: 0
Peak page file: 186777 Images executed: 7
They had experienced some process quota problem with the export job
with the error insufficient virtual memory. They are already increased
the quota to the following values :
pagefile quota : 195,000
virtualpagecnt : 200,000
workingset_ext : 25000
There was no pool expansion - only slight srp expansion. Pagefile quota
usage for the process is at 186,000. The export job used to die very
frequently. Now it has been running for more than 3 days. Quite a
record for this site!
Any ideas welcomed.
Regards,
Denny.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5764.1 | QUARK::LIONEL | Free advice is worth every cent | Mon Nov 29 1993 20:50 | 18 | |
It's:
%CMA-F-EXCCOP, exception raised; VMS condition code follows
Here's how I found it. First, I recognized that the leading 1 was
the INHIB_MSG bit, so I discarded it. I then saw what F$MESSAGE
of %X408014 told me which was %CMA-F-NOMSG. I'm running VMS T6.1
which knows about the CMA facility.
Now it gets tougher. There are no CMA message sections in
SYS$MESSAGE. I started doing an ANALYZE/IMAGE of all the CMA
shareable images to see if they referenced some other message
section, but no joy there. But I noticed that CMA$RTL defined
as universal some other CMA$_ message code, so I whipped up a
three-line Fortran program that linked against CMA$RTL and then
called SYS$EXIT with the appropriate status, with the above result.
Steve
| |||||
| 5764.2 | Leak, but where? | RACER::dave | Ahh, but fortunately, I have the key to escape reality. | Tue Dec 07 1993 16:20 | 27 |
A memory leak by any other name is still a memory leak. That is what it looks like from this side of the pond. (without a closer inspection). From the information provided, it is impossible to tell where the leak (if it is that) might be occuring, or how serious it may be. remember that the exporter (on vms) is running all the access modules it needs and the entire MCC kernel in its process space. So what is identified is that SOME peice of code may have a problem. How about some real information, like the EXACT export commands that were being used? And NOT, "well it was for NODE4", but the real EXACT commands. Then some pointers may be given to help isolate where the real problem is. The CMA exception is because most of the code does not set up exception handlers for things like illegal access to mem, and when they happen, the stack gets unwound, and the system finds an exception routine in the CMA code. So, be a nice person, open a CLD, and put all of the information into the CLD, not just one line saying "See not XXXX in some notes file". | |||||