T2T timeout

[Wim Van den Wyngaert]

I'm using task-to-task to execute things remotely. Decnet+.

The remote task must however open sys$net within 75 seconds or control returns to the main task. And the task continues (and fails in my case).

Is there a way to change the 75 ?

Wim

[Ian McKerracher_1]

Wim,

This could be caused by the logical NETSERVER$TIMEOUT on the remote node. This contains a delta time value representing the amount of time that NET$SERVER waits before it reaches timeout. The NET$SERVER image is invoked when a link request is received.

I am not entirely convinced that this is the cause of your problems but it is worth checking.

Hope this helps,

Ian

[Volker Halle]

Wim,

in DECnet Phase IV there are:

$ mc ncp sho exe char
...
Incoming timer = 45
Outgoing timer = 60
...

The incoming connection must be accepted/rejected within 45 seconds and the outgoing connection accepted/rejected within 60 seconds.

In DECnet Phase V (DECnet/Plus) there are

$ MC NCL SHOW SESSION CONTROL ALL
...
Incoming Timer = 45
Outgoing Timer = 60
...


Please check these values on both of your systems involved in the task-to-task communication and change them, where appropriate.

Volker.

[Ian Miller.]

this could also be related the the incoming timer characteristic of sesson control

ncl show session control incoming timer

[Wim Van den Wyngaert]

Volker,

I have the same settings. But I would like to modify them for this task only. Possible via logicals ?

Wim

[Ian Miller.]

NETSERVER$TIMEOUT logical is a delta time for how long a idle netserver process waits around for another incoming connection before exiting.

[Volker Halle]

Wim,

this is an attribute of the session control entity and cannot be specified for individual session control applications.

Why does the remote task take so long to open sys$net ? Maybe you can do the open earlier and then do other initialization tasks later.

Volker.

[Wim Van den Wyngaert]

Volker,

It is a remote backup procedure. The task mounts the tape and converts sys$net to tape.
However, if the tape needs to be positioned, this can take minutes to complete. I tried to open sys$net shared and to convert/shared but convert didn't work.

Wim

[Volker Halle]

Wim,

can't you just do an

$ OPEN/READ/WRITE x SYS$NET
$ MOUNT tape ...
$ CONVERT SYS$NET tape:file
$ CLOSE x

I've tested this with a simple DCL procedure:

SYS$LOGIN:ABC.COM:

$ SHOW LOG SYS$NET
$ OPEN/READ/WRITE x SYS$NET
$ convert sys$net aaa.txt
$ CLOSE x

$ copy x.com 0"user pwd"::"task=abc"

and the aaa.txt file gets created:

$ dir/dat aaa.txt

Directory USERDISK1:[HALLE]

AAA.TXT;1 19-AUG-2005 19:45:07.45

Volker.

[Volker Halle]

Wim,

it worked ONCE, now it won't work again ?!

%CONV-F-OPENIN, error opening node::"0=HALLE/ÿÿABC" as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

Sorry,

Volker.

[Volker Halle]

Wim,

now this works for me (more than just ONCE):

$ SHOW LOG SYS$NET
$ OPEN/READ/WRITE x SYS$NET
$ convert x: aaa.txt
$ CLOSE x

Volker.

[Robert Gezelter]

Wim,

In addition to the existing suggestions, please take a look at your LOGIN.COM file.

I have seen many cases of the timeouts similar to what you describe. In the majority of these cases, the problem was caused by extensive login processing that was simply unneeded for a network server process.

Generally speaking, LOGIN.COM should separate the interactive session definitions from the batch and network definitions, and insert the line:

$ IF F$MODE() .EQS. "NETWORK" THEN EXIT

at some appropriate point.

Note that this problem can occur at seemingly random times depending on system load.

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

[Wim Van den Wyngaert]

Volker,

Not on my 7.3 node.

WSYS01> backup login.com wsys01::"task=wim"/sav
WSYS01>ty wim.com
$ set ver
$ open/read/write x sys$net
$ convert sys$net wim.lis/stat
$ stop/id=0

WSYS01>ty net$server.log
$ Proc_ver = F$environment("Verify_procedure")
$ Imag_ver = F$environment("Verify_image")
$ set nover
$ exit
$ set nover
Setting up symbols for foreign command line usage...
JAVA$FILENAME_CONTROLS now set to: -1

--------------------------------------------------------

Connect request received at 22-AUG-2005 08:18:14.61
from remote process WSYS01::"0=SYSMGR_WVW"
for object "WIM"

--------------------------------------------------------

$ open/read/write x sys$net
$ convert sys$net wim.lis/stat
%CONV-F-OPENIN, error opening WSYS01::"0=SYSMGR_WVW/ÿÿWIM" as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

[Wim Van den Wyngaert]

Also tried /share in open and convert. Same result.

Wim

[Volker Halle · Accepted solution]

Wim,

in my working example, I used:

$ convert x: aaa.txt

You've opened SYS$NET already using the OPEN/READ/WRITE x SYS$NET, so the idea is for CONVERT to use the existing channel pointed to by logical x.

I ran this test on OpenVMS Alpha V8.2.

Volker.

[Wim Van den Wyngaert]

Volker,

Missed that when reading your postings.
It works here too.

Many thanks

Wim

BTW : why isn't /share in the open and convert not doing the same ?

[Volker Halle]

Wim,

CONVERT/SHARE SYS$NET ... seems to still open the file again in /SHARE mode, while CONVERT X: seems to use the process-permanent file opened by OPEN/READ/WRITE x SYS$NET.

Volker.

[Robert Gezelter]

Wim,

The process permanent file remains open between images, in effect the "open" is a no-op that uses the pre-existing connection to the file.

Opening SYS$NET a second time tries to re-use an existing network connection, one that is already in use by someone else (it may be the same process/image, but the network link may only be used by one reader/writer channel on either end).

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