Return status 120 from Pascal's OPEN

[Mike Stoddart]

I've noticed in our application that at some point when we call Pascal's OPEN procedure, we get a return value of 120 (insufficient virtual memory). We've seen nothing to support in terms of resourcing or memory usage. In fact, once we detect this error, if we then retry the OPEN it works fine.

I should point out that we define our own user_action for the OPEN, which involves a $create. When the OPEN fails, our user_action isn't called, the 120 status is being raised within the Pascal runtime library.

This file is a disk mapped global and is "opened" and "closed" at regular intervals.

This is OpenVMS 7.2, but I'm not sure if it's version 5.6 or 5.8 of Pascal.

Any suggestions appreciated.

Thanks

[Mike Stoddart]

I should also point out the following:

1) The account's PGFILQUO is 3,000,000
2) The paging file size is 500,000

Thanks

[Volker Halle]

Mike,

welcome to the OpenVMS ITRC forum.

Are you closing and re-opening the file immediately without any kind of wait or delay inbetween ?

If a global section is involved, the $DGBLSC system service might be involved, which will map the section for deletion. This may not be a synchronous operation, so it 'may take a while'.

The above theory would be supported by the fact, that re-opening the file after the error has been seen, seems to work fine. The problem also seems to be quite intermittent.

Just a thought...

Volker.

[Mike Stoddart]

I think the file is being closed immediately inbetween. I'm not the author so I'm still getting familiar with it as it involves C++ and Pascal.

I added a lib$wait(1) immediately after the close, but it didn't seem to make a difference.

I suppose the thing I don't understand is why the status is 120 - is there really insufficient virtual memory, or am I not reading the status correctly?

Thanks again

[Volker Halle · Accepted solution]

Mike,

120. (decimal) would be PAS$K_INSVIRMEM.

Is the status printed out somehow, if so, which format does the print statement use (decimal, hex, octal) ?

Can you run (and reproduce) this with the debugger ? Would DBG> SET BR/EXCEPTION; GO allow you to automatically stop, if an exception is being signalled ? It would be most helpful to find out, which call or system service seems to return a failure status, which PASCAL would report as PAS$K_INSVIRMEM.

Could you look at the running program with SHOW PROC/CONT/ID=xxx to at least watch Virtual Pages ?

Could you run the program after a $ SET WATCH FILE/CLASS=MAJOR (this will show all XQP operations). Turn it off with $ SET WATCH FILE/CLASS=NOMAJOR. This could generate some amount of output, so a SET HOST/LOG would be a good idea.

Volker.

[Mike Stoddart]

Thanks again. SET WATCH looks interesting but it doesn't work in my case. When I login I run our bootstrapper process, which creates numerous sub-processes using CREPRC. As soon as the sub-processes are created I stop getting the QXP operation info. Is there anyway around this?

I don't know if I have a debugger on this particular machine, and it's only accessible one way via TCP/IP. I'm not sure if I can try this.

I monitored the virtual page count for the process and it didn't exceed 34000.

I think it's 7.3-1 and not 7.2. And it might be Pascal 5.6, based on the output of the QXP operations!

Is there any information on SET WATCH? It doesn't appear to be documented in the HELP command.

Thanks

[Ian Miller.]

SET WATCH is one of the well known undocumented features. For some info see
http://decus.decus.de:8080/htbin/uhelp/help/@undoc/set/watch

[Volker Halle]

Mike,

does your 'bootstrapper' really create sub-processes (check with SHOW SYSTEM, do the processes created have a 'S' in the last column) ? If so, PGFLQUOTA would be shared between all those processes in the JOB tree.

You can watch the remaining page file quota with a little DCL procedure in a close loop using:

$ WRITE SYS$OUTPUT F$GETJPI("pid-of-the-process","PAGFILCNT")

You could only run SET WATCH FILE in the subprocess, if it would be run with DCL (i.e. being started via LOGINOUT.EXE and a command procedures as SYS$INPUT).

A debugger is integrated into OpenVMS, so it's available on any OpenVMS system (unless it has been tailored off).

I've checked and there seems to be no system service, which would return SS$_INSVIRMEM. This status seems to be returned from runtime library routines (STR$_INSVIRMEM, LIB$_INSVIRMEM and OTS$_INSVIRMEM). You could add a call to LIB$SHOW_VM to determine the usage of virtual memory allocated/deallocated with the LIB$*_VM routines over time.

It may not be easy and straightforward to find the reasons for this intermittent error. If retrying the open always works and you don't see any other bad side effects, you may be able to live with that workaround.

Volker.

[Mike Stoddart]

Sometimes you can't see the wood for the trees - OPEN may return insufficient virtual memory, but that doesn't mean IT couldn't grab any more memory!

It looks like we're grabbing some memory just prior to the call to OPEN, but for some reason our calculation to determine how much to grab is incorrect and we're ending up getting over 8,000,000 (blocks?).

Who knew that (0 - 24) / 520 = 8,000,000??

The zero is incorrect - it's supposed to contain the requested maximum length. We're always assuming it will be a positive value, so when we receive it as zero, it returns a bum value.

Hope that makes sense! Thanks for all your help - appreciate it. I definitely learnt something, even if it's an undocumented feature!

[Volker Halle]

Mike,


We're always assuming it will be a positive value,...


yeah, ASSUMING is probably the biggest mistake one can make when writing programs.

OpenVMS itself (internally) is pretty good at CHECKING (not assuming) all parameters passed in calls. This will lead to 'annoying' errors being returned to the user instead of crashing the program or system ;-)

Volker.