Pascal program crashing with -RMS-F-DME, dynamic memory exhausted

[labadie_1]

Not that I am convinced that this is your problem, but while we are on various limits of a process, check peakchan

$ if P1.eqs."" then exit
$ awk := $ sys$common:[syshlp.examples.tcpip.snmp]gawk.exe
$ fillm = f$getjpi("''P1'","fillm")
$ filcnt = f$getjpi("''P1'","filcnt")
$ used = fillm - filcnt
$ say "Process ",p1," has a fillm ",fillm," uses ",used," and peak open channels
"
$ say " "
$ pipe (say "set proc/id=''P1'" ; say "eval @CTL$GL_CHINDX" ) | ana/sys | sea sy
s$pipe Decimal | awk/command="{ print $(NF-1) }" sys$pipe

Or get it on

http://dcl.openvms.org/stories.php?story=08/06/09/6459295

[Brian Reiter]

Hmm curious, changing the file name logical to point to the physical disk seems to have stopped the problem occurring.

I'll install the latest version of LD driver and put the logical back to normal and see if that cures the problem.

Otherwise I nay be looking at an intermittent issue with interactions beween our application and LD driver which only seem to occur when the loading is heavy.

Regards

Brian

[Brian Reiter]

Oh well, looks as though pointing the file at the lgoical disk brings the problem back.

It only seems to be an issue at high loads during our system startup and at some periods overnight. The code change results in a temporary glitch which goes after 10 seconds or so and has no other impact on the system (other than the timestamp file may be out by a few seconds).

cheers

Brian

[Jur van der Burg]

How exactly is LDdriver involved? What (exact) commands did you use to configure it?

Jur.

[Brian Reiter]

Hi Jur,

During startup the system will do an LD CREATE if the container file is missing and then always issue the LD CONNECT. The drive is always initialised as ODS5 with no highwater marking. The volume itself is quite small, normally 1 Gbyte.

No other LD commands are involved and the whole things has worked like a charm for the past 5 years or so.

Could excessive disk queue lengths cause the problem I'm seeing?


cheers

Brian

[Jur van der Burg]

Where is the container file located? On an nfs volume?

:Could excessive disk queue lengths cause the problem I'm seeing?

Can't image that that would be an issue.

Jur.

[Brian Reiter]

Hi Jur,

The container file resides on a physical disk, so I think I can safely rule out NFS.

What is interesting though is that when the error does occur, and using the modified vversion (i.e. ERROR:=CONTINUE on the CLOSE) the Pascal RTL returns error during close rather than the RMS-F-DME.

cheers

Brian

[Hein van den Heuvel]

>> The code change results in a temporary glitch which goes after 10 seconds

and

>> What is interesting though is that when the error does occur, and using the modified vversion (i.e. ERROR:=CONTINUE on the CLOSE) the Pascal RTL returns error during close rather than the RMS-F-DME.

I'm not sure I understand that, but maybe others do.

I guess the program now only sees the "PAS-F-ERRDURCLO, error during CLOSE" from a call to "status" and no longer get access to the underlying RMS error.

To get that the program may need to use a user_action routine, or PAS$FAB but suppose that after a close the fab is gone error or success (not sure)

http://h71000.www7.hp.com/doc/82final/6083/6083pro_020.html#error_recovery_param_sec

" If you specify ERROR := CONTINUE, the program continues to execute regardless of any error conditions encountered during execution of the procedure. If you specify this value, you should use the STATUS function to be certain that the I/O routine worked as expected. "

I'm leaning towards memory corruption and would review any Async / stall / timer operations based on hight activity rates changing behaviour.

Or just live with the current situation until it degrades further, but it would bother me to know that a program is doing uncontrolled stuff.

Cheers,
Hein.

[Hein van den Heuvel]

I thought I had something to help a little, but the timing is probably wrong.

It bothered me to get a DME error from a CLOSE.
So I checked the listings for PASCLOSE
There was a fix back in 1990.

>>> 1-009 - Zero RAB$L_STS and RAB$L_STV before closing file. CCC 25-Jul-1990.

So if a prior operation (OPEN?, READ?) failed with RMS$_DME but was continued from then in the old days the pascal signal routine could pick up the stale RAB error in favor of the close error (in the FAB).

I have to believe that a 1990 era fix made it into the RTL you are running on V7.3-2 which was well after 1990.
But still, I would consider using PAS$RAB to check RAB$L_STS for DME before the close, and report that.

It is much easier to imagine a DME error before CLOSE.
Is this TMS_timestamp.DAT special at all? Simple sequential? Indexed? Global Buffers?


fwiw,
Hein

[Brian Reiter]

Hi Hein

The timestamp file is a one line text file.


cheers

Brian