Remote backup tmscp

[Wim Van den Wyngaert]

Hi,

I'm trying a remote backup on a TMSCP served tape drive (TZ87, VMS 6.2). I get data overrun when using block size 32K. With 4K no problem.
Is there a limit and when does it applies ?

Wim

[Wim Van den Wyngaert]

8 K is accepted, 16K isn't.

For non TMSCP drives I could use 32K without problems. But these also have more modern drives.

[Wim Van den Wyngaert]

Correction : even 8K is not accepted. Only 4K is.

[Willem Grooters]

You should be able to give points to yourself :D
But it's good to keep us updated and share your experiences. Thanks, Wim.

Willem

PS Just give me 0 points

[Wim Van den Wyngaert]

My problem is still open. Why doesn't it work with block/record size bigger than 4K ?

Wim
(Willem : 1 point for the effort)

[Willem Grooters]

Wild shot but IIRC I've seen someting in that area: Limitation of TMSCP?

Willem

[Wim Van den Wyngaert]

I was checking it again. The drive is connected to 2 HSD controllers (HS1CP) that are connected to 2 nodes (HS0*) of the clusters. So, I thought it was TMSCP served but show dev doesn't show it. How is this possible ?

$ show dev mu/fu (on the node doing the write to tape)
Magtape $18$MUA0: (HS007), device type TZ87, is online, controller supports tape
data caching (write-back cache disabled), record-oriented device, file-
oriented device, available to cluster, error logging is enabled, loader
present.

Error count 0 Operations completed 17251508
Owner process "" Owner UIC [SYS,SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 512
Density 6666 Format Normal-11
Host name "HS007" Host type, avail AlphaServer 1000 4/233,
yes
Alternate host name "HS006" Alt. type, avail AlphaServer 1000 4/233,
yes
Allocation class 18

Volume status: no-unload on dismount, beginning-of-tape, odd parity.


$ sh dev mu/fu (on the node serving the tape)

Magtape $18$MUA0: (HSD007), device type TZ87, is online, controller supports
tape data caching (write-back cache disabled), file-oriented device, served
to cluster via TMSCP Server, error logging is enabled, loader present.
Error count 1534 Operations completed 415659745
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 4096
Density TK87 Format Normal-11
Host name "HSD007" Host type, avail HSD4, yes
Alternate host name "HSD006" Alt. type, avail HSD4, yes
Allocation class 18
Volume status: no-unload on dismount, write-locked, odd parity.

[Wim Van den Wyngaert]

I have the impression that NISCS_MAX_PKTSZ (at 4468) is limiting the block size. A block is not cut into pieces ...
Could someone confirm this ?

Wim

[Uwe Zessin]

I'd say the device is not shown as 'TMSCP served', because it is not served by the OpenVMS TMSCP server. The OpenVMS system just acts as a TMSCP client to the HS1CP (DSSI) controller.

[Wim Van den Wyngaert]

Did some further testing. If I do the convert to tape interactively, it works (with 32K blocks). So, not TMSCP related.

I did the same operation (remote backup) with a high quota user. It worked with 32K.

Did the old test again : still failed.
But I saw that the dataoverrun message was preceded by "error reading xxx" and xxx is sys$net. So, something else is wrong.

The search continues.

Wim

[Uwe Zessin · Accepted solution]

SYS$NET? So you are using a DECnet link as part of the data path?

Does it help if you increase this value:
$ set RMS /NETWORK_BLOCK_COUNT=n

from the default of 8 to a higher value?

[Wim Van den Wyngaert]

Nice job Uwe. I was just comparing login.com but didn't reach the set rms yet.
Problem solved by doing (on both sides of the T2T) :
$ set rms/net=64

Disapointed in VMS about the error message. I remember again how it feels to work with Unix.

Wim

[Uwe Zessin]

Thanks and sorry that I didn't realize there was a DECnet link involved when you wrote 'remote', because a served device is remote to me as well.