INFO-VAX Sat, 01 Mar 2008 Volume 2008 : Issue 121 Contents: Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Re: Leap Year Re: Leap Year Re: Leap Year Re: Long term archiving of VMS stuff Re: Question about DFU Swapping new disks into a shadow set Re: Swapping new disks into a shadow set Re: Swapping new disks into a shadow set Re: Swapping new disks into a shadow set Re: Swapping new disks into a shadow set Re: Swapping new disks into a shadow set Re: Swapping new disks into a shadow set Re: Wollogong TCP/IP stack Re: Wollogong TCP/IP stack ---------------------------------------------------------------------- Date: Fri, 29 Feb 2008 14:46:06 -0700 From: Jim Mehlhop Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <47C87D1E.7080009@parsec.com> Stanley F. Quayle wrote: > On 26 Feb 2008 at 13:55, Richard B. Gilbert wrote: >> If you WANT Unix, why not just USE Unix????? > > It's not a question of wanting Unix -- it's a question of all those useful open-source > pieces (Firefox, Apache, Samba, etc.) being able to compile natively on VMS. We need > these things on VMS to be "relevant" [ie, saleable] in today's world. Compaq Secure Web Server(apache), CSWB Compaq Secure Web Browser (Mozilla), samba and the HP version of it run on VMS. > > As for the system I set up using GNV, it was a way to get the Unix guys on VMS quickly. > And there be no need for a learning curve if vi/emacs and some other tools were > available. We purists, of course, would use the more-powerful DCL environment... > > fork -- there are like 16 requirements for fork to work like it does in *nix. Right now, > VMS can do something like 5 of them. No problem, if you only need those 5. But most > *nix programmers don't restrict themselves to VMS's 5, even if they could. Why would > they? > > HP's not supporting the port of OpenOffice to VMS [darn!], but there's an "issuelist" of > things that need to be in VMS to make it work. Check out http://www.oooovms.dyndns.org/ > for the details... > > --Stan Quayle > Quayle Consulting Inc. > > ---------- > Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX > 8572 North Spring Ct., Pickerington, OH 43147 USA > stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html > "OpenVMS, when downtime is not an option" > > ------------------------------ Date: Sat, 01 Mar 2008 01:37:14 -0500 From: "Stanley F. Quayle" Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <47C8B34A.25029.17A00E00@infovax.stanq.com> On 29 Feb 2008 at 14:46, Jim Mehlhop wrote: > Compaq Secure Web Server(apache), CSWB Compaq Secure Web Browser (Mozilla), > samba and the HP version of it run on VMS. True enough. But each of those programs required a big effort to port. If VMS had better Unix support, that would just be a quick compile away. And what about client stuff? HP's making a big deal about samba -- but they only ported the server side. Why can't I mount a samba share on my VMS box?? --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: Fri, 29 Feb 2008 13:05:50 -0800 (PST) From: Jim Subject: Re: Leap Year Message-ID: > 2) =A0$ if p2 .eqs. "" then exit > > =A0 =A0 =A0Unreachable. > =A0 =A0 =A0If p1 is empty, then p2 must be empty ? $ @tt: "" abc _$ show sym/all P1 =3D "" P2 =3D "ABC" P3 =3D "" P4 =3D "" P5 =3D "" P6 =3D "" P7 =3D "" P8 =3D "" _$ exit ------------------------------ Date: Fri, 29 Feb 2008 13:57:56 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: Leap Year Message-ID: <4eaea4d8-c353-4c85-855d-573c7ac1a092@s37g2000prg.googlegroups.com> On Feb 29, 4:05=A0pm, Jim wrote: > > 2) =A0$ if p2 .eqs. "" then exit > > > =A0 =A0 =A0Unreachable. > > =A0 =A0 =A0If p1 is empty, then p2 must be empty > > ? Yes indeed, that 'must' is indeed too much. Others pointed that out (in Email) to me also. I should have written 'will be empty' for the purpose of this particular protection. And I was nitpicking I deserve to be nitpicked. I just find it a handy shortcut, acceptable to trap simply usage errors. For heavy duty production applications you need to do the old F$TYPE and/or proper range validation. I kinda like my leap-year test and wanted to show off. And I find that the symbol name substitution method to create dynamic symbols or fake-arrays is little known/understood. This looked like a nice application to demonstrate just that. Cheers, Hein. ------------------------------ Date: Fri, 29 Feb 2008 15:15:54 -0800 (PST) From: AEF Subject: Re: Leap Year Message-ID: <2f99e881-61e9-436b-b8a7-1140d033aeb5@p43g2000hsc.googlegroups.com> On Feb 29, 5:57 pm, Hein RMS van den Heuvel wrote: > On Feb 29, 4:05 pm, Jim wrote: > [...] > > I kinda like my leap-year test and wanted to show off. Yeah, but your clever leap-year test might produce erroneous results for another reason. See http://groups.google.com/group/comp.os.vms/msg/f759341424d7628c?dmode=source for details about how F$CVTIME() had at least one known bug (day of week incorrect for large years) in at least some versions of VMS before V5.5. This was due to a shortcut used to avoid having to do 64- bit arithmetic on a VAX. (See the cited article for details.) So there may be other bugs in it, where as I'd expect division to be more reliable (except on Intel chips! :-). OTOH, since the day of week goes through a 400 year cycle, using a range like 2000 through 2399 is all you really need to do (and this gives you the correct long-term distribution), which reduces the likelihood of encountering large-year bugs. [...] > > Cheers, > Hein. AEF ------------------------------ Date: Fri, 29 Feb 2008 16:28:52 -0600 From: Michael Austin Subject: Re: Long term archiving of VMS stuff Message-ID: Stanley F. Quayle wrote: > On 27 Feb 2008 at 18:50, Bill Gunshannon wrote: >> And, believe it or not, if this involved classified data I can probably put >> together a system at a secure facility to help them recover this data. > > If you don't have a clearance (DOE "Q"), they'll need to assign you a person with a > clearance to make sure you're not accessing the data, just copying it. But all the > people with the correct clearances are already working 100%+ on other projects. And that > person would get no other work done while they're watching your every move. You have not had fun until you try to correct an old LN03 laser printer print quality issue without ever being able to see a single sheet of paper... not even a test sheet as there "might be a ghost image of something secure that you are not allowed to see"... And the only thing in the room I can actually see (as everything else is draped with cloth sheets) is the a lone ln03 printer in the middle of the room. [them] Here is the printer - stand right here and do not look over your shoulder.... Problem is print quality a bit fuzzy all over the page... [me] Here, let me make a few adjustments...[print page] How is that? [them] still a little fuzzy on the right edge [me] Here, let me make a few adjustments...[print page] How is that? [them] now a little fuzzy on the left edge [me] Here, let me make a few adjustments...[print page] How is that? [them] Perfect. [me] Okay, I will have to take your word for it... ------------------------------ Date: Fri, 29 Feb 2008 14:32:31 -0700 From: Jim Mehlhop Subject: Re: Question about DFU Message-ID: <47C879EF.4090907@parsec.com> Fred Bach wrote: > > Does this mean that DFU for OpenVMS is available from you? > Are you currently supporting it? What would be your costs? > > Thanks.... > > . fred bach music at triumf dot c a > Since it is on the FREEware cd I will leave it up to you to figure out the cost. :-) >>> >>> I can understand its current status, along with the LDRIVER being >>> maintained by volunteers as freeware. (and many thanks are owed to Jur >>> for that). >>> >>> But before all the staff cuts and downsizing, was there some >>> technical/political/whatever reason that prevented DFU from being >>> included as part of VMS OS distribution ? ------------------------------ Date: Fri, 29 Feb 2008 13:03:55 -0800 (PST) From: tadamsmar Subject: Swapping new disks into a shadow set Message-ID: <095589ab-28dc-4658-b8eb-2fd10475865d@m34g2000hsc.googlegroups.com> I will be replacing the 2 physical disk drives in a shadow set shortly. The easiest way I can think of is to: 1. Dismount dka100: 2. Power down 3. Swap out dka100: 4. Reboot on dka0: 5. Merge the shadow set 6. Dismount dka0: 7. Power down 8. Swap out dka0: 9. Reboot on dka100: 10. Merge the shadow set Is there a better way? ------------------------------ Date: Fri, 29 Feb 2008 14:30:24 -0700 From: Jim Mehlhop Subject: Re: Swapping new disks into a shadow set Message-ID: <47C87970.200@parsec.com> I am assuming dka100 and dka0 are members of some shadowset. I am guessing it is the system disk that you are shadowing but not sure. Are the new drives the same size as the old drives? Are we talking about more than one system? what version of VMS tadamsmar wrote: > I will be replacing the 2 physical disk drives in a shadow set > shortly. > > The easiest way I can think of is to: > > 1. Dismount dka100: > 2. Power down > 3. Swap out dka100: > 4. Reboot on dka0: > 5. Merge the shadow set > 6. Dismount dka0: > 7. Power down > 8. Swap out dka0: > 9. Reboot on dka100: > 10. Merge the shadow set > > Is there a better way? ------------------------------ Date: Fri, 29 Feb 2008 16:46:51 -0500 From: "Richard B. Gilbert" Subject: Re: Swapping new disks into a shadow set Message-ID: <47C87D4B.8070701@comcast.net> tadamsmar wrote: > I will be replacing the 2 physical disk drives in a shadow set > shortly. > > The easiest way I can think of is to: > > 1. Dismount dka100: > 2. Power down > 3. Swap out dka100: > 4. Reboot on dka0: > 5. Merge the shadow set > 6. Dismount dka0: > 7. Power down > 8. Swap out dka0: > 9. Reboot on dka100: > 10. Merge the shadow set > > Is there a better way? I think you could skip the power downs and reboots! In my experience, RZ series disks are "hot swapable". ------------------------------ Date: Fri, 29 Feb 2008 17:08:38 -0500 From: JF Mezei Subject: Re: Swapping new disks into a shadow set Message-ID: <47c882bb$0$10283$c3e8da3@news.astraweb.com> tadamsmar wrote: > I will be replacing the 2 physical disk drives in a shadow set > shortly. > > The easiest way I can think of is to: > > 1. Dismount dka100: Since you are swapping a drive, then the new drive will be the target of a full copy operation no matter what you do. What is important is to ensure the rest of your shawdowset remains up on other nodes, and/or is cleanly dismounted so that when it remounts, the other members aren't target of merge/mini/full copy operations. ------------------------------ Date: Fri, 29 Feb 2008 15:19:37 -0800 (PST) From: AEF Subject: Re: Swapping new disks into a shadow set Message-ID: <5e9e35bf-b866-4261-b589-c9f10a46ae3b@d62g2000hsf.googlegroups.com> On Feb 29, 5:46 pm, "Richard B. Gilbert" wrote: > tadamsmar wrote: > > I will be replacing the 2 physical disk drives in a shadow set > > shortly. > > > The easiest way I can think of is to: > > > 1. Dismount dka100: > > 2. Power down > > 3. Swap out dka100: > > 4. Reboot on dka0: > > 5. Merge the shadow set > > 6. Dismount dka0: > > 7. Power down > > 8. Swap out dka0: > > 9. Reboot on dka100: > > 10. Merge the shadow set > > > Is there a better way? > > I think you could skip the power downs and reboots! In my experience, > RZ series disks are "hot swapable". Not on my Storage Works shelves/pedestals/towers or whatever the hell they're called. (Just what *are* they called?) I tried that on a test system and got several disk and SCSI bus errors. I've never done it again since. You need shelves/pedestals/towers/whatever that support hot swaps. AEF ------------------------------ Date: Fri, 29 Feb 2008 15:24:26 -0800 (PST) From: AEF Subject: Re: Swapping new disks into a shadow set Message-ID: <2cbb4367-4715-492e-9f8d-4a6a1a8b61db@q33g2000hsh.googlegroups.com> On Feb 29, 5:03 pm, tadamsmar wrote: > I will be replacing the 2 physical disk drives in a shadow set > shortly. > > The easiest way I can think of is to: > > 1. Dismount dka100: > 2. Power down > 3. Swap out dka100: > 4. Reboot on dka0: > 5. Merge the shadow set > 6. Dismount dka0: > 7. Power down > 8. Swap out dka0: > 9. Reboot on dka100: > 10. Merge the shadow set > > Is there a better way? Are you doing minimum boots? Otherwise won't your startup procedure attempt to mount both disks in the shadow set? Or fail to mount either depending on your command? Be sure not to include MOUNT commands for your system disk shadow set (if you have one) in your startup procedures. Otherwise you risk overwriting current data! (See the Vol. Shad. manual for the actual possible scenario.) AEF ------------------------------ Date: Fri, 29 Feb 2008 22:08:16 -0500 From: "Richard B. Gilbert" Subject: Re: Swapping new disks into a shadow set Message-ID: <47C8C8A0.7060501@comcast.net> AEF wrote: > On Feb 29, 5:46 pm, "Richard B. Gilbert" > wrote: > >>tadamsmar wrote: >> >>>I will be replacing the 2 physical disk drives in a shadow set >>>shortly. >> >>>The easiest way I can think of is to: >> >>>1. Dismount dka100: >>>2. Power down >>>3. Swap out dka100: >>>4. Reboot on dka0: >>>5. Merge the shadow set >>>6. Dismount dka0: >>>7. Power down >>>8. Swap out dka0: >>>9. Reboot on dka100: >>>10. Merge the shadow set >> >>>Is there a better way? >> >>I think you could skip the power downs and reboots! In my experience, >>RZ series disks are "hot swapable". > > > Not on my Storage Works shelves/pedestals/towers or whatever the hell > they're called. (Just what *are* they called?) I tried that on a test > system and got several disk and SCSI bus errors. I've never done it > again since. You need shelves/pedestals/towers/whatever that support > hot swaps. > > AEF The HSZxx and HSJxx controllers supported hot swaps. The HSZ40 had a button that you pushed in order to "quiesce the bus", after pushing that button and waiting a short period, you got a visual indicator that it was safe, for the next 30 seconds, to remove and, optionally, swap a disk. I don't recall what you did on the HSJs or the HSZ50s. In a former life I was the junior man in the systems group and had the privilege of hiking over to the data center and doing these hot swaps. ------------------------------ Date: Fri, 29 Feb 2008 14:40:29 -0700 From: Jim Mehlhop Subject: Re: Wollogong TCP/IP stack Message-ID: <47C87BCD.1040000@parsec.com> Stanley F. Quayle wrote: > On 25 Feb 2008 at 19:04, Bob Blum wrote: >> What version of Wollongong are they running? > How can they tell? (I have no access, it being a classified system.) > >> I have a copy of the Attachmate PathWay 3.1 documentation and CD. It >> supports UCX emulation, and still appears to use the TWG$* logicals and >> directories. > I'd be interested in getting a copy of what you have. Please call me at 888-VAX-VMS-8 to > discuss. > >> What version of VMS are they running? > V5.5-2H4 (and, yes, they're stuck on that version) Go with Multinet then. You can get the latest version and still have it run on 5.5-2 > > --Stan Quayle > Quayle Consulting Inc. > > ---------- > Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX > 8572 North Spring Ct., Pickerington, OH 43147 USA > stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html > "OpenVMS, when downtime is not an option" > > ------------------------------ Date: Sat, 01 Mar 2008 01:38:44 -0500 From: "Stanley F. Quayle" Subject: Re: Wollogong TCP/IP stack Message-ID: <47C8B3A4.23455.17A16B0F@infovax.stanq.com> On 29 Feb 2008 at 14:40, Jim Mehlhop wrote: > Go with Multinet then. > You can get the latest version and still have it run on 5.5-2 Or UCX -- I have the appropriate savesets. The big question is how Wollongong-specific they made their code. That could be a nasty port to get to anything else... --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ End of INFO-VAX 2008.121 ************************