MULTINET_SPOOL and multiple system disks

Discussion:

(too old to reply)

Conroy, Dana

2006-11-16 16:37:08 UTC

I recently added a second site (and a second system disk) to our VMS
7.3-2/MultiNet 5.1 cluster. This has resulted in sporadic SMTP errors (not able
to find spooled messages on the remote side's system disk) since the two system
disks are not mounted cluster-wide.

Can the following be done to effectively move the MULTINET_SPOOL directory to a
cluster-wide disk without rebooted any nodes?:
* stop SMTP on all nodes
* redefine the MULTINET_SPOOL logical to a directory on a disk that's mounted
cluster-wide
* restart SMTP on all nodes

If so, the only part that I'm not clear on is how to temporarily halt the SMTP
symbionts. The MultiNet documentation makes reference to starting and
restarting SMTP symbionts, but I was not able to easily find information on
temporarily halting the symbionts.

Thank you,
Dana Conroy
***@partners.org

Mo Boukantar

2006-11-16 16:44:49 UTC

Permalink

Hi Dana,
All you need to do to get this going is to:

1. Def/sys/exec multinet_spool

2.
$ mu config
net-config> set spool-directory "directory"

No need to reboot, but if you do number 2 with redefine the logical for you.

Thanks,
Mo,

-----Original Message-----
From: Conroy, Dana [mailto:***@PARTNERS.ORG]
Sent: Thursday, November 16, 2006 11:37 AM
To: info-***@process.com
Subject: MULTINET_SPOOL and multiple system disks

I recently added a second site (and a second system disk) to our VMS 7.3-2/MultiNet 5.1 cluster. This has resulted in sporadic SMTP errors (not able to find spooled messages on the remote side's system disk) since the two system disks are not mounted cluster-wide.

Can the following be done to effectively move the MULTINET_SPOOL directory to a cluster-wide disk without rebooted any nodes?:

* stop SMTP on all nodes
* redefine the MULTINET_SPOOL logical to a directory on a disk that's mounted cluster-wide
* restart SMTP on all nodes

If so, the only part that I'm not clear on is how to temporarily halt the SMTP symbionts. The MultiNet documentation makes reference to starting and restarting SMTP symbionts, but I was not able to easily find information on temporarily halting the symbionts.

Thank you,
Dana Conroy
***@partners.org

Steve +1 608 278 7700

2006-11-16 17:09:41 UTC

Permalink

I recently added a second site (and a second system disk) to our VM=

7.3-2/MultiNet 5.1 cluster. This has resulted in sporadic SMTP err=

ors (not able

to find spooled messages on the remote side's system disk) since th=

e two system

disks are not mounted cluster-wide.
Can the following be done to effectively move the MULTINET_SPOOL di=

rectory to a

* stop SMTP on all nodes
* redefine the MULTINET_SPOOL logical to a directory on a disk tha=

t's mounted

cluster-wide
* restart SMTP on all nodes
If so, the only part that I'm not clear on is how to temporarily ha=

lt the SMTP

symbionts. The MultiNet documentation makes reference to starting =

and

restarting SMTP symbionts, but I was not able to easily find inform=

ation on

temporarily halting the symbionts.

In your situation, you might want to consider using a common
Multinet_root disk. I like to put MultiNet on the same disk as the
cluster common files (SYSUAF, etc.), since they must be mounted
cluster-wide at boot time (and will have open files at shutdown time)
anyway. This saves a bit of storage since you're not duplicating com=
mon
files, but the big win is that you only need to do upgrades and make
configuration changes once to affect all systems with the same
architecture.

Moving to this configuration will involve a minimum boot, running bac=
kup
to move the Multinet directory tree, rebooting both systems, and
cleaning up the old directories.

Regards,
"Steve" Stephen L. Arnold, Ph.D., President, Arnold Consulting, Inc=
.
Address 2530 Targhee Street, Fitchburg, Wisconsin 53711-5491 U.S.=
A.
Telephone +1 608 278 7700 Facsimile +1 608 278 7701
Internet ***@Arnold.com http://WWW.Arnold.com
Arnold=AE is a registered trademark and service mark of Arnold Consul=
ting, Inc.

Jim Mehlhop

2006-11-16 17:33:55 UTC

Permalink

backing up the multinet tree this way will NOT
leave you with a rooted tree. Instead you will
have multiple copies of ALL the common multinet files.

You must MANUALLY create the synonym'd directory files first.

for example

dev:[multinet.'node']syscommon.dir must be
synonym'd to dev:[multinet]axp_common.dir

before you try to backup the tree. ONLY an image
backup handles synonym'd directories.

Post by Conroy, Dana

Post by Conroy, Dana
I recently added a second site (and a second system disk) to our VMS
7.3-2/MultiNet 5.1 cluster. This has

resulted in sporadic SMTP errors (not able

Post by Conroy, Dana
to find spooled messages on the remote side's

system disk) since the two system

Post by Conroy, Dana
disks are not mounted cluster-wide.
Can the following be done to effectively move

the MULTINET_SPOOL directory to a

Post by Conroy, Dana
* stop SMTP on all nodes
* redefine the MULTINET_SPOOL logical to a

directory on a disk that's mounted

Post by Conroy, Dana
cluster-wide
* restart SMTP on all nodes
If so, the only part that I'm not clear on is

how to temporarily halt the SMTP

Post by Conroy, Dana
symbionts. The MultiNet documentation makes reference to starting and
restarting SMTP symbionts, but I was not able to easily find information on
temporarily halting the symbionts.

In your situation, you might want to consider using a common
Multinet_root disk. I like to put MultiNet on the same disk as the
cluster common files (SYSUAF, etc.), since they must be mounted
cluster-wide at boot time (and will have open files at shutdown time)
anyway. This saves a bit of storage since you're not duplicating common
files, but the big win is that you only need to do upgrades and make
configuration changes once to affect all systems with the same
architecture.
Moving to this configuration will involve a minimum boot, running backup
to move the Multinet directory tree, rebooting both systems, and
cleaning up the old directories.
Regards,
"Steve" Stephen L. Arnold, Ph.D., President, Arnold Consulting, Inc.
Address 2530 Targhee Street, Fitchburg, Wisconsin 53711-5491 U.S.A.
Telephone +1 608 278 7700 Facsimile +1 608 278 7701
Arnold® is a registered trademark and service mark of Arnold Consulting, Inc.

Jim Mehlhop

Join Cauce to outlaw spam
http://www.cauce.org/

Michael Corbett

2006-11-17 15:07:45 UTC

Permalink

backing up the multinet tree this way will NOT leave you with a rooted
tree. Instead you will have multiple copies of ALL the common multinet
files.
You must MANUALLY create the synonym'd directory files first.
for example
dev:[multinet.'node']syscommon.dir must be synonym'd to
dev:[multinet]axp_common.dir
before you try to backup the tree. ONLY an image backup handles
synonym'd directories.

Here is some information on moving Multinet to a different disk -

Moving Multinet to a new disk

<srcdisk>
Disk where current MultiNet files reside, most likely the current
system disk
(F$Trnlnm("SYS$SYSDEVICE"))
i.e. DKA0:

<dstdisk>
Disk where new MultiNet files are to reside, can be the same as above.
i.e. DKA100:

<arch>
VAX (if VAX)
AXP (if Alpha)

<node>
F$Edit(F$Getsyi("SCSNODE"),"Trim")
or
F$Edit((F$Trnlnm("SYS$NODE")-"::"),"Trim")
or
F$Edit((F$Trnlnm("SYS$TOPSYS"),"Trim")

1. $ create/dir/owner=system >[MULTINET.<node>.MULTINET]
$ create/dir/owner=system <dstdisk>[MULTINET.<arch>_COMMON.MULTINET]

$ set file/enter=<dstdisk>[MULTINET.<node>]SYSCOMMON.DIR -
<dstdisk>[MULTINET]<arch>_COMMON.DIR

$ backup/log/ignore=interlock -
<srcdisk>[multinet.<node>.MULTINET...]*.*;* -
<dstdisk>[MULTINET.<node>.MULTINET...]/owner=original

$ backup/log/ignore=interlock -
<srcdisk>[multinet.<arch>.MULTINET...]*.*;* -
<dstdisk>[MULTINET.<arch>_COMMON.MULTINET...]/owner=original

2.Change the system command procedure to start MultiNet from the new
location.

old: $ @<srcdisk>[MULTINET.<node>.MULTINET]START_MULTINET

new: $ @<dstdisk>[MULTINET.<node>.MULTINET]START_MULTINET

3.Reboot the system.

5.Reboot the system.

This system will now be running the new version at the new location.

Additional Systems in Cluster

<srcdisk>
Disk where current MultiNet files reside, most likely the current
system disk
(F$Trnlnm("SYS$SYSDEVICE"))
i.e. DKA0:

<dstdisk>
Disk where new MultiNet files are to reside, can be the same as above.
i.e. DKA100:

<arch>
= VAX (if VAX)
= AXP (if Alpha)

<node>
= F$Edit(F$Getsyi("SCSNODE"),"Trim")
or
= F$Edit((F$Trnlnm("SYS$NODE")-"::"),"Trim")
or
= F$Edit((F$Trnlnm("SYS$TOPSYS"),"Trim")

1. $ create/dir/owner=system <dstdisk>[MULTINET.<node>.MULTINET]

$ set file/enter=<dstdisk>[MULTINET.<node>]SYSCOMMON.DIR -
<dstdisk>[MULTINET]<arch>_COMMON.DIR

$ backup/log/ignore=interlock -
<srcdisk>[MULTINET.<node>.MULTINET...]*.*;* -
<dstdisk>[MULTINET.<node>.MULTINET...]/owner=original

2.Change the system command procedure to start MultiNet from the new
location:

old: $ @<srcdisk>[MULTINET.<node>.MULTINET]START_MULTINET

new: $ @<dstdisk>[MULTINET.<node>.MULTINET]START_MULTINET

3.Reboot the system.

4.This system will now be running from the new location.

--
+-------------------------------------------------------------------------+
Michael Corbett Email: ***@process.com
Process Software Phone: 800 722-7770 x369
959 Concord St. 508 879-6994 x369
Framingham MA 01701-4682 FAX: 508 879-0042

Conroy, Dana

2006-11-17 15:24:25 UTC

Permalink

Thanks for your responses on this. In the short term, I've created a new spool
directory on a cluster-wide disk and redefined MULTINET_SPOOL. All messages are
now being delivered. I will evaluate the option of moving our MultiNet
installation to a cluster-wide disk.

Dana Conroy
***@partners.org

-----Original Message-----
From: Michael Corbett [mailto:***@process.com]
Sent: Friday, November 17, 2006 10:08 AM
To: info-***@process.com
Cc: ***@Arnold.com
Subject: Re: MULTINET_SPOOL and multiple system disks

backing up the multinet tree this way will NOT leave you with a rooted
tree. Instead you will have multiple copies of ALL the common multinet
files.
You must MANUALLY create the synonym'd directory files first.
for example
dev:[multinet.'node']syscommon.dir must be synonym'd to
dev:[multinet]axp_common.dir
before you try to backup the tree. ONLY an image backup handles
synonym'd directories.

Mike Sullenberger

2006-11-17 17:52:11 UTC

Permalink

Post by Michael Corbett
Here is some information on moving Multinet to a different disk -
Moving Multinet to a new disk
<srcdisk>

Boy, that brings back memories. I wrote that document over 10 years ago,
it is nice to see that it still has some uses.

Mike.

PS. Here is the original:

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

TITLE: Upgrading to MultiNet V4.0 and preserving the old MultiNet files.

DISTRIBUTION: WORLD

Date Entered: 31-OCT-1996 Date Changed:

=============================================================================

Product: MultiNet for VMS

Version: V4.0 and higher

Application: Upgrade MultiNet

Symptom/issue:

Upgrading to Multinet V4.0 or later starting from MultiNet V3.5 Rev B or
earlier, and preserving old MultiNet directories to go back to in case of
problems.

Note: If you have both VAX and Alpha systems in the cluster you must
upgrade one VAX AND one Alpha system following the procedure
"First System in cluster of a particular architecture"

For Additional VAX and Alpha systems follow the procedure
"Additional Systems in cluster of a particular architecture"

Before doing any systems:

! <dstdisk> = Disk where new MultiNet files are to reside, can be
the same as above.
i.e. DKA100:

$ create/dir/owner=system <dstdisk>[MULTINET]

First System in cluster of a particular architecture:

! <srcdisk> = Disk where current MultiNet files reside, most likely
the current system disk (F$Trnlnm("SYS$SYSDEVICE")
i.e. DKA0:
! <dstdisk> = Disk where new MultiNet files are to reside, can be
the same as above.
i.e. DKA100:

! <sysroot> = F$Edit((F$Trnlnm("SYS$TOPSYS"),"Trim")

! <arch> = VAX (if VAX) ***or***
= AXP (if Alpha)

! <node> = F$Edit(F$Getsyi("SCSNODE"),"Trim") ***or***
= F$Edit((F$Trnlnm("SYS$NODE")-"::"),"Trim") ***or***
= F$Edit((F$Trnlnm("SYS$TOPSYS"),"Trim")

$ create/dir/owner=system <dstdisk>[MULTINET.<node>.MULTINET]
$ create/dir/owner=system <dstdisk>[MULTINET.<arch>_COMMON.MULTINET]

$ set file/enter=<dstdisk>[MULTINET.<node>]SYSCOMMON.DIR -
<dstdisk>[MULTINET]<arch>_COMMON.DIR

$ backup/log/ignore=interlock -
<srcdisk>[<sysroot>.MULTINET...]*.*;* -
<dstdisk>[MULTINET.<node>.MULTINET...]/owner=original

$ backup/log/ignore=interlock -
<srcdisk>[<sysroot>.SYSCOMMON.MULTINET...]*.*;* -
<dstdisk>[MULTINET.<arch>_COMMON.MULTINET...]/owner=original

Change system command procedure to start multinet from the new
location.

old: $ @<srcdisk>[<sysroot>.MULTINET]START_MULTINET

new: $ @<dstdisk>[MULTINET.<node>.MULTINET]START_MULTINET

Reboot the system.

This system will now be running of off the new location and *OLD* version.

Upgrade Multinet.

Reboot the system.

This system will now be running of off the new location and *NEW* version.

Additional Systems in cluster of a particular architecture:

! <srcdisk> = Disk where current MultiNet files reside, most likely
the current system disk (F$Trnlnm("SYS$SYSDEVICE")
i.e. DKA0:
! <dstdisk> = Disk where new MultiNet files are to reside, can be
the same as above.
i.e. DKA100:

! <arch> = VAX (if VAX) ***or***
= AXP (if Alpha)

! <node> = F$Edit(F$Getsyi("SCSNODE"),"Trim") ***or***
= F$Edit((F$Trnlnm("SYS$NODE")-"::"),"Trim") ***or***
= F$Edit((F$Trnlnm("SYS$TOPSYS"),"Trim")

$ create/dir/owner=system <dstdisk>[MULTINET.<node>.MULTINET]

$ set file/enter=<dstdisk>[MULTINET.<node>]SYSCOMMON.DIR -
<dstdisk>[MULTINET]<arch>_COMMON.DIR

$ backup/log/ignore=interlock -
<srcdisk>[<sysroot>.MULTINET...]*.*;* -
<dstdisk>[MULTINET.<node>.MULTINET...]/owner=original

Change system command procedure to start multinet from the new
location.

old: $ @<srcdisk>[<sysroot>.MULTINET]START_MULTINET

new: $ @<dstdisk>[MULTINET.<node>.MULTINET]START_MULTINET

Note: If this system is booting from a different system disk then
the "First system in cluster of the same architecture" then
you will also need to do the following steps:

1. Copy SYS$SYSTEM:MULTINET*.EXE files from the system disk
of the "first system" to the system disk of the current
system.

<f-srcdisk> = System Disk of "first system"

<c-srcdisk> = System Disk of "current system"

$ Copy <f-srcdisk>:[VMS$COMMON.SYSEXE]MULTINET*.EXE -
<c-srcdisk>:[VMS$COMMON.SYSEXE]

2. Load the new MultiNet DCL verbs into DCLTABLES.EXE

$ Set Command/Table=SYS$COMMON:[SYSLIB]DCLTABLES.EXE -
/Output=SYS$COMMON:[SYSLIB]DCLTABLES.EXE -
<dstdisk>[MULTINET.<arch>_COMMON.MULTINET]MULTINET,USER

Reboot the system.

This system will now be running of off the new location *AND* new version.

=============================================================================

Copyright, Cisco Systems Inc., 1996. All rights reserved.

+------------------------------------------------+
| Mike Sullenberger | | |
| ***@cisco.com ||| ||| |
| Escalation Team ||||||||| |
| Customer Advocacy c i s c o |
+------------------------------------------------+