INFO-VAX Tue, 15 Jul 2008 Volume 2008 : Issue 392 Contents: Re: File modified date a week late Re: Q: Configure TCP/IP Services for a node not yet booted? Re: Q: Configure TCP/IP Services for a node not yet booted? Re: Q: Configure TCP/IP Services for a node not yet booted? Re: RFC: Switching to WASD after 15 yrs with OSU... Re: Tru64 file system source code now open source Re: VAX 7000 cameo appearance Re: VAX 7000 cameo appearance ---------------------------------------------------------------------- Date: Mon, 14 Jul 2008 18:10:57 -0400 From: JF Mezei Subject: Re: File modified date a week late Message-ID: <487bcf0c$0$1841$c3e8da3@news.astraweb.com> The modified date/time seems to match the start time of the next job. So it is possible that when that job starts, it examines the previous log and does something to them (perhaps open/read/write and only reads them to check previous job for errors ?) ------------------------------ Date: Mon, 14 Jul 2008 14:59:29 -0700 (PDT) From: Ken.Fairfield@gmail.com Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: <2fc0f3dc-f946-43fb-9c6e-d221a756f862@d1g2000hsg.googlegroups.com> On Jul 12, 1:52 pm, "Bart.Z...@gmail.com" wrote: > On Jul 12, 9:09 am, "R.A.Omond" wrote: > > > > > Ken.Fairfi...@gmail.com wrote: > > > [...snip...] > > > > QUESTION: Is there a way to configure the interfaces for > > > the production nodes on the new system disk > > > *before* each of the production nodes boots > > > from that disk. > > > > I've been told I can, but from a somewhat unreliable > > > source. :-( It seems to me that while I can mount the > > > new system disk on the other cluster nodes without > > > booting them from it, trying to run TCPIP$CONFIG from > > > that disk probably wouldn't work because it would > > > look for TCPIP$CONFIGURATION.DAT, etc., in "SYS$SYSTEM" > > > which would not exist on the old system disk. > > > > Is there a way to specify a node to configure other > > > than the node that's running TCPIP$CONFIG? > > > I would strongly recommend NOT attempting to do this. > > IIRC some of the configuration files use the hostname > > as a key into index files. One of my customers got > > burned by trying to do something similar (they changed > > the IP address of an interface, changed the system name, > > rebooted and wondered why it didn't come up with the > > new IP address). > > Confirmed. I have worked with a fairly complex TCP/IP configuration. > To keep things managable, I put most of the configuration in DCL > files. However, a new member added to the cluster required a manual > configuration using TCPIP$CONFIG first. Roy and Bart, In my case, the cluster membership (and names) is staying the same. As I said in the original post, my task is to migrate from Multinet to TCP/IP Services, and I'm trying to do that with the least downtime to production. To that end, I "cloned" the system disk The original sysdisk is DSA0:, new sysdisk is DSA10:, production nodes A, B and C still booted from DSA0:, dev node D booted from DSA10:. (All nodes are still in the same cluster, just booted from different system disks.) I've installed TCP/IP Services on DSA10:, configured node D in TCP/IP Services and rebooted to prove the configuration. For the production nodes, I will retain the configuration currently active under Multinet, e.g., all of nodes A, B and C's interfaces will keep there IP addresses, etc. What I need to do is configure those nodes' interfaces in the TCP/IP Services configuration. If I can do that directly by pointing TCP$CONFIGURATION at the files on DSA10: from the production nodes, and configure their respective interfaces, I'm way ahead. Am I correct to assume that when Roy (and JF) said that entries in TCP$CONFIGURATION are "indexed by node", that "node" in this cases is, e.g., SCSNODE or SCSSYTEMID? Then it would seem I could proceed with the "pre-configuration" step. But the suggestion to put the configuration commands in a DCL procedure (which was also suggest off-list) to be executed on first reboot also saves time over going through the prompts in TCP$CONFIG.COM. Thanks, Ken ------------------------------ Date: Mon, 14 Jul 2008 18:38:39 -0400 From: JF Mezei Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: <487bd58b$0$1806$c3e8da3@news.astraweb.com> K > Am I correct to assume that when Roy (and JF) said that > entries in TCP$CONFIGURATION are "indexed by node", > that "node" in this cases is, e.g., SCSNODE or SCSSYTEMID? I believe it is SCSNODE DUMP/RECORD is your friend there. Get the SCSSYSTEMID value and look for it in hex in the dump just to make sure. But the nodename is definitely there. > Then it would seem I could proceed with the "pre-configuration" > step. Could you shutdown D, separate it from the cluster, and then boot it minimal as Node A, you could then use TCPIP$CONFIG at your leasure, shut it down, boot it as Node B, rin TCPIP$CONFIG at your leasure and do the same for node C. Then you can reconnect the node to the lan and reboot it as D. And when you reboot the other nodes into the new system disk, they'll have their node specific configs. The other option, as I originally suggested is to use the TCPIP utility on each of the node to affect the files on DSA10: by refining the logicals to point to the DSA10: files. You *MIGHT* (with a lot of checking) be able to use TCPIP$CONFIG on Node A (with proper logicals defined, and SET COMMAND for TCPIP) and then you would need to backup the node specific directories that are created when you configure services over to DSA10: to the appropriate roots for each node. (this can be cloned for all 3 nodes since those directories are populated with files from TCPIP$TEMPLATES.TLB ) > But the suggestion to put the configuration commands in a > DCL procedure (which was also suggest off-list) to be executed > on first reboot also saves time over going through the prompts > in TCP$CONFIG.COM. How much of downtime is allowed ? Could could boot without starting your apps (halfway between minuimum and full boot) and then manually use TCPIP$CONFIG, and then reboot fully. This might be the safest bet. What we don't know is how your 3 nodes share the loads/applications and how long you can have one node shutdown at any point in time. ------------------------------ Date: Mon, 14 Jul 2008 15:56:55 -0700 (PDT) From: Ken.Fairfield@gmail.com Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: On Jul 14, 3:38 pm, JF Mezei wrote: > K > > > Am I correct to assume that when Roy (and JF) said that > > entries in TCP$CONFIGURATION are "indexed by node", > > that "node" in this cases is, e.g., SCSNODE or SCSSYTEMID? > > I believe it is SCSNODE > > DUMP/RECORD is your friend there. Get the SCSSYSTEMID value and look for > it in hex in the dump just to make sure. But the nodename is definitely > there. Will do, later in the week when I have more time. Thanks for the various hints, JF. :-) > > Then it would seem I could proceed with the "pre-configuration" > > step. > > Could you shutdown D, separate it from the cluster, and then boot it > minimal as Node A, you could then use TCPIP$CONFIG at your leasure, shut > it down, boot it as Node B, rin TCPIP$CONFIG at your leasure and do the > same for node C. That's probably more scary (risky?) to me. I know it should be OK in principle, but fat-fingering can lead to some issues I'd rather not deal with (yes, the new node won't be allowed to join the cluster, but I saw something close to a cluster hang when changed SHADOW_SYS_UNIT for node D in the *wrong* ALPHAVMSSYS.PAR and it tried to mount DSA10 as DSA0 first time around(!)...). [...] > The other option, as I originally suggested is to use the TCPIP utility > on each of the node to affect the files on DSA10: by refining the > logicals to point to the DSA10: files. This is what I'm leaning toward doing. > You *MIGHT* (with a lot of checking) be able to use TCPIP$CONFIG on Node > A (with proper logicals defined, and SET COMMAND for TCPIP) and then you > would need to backup the node specific directories that are created when > you configure services over to DSA10: to the appropriate roots for each > node. (this can be cloned for all 3 nodes since those directories are > populated with files from TCPIP$TEMPLATES.TLB ) I agree that it seem like this ought to work, but doing the individual configuration commands inside the TCPIP utility seems somewhat more controlled (at least to the extent that I'm confident what's going on). [...] > How much of downtime is allowed ? Could could boot without starting your > apps (halfway between minuimum and full boot) and then manually use > TCPIP$CONFIG, and then reboot fully. This might be the safest bet. Well, agreed about suppressing all the disk mounts and applications startup that aren't needed. But running TCPIP$CONFIG.COM is not particularly quick and leads to typos under time pressure. If I have to wait to boot the new system disk before configuring, then I'll do that configuration via a DCL command procedure. > What we don't know is how your 3 nodes share the loads/applications and > how long you can have one node shutdown at any point in time. In this case, I want all three (production) nodes using the same IP stack at any time the application is up (Cerner Millennium), so we'll make it a full application, full cluster downtime. Thanks for all the ideas, Ken ------------------------------ Date: Mon, 14 Jul 2008 18:04:01 -0400 From: JF Mezei Subject: Re: RFC: Switching to WASD after 15 yrs with OSU... Message-ID: <487bcd6d$0$1841$c3e8da3@news.astraweb.com> etmsreec@yahoo.co.uk wrote: > Important feature for me is that WASD doesn't require installation on > an ODS5 volume. CSWS requires an ODS5 installation volume so you > either need to have a container file, a data disk or the system disk > initialized / converted to this. OSU is multi threaded and is very efficient. Ran fine on an all mighty microvax II. Apache is not VMS friendly because of the number of processes constantly being created. Not sure what architecture WASD uses (threads, AST driven or multi process) ------------------------------ Date: Mon, 14 Jul 2008 11:07:40 -0700 (PDT) From: johnwallace4@gmail.com Subject: Re: Tru64 file system source code now open source Message-ID: <7f008f1a-8eb8-45f9-8eaa-74b0bf724fd7@e53g2000hsa.googlegroups.com> On Jul 14, 1:54 pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article , "Tom Linden" writes: > > > HP-UX has strong roots in BSD. HP, Apollo and Digital were all > > founding members of OSF which was to have standardised on the > > Mach (?) kernel, but I think internal politics in HP won out and > > they did their own dilletante version, proabaly Motif was about > > the only thing trhey used out of OSF. > > I don't know if there's Mach inside, but OSF/1 was BSD based. HP > was the first company to ship OSF/1, as an alternative to HP-UX, > which didn't sell so they dropped it. DEC decided to go with OSF/1 > for there new architecture (Alpha) instead of porting their 32 bit > BSD based Ultrix. > > HP never made any attempt to move HP-UX to OSF. DEC OSF/1 (and/or Tru64) was sometimes described as "microkernel ready", there are some sources which say it is "microkernel based" but as far as I know it didn't really have Mach inside. Also, OSF/1 had features from both BSD and System V factions. The start of Chapter 2 of the TruCluster Server Handbook says this too and looks fairly definitive on the subject (as it should, given that authors include a former Tru64 UNIX Technical Group Leader with HP's Consulting Division and two former TruCluster Server Team Leaders with the Customer Support Center). You can even find it in Google Books: http://preview.tinyurl.com/5pcd9z ------------------------------ Date: Mon, 14 Jul 2008 19:37:45 -0400 From: Jack Patteeuw Subject: Re: VAX 7000 cameo appearance Message-ID: FrankS wrote: > I was watching the premier episode of "Burn Notice" the other night > and they had a couple of VAX 7000-series systems as props. Complete > with a StorageWorks cabinet containing four TZ8x7 libraries. > > The story line was that the computer system was super-secure and the > bad guys kidnapped the family of the computer wiz that designed the > software. So they were forcing him to break into the system and > download files. > > The systems were in a sealed room with big windows. You could see > they had installed some non-stock blinking lights to demonstrate that > the systems were computing *something*. It was pretty funny. Blinking lights ! K.O. must be spinning in his grave ! ------------------------------ Date: Mon, 14 Jul 2008 20:21:49 -0400 From: JF Mezei Subject: Re: VAX 7000 cameo appearance Message-ID: <487bedb9$0$1815$c3e8da3@news.astraweb.com> Jack Patteeuw wrote: > FrankS wrote: > Blinking lights ! K.O. must be spinning in his grave ! Did I miss some really huge news here ? I don't recall hearing anything about Ken Olsen having passed away. ------------------------------ End of INFO-VAX 2008.392 ************************