INFO-VAX Fri, 29 Jun 2007 Volume 2007 : Issue 351 Contents: Re: And the question was? (Re: Amazing, two new articles on Computerworld.com Re: And the question was? (Re: Amazing, two new articles on Computerworld.com ac Re: And the question was? (Re: Amazing, two new articles on Computerworld.com ac Re: And the question was? (Re: Amazing, two new articles on Computerworld.com ac Re: Catch OPCOM messages (in PASCAL) Re: Catch OPCOM messages (in PASCAL) Re: Catch OPCOM messages (in PASCAL) Re: Catch OPCOM messages (in PASCAL) Re: creating firmware floppies on FreeBSD or VMS Re: creating firmware floppies on FreeBSD or VMS Re: EVA/ Itanium question Re: EVA/ Itanium question Re: HP "Support" for OpenVMS Re: OpenVMS - When downtime is not an option RE: OpenVMS - When downtime is not an option RE: OpenVMS - When downtime is not an option Re: OpenVMS - When downtime is not an option RE: OpenVMS - When downtime is not an option Re: OpenVMS - When downtime is not an option Re: OpenVMS - When downtime is not an option Question on FCS vs RMS on PDP11 RSX Re: Question on FCS vs RMS on PDP11 RSX Re: Question on FCS vs RMS on PDP11 RSX Search Largest Database of DEC VAX PDP Manuals Re: Supercomputer rankings Re: Tech support Re: Vms ---------------------------------------------------------------------- Date: 28 Jun 2007 14:58:22 -0500 From: briggs@encompasserve.org Subject: Re: And the question was? (Re: Amazing, two new articles on Computerworld.com Message-ID: In article , John Reagan writes: > Bill Gunshannon wrote: > >> proprietary extension. The original point was that the PLI/I language >> took alignment into consideration and included alignment instructions >> as a part of the language which means it is reasonable to expect a >> program using it to be somewhat portable. C and Pascal do not share >> this feature. Any concern for alignment is little more than an after- >> thought. >> > > Well, so does COBOL (see the SYNCRONIZED clause). > > As a member of a standards committee, it is hard for a language to > predict behavior & performance of future hardware. COBOL and PL/I > provide some sort of "using my crystal ball, I think I need some > alignment help right here". What if my crystal ball is broken and I > actually needed alignment help somewhere else? > > Allowing/requiring the human to "help" the compiler produce code on some > current hardware (much less future hardware) seems silly to me. Kinda > like the "register" declaration in C. Not really part of any language > design, but just a crutch for a brain-dead compiler. > > Computer languages allow you to represent some algorithm to the > underlying hardware. How does alignment help you do that? > > The mindset of the Pascal committee (the only one I can speak for > personally) is that alignment (or any physical implementation detail) > doesn't add to the ability to describe more algorithmic detail. We left > things vague for things like interpreters, p-code, ASCII or EBCID, etc. > to all live within the standard. Maybe I'm missing the point. If all we're worrying about is a performance hint for ephemeral storage layout within a single compilation unit then I certainly agree that embedding a hint mechanism into the standard is silly. But if we're worrying about the ability to specify field layout for purposes of cross-language programming or for data storage on a file or data transport across the network then the ability of the programmer to apply some sort of "representation specification" is surely important. Encoding the relevant syntax and semantics into the standard is surely a reasonable way to ensure both portability and interoperability. I may even want to know that the record data I pass in main line code compiled with version 3.1 will be properly understood in a subroutine compiled under version 3.2. [On the other hand, I'd rather expect my vendor to keep things consistent enough that I don't have to overspecify things just to get alignment behavior that is consistent between minor releases of the same compiler] ------------------------------ Date: 28 Jun 2007 20:08:55 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: And the question was? (Re: Amazing, two new articles on Computerworld.com ac Message-ID: <5eiiqmF37f0v3U1@mid.individual.net> In article , John Reagan writes: > Bill Gunshannon wrote: > >> proprietary extension. The original point was that the PLI/I language >> took alignment into consideration and included alignment instructions >> as a part of the language which means it is reasonable to expect a >> program using it to be somewhat portable. C and Pascal do not share >> this feature. Any concern for alignment is little more than an after- >> thought. >> > > Well, so does COBOL (see the SYNCRONIZED clause). No one said it didn't. The languages referenced were Pascal and C. COBOL does a lot of stuff that other languages don't, kind of liker PL/I. :-) > > As a member of a standards committee, it is hard for a language to > predict behavior & performance of future hardware. COBOL and PL/I > provide some sort of "using my crystal ball, I think I need some > alignment help right here". What if my crystal ball is broken and I > actually needed alignment help somewhere else? Yeah, but it seems to work, at least most of the time. > > Allowing/requiring the human to "help" the compiler produce code on some > current hardware (much less future hardware) seems silly to me. I guess I'm just old school. I hate languages that hogtie me and then expect me to get some work done. I still think tyhe programmer should actually know what the comouter is doing and should have a say in how best to do it. > Kinda > like the "register" declaration in C. Not really part of any language > design, but just a crutch for a brain-dead compiler. Sorry, I don't agree but then, I don;t know how any of the compilers you get to work on do it. My experience has always been that the compiler is free to use registers for normal variables if it wants, but need not. The "register" directive was provided to allow the programmer the ability to take some variable that he thinks will benefit from being kept in a register and force it to be there. Of course, over use on a machine with insufficient resources is just another sign of an incompetent programmer. > > Computer languages allow you to represent some algorithm to the > underlying hardware. How does alignment help you do that? I don't understand the question. Not everything a computer does is mathematical algorithms. One needs to store information in memory. Some machines have a serious efficiency penalty when this results in unaligned access. Some way to fix this is needed. Even Macro-11 had one. > > The mindset of the Pascal committee (the only one I can speak for > personally) is that alignment (or any physical implementation detail) > doesn't add to the ability to describe more algorithmic detail. We left > things vague for things like interpreters, p-code, ASCII or EBCID, etc. > to all live within the standard. No problem with that. It was a conscious decision made by the standards committee after due consideration and that is fine. COBOL originally did the same thing over things like Range Checking. But, programmers should know this and take it into consideration when writing code. Some people might think this makes PL/I a superior language. :-) Others are just as happy with Pascal and C. And, yes, I still like COBOL. But I know not to trust the compiler to keep all my arrays within bounds. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Thu, 28 Jun 2007 20:06:21 -0700 From: "Tom Linden" Subject: Re: And the question was? (Re: Amazing, two new articles on Computerworld.com ac Message-ID: On Thu, 28 Jun 2007 13:08:55 -0700, Bill Gunshannon wrote: > In article , > John Reagan writes: >> Bill Gunshannon wrote: >> >>> proprietary extension. The original point was that the PLI/I language >>> took alignment into consideration and included alignment instructions >>> as a part of the language which means it is reasonable to expect a >>> program using it to be somewhat portable. C and Pascal do not share >>> this feature. Any concern for alignment is little more than an after- >>> thought. >>> >> >> Well, so does COBOL (see the SYNCRONIZED clause). > > No one said it didn't. The languages referenced were Pascal and C. > COBOL does a lot of stuff that other languages don't, kind of liker > PL/I. :-) > >> >> As a member of a standards committee, it is hard for a language to >> predict behavior & performance of future hardware. COBOL and PL/I >> provide some sort of "using my crystal ball, I think I need some >> alignment help right here". What if my crystal ball is broken and I >> actually needed alignment help somewhere else? > > Yeah, but it seems to work, at least most of the time. > >> >> Allowing/requiring the human to "help" the compiler produce code on some >> current hardware (much less future hardware) seems silly to me. > > I guess I'm just old school. I hate languages that hogtie me and then > expect me to get some work done. I still think tyhe programmer should > actually know what the comouter is doing and should have a say in how > best to do it. > >> Kinda >> like the "register" declaration in C. Not really part of any language >> design, but just a crutch for a brain-dead compiler. > > Sorry, I don't agree but then, I don;t know how any of the compilers > you get to work on do it. My experience has always been that the > compiler is free to use registers for normal variables if it wants, > but need not. The "register" directive was provided to allow the > programmer the ability to take some variable that he thinks will > benefit from being kept in a register and force it to be there. > Of course, over use on a machine with insufficient resources is just > another sign of an incompetent programmer. The concept of register has no place in a high-level language and is part of the low-level implementation of the compiler itself, that is not visible to the user. In C it was added as a hack optimization early on. I have also added it PL/I for systems programming, but not in the VMS version, but for reasons very different than what K&R did, giving direct control otherwise only done in assembly language. Indeed with a few extensions of this sort, including absolute addressing there is never any need for assembly language. This is essentially what IBM did > >> >> Computer languages allow you to represent some algorithm to the >> underlying hardware. How does alignment help you do that? > > I don't understand the question. Not everything a computer does > is mathematical algorithms. One needs to store information in > memory. Some machines have a serious efficiency penalty when this > results in unaligned access. Some way to fix this is needed. Even > Macro-11 had one. > >> >> The mindset of the Pascal committee (the only one I can speak for >> personally) is that alignment (or any physical implementation detail) >> doesn't add to the ability to describe more algorithmic detail. We left >> things vague for things like interpreters, p-code, ASCII or EBCID, etc. >> to all live within the standard. > > No problem with that. It was a conscious decision made by the standards > committee after due consideration and that is fine. COBOL originally did > the same thing over things like Range Checking. But, programmers should > know this and take it into consideration when writing code. Some people > might think this makes PL/I a superior language. :-) Others are just > as happy with Pascal and C. And, yes, I still like COBOL. But I know > not to trust the compiler to keep all my arrays within bounds. > > bill > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 28 Jun 2007 15:09:32 -0400 From: John Reagan Subject: Re: And the question was? (Re: Amazing, two new articles on Computerworld.com ac Message-ID: Bill Gunshannon wrote: > proprietary extension. The original point was that the PLI/I language > took alignment into consideration and included alignment instructions > as a part of the language which means it is reasonable to expect a > program using it to be somewhat portable. C and Pascal do not share > this feature. Any concern for alignment is little more than an after- > thought. > Well, so does COBOL (see the SYNCRONIZED clause). As a member of a standards committee, it is hard for a language to predict behavior & performance of future hardware. COBOL and PL/I provide some sort of "using my crystal ball, I think I need some alignment help right here". What if my crystal ball is broken and I actually needed alignment help somewhere else? Allowing/requiring the human to "help" the compiler produce code on some current hardware (much less future hardware) seems silly to me. Kinda like the "register" declaration in C. Not really part of any language design, but just a crutch for a brain-dead compiler. Computer languages allow you to represent some algorithm to the underlying hardware. How does alignment help you do that? The mindset of the Pascal committee (the only one I can speak for personally) is that alignment (or any physical implementation detail) doesn't add to the ability to describe more algorithmic detail. We left things vague for things like interpreters, p-code, ASCII or EBCID, etc. to all live within the standard. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Thu, 28 Jun 2007 15:22:25 -0400 From: JF Mezei Subject: Re: Catch OPCOM messages (in PASCAL) Message-ID: <50a8d$46840a92$cef8887a$21074@TEKSAVVY.COM> Question: when you use the reply/enable on some pseudo terminal and use a mailbox for broadcasts, how big must the mailbox be to catch every possible OPCOM message ? Also, is there ANY way to know what class a message is ? (OPER, MAIL, SECURITY etc) ????? ------------------------------ Date: 28 Jun 2007 15:19:51 -0500 From: briggs@encompasserve.org Subject: Re: Catch OPCOM messages (in PASCAL) Message-ID: In article <50a8d$46840a92$cef8887a$21074@TEKSAVVY.COM>, JF Mezei writes: > Question: > > when you use the reply/enable on some pseudo terminal and use a mailbox > for broadcasts, how big must the mailbox be to catch every possible > OPCOM message ? Since terminal I/O is buffered, SYSGEN parameter MAXBUF should provide an upper bound on a broadcast message size. On the other hand, since mailbox I/O is also buffered, there's an edge case where an OPCOM broadcast message plus terminal mailbox header will exeed MAXBUF and force that particular message to be truncated. I've never tested that edge case. In practice, the ability to get all 8192 bytes of an 8192 byte OPCOM message is probably of limited value. > Also, is there ANY way to know what class a message is ? (OPER, MAIL, > SECURITY etc) ????? Has to be parsed out of the broadcast message I believe. Although one could get creative with $ SET BROADCAST and have a separate enabled operator terminal and a separate associated terminal mailbox for each class. Then you could impute the class from the mailbox where the message shows up. ------------------------------ Date: 28 Jun 2007 16:04:13 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Catch OPCOM messages (in PASCAL) Message-ID: JF Mezei writes: > Question: > > when you use the reply/enable on some pseudo terminal and use a mailbox > for broadcasts, how big must the mailbox be to catch every possible > OPCOM message ? > > Also, is there ANY way to know what class a message is ? (OPER, MAIL, > SECURITY etc) ????? The answers are contained in OPCDEF (such as opcdef.h for C, $OPCDEF for Macro). The Users' Guide for the language you're using will tell you where to find these system definitions. OPCDEF gives both the layout (and therefor maximum size) of the message and defines constants for fields like the message class. ------------------------------ Date: Thu, 28 Jun 2007 17:20:49 -0400 From: JF Mezei Subject: Re: Catch OPCOM messages (in PASCAL) Message-ID: <2af4b$46842653$cef8887a$17660@TEKSAVVY.COM> Bob Koehler wrote: > The answers are contained in OPCDEF (such as opcdef.h for C, $OPCDEF > for Macro). The Users' Guide for the language you're using will tell > you where to find these system definitions. Isn't that for sending messages to OPCOM ? When you use a mailbox to receive broadcasts, I wa under the impression that all you got was the textual OPCOM messages that would otherwise have been sent to your terminal in ascii text. (which is why I never bothered trying it since I would much prefer getting a "structured" OPCOM message. OPCOM messages, as displayed on screen, do not contain which class the sender mentioned. ------------------------------ Date: Thu, 28 Jun 2007 13:08:04 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: creating firmware floppies on FreeBSD or VMS Message-ID: <07062813080416_202003EE@antinode.org> From: Anton Shterenlikht > I'd like to update the firmware to 7.3 on my ds10l. I'd like to > use the floppies route. I'd like to make these floppies either on > VMS or on FreeBSD. > How can I create a fat floppy in vms? I'd use something mentioned here: http://antinode.org/dec/sw/mtools.html > On the other hand if I use dd, then the floppy is probably in ufs, > because I cannot even read the text file: I'd say that if you use "dd", then you don't have _any_ file system on the destination device (unless you're copying a file system image file using "dd"). ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 28 Jun 2007 12:27:58 -0700 From: IanMiller Subject: Re: creating firmware floppies on FreeBSD or VMS Message-ID: <1183058878.869159.46810@n60g2000hse.googlegroups.com> I see The Hoff is not in favour of firmware upgrades by floppy http://64.223.189.234/node/385 ------------------------------ Date: Thu, 28 Jun 2007 19:23:56 -0500 From: David J Dachtera Subject: Re: EVA/ Itanium question Message-ID: <4684511C.71F572C6@spam.comcast.net> "Don.Zong@gmail.com" wrote: > > Sorry for the confusion, this is for upgrade, we snap-cloned the > system disk, then do the upgrade on the new system disk, now it is > time to let production boot off new system disk, we would like change > the LUN assignment on the new system disk to match the old one so we > don't need to change boot options on every server, will this work? So, before you went to all this effort, you looked into turning a snap-clone into a "real" disk volume, right? I'd have simply created a new LUN, done a BACKUP/IMAGE to it, and then booted from that to do the upgrade, knowing I could always reverse the procedure to return to my original boot device and accomplish a defrag in the process. As always, your mileage may vary. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Thu, 28 Jun 2007 19:24:54 -0500 From: David J Dachtera Subject: Re: EVA/ Itanium question Message-ID: <46845156.4C88E12F@spam.comcast.net> Paul Raulerson wrote: > > Can I come work where you work please?! You pretty obviously don't have to > deal with Sarbanes-Oxley... I wish I did not! You're joking, right? What does Sarb/Ox have to do with re-certifying a vendor's storage array firmware? -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Thu, 28 Jun 2007 15:18:04 -0400 From: JF Mezei Subject: Re: HP "Support" for OpenVMS Message-ID: <50ea2$4684098e$cef8887a$21074@TEKSAVVY.COM> Main, Kerry wrote: > Bottom line summary is that HP says the same thing to HP-UX Cust's > moving to Linux. IBM says the same thing when looking at AIX to Linux > migrations. Sun says the same about Solaris to Linux. I am not sure that IBM VPs go around and purposefully send out a message stating that IBM will help customers migrate from MVS (Z-OS this week I think). Secondly, HP should be very aware of the case of VMS where customers have been left in the dark, lied to and several attempts on its life have been made in the last decade starting with Palmer. This is especially true since Stallard committed the same "mistake" in his May 7th 2002 memo. Statements made by Livermore touch a very raw nerve in the VMS community and send a very precise signal to the ISV base, and that is not a signal we want to see sent. ------------------------------ Date: Thu, 28 Jun 2007 14:01:16 -0400 From: Bill Todd Subject: Re: OpenVMS - When downtime is not an option Message-ID: Bill Gunshannon wrote: ... > Like I said, I work with "mission critical" systems, too. Windows > systems can be secured. The users may not be happy that they can't > play MS Hearts, but the box can be closed up made secure and made > stable. But then, I don;t expect you or anyone else here to ever > accept that fact. It's much easier to point at something like that > Los Alamos article and interpolate that all systems are run just > like it. Reality is otherwise. There are a lot of badly managed > Windows systems. they are badly managed because the users don't care. > If the same sloppiness were applied to VMS is would be just as vulnerable. > This has been pointed out repeatedly. there are Windows boxes out > there with no password on the administrator account and with the user > running everything from the administrator account to boot. The sheer > number of Windows boxes and the fact that so many of them are in the > hands of and totally under the control of users guarantees this. It > doesn't make Windows any less secure than someone not locking the door > of their house makes Yale locks insecure. Sorry to have snipped so much of such an excellent response, but given that the original is still there it seemed appropriate. Kerry is, of course, a dyed-in-the-wool corporate shill, and has amply demonstrated that he'll continue to trot out the same half-truths and out-right falsehoods that he's been touting for the near-decade that I've been acquainted with his posts regardless of how many times he's corrected. So it's good to have a real-world customer with considerable applicable experience around who's willing to take him to task for it. A lot of people base their beliefs about Windows on experiences with the old consumer (non-NT/2K/XP-based) versions, or on newer systems managed the same way the old ones were (e.g., without appropriate account restrictions and with uncontrolled execution of random third-party software or unsecured Microsoft applications). And since a lot of newer systems *are* still 'managed' that way, the horror stories continue unabated despite the fact that modern Windows *can* be very secure (and reliable, and available) indeed (as, of course, can other options such as Unix). True, NT and its descendants weren't crafted with the same care that VMS was. OTOH, they've had several orders of magnitude more exposure than VMS ever did, and have now had well over a decade to have had the significant bugs flushed out, so the gap is nowhere nearly as large as it started out being. Digital Had It Then. Unfortunately, today just about everyone else does as well, for most practical purposes: that's what happens when you stand relatively still while the rest of the world doesn't. - bill ------------------------------ Date: Thu, 28 Jun 2007 14:11:25 -0400 From: "Main, Kerry" Subject: RE: OpenVMS - When downtime is not an option Message-ID: > -----Original Message----- > From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] On > Behalf Of Bill Gunshannon > Sent: June 28, 2007 10:31 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: OpenVMS - When downtime is not an option >=20 > In article > t>, > "Main, Kerry" writes: > >> -----Original Message----- > >> From: bill@cs.uofs.edu [mailto:bill@cs.uofs.edu] On > >> Behalf Of Bill Gunshannon > >> Sent: June 27, 2007 8:33 AM > >> To: Info-VAX@Mvb.Saic.Com > >> Subject: Re: OpenVMS - When downtime is not an option > >>=3D20 > > > > [snip...] > > > >> > If Windows server consolidation were really really taken to the > >> limit, > >> > you might find Windows has a small presence in the real data > centres > >> > because like for unix and vms and MVS, they'd have one box to do > >> their work. > >>=3D20 > >> If Windows were consolidated at the rate of 10:1 it would still > >> outnumber > >> VMS by at least 100:1. People here really need to face reality. > >> Windows > >> is not as bad as you would like to think. Just because a bunch of > >> home > >> machines (mostly running the original Windows install they came > with) > >> get > >> hacked doesn't mean that the boxes in the datacenter are that easy > to > >> break. > >>=3D20 > >> bill > >>=3D20 > > [snip...] > > > > Bill, > > > > What upsets readers on this list is when people like you make > statements > > like "Windows is not as bad as people here state that it is" when in > > fact many of the readers here manage mission critical environments > and > > the concept of testing applications against *monthly* security > patches > > released by the host vendor is just plain ludicrous.=3D20 >=20 > Yeah, well I "manage mission critical environments" to unless you > don't > consider DOD to be "mission critical". :-) In a mell managed system > we just don't see the stuff you keep spouting. >=20 So, DOD is different than all other med-large prod environments? I doubt it. > > > > Readers here take security patches seriously and ensure they get > applied > > asap. >=20 > So does DOD. :-) >=20 > > This might happen once or twice every few years with > OpenVMS. > > Could be better? Possibly, but 5-20 security patches every month > with > > Linux and Windows? >=20 > Most of which can be applied with no impact on operations. You know, > when you haev 100,000 machines all running the same "mandated and un- > changable) baseline you really don't need to test a patch on every > box. > The central authority tests against the baseline and then pushes the > patch to all the other boxes. >=20 So how does one test and deploy 5-20 security patches against important applications released *every month* for 100,000 systems?=20 Only way I can see is by not deploying patches which opens up all sorts of security issues. [The issue with 50-60% of all security issues being internal driven (Trojans, worms etc on laptops, PDA's, memory sticks, cell phones etc etc that are looking for open holes and that touch internal and external networks.] > > > > Then folks like you state "Windows can do the same job as OpenVMS.." >=20 > Can and does. Every day in the real world. >=20 > > > > I deal with Windows, UNIX and OpenVMS environments and during > > consolidation engagements talk all the time to Operations / Apps > groups > > and their managers about their major challenges... getting Windows > > servers and the associated huge management issues under control is > by > > far the absolute biggest issue raised by these groups. When looking > at > > server consolidation, the number of Wintel server consolidation > targets > > is usually something like 70-80% Wintel as the primary focus > today.=3D20 > > > > The readers here on this newsgroup are not from the "just reboot it" > > stream of managing IT. >=20 > Neither is DOD. (Well, maybe the Navy....) >=20 > > When a problem occurs on OpenVMS, it is > usually > > thoroughly analyzed to ensure it does not happen again. Detailed > > register information is available in system error logs so you can > decode > > which bits are set in which device registers. This provides one with > the > > ability to properly troubleshoot a problem down to a bus or device > > level. > > > > I am sorry if it bothers you, >=20 > Theonly thing that bothers me is people who bitch about FUD all the > time > tossing so much of it around. >=20 > > but you seem to be unique in not > having > > the same challenges in operationally managing large numbers of > Wintel > > servers as most other med to large Customers today. >=20 > Hardly unique. >=20 > > It is not to > say IT > > is not that important in a University environment (I know it is), > but it > > just does not compare to many mission critical environments in > private > > industry today (e.g. OpenVMS lottery I was at a number of weeks here > in > > Canada measured down time during bigger pots at $1.5M/hr.) >=20 > The University is not my only job. In my second job downtime might be > measured in body counts, not dollars. >=20 > > Check this out for what challenges the real world is facing today: > > http://www.vista-control.com/itanium_success.htm > > "Los Alamos, February 15th. 2007 After implementing mission-critical > > systems on Windows-based computers for many years, a customer > > experienced a virus in one of these systems that shut down > production > > for two days while the infected systems were diagnosed, restored and > > tested. The impact was that plant production was severely impacted > at no > > small cost. Despite internal opposition because of the established > > standard, Vsystem on HP Itanium servers running OpenVMS was chosen > for > > the next system to be replaced." >=20 > You keep trotting out the same old tired examples. I read it. Not > impressed. The fact that a virus got into the system is a management > issue and nothing more. In January I went to a place where several > thousand people gathered. Most bringing their laptops with them from > their homestation. We had built a network, we integrated all these > machines into this network. These machines included some that came > from places not even under US control. During the entire operation > we were actively targeted by determined (and well trained and ex- > perienced) intruders. There were no virus incidents. There were no > crashes or outages that could be blamed on Windows (the only real > outage we had was network related and involved somebody doing > something > nasty to a CISCO box because they didn't know what they were doing. > Windows worked flawlessly running lot's of intense applications. Go > figure..... >=20 > > > > Another major issue - The reality is that the plain fact is that the > > most common method of troubleshooting Windows servers today is to > simply > > reboot it. Even those who have experience with other platforms look > at > > Windows event logs and find minimal information beyond a basic > cryptic > > message (e.g. sample error - scsi error xxxx0906, which means not a > > whole lot if you have 4 or 5 different scsi devices on 2 or 3 > different > > SCSI buses). This type of error means they will likely have to just > > reboot the server. >=20 > During the entire operation there was only one reboot of the servers > and that was after a critical update was pushed down to us. This > notion that Windows boxws have to be rebooted all the time is based > on totally open and uncontrolled desktops. Not properly managed > systems. >=20 Not according to Microsoft. They typically (albeit not always) recommend the server be rebooted after applying these monthly security patches. So, if you are not rebooting these servers after the vendor recommends it, then you are in uncharted and unsupported territory. If you subscribe to the auto patch update on your desktop Windows PC, the patch process will often *force* a reboot after the patch is applied. > > > > When the folks here state Windows servers do not have the same > bullet > > proof operational capabilities of OpenVMS, they are usually talking > from > > experience and dealing with OpenVMS and "hardened" Wintel server > > environments.=3D20 >=20 > If your machine can be infected by a virus in any of the usual means, > it isn't "hardened". >=20 Even "hardened" systems are potentially exposed when kernel security issues are identified. > > > > It is not OS religion that drives the "Windows can not match > OpenVMS" > > statements in this newsgroup, but rather a form of educating the > less > > enlightened who do not really understand mission critical support > > requirements. >=20 > I am not saying Windows can match VMS. There is no doubt that VMS can > do things that Windows can't. But the Windows picture is nowhere near > as bleak as people here try to paint it. And when you consider all > things, in the long run the few things that VMS does so much better > than Windows are becoming less important to businesses. But when > you base your decisions on bogus data, what do you expect. >=20 Exactly - when you hide the Operations and App *server* testing required every month by Linux and Windows, you are part of the issue with making decisions based on bogus data. =20 > > > > Unfortunately, sometimes it is like talking to teenagers - "talk to > the > > hand..". These "kids" are just going to have to go out and > experience > > for themselves what those with more experience tried to tell them in > the > > first place. >=20 > Like I said, I work with "mission critical" systems, too. Windows > systems can be secured. The users may not be happy that they can't > play MS Hearts, but the box can be closed up made secure and made > stable. =20 I am not talking about desktops. Totally different environment. > But then, I don;t expect you or anyone else here to ever > accept that fact. It's much easier to point at something like that > Los Alamos article and interpolate that all systems are run just > like it. Reality is otherwise. There are a lot of badly managed > Windows systems. they are badly managed because the users don't care. > If the same sloppiness were applied to VMS is would be just as > vulnerable. OpenVMS does not have 5-20 security patches released each and every month. > This has been pointed out repeatedly. there are Windows boxes out > there with no password on the administrator account and with the user > running everything from the administrator account to boot. =20 Again, I really do not care that much about desktops. You keep comparing what I am talking about with regards to Windows on desktops. Windows on servers is a totally different world than Windows on desktops. The very fact that you mentioned users having access to the Admin account illustrates you have limited experience with large scale Windows Servers management. Admin accounts in Windows server world is generally as well guarded as System password on OpenVMS or root password on UNIX. > The sheer > number of Windows boxes and the fact that so many of them are in the > hands of and totally under the control of users guarantees this. It > doesn't make Windows any less secure than someone not locking the door > of their house makes Yale locks insecure. >=20 > bill >=20 The issue is that Yale does not issue monthly warnings to its Customers about ways their locks can be compromised. Or issue recommendations for monthly maint on their locks to keep them safe.=20 Customers expect a much higher level of basic working security than this. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Thu, 28 Jun 2007 14:35:13 -0400 From: "Main, Kerry" Subject: RE: OpenVMS - When downtime is not an option Message-ID: > -----Original Message----- > From: Bill Todd [mailto:billtodd@metrocast.net] > Sent: June 28, 2007 2:01 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: OpenVMS - When downtime is not an option >=20 > Bill Gunshannon wrote: >=20 > ... >=20 > > Like I said, I work with "mission critical" systems, too. Windows > > systems can be secured. The users may not be happy that they can't > > play MS Hearts, but the box can be closed up made secure and made > > stable. But then, I don;t expect you or anyone else here to ever > > accept that fact. It's much easier to point at something like that > > Los Alamos article and interpolate that all systems are run just > > like it. Reality is otherwise. There are a lot of badly managed > > Windows systems. they are badly managed because the users don't > care. > > If the same sloppiness were applied to VMS is would be just as > vulnerable. > > This has been pointed out repeatedly. there are Windows boxes out > > there with no password on the administrator account and with the > user > > running everything from the administrator account to boot. The > sheer > > number of Windows boxes and the fact that so many of them are in the > > hands of and totally under the control of users guarantees this. It > > doesn't make Windows any less secure than someone not locking the > door > > of their house makes Yale locks insecure. >=20 > Sorry to have snipped so much of such an excellent response, but given > that the original is still there it seemed appropriate. >=20 > Kerry is, of course, a dyed-in-the-wool corporate shill, and has amply > demonstrated that he'll continue to trot out the same half-truths and > out-right falsehoods that he's been touting for the near-decade that > I've been acquainted with his posts regardless of how many times he's > corrected. So it's good to have a real-world customer with > considerable > applicable experience around who's willing to take him to task for it. >=20 And as often is the case, Bill Todd should stick to the areas where he is most comfortable and has real world experience. Windows Server operations and administration is obviously not one of those areas.=20 I work with large company IT server depts a great deal (UNIX, Windows, OpenVMS - even z/OS the odd time) and these are real world Windows *server* Operations issues. > A lot of people base their beliefs about Windows on experiences with > the > old consumer (non-NT/2K/XP-based) versions, or on newer systems > managed > the same way the old ones were (e.g., without appropriate account > restrictions and with uncontrolled execution of random third-party > software or unsecured Microsoft applications). And since a lot of > newer > systems *are* still 'managed' that way, the horror stories continue > unabated despite the fact that modern Windows *can* be very secure > (and > reliable, and available) indeed (as, of course, can other options such > as Unix). >=20 Sigh... You are missing the point. Basic admin processes is not the issue. Although still a big challenge, monthly roll-out challenges is not the main issue.=20 Lets assume a well managed Windows (Linux) and OpenVMS server is the baseline. Let me try real sloooowww here ... The issue is "how do you test important applications against the 5-20 OS and LP security patches released by the host vendor each and every month? " Lets hear some real world Windos (Linux) Operations experience on how you do this. > True, NT and its descendants weren't crafted with the same care that > VMS > was. OTOH, they've had several orders of magnitude more exposure than > VMS ever did, and have now had well over a decade to have had the > significant bugs flushed out, so the gap is nowhere nearly as large as > it started out being. >=20 So how does one account for so many monthly security issues?=20 > Digital Had It Then. Unfortunately, today just about everyone else > does > as well, for most practical purposes: that's what happens when you > stand relatively still while the rest of the world doesn't. >=20 > - bill [insert blustering personal insult from self appointed c.o.v. moderator] Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Thu, 28 Jun 2007 18:20:50 -0400 From: Bill Todd Subject: Re: OpenVMS - When downtime is not an option Message-ID: <5M6dncYdppEfqRnbnZ2dnUVZ_oSnnZ2d@metrocastcablevision.com> Main, Kerry wrote: ... The issue is "how do you test > important applications against the 5-20 OS and LP security patches > released by the host vendor each and every month? " The answer, which anyone even half-competent in this area already knows, is that most of the security patches *do not apply to your server environment and hence can be applied at leisure or in many cases not at all*: they apply to desktop-like environments that don't have proper account controls in place to contain application-level threats, have things like ActiveX and other browser scripting enabled, and/or run other popular layered software that (at least in an unsecured environment) opens paths up to the insecure code. So you actually look at the patch explanation rather than blindly throw the proffered fix over the transom, usually decide that your server environment cannot be affected by the exposure (though most likely won't be affected by the fix, either), add it to the "Perhaps I'll apply it the next time I actually have to patch the system" list, and optionally run it on a test system until then to make sure it doesn't have unforeseen consequences - much as you would with any other OS, save that most other OSs would not have been subject to such wide-spread attack attempts and hence would not have had many of their flaws exposed at all. - bill ------------------------------ Date: Thu, 28 Jun 2007 19:04:04 -0500 From: "Paul Raulerson" Subject: RE: OpenVMS - When downtime is not an option Message-ID: <004f01c7b9e1$024dc5e0$06e951a0$@com> The only answer to this is that anyone who believes it *is* only half competent. It is very VERY important to keep patches up to date on the Window server(s). The vast majority of the harmful and expensive virii, Trojans, and worms that get in get in via the server. E-Mail, SQL Server, IIS, etc. And yes, it is fact, for *whatever* reason, that the VAST majority of Windows Server time is spent putting in patches and fixes and working HooDoo on the Registry. Does not mean Windows is not deucedly useful though. Would you care to rethink your statement? Surely you could NOT have meant to say what you actually said. -Paul > -----Original Message----- > From: Bill Todd [mailto:billtodd@metrocast.net] > Sent: Thursday, June 28, 2007 5:21 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: OpenVMS - When downtime is not an option > > Main, Kerry wrote: > > ... > > The issue is "how do you test > > important applications against the 5-20 OS and LP security patches > > released by the host vendor each and every month? " > > The answer, which anyone even half-competent in this area already > knows, > is that most of the security patches *do not apply to your server > environment and hence can be applied at leisure or in many cases not at > all*: they apply to desktop-like environments that don't have proper > account controls in place to contain application-level threats, have > things like ActiveX and other browser scripting enabled, and/or run > other popular layered software that (at least in an unsecured > environment) opens paths up to the insecure code. ------------------------------ Date: Fri, 29 Jun 2007 00:21:16 -0000 From: ultradwc@gmail.com Subject: Re: OpenVMS - When downtime is not an option Message-ID: <1183076476.052445.218250@m36g2000hse.googlegroups.com> On Jun 28, 10:30 am, b...@cs.uofs.edu (Bill Gunshannon) wrote: > > Then folks like you state "Windows can do the same job as OpenVMS.." > > Can and does. Every day in the real world. except it does it with viruses and errors and reboots ... > During the entire operation there was only one reboot of the servers > and that was after a critical update was pushed down to us. This > notion that Windows boxws have to be rebooted all the time is based > on totally open and uncontrolled desktops. Not properly managed > systems. > > Like I said, I work with "mission critical" systems, too. Windows > systems can be secured. The users may not be happy that they can't > play MS Hearts, but the box can be closed up made secure and made > stable. that is a bunch of bull ... we have a windows server that needs rebooted all the time from apps locking or errors locking the server ... server has all the latest virus and spyware tools ... call the apps vendor and they tell us to REBOOT ... and the idea of windows being secure can be verified at the CERT sight, just don't laugh too hard after analyzing the results ... ------------------------------ Date: Fri, 29 Jun 2007 00:23:06 -0000 From: ultradwc@gmail.com Subject: Re: OpenVMS - When downtime is not an option Message-ID: <1183076586.322976.256900@n60g2000hse.googlegroups.com> On Jun 28, 2:01 pm, Bill Todd wrote: > Bill Gunshannon wrote: > > ... > > > > > > > Like I said, I work with "mission critical" systems, too. Windows > > systems can be secured. The users may not be happy that they can't > > play MS Hearts, but the box can be closed up made secure and made > > stable. But then, I don;t expect you or anyone else here to ever > > accept that fact. It's much easier to point at something like that > > Los Alamos article and interpolate that all systems are run just > > like it. Reality is otherwise. There are a lot of badly managed > > Windows systems. they are badly managed because the users don't care. > > If the same sloppiness were applied to VMS is would be just as vulnerable. > > This has been pointed out repeatedly. there are Windows boxes out > > there with no password on the administrator account and with the user > > running everything from the administrator account to boot. The sheer > > number of Windows boxes and the fact that so many of them are in the > > hands of and totally under the control of users guarantees this. It > > doesn't make Windows any less secure than someone not locking the door > > of their house makes Yale locks insecure. > > Sorry to have snipped so much of such an excellent response, but given > that the original is still there it seemed appropriate. > > Kerry is, of course, a dyed-in-the-wool corporate shill, and has amply > demonstrated that he'll continue to trot out the same half-truths and > out-right falsehoods that he's been touting for the near-decade that > I've been acquainted with his posts regardless of how many times he's > corrected. So it's good to have a real-world customer with considerable > applicable experience around who's willing to take him to task for it. > > A lot of people base their beliefs about Windows on experiences with the > old consumer (non-NT/2K/XP-based) versions, or on newer systems managed > the same way the old ones were (e.g., without appropriate account > restrictions and with uncontrolled execution of random third-party > software or unsecured Microsoft applications). And since a lot of newer > systems *are* still 'managed' that way, the horror stories continue > unabated despite the fact that modern Windows *can* be very secure (and > reliable, and available) indeed (as, of course, can other options such > as Unix). > > True, NT and its descendants weren't crafted with the same care that VMS > was. OTOH, they've had several orders of magnitude more exposure than > VMS ever did, and have now had well over a decade to have had the > significant bugs flushed out, so the gap is nowhere nearly as large as > it started out being. > > Digital Had It Then. Unfortunately, today just about everyone else does > as well, for most practical purposes: that's what happens when you > stand relatively still while the rest of the world doesn't. > > - bill- Hide quoted text - > > - Show quoted text - again a visit to the CERT site will make your statement look idiotic ... ------------------------------ Date: Thu, 28 Jun 2007 18:07:46 -0700 From: Jeff Cameron Subject: Question on FCS vs RMS on PDP11 RSX Message-ID: I would like some clarification on FCS (File Control Services) and RMS (Record Management System) in RSX 11M+ for the PDP-11. I have been told by one of the original MACRO-11 developers for our PDP-11 system that our file system on the RSX systems only supports FCS files and not RMS files. While I fully understand that support for RMS files is a Sysgen option, I don't believe that the files are either in FCS format or RMS format. I had always thought that FCS was a set of basic file control services for manipulating, reading and writing files in RSX, and NOT a file format. Further more, I was under the impression that RMS record management was layered on top of FCS. Our old Macro developer was quite vehement that the format of the two types of files are very different, specifically the file headers. This seemed very wrong to me since the format of file headers are a Files-11 volume attribute. Now this macro developer is an older man who is not to familiar with newer technologies, who often replies with "It is not true just because you want it to be true." for things I already know to be true. For example we had quite an argument concerning file headers on a Files-11 disk (even ODS1 for RSX); It was my position that the actual header information was stored in the volume index file, while he insisted that it was actually a reserved block at the beginning of the physical file. So, if any of you have any information concerning the FCS/RMS issue, if you could site some resource, it would be extremely valuable. The point of contention is that I am considering using the Process Software TCP Stack, TCPWare. The TCPWare SPD says it supports RMS files, but says nothing about FCS, and our developer says it will not work because our files are all FCS format. I need irrefutable evidence that it will work, since he is the roadblock to my proceeding with this plan. Jeff Cameron ------------------------------ Date: Thu, 28 Jun 2007 21:37:35 -0500 From: "Lee K. Gleason" Subject: Re: Question on FCS vs RMS on PDP11 RSX Message-ID: <46846fdf$0$3177$4c368faf@roadrunner.com> "Jeff Cameron" wrote in message news:C2A9A972.29221%roktsci@ca.rr.com... > I would like some clarification on FCS (File Control Services) and RMS > (Record Management System) in RSX 11M+ for the PDP-11. > > I have been told by one of the original MACRO-11 developers for our PDP-11 > system that our file system on the RSX systems only supports FCS files and > not RMS files. While I fully understand that support for RMS files is a > Sysgen option, I don't believe that the files are either in FCS format or > RMS format. I had always thought that FCS was a set of basic file control > services for manipulating, reading and writing files in RSX, and NOT a file > format. Further more, I was under the impression that RMS record management > was layered on top of FCS. > > Our old Macro developer was quite vehement that the format of the two types > of files are very different, specifically the file headers. This seemed very > wrong to me since the format of file headers are a Files-11 volume > attribute. > > Now this macro developer is an older man who is not to familiar with newer > technologies, who often replies with "It is not true just because you want > it to be true." for things I already know to be true. For example we had > quite an argument concerning file headers on a Files-11 disk (even ODS1 for > RSX); It was my position that the actual header information was stored in > the volume index file, while he insisted that it was actually a reserved > block at the beginning of the physical file. > > So, if any of you have any information concerning the FCS/RMS issue, if you > could site some resource, it would be extremely valuable. > > The point of contention is that I am considering using the Process Software > TCP Stack, TCPWare. The TCPWare SPD says it supports RMS files, but says > nothing about FCS, and our developer says it will not work because our files > are all FCS format. I need irrefutable evidence that it will work, since he > is the roadblock to my proceeding with this plan. > > Jeff Cameron > The format of FCS and RMS sequential files, very compatible. FCS can open, read and write an RMS sequential file just fine, and vice versa. RMS Indexed and Relative files, not so compatible with FCS routines - I don't know if it's still true, but there was a time when simply opening and closing an RMS indexed file with FCS routines was enough to corrupt it beyond use. Even if opening and closing doesn;'t destroy them anymore, you certainly won't be reading and writing them with any useful results from FCs code. But, you're going the other way, FCS files manipulated by RMS code. RMS is not layered on top of FCS - both of them do their own QIOs to read and write blocks. However, I'm thinking, in regards to your question, that the Process Sotware stack, since it uses RMS, should be able to handle FCS created files just fine. What exactly are you contemplating doing to these files? Just copying them? Reading and writing records/blocks? Access via NFS? Given a little more detail, we might be able to come closer to a definitive answer. -- Lee K. Gleason N5ZMR Control-G Consultants lgleason@houston.rr.com ------------------------------ Date: Fri, 29 Jun 2007 04:04:04 -0000 From: Hein RMS van den Heuvel Subject: Re: Question on FCS vs RMS on PDP11 RSX Message-ID: <1183089844.087763.227460@w5g2000hsg.googlegroups.com> On Jun 28, 10:37 pm, "Lee K. Gleason" wrote: > "Jeff Cameron" wrote in message > > news:C2A9A972.29221%roktsci@ca.rr.com... >> I don't believe that the files are either in FCS format or > > RMS format. I had always thought that FCS was a set of basic file control > > services for manipulating, reading and writing files in RSX, and NOT a > file format. Right. > Further more, I was under the impression that RMS record > management was layered on top of FCS. Wrong. RMS did it's own QIO access. > > > Jeff Cameron > > The format of FCS and RMS sequential files, very compatible. FCS can open, > read and write an RMS sequential file just fine, and vice versa. That's how I remember it. FCS might not have had all stream formats And I seem to recall fcs did have for 'segmented record' files (for fortran) with and first, continuation, last flag construct. But I may well have this wrong The SPD suggest a nice level of compatibility: http://ftp.digital.com/pub/Digital/info/.2/SPD/14-35-33.txt FCS did not do Relative nor Indexd files of course. Just sequential so it had a small memory footprint. And in late version FCS did this cute name.ext/lib=modulename special fiel name syntax allowing one to keep files as modules in libraries. > However, I'm thinking, in regards to your question, that the Process > Sotware stack, since it uses RMS, should be able to handle FCS created files > just fine. Agreed. Cheers, Hein. ------------------------------ Date: Thu, 28 Jun 2007 23:33:10 -0500 From: "Headley Sappleton" Subject: Search Largest Database of DEC VAX PDP Manuals Message-ID: www.vaxennet.com Search Largest Database of DEC VAX PDP Manuals. In searchable Acrobat pdf format. New manuals will be added periodically. Good for educational purpose, for collectors and even Ebay sellers -- 6/28/2007 11:22:50 PM !****************************************! ! WWW.familyradio.com ! ! The Sound of the New life ! ! 4 year(s)s 3 months 22 days until ! ! Judgement Day ! !****************************************! ! Oxymoron: Rap Music. ! !****************************************! ------------------------------ Date: Thu, 28 Jun 2007 19:29:35 -0500 From: David J Dachtera Subject: Re: Supercomputer rankings Message-ID: <4684526F.6F70A42@spam.comcast.net> JF Mezei wrote: > [snip] > The 28 out of 500 systems based on that IA64 thing represent 0.056% of > the total. Oops! Slipped a decimal point there, JF! 28/500 is indeed 0.056, but that's 5.6%. > Not quite "maintream" , "commodity" or "industry standard" > that HP would like us to believe. No argument there, certainly. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Fri, 29 Jun 2007 00:48:09 -0400 From: "Ray" Subject: Re: Tech support Message-ID: > But how do you retain employees for 10 years on support jobs ? > BY PAYING THEM ENOUGH MONEY TO KEEP THEM. That that defeats the whole > purpose of outsourcing to low wage countries. A person in India with 2 or more years on the same job is unheard of. They gain a little experience, and move to the next job because they can get more pay. How can you fault them if HP is apparently not willing to pay for experience? Companies are just beginning to understand that one embarrassing question to ask their potential outsourcer is their employee turnover rate. (And then put in penalty clauses.) ------------------------------ Date: Thu, 28 Jun 2007 19:26:06 -0500 From: David J Dachtera Subject: Re: Vms Message-ID: <4684519E.6D877E8A@spam.comcast.net> Brandon wrote: > > Check it out: www.BrandonsMansion.com No mention of VMS there. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ End of INFO-VAX 2007.351 ************************