1 INFO-VAX	Tue, 18 May 2004	Volume 2004 : Issue 274       Contents: Re: BTCROUT  Re: BTCROUT 
 Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes 8 Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time3 Re: Determining amount of  space used on a DLT tape 3 Re: Determining amount of  space used on a DLT tape  DISMOUNT/POLICY=MINICOPY! Re: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services . TCPIP Services IMAP server - reloading headers  F ----------------------------------------------------------------------  " Date: Mon, 17 May 04 20:33:41 +100 From: rok@nuk.uni-lj.si  Subject: Re: BTCROUT& Message-ID: <40a921a9$1@NUK.Uni-Lj.Si>  / In Article <YD6qc.1667$x8.473@news.cpqcorp.net> % hoff@hp.nospam (Hoff Hoffman) writes: A >In article <40a69660$1@NUK.Uni-Lj.Si>, rok@nuk.uni-lj.si writes: # >: OpenVMS AXP V7.3-2, all patches.  >:3 >:%BACKUP-I-BTCROUT, routine ODS-5 RMS SYNTAX ERROR  >...G >: OK, someday it will be found there. But right now, is there anybody  # >:to let me know what's that about?  > @ >  From the AskQ search tool (cited in the FAQ), here are two of >  the more relevent responses:  > ( >    http://h18000.www1.hp.com/support -0 >      /askkcs/hpcg/215_0_220781700_3986506.html > ( >    http://h18000.www1.hp.com/support -: >      /asktima/operating_systems/CTI_SRC000628004228.html    Thanks, Hoff! Google    BTCROUT site:hp.com    didn't find those two :(    @  A warning though. As there were 70K+ lost files on the disk, I G stopped BACKUP restore from save set file after the last file I needed  D ([000000]z*.*, just before the empty named files) was safely on the E disk. The ODS-5 disk restored this way was unusable (but I recall it  " didn't do any harm to ODS-2 disk).8  I tried the save side of this storry too - same result.   Regards,  D Rok Vidmar                       Internet:  rok.vidmar@nuk.uni-lj.si; National and University Library  Phone:     +386 1 421 5461 ; Turjaska 1, SI-1000 Ljubljana    Fax:       +386 1 421 5464  Slovenia   ------------------------------  # Date: Mon, 17 May 2004 19:33:29 GMT # From: hoff@hp.nospam (Hoff Hoffman)  Subject: Re: BTCROUT0 Message-ID: <ds8qc.1686$Lh.566@news.cpqcorp.net>  @ In article <40a921a9$1@NUK.Uni-Lj.Si>, rok@nuk.uni-lj.si writes:1 :...As there were 70K+ lost files on the disk, I  - :stopped BACKUP restore from save set file...   H   Having more than 70K lost files tends to imply one or more disk volumeE   structure corruptions.  This might be one or a few directory files  F   "gone missing", -- if there are very large numbers of files in theseC   now-missing (or SET FILE/NODIRECTORY) directories.  Or this could F   imply corruptions elsewhere in the file structure.  Or a volume thatC   simply hasn't been repaired sufficiently often for its particular C   file structure activity level, assuming a sufficient frequency of B   application, system, and/or system power failures.  (That you'reE   already restoring a BACKUP tends to imply that one or more problems "   have already been seen, too. :-)  N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------    Date: 17 May 2004 13:28:40 -0700* From: denny.rich@swagelok.com (Denny Rich) Subject: Copying tapes< Message-ID: <d28306e.0405171228.2bc59e91@posting.google.com>  C I seem to remember (dimly) that in the olden days, with tu78/ta79s, ? connected through HSCs, it was possible to mount  a source tape @ Files11 (backup tape full of save sets), and a target tape  alsoC Files11, and then "$ copy source:*.* target:"  (or was I doing this  with HSC backup?)   > Anyway, the obvious would happen.  (IIRC...and thats a big if)  B When I try this with a couple of backup tapes on TK89s, they won't copy a single byte.   B Short of laying out each saveset and then putting it back onto the= target tape, is there an easy way to duplicate a backup tape?    thanks   denny    ------------------------------  % Date: Mon, 17 May 2004 17:18:34 -0400 * From: "Marty O'Connor" <moconnor@dvfs.com> Subject: Re: Copying tapes* Message-ID: <2gsoh4F6dscrU1@uni-berlin.de>  7 "Denny Rich" <denny.rich@swagelok.com> wrote in message 6 news:d28306e.0405171228.2bc59e91@posting.google.com...E : I seem to remember (dimly) that in the olden days, with tu78/ta79s, A : connected through HSCs, it was possible to mount  a source tape B : Files11 (backup tape full of save sets), and a target tape  alsoE : Files11, and then "$ copy source:*.* target:"  (or was I doing this  : with HSC backup?)  : @ : Anyway, the obvious would happen.  (IIRC...and thats a big if) : D : When I try this with a couple of backup tapes on TK89s, they won't : copy a single byte.  : D : Short of laying out each saveset and then putting it back onto the? : target tape, is there an easy way to duplicate a backup tape?   d I have used MTEXCH to do this. I don't remember if its on the freeware CDs or an old DECUS SIG tape.^ I do know that a few years ago when we converted from VAX to Alpha I was able to find an Alpha version.   Marty    ------------------------------  % Date: Mon, 17 May 2004 23:59:46 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> Subject: Re: Copying tapes* Message-ID: <c8bg1v$1qlh$1@news.wplus.net>  7 "Denny Rich" <denny.rich@swagelok.com> wrote in message 6 news:d28306e.0405171228.2bc59e91@posting.google.com...E > I seem to remember (dimly) that in the olden days, with tu78/ta79s, A > connected through HSCs, it was possible to mount  a source tape B > Files11 (backup tape full of save sets), and a target tape  alsoE > Files11, and then "$ copy source:*.* target:"  (or was I doing this  > with HSC backup?)  > @ > Anyway, the obvious would happen.  (IIRC...and thats a big if) > D > When I try this with a couple of backup tapes on TK89s, they won't > copy a single byte.  > D > Short of laying out each saveset and then putting it back onto the? > target tape, is there an easy way to duplicate a backup tape?  >     2 http://h18000.www1.hp.com/info/SP6264/SP6264PF.PDF  ' Save Set Manager. Makes it very easy...    Alex   ------------------------------  % Date: Mon, 17 May 2004 21:31:35 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: Copying tapes6 Message-ID: <40A97587.FE8820D9@NeOaSrPtAhMlNiOnWk.net>   Denny Rich wrote:  > E > I seem to remember (dimly) that in the olden days, with tu78/ta79s, A > connected through HSCs, it was possible to mount  a source tape B > Files11 (backup tape full of save sets), and a target tape  alsoE > Files11, and then "$ copy source:*.* target:"  (or was I doing this  > with HSC backup?)  > @ > Anyway, the obvious would happen.  (IIRC...and thats a big if) > D > When I try this with a couple of backup tapes on TK89s, they won't > copy a single byte.  > D > Short of laying out each saveset and then putting it back onto the? > target tape, is there an easy way to duplicate a backup tape?   8 If you have the option, re-write your backup tapes using7 /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.   B Then, you can MOUNT the source and target tapes /FOREIGN using theE appropriate /BLOCKSIZE parameter, and copy the datasets one at a time  for each saveset:    1. Header labels 2. Saveset data  3. Trailer labels.  H Use SET MAGTAPE/END after the last trailer labels after the last saveset+ to properly mark the logical end of volume.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 03:33:18 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> Subject: Re: Copying tapes) Message-ID: <c8bsi9$70r$1@news.wplus.net>   K "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message 0 news:40A97587.FE8820D9@NeOaSrPtAhMlNiOnWk.net... > Denny Rich wrote:  > > G > > I seem to remember (dimly) that in the olden days, with tu78/ta79s, C > > connected through HSCs, it was possible to mount  a source tape D > > Files11 (backup tape full of save sets), and a target tape  alsoG > > Files11, and then "$ copy source:*.* target:"  (or was I doing this  > > with HSC backup?)  > > B > > Anyway, the obvious would happen.  (IIRC...and thats a big if) > > F > > When I try this with a couple of backup tapes on TK89s, they won't > > copy a single byte.  > > F > > Short of laying out each saveset and then putting it back onto theA > > target tape, is there an easy way to duplicate a backup tape?  > : > If you have the option, re-write your backup tapes using9 > /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.  > D > Then, you can MOUNT the source and target tapes /FOREIGN using theG > appropriate /BLOCKSIZE parameter, and copy the datasets one at a time  > for each saveset:  >  > 1. Header labels > 2. Saveset data  > 3. Trailer labels. > J > Use SET MAGTAPE/END after the last trailer labels after the last saveset- > to properly mark the logical end of volume.  >  <snip>  H One person I worked with, claimed to have physically snapped a couple ofI tapes on older tape drives by not setting the end of tape marker and then @ later still trying to copy off of the tape beyond the last file.  E I might give it a go on a couple of old TU81's I've got lying around.    Alex   ------------------------------  % Date: Mon, 17 May 2004 21:52:38 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: Copying tapes6 Message-ID: <40A97A76.7B1F332E@NeOaSrPtAhMlNiOnWk.net>   Alex Daniels wrote:  > M > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message 2 > news:40A97587.FE8820D9@NeOaSrPtAhMlNiOnWk.net... > > Denny Rich wrote:  > > > I > > > I seem to remember (dimly) that in the olden days, with tu78/ta79s, E > > > connected through HSCs, it was possible to mount  a source tape F > > > Files11 (backup tape full of save sets), and a target tape  alsoI > > > Files11, and then "$ copy source:*.* target:"  (or was I doing this  > > > with HSC backup?)  > > > D > > > Anyway, the obvious would happen.  (IIRC...and thats a big if) > > > H > > > When I try this with a couple of backup tapes on TK89s, they won't > > > copy a single byte.  > > > H > > > Short of laying out each saveset and then putting it back onto theC > > > target tape, is there an easy way to duplicate a backup tape?  > > < > > If you have the option, re-write your backup tapes using; > > /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.  > > F > > Then, you can MOUNT the source and target tapes /FOREIGN using theI > > appropriate /BLOCKSIZE parameter, and copy the datasets one at a time  > > for each saveset:  > >  > > 1. Header labels > > 2. Saveset data  > > 3. Trailer labels. > > L > > Use SET MAGTAPE/END after the last trailer labels after the last saveset/ > > to properly mark the logical end of volume.  > >  > <snip> > J > One person I worked with, claimed to have physically snapped a couple ofK > tapes on older tape drives by not setting the end of tape marker and then B > later still trying to copy off of the tape beyond the last file.  H Well, the only way to tell EOV is when COPY returns a zero record count.  G > I might give it a go on a couple of old TU81's I've got lying around.   H Should work on any "magtape" medium, including (but not limited to) 4mm,& 8mm, DLT, VHS, 9-track, QIC, others...   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 17 May 2004 15:03:01 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)A Subject: Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time = Message-ID: <b096a4ee.0405171403.609263a7@posting.google.com>   ~ "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40A18BC1.11FC0E59@NeOaSrPtAhMlNiOnWk.net>... > "Alan E. Feldman" wrote: > >  > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<409E5608.A14E4BE5@NeOaSrPtAhMlNiOnWk.net>... > > > "Alan E. Feldman" wrote: > > > > J > > > > Any chance of having a time option added to SET PROMPT? Perhaps itN > > > > could be added F$FAO style. Note: The time would be static -- it would@ > > > > just be the time that the prompt appeared on the screen. > > > * > > > Ala SET PREFIX, only for the prompt. > > > K > > > Seems a simple enough change, though a lot of folks have been looking F > > > for a more UN*X-ly prompt showing the current working directory. > > > ' > > > Can't please everyone, I guess...  > > J > > Well, I envision it as something customizable. The default would stillG > > be "$ ". You could make it like the MS-DOS prompt which can contain J > > the time, the directory, both, or neither. As for me, I would like theH > > time and the node name. The node name I can do, and do do, of course) > > (no pun intended). The time, I can't.  > G > The string for SET PROMPT needs to be like SET PREFIX: it needs to be - > employed as a string argument to (SYS)$FAO.    That would be fine.    ------------------------------  % Date: Mon, 17 May 2004 14:55:21 -0400 * From: "Marty O'Connor" <moconnor@dvfs.com>< Subject: Re: Determining amount of  space used on a DLT tape* Message-ID: <2gsg4kF6bu78U1@uni-berlin.de>  ? : > Is there a way to determine how much data is on a DLT tape? J : > It would be useful to know what the compation ratio is and how much of0 : > the tape is used? Is there a way to do this? : > I : Compression ratio is highly data-dependent.  Tests run on the first DLT F : controller showed a c.r. range from <1:1 to 30:1.  We decided to useC : a de facto industry-standard c.r. of 2:1 as a simplification (OK,  : gross over-simplification).  : C : Data that has been pre-compressed does not compress well, and may F : actually expand when compressed, since the compression metadata mustF : be written along with the data.  Text compresses pretty well; 2:1 isB : a reasonable ballpark estimate.  ISTR that the 30:1 c.r. was forB : blocks of all 0's or, probably, for blocks of any repeated byte.H : Surprisingly, executables sometimes compressed better than I expected,6 : due IIRC to blocks of initialized data and the like. : --  _ Our development area uses about 440 GigaBytes of disk space and it still hasn't overflowed to a b second SDLT II tape that is rated at 320 GB compressed (2:1). I have remounted the tape and listed\ all the save sets just to make sure I wasn't missing anything. I like the results but I keep, wondering when I'm going to run out of tape.   ------------------------------    Date: 17 May 2004 15:15:08 -0700, From: JimStrehlow@data911.com (Jim Strehlow)< Subject: Re: Determining amount of  space used on a DLT tape= Message-ID: <4b6ec350.0405171415.37e19b13@posting.google.com>   k dorrt@sutterhealth.org (tr dorr) wrote in message news:<59b7bbb8.0405111001.46e24412@posting.google.com>... = > Is there a way to determine how much data is on a DLT tape? H > It would be useful to know what the compation ratio is and how much of. > the tape is used? Is there a way to do this?  ( My "work-around" has been the following.  D If I have three disks such as DKB0:, DKB1:, and DKB2:, I temporarilyE modify my production backup script (or make a copy of it) so that the D script runs a backup of all the disks in a loop until it reaches the' end of tape and requests a second tape. C If my system has 3 disks of 20 GB data and the loop writes the data E four times before end of tape, then I am comfortable that the regular E "weekly production backup" will not run out of tape (on one tape) for  quite a while.  @ That is very unscientific; but it is simple and it works without	 guessing. F The compression results are based upon your own data ... how well your data compresses.  7 Jim, OpenVMS Systems Manager, Data911, Alameda, CA, USA    ------------------------------  + Date: Mon, 17 May 2004 18:41:42 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)! Subject: DISMOUNT/POLICY=MINICOPY $ Message-ID: <c8b116$ohl$1@online.de>  F I've read the help, read the release notes, read the volume-shadowing D manual and am still confused about DISMOUNT/POLICY=MINICOPY and its ! support (or lack thereof) on VAX.   G Imagine a VAX/ALPHA cluster, VMS 7.3 VAX and 7.3-1 ALPHA.  Some shadow  D sets are on just a VAX node, some on just an ALPHA node, some split G across two VAX nodes, some split across a VAX node and an ALPHA node.   ) All shadow sets are mounted by all nodes.   G Obviously, MINICOPY is only of interest for the split shadow sets when  H one node reboots and one stays up.  So we are down to two cases.  (Note H that I don't (yet) have any shadow sets split across two ALPHA nodes.)  I Presumably, I issue the DISMOUNT command for a member of the shadow set,  G perhaps with the /CLUSTER qualifer.  All nodes which stay up will keep  2 the shadow set mounted (now with only one member).  E So, for the two cases above, can I reboot a VAX node (or in case one  H member is on an ALPHA, the ALPHA node)?  Does it matter from which node G (VAX or ALPHA, direct connection to the member to be lost or not, node  6 to be rebooted or not) the DISMOUNT command is issued?   ------------------------------  % Date: Mon, 17 May 2004 20:30:25 +0200  From:  neale.hunt@hispeed.ch* Subject: Re: Reboot forces Shadowset Merge) Message-ID: <c8b0bn$h4f$1@newshispeed.ch>   A If you want to do cluster reboot, then yes you have to shut dwon  E everything firts, and no the standard procedures don' tatk that into  I account. However with the use of a few logicalor symbosl (maybe they are  I even created as part of "shutdown") you can write the DCL to do whatever  I you want by adding it to sys$manager:syshutdwn.com, ie if it's a cluster  @ shutdown make sure all the open files are closed - exception is H generally the disk that holds the sysuaf etc (often in cluster moved to I a common disk unless all nodes use the same system disk), as that is not  D closed ,and if that disk is shadowed will merge (or copy if you are A lucky). In the near future the new "mini-merge" function will be  E available that will resolve this issue, provided you upgraded to VMS  E 7.3-2. Colleaugues of mine in London are currently have a field test   version.   -- Neale  / Phillip Helbig---remove CLOTHES to reply wrote: 6 > In article <c88j1r$e8a$1@newshispeed.ch>, Neale Hunt# > <nhunt1066@netscape.net> writes:   >  > G >>If you want to do a cluster reboot in one go then you are stuffed as  G >>mini-copy will not work, but you can force a copy by dismounting the  K >>additional members before rebooting - copy take about half the time of a   >>merge typically. >  > K > Yes, but if you are doing a cluster reboot it should be possible to stop  G > all applications with open files first (I'm not sure if the standard  I > shutdown procedure takes care of this in the case of shadow sets) then  = > reboot the entire cluster with no need for a copy or merge.  >    ------------------------------  % Date: Mon, 17 May 2004 18:04:00 -0400   From: John Santos <JOHN@egh.com>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <1040517175839.32308A-100000@Ives.egh.com>  ! On 16 May 2004, Tom Linden wrote:    > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40A6720B.3D5B5D9B@NeOaSrPtAhMlNiOnWk.net>... > > Tom Linden wrote:  > > > ? > > > I have three shadow sets on a BA356 attached to two nodes B > > > (7.3 and 7.3-1 alphas) If I shutdown and reboot another node> > > > in the cluster it causes a merge operation on the shadowG > > > sets, which takes 24 hours!  (74GB disks and bandwidth on BA3565)  > > > ( > > > the shutdown command I ma using isK > > >   SHUTDOWN == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER NO NONE"  > > > C > > > Now if I manually dismount the shadow sets from the node I am G > > > shutting down, then this doesn't happen, but in order to do that, 2 > > > I have to stop the queue manager (open file) > > I > > There's your clue right there - an open file on the volume preventing  > > clean dismount.  > > L > > You'll find there is no work-around for this. You'll have to get a clean) > > dismount to prevent the shadow merge.  > F > Yes, I know,  but the problem is that QMAN$MASTER.DAT resides on oneJ > of the shadow sets, DSA0:, and the only way to close the file to allow aE > clean dismount is to stop the cluster queue manager, which is not a  > satifactory solution.   F You only need to dismount on the node that is rebooting.  If the queueE manager is running on the node that is rebooting, you need to fail it B over to the other node.  (I always thought this was automatic????)E If the queue manager is running on the other node, then it can't have % any open files on the rebooting node.   F (SHUTDOWN should be doing a "DISMOUNT DSAxx:", not a "DISMOUNT/CLUSTERB DSAxx:".  This dismount should succeed unless there are open files on the node being rebooted.)  B SHOW DEVICE/FILES DSAxx: will only show files open on the node youB execute it on (the local node.)  It won't list files open from theA other node, which are irrelevent to doing a dismount on the local @ node.  How do you know that the queue manager has the file open?? If is by doing "SHOW DEVICE/FILES" on the other node, then it's  a red herring.       --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 17 May 2004 21:13:16 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <40A9713C.FDEE928E@NeOaSrPtAhMlNiOnWk.net>   Rob Brooks wrote:  > D > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes: > > Neale Hunt wrote:  > >>1 > >> Actually it's not as difficult as it sounds.  > >>L > >> You simply dismount one (or more if you have more that 2 members of the> > >> shadow set) from one of the other cluster nodes using the > >> /policy=minicopy option.  > > L > > Assumes that HSx controllers are at the root of the storage architectureI > > and that the controllers and the host o.s. version support it. A very ' > > limited subset of what's out there.  > + > Huh?  Minicopy is controller-independent.   G Quite right - I WAS thinking "mini-merge", since that was more germaine  to the o.p.'s query.  G That said, does not mini-copy depend on the write bitmaps which are, of E course, destroyed upon reboot? (The o.p. was asking about rebooting a < node that might be the MSCP server for a shadow-set member.)   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 17 May 2004 21:16:36 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>   John Santos wrote: > # > On 16 May 2004, Tom Linden wrote:  >  > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40A6720B.3D5B5D9B@NeOaSrPtAhMlNiOnWk.net>... > > > Tom Linden wrote:  > > > > A > > > > I have three shadow sets on a BA356 attached to two nodes D > > > > (7.3 and 7.3-1 alphas) If I shutdown and reboot another node@ > > > > in the cluster it causes a merge operation on the shadowI > > > > sets, which takes 24 hours!  (74GB disks and bandwidth on BA3565)  > > > > * > > > > the shutdown command I ma using isM > > > >   SHUTDOWN == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER NO NONE"  > > > > E > > > > Now if I manually dismount the shadow sets from the node I am I > > > > shutting down, then this doesn't happen, but in order to do that, 4 > > > > I have to stop the queue manager (open file) > > > K > > > There's your clue right there - an open file on the volume preventing  > > > clean dismount.  > > > N > > > You'll find there is no work-around for this. You'll have to get a clean+ > > > dismount to prevent the shadow merge.  > > H > > Yes, I know,  but the problem is that QMAN$MASTER.DAT resides on oneL > > of the shadow sets, DSA0:, and the only way to close the file to allow aG > > clean dismount is to stop the cluster queue manager, which is not a  > > satifactory solution.  > H > You only need to dismount on the node that is rebooting.  If the queueG > manager is running on the node that is rebooting, you need to fail it D > over to the other node.  (I always thought this was automatic????)G > If the queue manager is running on the other node, then it can't have ' > any open files on the rebooting node.   H True. If the queue manager is enabled to run on any node of the cluster,E the shutdown procedure should make it fail over to the surviving node H (queue processing continues uninterrupted). In that case, the local nodeH would no longer see the queue database as an open file, and the DISMOUNT should go cleanly.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 17 May 2004 22:36:18 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) * Subject: Re: Reboot forces Shadowset Merge3 Message-ID: <SEEuw1HkkchG@eisner.encompasserve.org>   y In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  > John Santos wrote:  I >> You only need to dismount on the node that is rebooting.  If the queue H >> manager is running on the node that is rebooting, you need to fail itE >> over to the other node.  (I always thought this was automatic????) H >> If the queue manager is running on the other node, then it can't have( >> any open files on the rebooting node. > J > True. If the queue manager is enabled to run on any node of the cluster,G > the shutdown procedure should make it fail over to the surviving node J > (queue processing continues uninterrupted). In that case, the local nodeJ > would no longer see the queue database as an open file, and the DISMOUNT > should go cleanly.  ? Actually, the Job Controller process holds QMAN$MASTER.DAT open 5 even on nodes where the Queue Manager is not running.   % SYSMAN> do search tie.tmp job_control 2 %SYSMAN-I-OUTPUT, command execution on node NODE_14 JOB_CONTROL     2020020F  [SYSEXE]QMAN$MASTER.DAT;362 %SYSMAN-I-OUTPUT, command execution on node NODE_24 JOB_CONTROL     2060020F  [SYSEXE]QMAN$MASTER.DAT;362 %SYSMAN-I-OUTPUT, command execution on node NODE_34 JOB_CONTROL     2080020F  [SYSEXE]QMAN$MASTER.DAT;362 %SYSMAN-I-OUTPUT, command execution on node NODE_44 JOB_CONTROL     20C0010F  [SYSEXE]QMAN$MASTER.DAT;362 %SYSMAN-I-OUTPUT, command execution on node NODE_54 JOB_CONTROL     21C00410  [SYSEXE]QMAN$MASTER.DAT;36 SYSMAN> do show sys/noproc2 %SYSMAN-I-OUTPUT, command execution on node NODE_1J OpenVMS V7.3  on node NODE_1  17-MAY-2004 20:30:17.16  Uptime  25 04:43:362 %SYSMAN-I-OUTPUT, command execution on node NODE_2L OpenVMS V7.3-1  on node NODE_2  17-MAY-2004 20:31:05.66  Uptime  25 01:50:172 %SYSMAN-I-OUTPUT, command execution on node NODE_3J OpenVMS V7.3  on node NODE_3  17-MAY-2004 20:31:44.45  Uptime  25 01:49:282 %SYSMAN-I-OUTPUT, command execution on node NODE_4L OpenVMS V7.3-1  on node NODE_4  17-MAY-2004 20:32:01.32  Uptime  21 13:46:522 %SYSMAN-I-OUTPUT, command execution on node NODE_5K OpenVMS V7.3-2  on node NODE_5  17-MAY-2004 20:31:42.91  Uptime  3 11:50:59  SYSMAN>    ------------------------------  + Date: Mon, 17 May 2004 17:13:19 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)F Subject: Re: Switching from Process Software TCPware to TCPIP Services1 Message-ID: <newscache$vnbvxh$iqz1$1@news.sil.at>   Z In article <40a889c0$0$3034$afc38c87@news.optusnet.com.au>, "Pip" <pip@ti.nl0.com> writes:I >Has anybody ever switched from Process Software's TCPware to HP's TCPIP  , >Services, and have gotchas to look out for?  I We did some years ago (with V7.3-1) but knowledge went out of my mind :-(   L >(In particular, features that TCPware has that might be missing from TCPIP 
 >Services) > ) >For example, does TCPIP Services support  > 3 >Permanent telnet connections (telnet /create=perm)   ; Yup. (Though syntax is different /CREATE_SESSION/PERMANENT)   = btw: I always wondered why both choose such a strange syntax. ? I expected NETCU> CREATE PORT and NETCU> SET PORT like in LATCP G way back in the very early nineties, but I wasn't able to convince them 0 (though PSC was __VERY__ helpful in this years).  0 >A reverse telnet print symbiont (tcpware_tssym)   Yes (TCPIP$TELNETSYM).N But much better (because IP stack independant besides other things) is DCPS !!  M >A telnet server config option to force tt_accpornam to return the IP address   + TT_ACCPORNAM is filled in, but differently.   ; eg. a TELNET to localhost shows "localhost" on TCPware, but 5 "Host: LOCALHOST Locn: _FTA3:/EPLAN" on TCPIP (V5.4).   7 >bootp support to load DECserver terminal server images   & Haven't tried (I use MOP), but I bet.   9 >Ability to add & remove secondary IP addreses on-the-fly    Yes, but differently.   - TCPware: NETCU> ADD SECONDARY [/CLUSTER_LOCK] ! TCPware: NETCU> REMOVE SECONDARY   TCPIP: TCPIP> IFCONFIG ALIAS TCPIP: TCPIP> IFCONFIG -ALIAS   B >Scriptable FTP client support with per-command error handling (eg >        $ ftp >        open server user pass >        error_exit %x10 >        cd incoming >        error_exit %x20 >        put file.bin file.bin >        error_exit %x30K >        $ if $status .eq. %x10000010 then write sys$output "Error logging   >in" >        ...   Currently don't know. L There are some differences in the FTP clients, like TCPware accepts usernameD and password in the commandline while TCPIP wants /USER= and /PASS=.K TCPware FTP client translates characters to lowercase and you have to quote 6 uppercase filenames while TCPIP's passes it unchanged.  D So, better think stack independant, and this means HGFTP (AKA MGFTP)   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Tue, 18 May 2004 08:18:55 +1000  From: "Pip" <pip@ti.nl0.com>F Subject: Re: Switching from Process Software TCPware to TCPIP Services< Message-ID: <40a93a4f$0$31675$afc38c87@news.optusnet.com.au>  L Because it appears that TCPware is not currently available for OpenVMS v8.1  on Itanium.    Thanks all for the feedback.   Pip   7 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message  ! news:40A8DD29.6090904@MMaz.com...  > Pip wrote: > J >>Has anybody ever switched from Process Software's TCPware to HP's TCPIP - >>Services, and have gotchas to look out for? M >>(In particular, features that TCPware has that might be missing from TCPIP   >>Services)  >>- > Perhaps a dumb question, but why would you?  >  > Barry  >  > --   > @ > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com@ > Midwest Microwave                          Phone: 480/314-1320@ > Vice President & CIO                         FAX: 480/661-7028 >  >    ------------------------------  % Date: Mon, 17 May 2004 16:48:48 -0600 % From: Dan O'Reilly <dano@process.com> F Subject: Re: Switching from Process Software TCPware to TCPIP ServicesB Message-ID: <6.0.0.22.2.20040517164835.02278748@raptor.psccos.com>   ..but it will be...   ! At 04:18 PM 5/17/2004, Pip wrote: L >Because it appears that TCPware is not currently available for OpenVMS v8.1 >on Itanium. >  >Thanks all for the feedback.N >V >Pip >87 >"Barry Treahy, Jr." <Treahy@MMaz.com> wrote in messageT" >news:40A8DD29.6090904@MMaz.com... > > Pip wrote: > > K > >>Has anybody ever switched from Process Software's TCPware to HP's TCPIP / > >>Services, and have gotchas to look out for?MN > >>(In particular, features that TCPware has that might be missing from TCPIP
 > >>Services)e > >>/ > > Perhaps a dumb question, but why would you?o > >r	 > > Barrye > >g > > -- > >tB > > Barry Treahy, Jr                       E-mail: Treahy@MMaz.comB > > Midwest Microwave                          Phone: 480/314-1320B > > Vice President & CIO                         FAX: 480/661-7028 > >n > >m   ------J +-------------------------------+----------------------------------------+J | Dan O'Reilly                  |  "There are 10 types of people in this |J | Principal Engineer            |   world: those who understand binary   |J | Process Software              |   and those who don't."                |J | http://www.process.com        |                                        |J +-------------------------------+----------------------------------------+   ------------------------------    Date: 17 May 2004 16:12:14 -0700, From: JimStrehlow@data911.com (Jim Strehlow)F Subject: Re: Switching from Process Software TCPware to TCPIP Services< Message-ID: <4b6ec350.0405171512.1f13c58@posting.google.com>  _ "Pip" <pip@ti.nl0.com> wrote in message news:<40a889c0$0$3034$afc38c87@news.optusnet.com.au>... J > Has anybody ever switched from Process Software's TCPware to HP's TCPIP - > Services, and have gotchas to look out for?aM > (In particular, features that TCPware has that might be missing from TCPIP l > Services)e  ? 1) We switched three years ago when it was a budget concern forh6 multiple new nodes.   H.P.'s stack comes with OpenVMS.  F 2) H.P.'s TCP/IP stack is reliable. They patch it as necessary; but we) have had no operational problems with it.0  * 3) We had to relink existing applications.  = 4) A coworker mentions that answering the prompts in order tot2 configure TCP/IP can be tedious; but work is work.  C 5) You will need to allow time to replace "customized code" writtendD for your existing stack to the new stack.  e.g. When we FTP, we save@ the log and search the log for different error messages and test) accordingly. (Same thing only different.).  E 6) I personally do not know all the features of one versus the other. A That is one of your goals during testing if you decide to change.i  7 Jim, Data911, OpenVMS Systems Manager, Alameda, CA, USA6   ------------------------------    Date: 17 May 2004 19:10:55 -0700( From: bob@instantwhip.com (Bob Ceculski)F Subject: Re: Switching from Process Software TCPware to TCPIP Services= Message-ID: <d7791aa1.0405171810.5ef4b48f@posting.google.com>p  ` "Pip" <pip@ti.nl0.com> wrote in message news:<40a93a4f$0$31675$afc38c87@news.optusnet.com.au>...N > Because it appears that TCPware is not currently available for OpenVMS v8.1 
 > on Itanium.     8 TCPware is being ported to itanium ... will be there for8 8.2 ... plus it is the ONLY IP stack that can run decnet phase IV over IP ...   ------------------------------  % Date: Mon, 17 May 2004 21:25:50 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>F Subject: Re: Switching from Process Software TCPware to TCPIP Services6 Message-ID: <40A9742E.E03754D7@NeOaSrPtAhMlNiOnWk.net>  
 Pip wrote: > I > Has anybody ever switched from Process Software's TCPware to HP's TCPIPe- > Services, and have gotchas to look out for? L > (In particular, features that TCPware has that might be missing from TCPIP > Services)   C Well, I've never hacked a TCPware distro., but I can tell you this:-C Multinet provides 13 more DCL verbs than UCX or TCP/IP Services forFE OpenVMS. The names "TCPware" and "Multinet" are a lot shorter, also.)s  E In general (in my experience and analysis), the economics of bundling G (TCPIP is now included in the VMS license bundle) don't offset the loss ? of features or the expense of conversion from either TCPware or 	 Multinet.)  H Frankly, IMO, since Tru64 is toast anyway, someone should buy up VMS (hpF can't be trusted with it, this much is obvious to even the most casualG observer) and Process Software's TCP/IP stacks for it, combine the bestp@ features of all three stacks into one and bundle the result with OpenVMS.   -- t David J. Dachtera* dba DJE Systemsw http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/)   ------------------------------  % Date: Mon, 17 May 2004 21:50:01 -0500y@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>F Subject: Re: Switching from Process Software TCPware to TCPIP Services6 Message-ID: <40A979D9.622D78C0@NeOaSrPtAhMlNiOnWk.net>   Bob Ceculski wrote:, > b > "Pip" <pip@ti.nl0.com> wrote in message news:<40a93a4f$0$31675$afc38c87@news.optusnet.com.au>...O > > Because it appears that TCPware is not currently available for OpenVMS v8.1> > > on Itanium.  > : > TCPware is being ported to itanium ... will be there for: > 8.2 ... plus it is the ONLY IP stack that can run decnet > phase IV over IP ...  A Not true. Multinet also provides DnIV/IP as Point-to-Point links.a   --   David J. Dachteraa dba DJE Systemso http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 00:09:36 +0100I; From: "Mark Iline - Info-VAX account" <ivax@meng.ucl.ac.uk> 7 Subject: TCPIP Services IMAP server - reloading headersv: Message-ID: <057d01c43c64$05b87f70$bbff0352@HP19054647700>  , This is a multi-part message in MIME format.  + ------=_NextPart_000_057A_01C43C6C.675450D0  Content-Type: text/plain;o 	charset="iso-8859-1".+ Content-Transfer-Encoding: quoted-printablee  ) I don't think this made it out before (?)A  F Subsequent to this, the current release of Mozilla on Windows seems to behave as OXP & OE.0     Mark ----- Original Message -----=20S# From: Mark Iline - Info-VAX accountC To: INFO-VAX@LISTSERV.UGA.EDU1$ Sent: Tuesday, May 11, 2004 11:59 AM7 Subject: TCPIP Services IMAP server - reloading headers0     Hi,1  H I'm currently playing with the IMAP server in HP TCPIP Services 5.3 to = seen  if it's suitable for prime-time.  E Our users are likely to have large quantities of mail stored on the =c serverD (both number and size), so reports of slow performance downloading = headerse or mails were worrying.d  G Playing with both Outlook XP & Outlook Express clients, things seem a =( bit.F more complicated. When opening an IMAP folder, in some cases all the = headerssC will be downloaded each time at a rate of of about 10 per second. =s (OpeningH another folder, then re-opening the original folder will cause them to = alleA be downloaded again) In other cases, the folder opens pretty much26 instantaneously (eg a folder with 500 messages in it).  C In these cases, there are no obvious differences in the OXP or OE =3 settingsE on the folders. The size of the folders seems to have no bearing on =c whetherpJ a reload occurs. The only pointer to a pattern that I've spotted is that = itG may be something to do with whether the folder has recent e-mails in ituI (maybe arrived in the last few days). ie the folders that don't provoke =p a E reload tend to contain mail that's a month old. However the pattern =i doesn'td  seem to be that straightforward.  C I'm not actually sure whether it's OXP/OE or the IMAP server that's A governing the behaviour. It's not impossible that the client *is*iG downloading the headers each time, but on some folders the server has =  all I the information cached, so this can be done very fast; whereas on other =t it's wading through the .MAI file.a  J Does anyone have any ideas as to what the criteria is for which of these = twoO apparent cases occurs ?i     Mark  9 Mark Iline, Sys Mgr, UCL Mech Eng; ivax"at"meng.ucl.ac.uk   + ------=_NextPart_000_057A_01C43C6C.675450D0E Content-Type: text/html; 	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printablev  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =e charset=3Diso-8859-1">9 <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>/ <STYLE></STYLE>f </HEAD>p <BODY bgColor=3D#ffffff>A <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =  size=3D3>I don't think=200D this made it out before (?)<BR><BR>Subsequent to this, the current =
 release of=20i4 Mozilla on Windows seems to<BR>behave as OXP &amp; = OE.<BR><BR><BR>Mark<BR>-----=20pG Original Message ----- <BR>From: Mark Iline - Info-VAX account<BR>To: =S </FONT><A=20J href=3D"mailto:INFO-VAX@LISTSERV.UGA.EDU"><FONT face=3D"Times New Roman" =  J size=3D3>INFO-VAX@LISTSERV.UGA.EDU</FONT></A><BR><FONT face=3D"Times New =	 Roman"=20 J size=3D3>Sent: Tuesday, May 11, 2004 11:59 AM<BR>Subject: TCPIP Services = IMAP=20 H server - reloading headers<BR><BR><BR>Hi,<BR><BR>I'm currently playing = with the=20cF IMAP server in HP TCPIP Services 5.3 to see<BR>if it's suitable for=20J prime-time.<BR><BR>Our users are likely to have large quantities of mail =	 stored=20 J on the server<BR>(both number and size), so reports of slow performance=20I downloading headers<BR>or mails were worrying.<BR><BR>Playing with both =a
 Outlook=20J XP &amp; Outlook Express clients, things seem a bit<BR>more complicated. = When=203B opening an IMAP folder, in some cases all the headers<BR>will be = downloaded each=20G time at a rate of of about 10 per second. (Opening<BR>another folder, =o then=20tH re-opening the original folder will cause them to all<BR>be downloaded = again) In=20D other cases, the folder opens pretty much<BR>instantaneously (eg a = folder with=20B 500 messages in it).<BR><BR>In these cases, there are no obvious = differences in=20nI the OXP or OE settings<BR>on the folders. The size of the folders seems =d
 to have=20I no bearing on whether<BR>a reload occurs. The only pointer to a pattern =o that=20 D I've spotted is that it<BR>may be something to do with whether the =
 folder has=20 F recent e-mails in it<BR>(maybe arrived in the last few days). ie the =
 folders=20I that don't provoke a<BR>reload tend to contain mail that's a month old. =O
 However=20H the pattern doesn't<BR>seem to be that straightforward.<BR><BR>I'm not = actually=20xE sure whether it's OXP/OE or the IMAP server that's<BR>governing the =N
 behaviour.=20eJ It's not impossible that the client *is*<BR>downloading the headers each = time,=20F but on some folders the server has all<BR>the information cached, so = this can be=20C done very fast; whereas on other it's<BR>wading through the .MAI=20 H file.<BR><BR>Does anyone have any ideas as to what the criteria is for = which of=20,I these two<BR>apparent cases occurs ?<BR><BR><BR>Mark<BR><BR>Mark Iline, =C Sys Mgr,=20  UCL Mech Eng; =y< ivax"at"meng.ucl.ac.uk</FONT><BR></FONT></DIV></BODY></HTML>  - ------=_NextPart_000_057A_01C43C6C.675450D0--    ------------------------------   End of INFO-VAX 2004.274 ************************