topic lib$spawn problem in Operating System - OpenVMS

lib$spawn problem

dschwarz — Wed, 24 Apr 2013 07:55:07 GMT

We have an old application working for about 20 years
without major problems on a MicroVAX 3100 running OpenVMS 6.2.

There are a lot of detached processes, one of them
starting a subprocess every 8 hours to transfer data
from the previous working shift to another system.
The source code (VAX-FORTRAN) looks like this:

...
open a file
write some data to that file
close that file

RTC = LIB$SPAWN (SPAWN_CMD,,SPAWN_OUT,CLI$M_NOWAIT)
IF (.NOT. RTC) write message to Logfile

Since some weeks this doesn't work anymore.
RTC is 2264 which translates to %SYSTEM-W-MBFULL, mailbox is full.

I know lib$spawn is using a mailbox to transfer
symbol table, logical names and so on.

I tried to increase DEFMBXBUFQUO and DEFMBXMXMSG
one value at a time, but it still does not work.

I am sure that after a reboot everything will work fine
for a long period as it does in the past.

But I'd like to understand what is happening.

Is there a chance ?

Thanks

dschwarz

Re: lib$spawn problem

abrsvc — Wed, 24 Apr 2013 11:13:58 GMT

Just as a doublecheck, how did you get that value? Is the number actually in decimal? In HEX, that value translates to:
%SYSTEM-F-INSSWAPSPACE, insufficient swap file space available

Check for that as well.

DAn

Re: lib$spawn problem

Hein van den Heuvel — Wed, 24 Apr 2013 13:39:55 GMT

Interesting thought Dan! Wouldn't be the first time.

As one increases DEFMBXBUFQUO, it eats more into the process byte limit quota.

So you also need to check out: SYSGEN PQL_MBYTLM and/or AUTHORIZE BYTLM

Hein.

Re: lib$spawn problem

John McL — Sun, 28 Apr 2013 22:58:13 GMT

Are you explicitly using mailboxes anywhere in this code? If so, has something written to it but the other party not read from it? (IIRC, some simple DCL to open the mailbox and read a record from it then close it will solve that problem.)

How many mailbox devices exist on your system? Tens? Hundreds? Maybe they are not being cleared up or not being re-used by your application or by VMS.

Did anything odd happen when this first occurred or in the execution prior to that? I'm wondering if some other failure has caused a mailbox to hang around.

Re: lib$spawn problem

John Gillings — Mon, 29 Apr 2013 00:59:03 GMT

First why are you using CLI$M_NOWAIT? Since you're not specifying a completion status address or AST, you have no way of determining if/when the subprocess competes, or the completion status. The function status just tells you about the success or failure of starting the subprocess.

How frequently does this execute, and what happens if there are two or more subprocesses executing simultaneously? Can they interfere with each other?

There's nothing wrong with writing asynchronous code, but unless there really are no implications of issuing multiple simultaneous commands (rare!) then you should implement some kind of syncronisation code.

What is the value of SPAWN_CMD and SPAWN_OUT at the time of the call?

Stuff sent through the mailbox to the subprocess includes the command, I/O specifications, process logical names and CLI symbols.

Do you really need process logical names and symbols to be sent to the subprocess? Have any new symbols or logical names been defined? If they aren't required does adding flags CLI$M_NOLOGNAM and/or CLI$M_NOCLISYM make any difference? (it will make the SPAWN faster too).