topic Re: Detached processes in Operating System - OpenVMS

Detached processes

Wim Van den Wyngaert — Fri, 02 Jul 2004 06:11:39 GMT

I have a DCL procedure that runs well when executed interactively. However in detached or batch I get strange things.

I checked logicals and symbols. No difference that can explain the problem.
I set quotas to the same value. Still the problem occurs.

Some logicals are missing in detached. They are defined too (e.g. sys$scratch).

What can be the problem ???

(program is tcpip$snmp_request in mode dump everything)

Re: Detached processes

Ian Miller. — Fri, 02 Jul 2004 06:26:57 GMT

what problem do you see?

It may be the program is making assumptions about its input or output device being a terminal or some part of the environment set by an interactive login.

Re: Detached processes

Mobeen_1 — Fri, 02 Jul 2004 06:32:58 GMT

Wim,
Can you add set verify in the starting and set noverify at the end and then submit the command procedure to execute with a /output qualifier.

Lets see what errors you are getting

regards
Mobeen

Re: Detached processes

Wim Van den Wyngaert — Fri, 02 Jul 2004 06:43:03 GMT

The program is not always functioning correctly. The first execution is OK but the second and subsequent execution mosty (but not always) end with "Unexpected reply".

I capture sys$output and sys$error but I will add a global log file and check.

Re: Detached processes

Lokesh_2 — Fri, 02 Jul 2004 07:12:07 GMT

Is same happens when you run program interactively, then first OK ,then remaining fails ??

Thanks & regards,
Lokesh

Re: Detached processes

Wim Van den Wyngaert — Fri, 02 Jul 2004 07:12:49 GMT

Done.

Not 1 message in the log file. And this time it went wrong on the first execution.

If someone could post the source of tcpip$snmp_request ...

What can change the behaviour of this program ?

Note that for 5 out 6 san switches the program works fine.

Re: Detached processes

John Gillings — Fri, 02 Jul 2004 23:29:43 GMT

Wim,

Could you please post the EXACT command you use to start the procedure as a detached process?

It would also help if you could explain what you mean by "I get strange things".

Re: Detached processes

Wim Van den Wyngaert — Tue, 06 Jul 2004 09:40:15 GMT

John,

Try these threats :

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=616957

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=533394

For 1 SANswitch, I get "Unexpected reply". But not when asked interactively.

Wim

Re: Detached processes

Wim Van den Wyngaert — Wed, 22 Dec 2004 02:41:47 GMT

This problem is not solved but since the software on the sanswitch was upgraded, the problem is almost gone.

Wim

Re: Detached processes

John Gillings — Wed, 22 Dec 2004 15:23:19 GMT

Wim,
Same request...

Could you please post the EXACT command you're using to start the process and the EXACT (cut and paste transcript) of any error messages you are receiving.

Re: Detached processes

Wim Van den Wyngaert — Thu, 23 Dec 2004 03:42:56 GMT

John,

Sorry to be so vague but it's a strange thing.

This is the startup command.
$ run -
/uic=[system] -
/input='f$par("bbl$com:ver_proc.com")' -
/output=nl: -
/privileges=all -
/priority=2 -
sys$system:loginout.exe

in ver_proc.com, the problem is given on the command
mc TCPIP$SNMP_REQUEST.EXE 'p1' public getnext -l -w 9 1.3.6.1.4.1
and p1 is the IP address of the hub900.

More info can be found in the threads 2 postings back. The IP trace could be handy.

There are no error messages, only "unexpected reply". But when running the script within an interactive session, the problem never occurs (at least not during a couple of days). In detached, it goes wrong once on every 40 runs.

The sanswitch was upgraded to 2.6.0c and no longer has the problem. The hub900 is in 5.5 (?) and still has the problem.

Wim

Re: Detached processes

Antoniov. — Thu, 23 Dec 2004 06:17:05 GMT

Hi Wim,
because I believe you already checked for any different things between interactive and detached mode, I've persuaded trouble stands exactly in execution mode.
I guess, your application, sometimes need to use reply command that's not avaiable in detached mode because is a DCL command.
I hope this clue can help you.
Merry Christmas!

Antonio Vigliotti

Re: Detached processes

Uwe Zessin — Thu, 23 Dec 2004 06:58:48 GMT

But he starts the process by running LOGINOUT.EXE with a DCL procedure as input. Last time I checked, LOGINOUT maps DCL, no?

Re: Detached processes

Antoniov. — Thu, 23 Dec 2004 10:36:46 GMT

Yes, Uwe,
DCL commands runned by .COM work fine!
Wim in his .COM executes MCR ... command and I guess this command wait for some reply.
I don't know his exact commands so I'm not able to give more informations.

Antonio Vigliotti

Re: Detached processes

Uwe Zessin — Thu, 23 Dec 2004 11:31:15 GMT

Re: Detached processes

Antoniov. — Thu, 23 Dec 2004 12:35:14 GMT

MCR (short for Monitor Console Routine, the CLI on some RSX operating systems) is a convenient abbreviation for 'RUN SYS$SYSTEM:'. Wim could also define a foreign command, e.g.

$ REQ = "$TCPIP$SNMP_REQUEST.EXE"
$ REQ ..parameters..

Yes,
if TCPIP$SNMP_REQUEST.EXE use a DCL symbol, DCL procedure works fine in interactive mode and fails in detached mode.

Merry Xmas!
Antonio Vigliotti

Re: Detached processes

Uwe Zessin — Thu, 23 Dec 2004 13:17:27 GMT

EH?
Of course you define the foreign command _inside_ the DCL procedure.

Re: Detached processes

John Gillings — Thu, 23 Dec 2004 17:43:04 GMT

Wim,

Since your RUN command does not specify any quotas, you'll get only the PQL_D* quota values, which are almost certainly WAY below those of your interactive process. We went over the origin of quotas in a recent thread. Low quotas is a very likely cause of mysterious failures after some run time.

Add a SHOW PROCESS/QUOTA to your DCL procedure to see what you're getting. You'll need to direct the output to a log file to see it (which would be a good idea anyway - maybe the process is trying to give you an error message?)

Also note that although you've said /UIC=SYSTEM, the USERNAME of the process will be that of the creator, NOT SYSTEM! If this process should run under SYSTEM, the best approach is to put your RUN/DETACHED command into a procedure and SUBMIT/USER=SYSTEM. That way you'll get both username and UIC as SYSTEM. It will also allow you to add /AUTHORIZE to the RUN command to inherit the quotas from the SYSTEM UAF entry.

So:

START_VER_PROC.COM
$ run/AUTHORIZE -
/input='f$par("bbl$com:ver_proc.com")' -
/output=BBL$LOG:VER_PROC.LOG -
/priority=2 -
sys$system:loginout.exe

$ SUBMIT/USER=SYSTEM START_VER_PROC

If you don't want to do it this way, check out any RUN/DETACHED command from procedures in SYS$STARTUP - they have fully populated quota qualifiers. Cut and paste one and fill in appropriate values.

Re: Detached processes

Wim Van den Wyngaert — Fri, 24 Dec 2004 02:11:44 GMT

John,

I already checked the quotas during the problem. Good guess but that's not the prblem. They are high.

* ASTCNT = 298 free of 300 = 1% used
* BIOCNT = 300 free of 300 = 0% used
* BYTCNT = 99616 free of 99616 = 0% used
* DIOCNT = 300 free of 300 = 0% used
* ENQCNT = 2048 free of 2048 = 0% used
* FILCNT = 299 free of 300 = 1% used
* PRCCNT = 32 free of 32 = 0% used
* TQCNT = 298 free of 300 = 1% used
* VIRTPEAK = 2147276000 free of 2147483647 = 1 % used
* PAGFILCNT = 195440 free of 200000 = 3 % used

I also checked the quotas during the execution : nothing special.

How to explain that an upgrade of the san switch solved the problem ?

Wim

Re: Detached processes

John Gillings — Fri, 24 Dec 2004 03:30:50 GMT

Wim,

Are you saying those are the quotas set by your PQL_D* or PQL_M* SYSGEN parameters? They are surprisingly high. The RUN command you posted doesn't specify any quotas, therefore it will get them from PQL parameters.

If your process is dependent on unusually high site specific values of PQL parameters, it's in danger of breaking if you ever move it to another system. It's very important that your RUN command specify appropriate quotas, or you use /AUTHORIZE.

I'd go so far as to say that any RUN command that doesn't have a complete set of quota qualifiers is a bug waiting to happen.

I strongly suggest you check what quotas your process is getting with a procedure containing "SHOW PROCESS/QUOTA" or the equivalent F$GETJPI calls. Make certain you really understand exactly where each value is coming from.

I've taken thousands of cases of detached process failure over more than 25 years, and they are almost always due to misunderstandings in quotas.