Detached processes

[Wim Van den Wyngaert]

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)

[Ian Miller.]

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.

[Mobeen_1]

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

[Wim Van den Wyngaert]

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.

[Lokesh_2]

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

Thanks & regards,
Lokesh

[Wim Van den Wyngaert]

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.

[John Gillings]

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".

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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

Wim

[John Gillings]

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.

[Wim Van den Wyngaert]

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

[Antoniov.]

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

[Uwe Zessin]

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

[Antoniov.]

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

[Uwe Zessin]

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..

[Antoniov.]

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

[Uwe Zessin]

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

[John Gillings]

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.

[Wim Van den Wyngaert]

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

[John Gillings]

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.

[Wim Van den Wyngaert]

John (isn't it night in AU ?)

I already did start the procedure with explecit quotas. No change. I also monitor the quotas every 10 minutes and no monitor process ever occured on the alarm.

My guess is that the snmp program is doing something special. But I have no idea what.

CPU and IO is not charged when the problem occurs (10%, 3MBsec on GS160).

Wim

[Antoniov.]

Wim,

My guess is that the snmp program is doing something special. But I have no idea what.


May be snmp needs DCL to execute some command; in detached mode this is not possible.

Antonio Vigliotti

[Wim Van den Wyngaert]

Antonio,

It works for 98% of the time. So, if the command should fail (it doesn't), it should always fail.

[Robert Gezelter]

Wim,

The quotas and the process environment are often good suspects, but your comment "only one switch and ... upgrade ..." make me curious.

You could be dealing with a timing/message parsing bug in the VMS program that is interacting strangely with the switch. I have often seen automated scripts talking to remote devices fail for reasons of that type.

It is truly a pain to do, but I suspect that you want to get a TCP trace of the communications between your program and the failing switch, and then carefully analyze the dialogue (it would not hurt to also log a successful dialogue for comparison purposes).

Once, a long time ago, I found a timing problem in this way. If the foreign device being controlled was too, or produced a unexpected response, the conversation between the program and the device got out of synch, resulting in a slew of error messages. Since changes in the SWITCH change the problem, perhaps the dialog is the source of the trouble.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

Robert,

A faulty trace can be found at
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=616957

The reason certainly isn't "too slow" on VMS because I had the problem even at prio=10.

WIm