INFO-VAX Wed, 19 Jan 2005 Volume 2005 : Issue 38 Contents: An Interview With Mr. OpenVMS Himself AS 1000 boot failure (battery?) Re: carly(tm) transcipt Re: carly(tm) transcipt GnuPG in batch Re: Marcello predicts 500% perfomance improvement Re: Marcello predicts 500% perfomance improvement Minimerge on HSG80 in V8.2? Re: Minimerge on HSG80 in V8.2? New Command Language (CL) for OpenVMS? Re: New Command Language (CL) for OpenVMS? Re: New Command Language (CL) for OpenVMS? Re: New Command Language (CL) for OpenVMS? Re: New Command Language (CL) for OpenVMS? Re: New Command Language (CL) for OpenVMS? Re: Next Gen Fabs & Itanium Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: Webcast and VMS ---------------------------------------------------------------------- Date: Wed, 19 Jan 2005 17:47:30 GMT From: "Kenneth Farmer" Subject: An Interview With Mr. OpenVMS Himself Message-ID: ShannonKnowsHPC.com: http://www.shannonknowshpc.com/stories.php?story=05/01/18/0435366 Ken OpenVMS.org _____________________________________ Kenneth R. Farmer <>< SpyderByte: http://www.SpyderByte.com ------------------------------ Date: Wed, 19 Jan 2005 17:08:01 GMT From: "Ransom Fitch" Subject: AS 1000 boot failure (battery?) Message-ID: When I attempt a cold boot on a AS 1000 it fails with: EISA Data in non-volatile storage is corrupt EISA Configuration Error..... After running ECU I can boot normally (requires setting date and time). Reboots (warm boots) work fine. I suspect that this is due to a dead battery, and if so may have been caused by a KVM switch. The only thing that I find that looks like a battery is ~0.5(w) x 0.375(h) x 2.0(l) inches that's marked "lithium battery...." on the main board(?). Any suggestions on: 1) determining if battery is dead 2) finding a replacement (if needed) 3) installing a replacement (if needed). I believe that this is (multi-)pin socket but may require some tool(s) for extraction. If the problem is not the battery then what? thanks, Ransom Fitch rlf_vms at earthlink dot net ------------------------------ Date: 19 Jan 2005 06:30:46 -0800 From: "AEF" Subject: Re: carly(tm) transcipt Message-ID: <1106145046.812812.194540@z14g2000cwz.googlegroups.com> JF Mezei wrote: > Dave Froble wrote: > > > Are you for real? > > > > > > > > > > Don't go there. It's a bit like, "Be careful what you ask for, you just might > > get it." > > Oh come on guys. There have been a constant flow of comments about > Carly's presentation, hairdo, private jets etc etc. Why make such a big > fuss about yet another comment about her image ? Hmmm. I thought we were above that in c.o.v. Do you make equally inane comments in the other groups, thereby attracting undesirables? ------------------------------ Date: Wed, 19 Jan 2005 17:34:25 GMT From: "FredK" Subject: Re: carly(tm) transcipt Message-ID: > > JF Mezei wrote: > > Dave Froble wrote: > > > > Are you for real? > > > > > > > > > > > > > > Don't go there. It's a bit like, "Be careful what you ask for, you > just might > > > get it." > > > > Oh come on guys. There have been a constant flow of comments about > > Carly's presentation, hairdo, private jets etc etc. Why make such a > big > > fuss about yet another comment about her image ? > You really don't get it. I imagine that you thought you were being funny or witty. What you come off as is a sexist fool. If anyone *was* inclined to take you seriously, it simply lessens that possibility (or reduces the number). ------------------------------ Date: Wed, 19 Jan 2005 14:44:31 +0000 From: David Gray Subject: GnuPG in batch Message-ID: Hi all, OpenVMS 7.3-2 GnuPG v1.2.3 Has anyone got an example of how to use the PASSPHRASE-FD command of GnuPG when running in batch? I've searched the net but cannot find any examples of it's use under VMS. I'm currently writing the GPG command into a temporay command file with the passphrase on the second line but wondered if the PASSPHRASE-FD would provide a 'neater' solution. Thanks in advance Dave. ------------------------------ Date: Wed, 19 Jan 2005 17:53:48 GMT From: "FredK" Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: "Dave Froble" wrote in message news:41EDD481.60201@tsoft-inc.com... > John Smith wrote: > Hey, now is now. The itanic is all we got. If it's working well enough, fine > by me. Yes, I think EPIC is rather a stupid thing to do. So what. If it runs > my programs, I'm a whole bunch happier than having no options. > > My big concern is whether the itanic will survive. If Alpha couldn't survive in > the low volume world, why would any other CPU? The volume is better, even if it isn't the size of the x86 business. HP-UX is a bigger business than Tru64 was. The UNIX world is shrinking to the point of only having 2-3 serious vendors HP, IBM and SUN. Of those three, SUN is the one who has not been able to at least squeek out break even. POWER and Itanium will be the only 2 surviving RISC architectures. So the only question remains is if Windows and Linux squeeze out higher end UNIX on RISC platforms from the bottom (IA32) up (x86-64). I haven't seen "mission critical" Linux or Windows yet, but it doesn't mean that it will never happen. In any case, it isn't here yet. We've (VMS) invested 3-1/2 years of time and money in Itanium, and for the forseable future, I don't see large scale AMD 64 systems with mission critical Windows and Linux. The latest public move with Itanium removes any stigma of having HP (a system competetor) from controlling IA64, or having an unfair inside advantage. If we or Intel thought that Itanium was going away, it's likely that any move would have been the other direction. Just because there are dissapointed people out there mad about the demise of Alpha, does not mean that Itanium cannot succeed as one of the 2 premier high-end, mission critical, UNIX (and VMS) platforms. Will x86 be able to be grown "up" into this role? Time will tell. With enough thrust, a pig will fly. ------------------------------ Date: Wed, 19 Jan 2005 13:12:53 -0500 From: "John Smith" Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: FredK wrote: > "Dave Froble" wrote in message > news:41EDD481.60201@tsoft-inc.com... >> John Smith wrote: > >> Hey, now is now. The itanic is all we got. If it's working well >> enough, fine by me. Yes, I think EPIC is rather a stupid thing to >> do. So what. If it runs my programs, I'm a whole bunch happier >> than having no options. >> >> My big concern is whether the itanic will survive. If Alpha >> couldn't survive in the low volume world, why would any other CPU? > > The volume is better, even if it isn't the size of the x86 business. > HP-UX is a bigger business than Tru64 was. The UNIX world is > shrinking to the point of only having 2-3 serious vendors HP, IBM and > SUN. Of those three, SUN is the one who has not been able to at > least squeek out break even. POWER and Itanium will be the only 2 > surviving RISC architectures. > > So the only question remains is if Windows and Linux squeeze out > higher end UNIX on RISC platforms from the bottom (IA32) up (x86-64). > > I haven't seen "mission critical" Linux or Windows yet, but it > doesn't mean that it will never happen. In any case, it isn't here > yet. That does not stop people/corporations from believeing that it is there, or nearly so. And that comes back to the issue of perception vs. reality, or perhaps more properly put in this context - the Linux/Windows perception of reality vs. the VMS perception of reality. If you want VMS to grow again people have to be persuaded that the VMS perception of reality is the 'truth'. > We've (VMS) invested 3-1/2 years of time and money in Itanium, and > for the forseable future, I don't see large scale AMD 64 systems with > mission > critical Windows and Linux. The latest public move with Itanium > removes any stigma of having HP (a system competetor) from > controlling IA64, > or having an unfair inside advantage. If we or Intel thought that > Itanium was going away, it's likely that any move would have been the > other direction. > > Just because there are dissapointed people out there mad about the > demise of Alpha, does not mean that Itanium cannot succeed as one > of the 2 premier high-end, mission critical, UNIX (and VMS) platforms. > Will x86 be able to be grown "up" into this role? Time will tell. Hopefully enough companies will buy into the Intel/HP bet on Itanic. And hopefully HP will see the light enough to advertise and market VMS effectively. At this stage of the game I'd like to devote my spare time to recreational pursuits vs. learning how to change my earn-my-living paradigm to Windows. > With enough thrust, a pig will fly. F-4 Phantom II - the flying brick. ------------------------------ Date: Wed, 19 Jan 2005 14:08:02 GMT From: "Jeff Goodwin" Subject: Minimerge on HSG80 in V8.2? Message-ID: <6RtHd.151340$Uf.42792@twister.nyroc.rr.com> Whilst reading the V8.2 white paper, I noticed this in Chapter 10: Shadowing Minimerge for Fibre Channel (HSG80) Improving the performance of shadow-set merge operations, this shadowing feature is supported by OpenVMS V7.3-1 +TIMA kit, along with an ACS 8.7 W/R release from Storage (this is the firmware for the HSG80 controller). This feature allows the merging of only the physical disk changes, rather than a full merge. The changes are kept in the HSG80 memory cache via write history logging (WHL) done via the ACS 8.7 W/R code. The W/R variants are identical to the F/S variants that customers use today for switch and snapshot capabilities, except they add the WHL capability. Similar Minimerge functionality exists with the HSJ controller today for CI storage. It then went on to talk about HBMM. Wasn't the HSG80 Minimerge feature scrapped in favor of HBMM? The white paper also said this: OpenVMS Alpha V8.2 and OpenVMS VAX V7.3-2 are also a supported mixed-architecture cluster pair. Where do I get this new VAX version? :) -Jeff ------------------------------ Date: 19 Jan 2005 10:46:19 -0500 From: brooks@cuebid.zko.dec.nospam (Rob Brooks) Subject: Re: Minimerge on HSG80 in V8.2? Message-ID: "Jeff Goodwin" writes: > Whilst reading the V8.2 white paper, I noticed this in Chapter 10: > > Shadowing Minimerge for Fibre Channel (HSG80) > Improving the performance of shadow-set merge > operations, this shadowing feature is supported by > OpenVMS V7.3-1 +TIMA kit, along with an ACS 8.7 > W/R release from Storage (this is the firmware for the > HSG80 controller). [...] > It then went on to talk about HBMM. > > Wasn't the HSG80 Minimerge feature scrapped in favor of HBMM? Yes; the white paper needs to be updated. -- Rob Brooks VMS Engineering -- I/O Exec Group brooks!cuebid.zko.dec.com ------------------------------ Date: Wed, 19 Jan 2005 13:55:37 +0100 From: "Rudolf Wingert" Subject: New Command Language (CL) for OpenVMS? Message-ID: <000d01c4fe26$2c494c30$994614ac@wat153> Hello, I did hear about a new CL for OpenVMS (HPCL). Is that true? If yes, when will we see this one (8.2?)? What's happen with all our command procedure? Is there a compatibility mode? TIA and best regards R. Wingert ------------------------------ Date: Wed, 19 Jan 2005 13:17:06 +0000 From: Roy Omond Subject: Re: New Command Language (CL) for OpenVMS? Message-ID: <35752gF4gldg1U1@individual.net> Rudolf Wingert wrote: > Hello, > > I did hear about a new CL for OpenVMS (HPCL). Is that true? If yes, when > will we see this one (8.2?)? What's happen with all our command > procedure? Is there a compatibility mode? Es war ein Scherz ! ------------------------------ Date: 19 Jan 2005 14:02:31 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: New Command Language (CL) for OpenVMS? Message-ID: <3577jnF4h517hU3@individual.net> In article <0IntsTrIDtHq@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <000d01c4fe26$2c494c30$994614ac@wat153>, "Rudolf Wingert" writes: >> Hello, >> >> I did hear about a new CL for OpenVMS (HPCL). Is that true? If yes, when >> will we see this one (8.2?)? What's happen with all our command >> procedure? Is there a compatibility mode? > > Aaaaaarrrrrgh. Please file this next to the difference between VMS > and OpenVMS. Cut him some slack. After all, it was a joke and at least one english speaker here fell for it too, so having a non-english speaker fooled by the subtlety shouldn't be that much of a surprise. :-) 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: 19 Jan 2005 07:55:54 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: New Command Language (CL) for OpenVMS? Message-ID: <0IntsTrIDtHq@eisner.encompasserve.org> In article <000d01c4fe26$2c494c30$994614ac@wat153>, "Rudolf Wingert" writes: > Hello, > > I did hear about a new CL for OpenVMS (HPCL). Is that true? If yes, when > will we see this one (8.2?)? What's happen with all our command > procedure? Is there a compatibility mode? Aaaaaarrrrrgh. Please file this next to the difference between VMS and OpenVMS. ------------------------------ Date: 19 Jan 2005 10:31:02 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: New Command Language (CL) for OpenVMS? Message-ID: In article <000d01c4fe26$2c494c30$994614ac@wat153>, "Rudolf Wingert" writes: > Hello, > > I did hear about a new CL for OpenVMS (HPCL). Is that true? If yes, when > will we see this one (8.2?)? What's happen with all our command > procedure? Is there a compatibility mode? http://groups-beta.google.com/group/comp.os.vms/msg/5407514334cf160c ------------------------------ Date: Wed, 19 Jan 2005 16:42:28 GMT From: "Kenneth Farmer" Subject: Re: New Command Language (CL) for OpenVMS? Message-ID: "Larry Kilgallen" wrote in message news:zq73y755gTit@eisner.encompasserve.org... > In article <000d01c4fe26$2c494c30$994614ac@wat153>, "Rudolf Wingert" > writes: >> Hello, >> >> I did hear about a new CL for OpenVMS (HPCL). Is that true? If yes, when >> will we see this one (8.2?)? What's happen with all our command >> procedure? Is there a compatibility mode? > > http://groups-beta.google.com/group/comp.os.vms/msg/5407514334cf160c You just had to do that, didn't you. :) Ken OpenVMS.org _____________________________________ Kenneth R. Farmer <>< SpyderByte: http://www.SpyderByte.com ------------------------------ Date: Wed, 19 Jan 2005 06:17:39 -0800 From: "Tom Linden" Subject: Re: Next Gen Fabs & Itanium Message-ID: On Wed, 19 Jan 2005 04:10:35 GMT, Robert Deininger wrote: > In article <41ED4783.F705C654@teksavvy.com>, JF Mezei > wrote: > >> Robert Deininger wrote: >>> Alpha systems absolutely cost more to make than similar Integrity >>> systems. You'd lose your bet if the numbers were available to the >>> public. Since they're not, you're safe with your wild public >>> speculations. >> >> Why should an Alpha box cost more than an IA64 box ? >> Is the the power supply ? > > Almost always. > >> Is it the case ? > > Usually. > >> Is it the disk drives ? > > Probably not. > >> Is it the connectors ? > > Yes. > > >> Is it the type of memory ? > > Often. > > >> Are alpha servers built with gold solder instead of lead ? > > No. > >> >> If it is just the chip which is different, then I doubt that Alpha chips >> actualy cost more than IA64, especially if HP ordered one large batch of >> them made for a final production. > > Alpha CPUs do in fact cost a lot more than IA64. I don't know why. I > don't think either benefits greatly from economies of scale. > > But if you spend 5 minutes inside a recent alpha server and a similar > Integrity server, you will see that it's NOT just the CPU which is > different. > >> (Higher volum the smaller quaktities >> of IA64s being made in light of the fact that the chip is still evolving >> and you don't want to stockpile years worth of Merced supplies). >> >> If IA64 and Alpha servers are of same quality, I do not buy the argument >> that the Alpha has to be more expensive. Remember that many were done >> under Compaq which also had good "low cost manufacturing" expertise. > > > Alpha systems might not HAVE TO cost more, but they do. Low-cost designs > were simply not a strength of the Digital server design teams, and were > not a particular interest of the management food chain. Could they have > done better? Yes, but they rarely did in practice. Alpha servers are > (mostly) excellent designs, but low-cost was not high on the list of > goals. That might be one reason Digital didn't survive. > > They merger with Compaq did not affect the way Alpha systems were > designed > at all. The Digital teams pretty much continued as always, until they > were dispersed. The supply chain overlap between Alpha systems and the > Compaq PC business was pretty minor -- disk drives, CD-ROMs, sometimes > memory. Not a heck of a lot else. > > The Digital and Compaq manufacturing facilities weren't combined > particularly well either. Compaq may have had low cost manufacturing > expertise for PCs, but it never transfered to the server business. There > were some notable failures at trying to do so. > > The HP teams that design and build IA64 systems pay particular attention > to cost. There is increasing overlap in the supply chains for PCs and > servers. There are fewer minor variations in parts, meaning fewer types > of spares to buy and stock. HP is just better at low-cost servers than > Digital was, and the prices for customers reflect this. Folks might > enjoy > bashing HP, but they deserve credit for doing a pretty good job in this > area. Alphas suffered from lack of standardization, which is a failing of central management. With how many Alphas, for example, can you interchange memory? QED. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 01:51:24 -0500 From: JF Mezei Subject: Re: vms versus solaris Message-ID: <41EE035F.308ABC31@teksavvy.com> re: RMS bundled into VMS. Perhaps the right approach would be to follow Quicktime. It used to be included with all MACs. Then Apple realised that to make quicktime relevant, it had to be available for free to other platforms as well. Consider that the vast number of applications that make use of a database engine could run very easily on simple indexed files, but theyt go through the more complex DB engine because that is all they have available. If RMS were available for free on Linux, it would give RMS a much greater profile and allow simple apps to start making use of RMS. ------------------------------ Date: 19 Jan 2005 07:03:26 GMT From: "Dave Weatherall" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 03:05:11 UTC, Dave Froble wrote: > Bill Gunshannon wrote: > > > > I am sure (and I certainly hope) that other readers hear realize there > > is no animosity between me and Dave or Bob or anyone else here. I don't > > know about them, but I enjoy the lively debates and I even learn stuff > > from them. (I'm still waiting for someone to explain to me the difference > > between Symbols and Logicals as I really thought they were pretty much > > the same except for the method of defining them.) > > > I wish someone else would do this. Oh well... > > Symbols exist within a process. They can be global to the process, or can be > local to a DCL procedure. Symbols have a value, and can be evaluated, set and > re-set by DCL and library routines. > > Logicals are entries in various tables, process, group, system, cluster, and at > various levels in some of the catagories. A "logical name" can also be used to > represent another logical name. It can represent multiple values, as when used > to represent multiple disk/directory locations. Logical names are evaluated by > the filespec parser. > > And now you probably know less than before. It's a bit tough for me, I use > logical names, but have never gave much thought to a formal definition of what > they are. I'm sure someone else could give a better 'design view' of what > logical names are. Picking up on Bob's scope comments, one further advantage of a logical over a symbol is that it allows information to be stored in a logical name table that can be seen by chosen users or groups of user's. It does require some manipulation of the LNM table scanning control (itself a logical name), but it does provide a method of setting up project-wide definitions without taking up excessive process/user memory, as happens when the definitions are made in the process table during login. Similarly, access to logical name tables can be controlled by ACL -- Cheers - Dave W. ------------------------------ Date: 19 Jan 2005 07:03:25 GMT From: "Dave Weatherall" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 06:17:52 UTC, Bill Todd wrote: > Given its splendid isolation from the rest of the industry, just like > many other useful aspects of VMS RMS simply doesn't constitute anything > like a decisive plus, save perhaps (if you consider this an advantage) > to the degree that it locks in VMS customers who can't easily migrate > applications which depend on it elsewhere. Just one more example of > where Digital Had It Then but failed to turn it into the lasting > leverage of a true (sanctioned or de facto) industry standard. Bill am I parsing this right when I take 'decisive plus' in the context of 'bringing new customers to the VMS platform'. As a record-oriented user/programmer, it _is_ a decisive plus but then, perhaps, I fall into the 'locked in' category (mentally or philosophically). -- Cheers - Dave W. ------------------------------ Date: 19 Jan 2005 07:03:23 GMT From: "Dave Weatherall" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 04:02:56 UTC, JF Mezei wrote: > Dave Froble wrote: > > The default on VMS it to grant TMPMBX and NETMBX to a user. I'm a bit fuzzy > > about DECnet at this time, so I'm not sure, but I think this gives non-priv > > users capability to send and receive DECnet messages. > > You need privs (I believe SYSNAM) to create a decnet object anyone can > connect to without any authentication. (or have read/write access to the > NCP database to define the object there). Correct,. I was going to pick up on the discussion about what priveleges one needs to set up a TCP/IP socket service but then I remembered that my only actual experience is with my application that receives DecNet comms from a VMS client but uses TCP/IP to pass simulation data to/from a host simulation running under Solaris. Because I need SYSNAM for the DecNet service I don't know, for sure, whether the TCP/IP runs without it. My colleague who developed the TCP/IP interface also has SYSNAM, for the DecNet circuit, so I couldn't extrapolate from his experience either. -- Cheers - Dave W. ------------------------------ Date: Wed, 19 Jan 2005 10:09:57 +0000 From: John Laird Subject: Re: vms versus solaris Message-ID: <04csu0tvu0gelnuddt47v1msnter98jqk8@4ax.com> On Tue, 18 Jan 2005 23:16:19 -0500, JF Mezei wrote: >Dave Froble wrote: >> Symbols exist within a process. They can be global to the process, or can be >> local to a DCL procedure. Symbols have a value, and can be evaluated, set and >> re-set by DCL and library routines. > > >Would it be more precise to state that symbols exist at the CLI/DCL >level, whereas logicals exist in various tables, including a process and >job tables ? > >Is it correct to state that RUN/DETACHED image.exe will not give >image.exe access to any symbols for reading and writing ? Yes and yes. I think it used to be the case that images couldn't even access symbols wihout dipping into process structures - I'm sure I remember LIB$GET[SET]_SYMBOL arriving. By and large, symbols are for DCL. Logical names are for whatever you wish to use them for - storing state information, controlling images, reporting results, and of course they have always had special meaning in file-parsing, their original purpose (fair to say ?). -- Try to look unimportant; the bad guys may be low on ammo. Mail john rather than nospam... ------------------------------ Date: Wed, 19 Jan 2005 05:52:57 -0500 From: Bill Todd Subject: Re: vms versus solaris Message-ID: <0LudneELkKGboXPcRVn-iw@metrocastcablevision.com> Dave Weatherall wrote: ... As a > record-oriented user/programmer, it _is_ a decisive plus but then, > perhaps, I fall into the 'locked in' category (mentally or > philosophically). The point is that as a record-oriented user/programmer, you'd also have access to the kinds of packages I mentioned on Unix (or - blech - even to some extent on Windows) - in fact, to a considerably larger collection of options in this area than is available to you on VMS, many of them free or very low cost but still very functional and stable and quite a few of them also somewhat more technically current than RMS is (e.g., in their integral use of journaling to improve both performance and reliability). The fact that RMS is bundled and supported as part of the OS may be convenient and reassuring, but is hardly of *major* significance to most users (or applications, though not having a third-party dependency in this area is part of the convenience). - bill ------------------------------ Date: 19 Jan 2005 13:23:22 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: vms versus solaris Message-ID: <3575aaF4g3o73U1@individual.net> In article <41EDCE67.50107@tsoft-inc.com>, Dave Froble writes: > Bill Gunshannon wrote: > > >> I am sure (and I certainly hope) that other readers hear realize there >> is no animosity between me and Dave or Bob or anyone else here. I don't >> know about them, but I enjoy the lively debates and I even learn stuff >> from them. (I'm still waiting for someone to explain to me the difference >> between Symbols and Logicals as I really thought they were pretty much >> the same except for the method of defining them.) > > > I wish someone else would do this. Oh well... > > Symbols exist within a process. They can be global to the process, or can be > local to a DCL procedure. Symbols have a value, and can be evaluated, set and > re-set by DCL and library routines. > > Logicals are entries in various tables, process, group, system, cluster, and at > various levels in some of the catagories. A "logical name" can also be used to > represent another logical name. It can represent multiple values, as when used > to represent multiple disk/directory locations. Logical names are evaluated by > the filespec parser. > > And now you probably know less than before. It's a bit tough for me, I use > logical names, but have never gave much thought to a formal definition of what > they are. I'm sure someone else could give a better 'design view' of what > logical names are. > No, actually that was a good explanation. I can now say that Unix has the equivalent in it's system variables but that VMS appears to have a bit more flexibility. All unix scoping is downward. I can not change the value of a variable defined in a process above me except for how it will appear to processes below me. Any variable I create is only valid for processes below me and goes away when my process ends. Assuming a Logical can be changed system wide (that is also assuming adequate priveledge) that would be a good feature that unix lacks. Interestingly enough, I don't think it would be that hard to implement. Hmmmm..... Maybe it is but I just never needed to do it so I never learned how. Worth more investigation. Thanks for the explanation. I told you I actually learn stuff from these debates. And they tend to kick the brain into gear. 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: 19 Jan 2005 13:38:31 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: vms versus solaris Message-ID: <35766mF4h517hU1@individual.net> In article , Bob Harris writes: > In article <41EDCE67.50107@tsoft-inc.com>, > Dave Froble wrote: > >> Bill Gunshannon wrote: >> >> >> > I am sure (and I certainly hope) that other readers hear realize there >> > is no animosity between me and Dave or Bob or anyone else here. I don't >> > know about them, but I enjoy the lively debates and I even learn stuff >> > from them. (I'm still waiting for someone to explain to me the difference >> > between Symbols and Logicals as I really thought they were pretty much >> > the same except for the method of defining them.) >> >> >> I wish someone else would do this. Oh well... >> >> Symbols exist within a process. They can be global to the process, or can be >> local to a DCL procedure. Symbols have a value, and can be evaluated, set >> and >> re-set by DCL and library routines. >> >> Logicals are entries in various tables, process, group, system, cluster, and >> at >> various levels in some of the catagories. A "logical name" can also be used >> to >> represent another logical name. It can represent multiple values, as when >> used >> to represent multiple disk/directory locations. Logical names are evaluated >> by >> the filespec parser. >> >> And now you probably know less than before. It's a bit tough for me, I use >> logical names, but have never gave much thought to a formal definition of >> what >> they are. I'm sure someone else could give a better 'design view' of what >> logical names are. >> >> Dave > > More on symbols. Local symbols have what I like to call "Umbrella > Scope" that is to say, a sub procedure can look up and see local > variables created in a parent procedure, unless the subprocedure creates > a local symbol with the same name. > > UNIX script variables do not have this characteristic. And while script > variables can local or global (depending on which shell is being run) > they are not the same kind of global as a VMS Global Symbol. That is to > say they are only visible to scripts running in the current process > which and not to any subprocess or program that might be run. Not true. Depending on shell variables are either exported automatically or can be using the "export" command. For every modern shell I am aware of, it is automatic. If this were not true, there would be no way for the system to pass to all users things like PATH, TERMCAP, etc. > > A shell symbol that needs to be visible to a child process and/or > program invoked from a script can be made an environment variable. > Environment variables are passed down (inherited) by child processes. I should have read on. But the above still stands. There really is only one type of variable. > BUT, unlike a Global Symbol, changes to the environment variable by a > child process are _NOT_ visible to the parent. Changes are only visible > to the child process that changes the environment variable or to any > child processes that it creates. This is because environment variables > are copied from the parent onto the stack of the child process, and the > parent does not have access to that address space, and when the child > terminates, the child's stack is deleted. So any return information has > to use a different means (and we have all kinds of tricks, the most > common of which is to have the parent read what we write to standard > out). This is true, but the trick you mention is only usable if the parent is expecting the child to change something. This still limits the scope to something much less than VMS. > > And another point about logicals is that there does not need to be a > parent child relationship for some classes of logicals to be seen (or > there can if you use the right class). And logicals can be used to pass > information from the child back to the parent, if that is desired. That's a plus. > > And Global Symbols can also be used to return information to the parent > when running a program that does not spawn a subprocess, because a > program is run in the same process space as DCL, just a different mode. Don't understand this one. > > Passing information from child to parent or to non-related processes can > not be down via variables or environment variables. Child to parent is > frequently done by the parent establishing a pipe between the child's > standard out and reading that to capture any information to be passed > back. Non-parent/child information passing could use the file system, > as in either the name of a file, the contents of a symbolic link (which > does not need to be a file spec, but rather can be almost anything), or > the content of a file, or a named pipe, a message queue for interprocess > message passing, or shared memory. > > I would say the closest thing to a logical name would be a symbolic > link. A symbolic link is merely a different logical name for a file or directory. Other than that, it passes no information and being as it can point at a non-existant filename sometimes it doesn't pass any information. > I'm not saying it does everything a logical does, just that it > can be used to pass information around, as well as be used to hold file > spec information. And a symbolic link is accessible anywhere the file > system can be seen, such as Tru64 TruCluster or even NFS server/client > mounted disk. Although not too many applications actually use symbolic > links to pass information. I just tried it for grins. I have never seen a symbolic link used for this, but I can see how it wold work. I also don't think the original designers eevr had this idea in mind. :-) > File and shared memory are much more common > for unrelated processes. True. > > And just to put my credentials on the table: > > o 12 years OpenVMS as System Admin, Applications programmer, and > PATHWORKS for Mac file server developer (with a smidge of kernel code > for intrusion detection). > > o 12 years UNIX as System Admin, Applications programmer, and Tru64 > UNIX AdvFS file system developer working inside the kernel. > > I have _ALWAYS_ had SYSTEM or ROOT access (and the scars to prove it :-) > > And for the most part I tend to agree with most of the stuff that Bill > Gunshannon has been try to say. OpenVMS has its strengths, and UNIX has > it strengths. If you know one and not the other, you are going to tend > to favor the one you know. > > And since this is comp.os.vms, I say, buy more OpenVMS systems and keep > the ZKO3-4 fully populated :-) > > Bob Harris 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: 19 Jan 2005 07:44:03 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: vms versus solaris Message-ID: In article , "Neil Rieck" writes: > It would be nice if someone in this newsgroup with > experience on both UNIX and OpenVMS would set the record straight. The records, they are a changin'. ------------------------------ Date: 19 Jan 2005 13:46:32 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: vms versus solaris Message-ID: <3576loF4h517hU2@individual.net> In article <0rF4L0yqRgL6@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article , "Tom Linden" writes: > >>> As some people have already mentioned to me by email, modern flavors of >>> UNIX >>> do implement quota-based resource management. (most of my UNIX experience >>> came from BSD 4.4 on PDP-11/44 back in the mid 1980's and lots of stuff >>> has >>> changed since then). It would be nice if someone in this newsgroup with >>> experience on both UNIX and OpenVMS would set the record straight. >> >> >> >> ulimit(1) >> ulimit(1) >> >> NAME >> >> ulimit - Sets or reports a resource limit > > I did not see anything in that description specifying the name of the > user affected. A user can only change his own limimits so there is no need for the ability to specify a user. > > Does this mean that all users on the system have the same quotas ? No, the initial values are set at login based on a class. The values are defined in /etc/login.conf. 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: 19 Jan 2005 07:41:48 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: vms versus solaris Message-ID: In article <355cdiF4ik1fqU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> I've actually had one >> (1), count them : ONE programmer who set up cd, pwd, ... for his VMS >> account. >> >> All true VMS users know that sd is the symbol for some command file >> that does nice things with set default. > > What happened to the idea of making the machine work for the users > rather than making the users work for the machine? I don't believe foisting my ideas on users is a way to make it work for anyone but me. >> My admin friend down the hall recognizes "admin account". Some OS >> are even more prevalent than UNIX. > > Name one! Guess quickly: he does a lot of Microsoft type stuff. > > I am sure (and I certainly hope) that other readers hear realize there > is no animosity between me and Dave or Bob or anyone else here. I don't > know about them, but I enjoy the lively debates and I even learn stuff > from them. (I'm still waiting for someone to explain to me the difference > between Symbols and Logicals as I really thought they were pretty much > the same except for the method of defining them.) I have a fellow who refers to them as "logical symbols". I tell new users these are the most important: 1 they are both memory resident strings which stand for other strings 2 symbols are per-process, but usually inherited by spawned processes 3 symbols are global to all procs in a process or local to one proc 4 logicals are per-process, job-wide, group-wide, system-wide, or cluster-wide 5 logicals are global to all procs 6 DCL will use symbols like UNIX aliases, but not logicals 7 the file system will automatically use logicals, but not symbols I don't bother new users with inner vs. outer mode, concealed, and all those other attributes logicals can have. ------------------------------ Date: 19 Jan 2005 07:45:49 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: vms versus solaris Message-ID: <84S2hUkSEi9G@eisner.encompasserve.org> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <3555ujF4j0dtaU3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> >> No, it's not. ISAM and DBMS are both available on unix. It's just not >> the default. And before you you bring up the additional cost of buying >> an additional commercial package. What is the difference between VMS >> and pretty much any unix, pricewise? Basicly, VMS provides it, wether >> you need it or not and makes you pay for it, wether you need it or not. > > In the real world, that's like selling soup without the bowl. Oops, I meant milkshakes without the cup. ------------------------------ Date: Wed, 19 Jan 2005 06:25:24 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Tue, 18 Jan 2005 23:16:19 -0500, JF Mezei wrote: > Dave Froble wrote: >> Symbols exist within a process. They can be global to the process, or >> can be >> local to a DCL procedure. Symbols have a value, and can be evaluated, >> set and >> re-set by DCL and library routines. > > > Would it be more precise to state that symbols exist at the CLI/DCL > level, whereas logicals exist in various tables, including a process and > job tables ? > > Is it correct to state that RUN/DETACHED image.exe will not give > image.exe access to any symbols for reading and writing ? What about lib$[s,g]et_symbol? -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 06:28:11 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On 18 Jan 2005 22:46:49 -0600, Larry Kilgallen wrote: > In article , "Tom Linden" > writes: > >>> As some people have already mentioned to me by email, modern flavors of >>> UNIX >>> do implement quota-based resource management. (most of my UNIX >>> experience >>> came from BSD 4.4 on PDP-11/44 back in the mid 1980's and lots of stuff >>> has >>> changed since then). It would be nice if someone in this newsgroup with >>> experience on both UNIX and OpenVMS would set the record straight. >> >> >> >> ulimit(1) >> ulimit(1) >> >> NAME >> >> ulimit - Sets or reports a resource limit > > I did not see anything in that description specifying the name of the > user affected. > > Does this mean that all users on the system have the same quotas ? It has been a while, but I believe it is per user, as determine at login. Of course that was Tru64, don't know what Linux does. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 06:31:42 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 01:17:52 -0500, Bill Todd wrote: > Larry Kilgallen wrote: >> In article <355hpdF4g6skfU2@individual.net>, bill@cs.uofs.edu (Bill >> Gunshannon) writes: > > ... > >>> If you offer a commercial package that depends on another commercial >>> package you don't expect to find on the customers machine, you license >>> that package and provide it along with yours. >> That works if the product is the reason people are running the >> machine, >> but not for utility programs. Consider all the VMS Freeware that >> depends >> on RMS. > > And if RMS weren't there, either those utilities wouldn't depend upon it > or they would bundle in whatever they did depend on. > > Look, guys: I'm about as record-biased as one can get. While I believe > that RMS could (and should) be made much more approachable and possibly > more streamlined internally to avoid imposing overheads on those who > don't need them (the implicit system cost of bundling it in is a > separate, though similar, issue, but I firmly believe that if RMS-type > facilities were *standard* in the industry the industry would appreciate > them - and I tried to get DEC to take the lead in standardizing them > across Unix and Windows almost 20 years ago), when it comes to data > management I think byte streams represent the stone age. The ISAM packaged developed to support PL/I under Ultrix was spun off as a separately licensable package, but I don't think it ever sold very much outside of PL/I usage. > > But the incontrovertible fact is that most of the world doesn't see > things that way. They're quite happy with Unix- and (shudder) > Windows-level byte-stream file systems, plus add-on packages when they > need them such as dbm (free, I think), Postgres and IBPhoenix (nee > Interbase), both free and the latter with a relatively small footprint > and excellent reputation, Berkeley db and C-ISAM-like products (free or > at least low-cost), and Oracle (not free at all, but still popular). > > Given its splendid isolation from the rest of the industry, just like > many other useful aspects of VMS RMS simply doesn't constitute anything > like a decisive plus, save perhaps (if you consider this an advantage) > to the degree that it locks in VMS customers who can't easily migrate > applications which depend on it elsewhere. Just one more example of > where Digital Had It Then but failed to turn it into the lasting > leverage of a true (sanctioned or de facto) industry standard. > > - bill -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 06:34:06 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 05:52:57 -0500, Bill Todd wrote: > Dave Weatherall wrote: > > ... > > As a >> record-oriented user/programmer, it _is_ a decisive plus but then, >> perhaps, I fall into the 'locked in' category (mentally or >> philosophically). > > The point is that as a record-oriented user/programmer, you'd also have > access to the kinds of packages I mentioned on Unix (or - blech - even > to some extent on Windows) - in fact, to a considerably larger > collection of options in this area than is available to you on VMS, many > of them free or very low cost but still very functional and stable and > quite a few of them also somewhat more technically current than RMS is > (e.g., in their integral use of journaling to improve both performance > and reliability). An interesting aside, IBM has added record I/O support to C for Z-OS > > The fact that RMS is bundled and supported as part of the OS may be > convenient and reassuring, but is hardly of *major* significance to most > users (or applications, though not having a third-party dependency in > this area is part of the convenience). > > - bill -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 15:20:21 +0000 (UTC) From: m.kraemer@gsi.de (Michael Kraemer) Subject: Re: vms versus solaris Message-ID: In article , "Tom Linden" writes: > > The ISAM packaged developed to support PL/I under Ultrix was spun off as a ^^^^^^^^^^^^^^^^^^ Such a beast is still available ? ------------------------------ Date: Wed, 19 Jan 2005 10:56:59 -0500 From: "John Smith" Subject: Re: vms versus solaris Message-ID: Bill Todd wrote: > Larry Kilgallen wrote: >> In article <355hpdF4g6skfU2@individual.net>, bill@cs.uofs.edu (Bill >> Gunshannon) writes: > > ... > >>> If you offer a commercial package that depends on another commercial >>> package you don't expect to find on the customers machine, you >>> license that package and provide it along with yours. >> >> >> That works if the product is the reason people are running the >> machine, >> but not for utility programs. Consider all the VMS Freeware that >> depends >> on RMS. > > And if RMS weren't there, either those utilities wouldn't depend upon > it or they would bundle in whatever they did depend on. > > Look, guys: I'm about as record-biased as one can get. While I > believe that RMS could (and should) be made much more approachable > and possibly more streamlined internally to avoid imposing overheads > on those who don't need them (the implicit system cost of bundling it > in is a separate, though similar, issue, but I firmly believe that if > RMS-type facilities were *standard* in the industry the industry > would appreciate them - and I tried to get DEC to take the lead in > standardizing them across Unix and Windows almost 20 years ago), when > it comes to data management I think byte streams represent the stone > age. > > But the incontrovertible fact is that most of the world doesn't see > things that way. They're quite happy with Unix- and (shudder) > Windows-level byte-stream file systems, plus add-on packages when they > need them such as dbm (free, I think), Postgres and IBPhoenix (nee > Interbase), both free and the latter with a relatively small footprint > and excellent reputation, Berkeley db and C-ISAM-like products (free > or at least low-cost), and Oracle (not free at all, but still > popular). > > Given its splendid isolation from the rest of the industry, just like > many other useful aspects of VMS RMS simply doesn't constitute > anything like a decisive plus, save perhaps (if you consider this an > advantage) to the degree that it locks in VMS customers who can't > easily migrate applications which depend on it elsewhere. Just one > more example of where Digital Had It Then but failed to turn it into > the lasting leverage of a true (sanctioned or de facto) industry > standard. Interesting that you mention Interbase. Firebird, the renamed build of Interbase 6, still has the VMS conditionals in it - including use of the DLM. Jim Starkey (Datatrieve, Rdb, and Interbase) is still involved with Firebird. In speaking with Ann Harrison (IBPhoenix) today, her sense of resurrecting a VMS version of Interbase/Firebird is that it would not be very difficult. We last used Interbase/VMS at v4 (as an embedded db for one of our applications - a stock exchange 'ticker plant' for lack of a better term) and found it to be fast, extremely stable, easy to administer, and consumed very little system resource. We went to Interbase primarily as a result of the Rdb runtime being removed from the base VMS license years ago. I don't know how Firebird compares to current versions of MySQL , which would be what I'd otherwise consider for an 'open source' rdbms. ------------------------------ Date: Wed, 19 Jan 2005 07:55:10 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 15:24:46 +0000 (UTC), Michael Kraemer wrote: > In article , "Tom Linden" > writes: >> >> An interesting aside, IBM has added record I/O support to C for Z-OS > > that was available even way back in MVS of 1993 vintage, > from my sw attic: > > fopen( cFile, "rb,type=record,recfm=F,lrecl=4096,blksize=4096" ) > Shows you what I know. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: 19 Jan 2005 10:19:42 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: vms versus solaris Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > 4 logicals are per-process, job-wide, group-wide, system-wide, or > cluster-wide or in a custom table available to particular users (independent of UIC groups). ------------------------------ Date: 19 Jan 2005 10:17:06 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: vms versus solaris Message-ID: In article , "Dave Weatherall" writes: > am I parsing this right when I take 'decisive plus' in the > context of 'bringing new customers to the VMS platform'. As a > record-oriented user/programmer, it _is_ a decisive plus but then, > perhaps, I fall into the 'locked in' category (mentally or > philosophically). The languages Cobol, Pascal and Ada all have the notion of record-IO, and probably PL/I does also. So I would say you are locked in by programming paradigms that have been found to actually be needed in real applications. ------------------------------ Date: 19 Jan 2005 10:25:02 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: vms versus solaris Message-ID: <6LOwnuAnaCF1@eisner.encompasserve.org> In article <35766mF4h517hU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > Bob Harris writes: >> And Global Symbols can also be used to return information to the parent >> when running a program that does not spawn a subprocess, because a >> program is run in the same process space as DCL, just a different mode. > > Don't understand this one. Within a process, one command procedure or program can change the value of a global DCL symbol to be read by an invoking entity. For logical names those need not be in the same process - data can be passed back and forth between processes re-using the same logical names (of appropriate scope). ------------------------------ Date: 19 Jan 2005 10:26:31 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: vms versus solaris Message-ID: In article <3576loF4h517hU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article <0rF4L0yqRgL6@eisner.encompasserve.org>, > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> In article , "Tom Linden" writes: >>> ulimit(1) >>> ulimit(1) >>> >>> NAME >>> >>> ulimit - Sets or reports a resource limit >> >> I did not see anything in that description specifying the name of the >> user affected. > > A user can only change his own limimits so there is no need for > the ability to specify a user. > >> >> Does this mean that all users on the system have the same quotas ? > > No, the initial values are set at login based on a class. The values > are defined in /etc/login.conf. Does that mean a user can raise values with the ulimit command even though the system manager has set them to a particular limit ? ------------------------------ Date: 19 Jan 2005 10:27:40 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: vms versus solaris Message-ID: In article , "Tom Linden" writes: > On Tue, 18 Jan 2005 23:16:19 -0500, JF Mezei > wrote: > >> Dave Froble wrote: >>> Symbols exist within a process. They can be global to the process, or >>> can be >>> local to a DCL procedure. Symbols have a value, and can be evaluated, >>> set and >>> re-set by DCL and library routines. >> >> >> Would it be more precise to state that symbols exist at the CLI/DCL >> level, whereas logicals exist in various tables, including a process and >> job tables ? >> >> Is it correct to state that RUN/DETACHED image.exe will not give >> image.exe access to any symbols for reading and writing ? > > What about lib$[s,g]et_symbol? Those depend on a CLI, so unless image.exe was LOGINOUT.EXE those calls do not work. ------------------------------ Date: Wed, 19 Jan 2005 08:39:26 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg wrote: > Bill Todd wrote: >> Dave Weatherall wrote: >> .... >> As a >> >>> record-oriented user/programmer, it _is_ a decisive plus but then, >>> perhaps, I fall into the 'locked in' category (mentally or >>> philosophically). >> The point is that as a record-oriented user/programmer, you'd also >> have access to the kinds of packages I mentioned on Unix (or - blech - >> even to some extent on Windows) - in fact, to a considerably larger >> collection of options in this area than is available to you on VMS, >> many of them free or very low cost but still very functional and stable >> and quite a few of them also somewhat more technically current than RMS >> is (e.g., in their integral use of journaling to improve both >> performance and reliability). >> The fact that RMS is bundled and supported as part of the OS may be >> convenient and reassuring, but is hardly of *major* significance to >> most users (or applications, though not having a third-party dependency >> in this area is part of the convenience). >> - bill > > It appears to me that everyone here fails to understand the philosophy > behind having an universal record handling service integrated into the > operating system. > > It's primary purpose within the context of professional programming is > not to make record handling "easier" or more "convenient" for the > programmer. > > It's primary purpose is to improve the quality and correctness of record > storage and transfer. > > This principle is similar to that which behind the use of Descriptors > and a defined Call Standard in OpenVMS, which are also excellent unique > quality features of the OpenVMS OS Architecture. > > By making this service "default" or for some purposes even "mandatory" > for the operating system, programmers are encouraged to forego their > artistic-license to make many common record-handling errors, and provide > a clear definition of the record structure of a file. When another > program tries to use the record service to read the records in an > erroneous format, this is quickly identified as an error, before passing > the incorrectly interpreted information to the next application. > > I have been told several times by programmers, that they found > > "RMS is a frustrating obstacle to my programming freedom", > or that > "RMS is very finicky about file and record definitions". > > I then tell them... > > "That is why RMS exists, to be finicky and frustrate you". > > RMS helps programmers to be disciplined, and to get their file > definitions right. Actually, you could make all the same arguments as a case for using PL/I instead of C. > > Please note, that RMS also manages the access of files with the > stream-lf format. This protects, for instance, a program correctly > programmed for accessing a stream-lf file from accessing an > Indexed-Sequential file, or even an executable file erroneously. RMS > thus reduces the likelihood not only of programmer error, but user error > as well. > > I have over the years experienced countless cases where RMS has saved > our customers a lot of trouble. I am especially referring to a complex > CIM and Production Planning environment in which a diagram of the > interfaces between the processes controlling the various factory > processes looks like a 3D spider web. Information produced by one > process is often transferred to many other processes in that processing > web using some form of file transfer. Having an undiscovered error in an > interface would quickly propagate deeply into many other systems. It > would be a potentially create an unrecoverable mess! This CIM > environment also sends and receives information from external systems, > often programmed by external companies or consultants using their own > methods. By having a RMS described file as a transfer medium, we have > often caught these external agencies that have quietly (perhaps > unintentially through their own programming errors) changed the format > of these files, before accepting their information in our complex CIM > environment. For us, this seems to happen regularly when information is > transferred from SAP systems which have had some sort of upgrade. The > SAP folks appear to be so isolated from the file details that they don't > always know the exact format of a file that will be produced after a > change. They could certainly use a service that implements the > principles found in RMS! > > Although, I agree that there are customers and applications with design > goals that would make the Unix minimalism desirable, I respectfully > disagree that this philosophy should be a goal within an Enterprise or > Mission-Critical oriented OS. The presence of such universal (at least > within the chosen OS) quality-oriented services is clearly a desirable > quality enhancement within the professional Enterprise OS and > Mission-Critical problem space. > > Cheers! > > Keith Cayemberg -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 17:26:13 +0100 From: Keith Cayemberg Subject: Re: vms versus solaris Message-ID: <41ee8a25$0$17600$9b4e6d93@newsread4.arcor-online.net> Bill Todd wrote: > Dave Weatherall wrote: > > .... > > As a > >> record-oriented user/programmer, it _is_ a decisive plus but then, >> perhaps, I fall into the 'locked in' category (mentally or >> philosophically). > > > The point is that as a record-oriented user/programmer, you'd also have > access to the kinds of packages I mentioned on Unix (or - blech - even > to some extent on Windows) - in fact, to a considerably larger > collection of options in this area than is available to you on VMS, many > of them free or very low cost but still very functional and stable and > quite a few of them also somewhat more technically current than RMS is > (e.g., in their integral use of journaling to improve both performance > and reliability). > > The fact that RMS is bundled and supported as part of the OS may be > convenient and reassuring, but is hardly of *major* significance to most > users (or applications, though not having a third-party dependency in > this area is part of the convenience). > > - bill It appears to me that everyone here fails to understand the philosophy behind having an universal record handling service integrated into the operating system. It's primary purpose within the context of professional programming is not to make record handling "easier" or more "convenient" for the programmer. It's primary purpose is to improve the quality and correctness of record storage and transfer. This principle is similar to that which behind the use of Descriptors and a defined Call Standard in OpenVMS, which are also excellent unique quality features of the OpenVMS OS Architecture. By making this service "default" or for some purposes even "mandatory" for the operating system, programmers are encouraged to forego their artistic-license to make many common record-handling errors, and provide a clear definition of the record structure of a file. When another program tries to use the record service to read the records in an erroneous format, this is quickly identified as an error, before passing the incorrectly interpreted information to the next application. I have been told several times by programmers, that they found "RMS is a frustrating obstacle to my programming freedom", or that "RMS is very finicky about file and record definitions". I then tell them... "That is why RMS exists, to be finicky and frustrate you". RMS helps programmers to be disciplined, and to get their file definitions right. Please note, that RMS also manages the access of files with the stream-lf format. This protects, for instance, a program correctly programmed for accessing a stream-lf file from accessing an Indexed-Sequential file, or even an executable file erroneously. RMS thus reduces the likelihood not only of programmer error, but user error as well. I have over the years experienced countless cases where RMS has saved our customers a lot of trouble. I am especially referring to a complex CIM and Production Planning environment in which a diagram of the interfaces between the processes controlling the various factory processes looks like a 3D spider web. Information produced by one process is often transferred to many other processes in that processing web using some form of file transfer. Having an undiscovered error in an interface would quickly propagate deeply into many other systems. It would be a potentially create an unrecoverable mess! This CIM environment also sends and receives information from external systems, often programmed by external companies or consultants using their own methods. By having a RMS described file as a transfer medium, we have often caught these external agencies that have quietly (perhaps unintentially through their own programming errors) changed the format of these files, before accepting their information in our complex CIM environment. For us, this seems to happen regularly when information is transferred from SAP systems which have had some sort of upgrade. The SAP folks appear to be so isolated from the file details that they don't always know the exact format of a file that will be produced after a change. They could certainly use a service that implements the principles found in RMS! Although, I agree that there are customers and applications with design goals that would make the Unix minimalism desirable, I respectfully disagree that this philosophy should be a goal within an Enterprise or Mission-Critical oriented OS. The presence of such universal (at least within the chosen OS) quality-oriented services is clearly a desirable quality enhancement within the professional Enterprise OS and Mission-Critical problem space. Cheers! Keith Cayemberg ------------------------------ Date: Wed, 19 Jan 2005 17:13:35 +0000 (UTC) From: m.kraemer@gsi.de (Michael Kraemer) Subject: Re: vms versus solaris Message-ID: In article <41ee8a25$0$17600$9b4e6d93@newsread4.arcor-online.net>, Keith Cayemberg writes: > > I have been told several times by programmers, that they found > > "RMS is a frustrating obstacle to my programming freedom", > or that > "RMS is very finicky about file and record definitions". > > I then tell them... > > "That is why RMS exists, to be finicky and frustrate you". > > RMS helps programmers to be disciplined, and to get their file > definitions right. > Funny. In former times some of the VMS bigots in my field joked about the - in their view - strange concept of record structured files on IBM's mainframes. "No need for that, just open a file and be happy bytewise". Strange that VMS bigots nowadays bash Unix for exactly the opposite. ------------------------------ Date: Wed, 19 Jan 2005 18:01:59 GMT From: "FredK" Subject: Re: vms versus solaris Message-ID: "Tom Linden" wrote in message news:opskuy70bkzgicya@hyrrokkin... > On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg > > Actually, you could make all the same arguments as a case for using PL/I > instead of C. I can make arguments for buying a caddy rather than a bimmer, but the caddy still remains an old fart car. Kind-of like PL/I. Or VMS itself. Not a lot of appeal to anyone who wants to appear young or cool. ------------------------------ Date: 19 Jan 2005 18:09:15 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: vms versus solaris Message-ID: <357m2aF4h22dhU3@individual.net> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <3576loF4h517hU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> In article <0rF4L0yqRgL6@eisner.encompasserve.org>, >> Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>> In article , "Tom Linden" writes: > >>>> ulimit(1) >>>> ulimit(1) >>>> >>>> NAME >>>> >>>> ulimit - Sets or reports a resource limit >>> >>> I did not see anything in that description specifying the name of the >>> user affected. >> >> A user can only change his own limimits so there is no need for >> the ability to specify a user. >> >>> >>> Does this mean that all users on the system have the same quotas ? >> >> No, the initial values are set at login based on a class. The values >> are defined in /etc/login.conf. > > Does that mean a user can raise values with the ulimit command even > though the system manager has set them to a particular limit ? No. 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: Wed, 19 Jan 2005 10:13:37 -0500 From: "John Smith" Subject: Re: Webcast and VMS Message-ID: Dave wrote: > You asked for suggestions for improving the perception of VMS in the > marketplace. At least I think that's what you asked. > > I think you've already said what's required. A quote from the Q&A: > > "OpenVMS is one of the most powerful operating environments in the > industry." > > All you need to do is continue to say this publically. Often. In > advertisements. Every salesman should make this statement to a > customer, at least once, regardless of what the customer is looking > at. > > If a customer had to choose between a perceived "industry standard" > and "the best", how many people do you know that want second best. > All you have to do is make sure that they know that "the best" > exists, and is available from HP. > > It's my perception that HP makes more on a VMS sale than most other > HP products. Most VMS customers buy lots of support. Good support, > forget about India. Well put. try sending this to Ann (and Marcello) using the usual fname.lname@CUTTHIShp.com, perhaps with 'OpenVMS' as the subject line to escape spam filters. Also request a Read Reply receipt. And/Or you can use both these links to send your message with the preamble that Ann explicitly requested feedback like this during the chat phase of the webcast yesterday... via carly(tm): http://www.hp.com/hpinfo/execteam/email/fiorina/index.html via the Board of Directors: http://www.hp.com/hpinfo/execteam/email/bod/index.html ------------------------------ End of INFO-VAX 2005.038 ************************