INFO-VAX Sat, 15 Sep 2007 Volume 2007 : Issue 504 Contents: Re: despair Re: despair Re: despair Re: Pearl from The Availability Digest - Integrity, VMS, TDMS TCP/IP Re: TCP/IP RE: TCP/IP Re: TCP/IP Re: TCP/IP Re: Will Linux bloat itself out of existance ? Re: Will Linux bloat itself out of existance ? ---------------------------------------------------------------------- Date: Sat, 15 Sep 2007 07:39:42 -0700 From: AEF Subject: Re: despair Message-ID: <1189867182.482875.64450@r29g2000hsg.googlegroups.com> On Sep 14, 9:57 pm, "David P. Murphy" wrote: > On Sep 14, 1:40 pm, AEF wrote: > > > So the author of this bad code was apparently only worried about show- > > stoppers. > > I beg to differ. Anytime you code > > $ ON ERROR THEN CONTINUE > > in front of a ALLOCATE command, that is just plain wrong. No debate. Please forgive me if I'm being obtuse on this. That said... Please tell me what error from the ALLOCATE command would screw things up and how. > Your arguments seem to hold water only as far as error trapping the > outcome of the BACKUP command, but this lies before the INITIALIZE > and ALLOCATE as well as the BACKUP. Guilty, guilty, guilty. What error from INIT would screw things up? My experience is that when INIT fails, it's an F error. Relax, dude! The world is not going to end because of this command procedure. Besides, that's only two "guilty"s. :-) > > I'm not recommending this way of doing things; I'm just > > trying to explain what I think the motivating factors were. > > Of course incompetence and not-giving-a-s%%% are other possible > > reasons! > > I'm going with "stupidity" here. Truly, a little knowledge can be > a very dangerous thing. > > > Maybe it was written by a BOFH! > > Nah, the Bastard always knows exactly what he's doing. Sorry, I disagree or missed your point (about BOFH). > > ok > dpm All right. First: Never say never! OK. Next... Only once did I ever have a problem from "misuse" (actually, in this case, non-use) of ALLOCATE. It was in 1988 when I was a (rather inexperienced -- well let's say, non-expert -- certainly not system manager level) user at IUCF. I was in the terminal room where the TU77 (or TU78 or similar tall vacuum) drives were located. I mounted a tape and was unable to MOUNT it. After trying some things, someone came down and said he had ALLOCATED the drive I had my tape on. I was only visiting there for a week or so to do an experiment, and back at my U. of Md. physics group (much smaller) we never had people ALLOCATE drives and then come down to mount a tape. But this was a bigger place and I didn't know that that's how they do things there. The guy was nice and let me do my tape job. OK. Something went wrong with misuse (non-used) of ALLOCATE. The world didn't come to an end! What's the big deal? (If they're going to have this ALLOCATE policy, they should have told me!) I find it interesting that you get all upset over this code snippet yet you can't even tell me if the tape is changed daily! You appear to know nothing at all about this environment except this code snippet. How did you come across this code in the first place? What is your role at this place that you have access to this code but still don't know if the tape is ever changed? At my current job no one but me loads tapes. No one but me uses DCL on the system. The tape drives are in the data center which is locked. Only people who need access to the room are allowed in. So a command procedure that would be okay at my site would not be okay at others. For example, you complained that the code didn't have a DEALLOCATE command. Why is this a big problem? Could it not be, maybe, that no one else ever uses this tape drive, in which case the lack of a DEALLOCATE command is not a problem? (OK, if the process hangs, the drive will stay allocated, but isn't there someone checking the system at least daily to take care of any problems that may arise? And if it does hang, someone will have to take care of it anyway.) AEF ------------------------------ Date: Sat, 15 Sep 2007 12:59:34 -0400 From: JF Mezei Subject: Re: despair Message-ID: <4bccb$46ec0f7b$cef8887a$26430@TEKSAVVY.COM> >> $ ON ERROR THEN CONTINUE >> in front of a ALLOCATE command, that is just plain wrong. No debate. You are perfectly right. One should use $ SET NOON instead. This would ensure the command procedure always completes succesfully. :-) :-) :-) AEF wrote: > Please tell me what error from the ALLOCATE command would screw things > up and how. Say this runs on the SYSTEM account (with allmighty privileges). Someone else has allocated the drive but is otherwise not being used. The allocate will fail, but other commands may succeed due to the fact that this account has all mighty privileges. Of course, the command would then write the backup to whatever tape was physically in the drive, and it could be someone else's tape. OR, the system manager has decided to have a process permanently allocate the tape drive so that nobody else can use it. > What error from INIT would screw things up? My experience is that when > INIT fails, it's an F error. $HELP ON PARA 2.$ ON ERROR THEN GOTO BYPASS $ RUN A $ RUN B . . . $ EXIT $ BYPASS: $ RUN C If either program A or program B returns a status code with a severity level of error or severe error, control is transferred to the statement labeled BYPASS and program C is run. So if INIT fails with an F mark, it will "CONTINUE". The text is quite clear in help that the action is triggered if the severity is equal to or greater than the one specified. WARNING < ERROR < SEVERE_ERROR > For example, you complained that the code didn't have a DEALLOCATE > command. Why is this a big problem? Say the procedure is meant to run at batch. This ensures that the tape device is freed once the job is complete and process is deleted. But if someone runs it interactively, it will leave the device allocated to their process until the person logs out and he/she/it may be unaware of it. > Could it not be, maybe, that no > one else ever uses this tape drive, in which case the lack of a > DEALLOCATE command is not a problem? A good system manager should setup his/her/its system to accomodate possible growth and new users coming in. ------------------------------ Date: Sat, 15 Sep 2007 12:35:10 -0500 From: Ron Johnson Subject: Re: despair Message-ID: On 09/15/07 11:59, JF Mezei wrote: >>> $ ON ERROR THEN CONTINUE >>> in front of a ALLOCATE command, that is just plain wrong. No debate. > > You are perfectly right. One should use $ SET NOON instead. This would > ensure the command procedure always completes succesfully. :-) :-) :-) Or allow the DCL writer to grab $STATUS and handle it as he sees fit. > AEF wrote: > > >> Please tell me what error from the ALLOCATE command would screw things >> up and how. > > > Say this runs on the SYSTEM account (with allmighty privileges). Someone > else has allocated the drive but is otherwise not being used. The > allocate will fail, but other commands may succeed due to the fact that > this account has all mighty privileges. > > Of course, the command would then write the backup to whatever tape was > physically in the drive, and it could be someone else's tape. Really? It won't hang on the ALLOCATE? Even if it didn't, how could it INIT a tape loaded by another process? Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it isn't necessary) and the job would have to hang there, sending occasion OPCOM messages. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 15 Sep 2007 12:47:04 -0000 From: Hein RMS van den Heuvel Subject: Re: Pearl from The Availability Digest - Integrity, VMS, TDMS Message-ID: <1189860424.896371.322140@50g2000hsm.googlegroups.com> > Home page:http://availabilitydigest.com/ > > This week they had an OpenVMS specific article - > QEI Provides Active/Active SCADA with OpenVMS > > http://www.availabilitydigest.com/public_articles/0209/qei.pdf Fine article. Nicely showing the PDP-VAX-ALPHA-IPF succes story. I do find the 'TDMS' in the subject line highly misleadng though, as that turns out to be the customers software, not the screen manager many of us will have expected. fwiw, Hein ------------------------------ Date: Sat, 15 Sep 2007 13:20:14 GMT From: dgsoftnz@gmail.com (David Goodwin) Subject: TCP/IP Message-ID: <46ebd015.2461449@news.clear.net.nz> In a few days I will finally get my hands on a machine to learn OpenVMS on (an AlphaServer 1200). Before then I must figure out what TCP/IP stack to use. I know almost nothing about any of them and dont know very much about how to use OpenVMS in general. Multinet and TCPware seem to be made by the same company and their website pages seem almost identical. I assume there must be some major difference between them - I dont see any reason why one company would make two seemingly identical products for the same platform. Could anyone tell me which TCP/IP stack I want to use and what are the major differences between them? ------------------------------ Date: Sat, 15 Sep 2007 15:26:23 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: TCP/IP Message-ID: David Goodwin wrote: > In a few days I will finally get my hands on a machine to learn > OpenVMS on (an AlphaServer 1200). Before then I must figure out what > TCP/IP stack to use. I know almost nothing about any of them and dont > know very much about how to use OpenVMS in general. > > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. I assume there must be some major > difference between them - I dont see any reason why one company would > make two seemingly identical products for the same platform. > > Could anyone tell me which TCP/IP stack I want to use and what are the > major differences between them? Don't bother, just use the one one the VMS distribution, TCPIP Services. Jan-Erik. ------------------------------ Date: Sat, 15 Sep 2007 10:51:11 -0500 From: "Paul Raulerson" Subject: RE: TCP/IP Message-ID: <000001c7f7b0$3d603b10$b820b130$@com> Not an expert on VMS TCP/IP stacks, but the version that comes with VMS seems pretty decent, especially the version included with 8.3. Works great for me and is a decently fast. -Paul > -----Original Message----- > From: David Goodwin [mailto:dgsoftnz@gmail.com] > Sent: Saturday, September 15, 2007 8:20 AM > To: Info-VAX@Mvb.Saic.Com > Subject: TCP/IP > > In a few days I will finally get my hands on a machine to learn > OpenVMS on (an AlphaServer 1200). Before then I must figure out what > TCP/IP stack to use. I know almost nothing about any of them and dont > know very much about how to use OpenVMS in general. > > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. I assume there must be some major > difference between them - I dont see any reason why one company would > make two seemingly identical products for the same platform. > > Could anyone tell me which TCP/IP stack I want to use and what are the > major differences between them? ------------------------------ Date: Sat, 15 Sep 2007 13:02:22 -0400 From: JF Mezei Subject: Re: TCP/IP Message-ID: David Goodwin wrote: > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. My recollection is that Multinet was made by TGV which was later bought by Cisco who then resold the VMS portion to Process. Process is the original writer of TCPWare. It would make sense for Process to migrate both products onto a converging path so that eventually they would be identical (single product). ------------------------------ Date: Sat, 15 Sep 2007 10:14:55 -0700 From: "johnhreinhardt@yahoo.com" Subject: Re: TCP/IP Message-ID: <1189876495.381295.58470@w3g2000hsg.googlegroups.com> On Sep 15, 9:20 am, dgsof...@gmail.com (David Goodwin) wrote: > In a few days I will finally get my hands on a machine to learn > OpenVMS on (an AlphaServer 1200). Before then I must figure out what > TCP/IP stack to use. I know almost nothing about any of them and dont > know very much about how to use OpenVMS in general. > > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. I assume there must be some major > difference between them - I dont see any reason why one company would > make two seemingly identical products for the same platform. > > Could anyone tell me which TCP/IP stack I want to use and what are the > major differences between them? If you're new to OpenVMS then just install the HP stack that comes on the distribution media. You didn't say what version of OpenVMS you have, but any recent (V7.3.-2 and later) version is adequate for home and learning use. If you have the latest versions (OpenVMS V8.3 and TCP/IP V5.6) then you have a very good combination. All three TCP/IP stacks will do the job and are overall pretty equal in features and performance. Each also has advantages in different areas. The HP stack has the advantage of being the vendor supported one. Installation is easy and the setup is fairly painless for typical usage - especially for use on an internal network in a general server role. Once you get a little more advanced and if you want to put your system onto the internet then you might consider one of the two offerings from Process. Both TCPWare and Multinet seem to have features which lend themselves to internet use particularly in dealing with SMTP mail processing and VPN options. I'm not an expert on either, unfortunately, so hopefully their various proponents will chime in also. Hope this helps. John H. Reinhardt ------------------------------ Date: Sat, 15 Sep 2007 04:01:29 -0500 From: Ron Johnson Subject: Re: Will Linux bloat itself out of existance ? Message-ID: On 09/14/07 20:05, Stephen Hoffman wrote: [snip] > > There will eventually be a day when there won't be Linux -- that's the > way of all products -- but there'll almost certainly be a successor or > descendant or heir to the Linux environment. What that heir might look > like is something we just don't know yet. But it is about as certain as > anything in this business that the heir OS will have substantial Linux > compatibility. FreeBSD? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 15 Sep 2007 05:05:36 -0700 From: Neil Rieck Subject: Re: Will Linux bloat itself out of existance ? Message-ID: <1189857936.647548.142650@57g2000hsv.googlegroups.com> On Sep 13, 8:02 pm, Neil Rieck wrote: [...snip...] > HP doesn't use distributed remote access for the OpenVMS source pool; > it's all home-grown access with VDE. VDE is a very old user interface > and very old design by current standards. (cvs and svn are also > relatively old environments, though far newer than VDE.) This use of > VDE assuming there have not been radical changes in the operations of > OpenVMS over last year; VDE has been in use in OpenVMS Engineering for > a very long time, and is accordingly rather entrenched. > > http://mvb.saic.com/freeware/freewarev40/vde/doc/vde_guide.html > > http://mvb.saic.com/freeware/freewarev70/vde/ > > If you dig around, you should be able to find some ancient > presentations I've done on VDE. > VDE = VMS Development Environment Thanks to Mr. Anonymous. I didn't know about this and will definately check it out. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada.http://www3.sympatico.ca/n.rieck/ ------------------------------ End of INFO-VAX 2007.504 ************************