1 INFO-VAX	Mon, 19 Mar 2001	Volume 2001 : Issue 155       Contents:* Building a VAX 3100 from the ground up 8-(P Re: I seem to be in a different reality today, one where VMS and Marketing go to8 Looking for Installation & Operations Guide for VAX 3100< Re: Looking for Installation & Operations Guide for VAX 3100< Re: Looking for Installation & Operations Guide for VAX 3100! Re: Obtaining 7.2-1 and TCPIP 5.1  One For the CI Cluster Experts" Re: One For the CI Cluster Experts/ Re: Open VMS Experience with Enterprise Storage / RE: Open VMS Experience with Enterprise Storage / Re: Open VMS Experience with Enterprise Storage / Re: Open VMS Experience with Enterprise Storage  Re: OpenVMS Educational Program  Re: OpenVMS Educational Program  Q-Bus hardware Re: RMS and file types. A Volunteer Board Members Wanted for the Plex86 Software Foundation   F ----------------------------------------------------------------------  % Date: Sun, 18 Mar 2001 09:25:44 -0500 - From: "Cannell, David M." <canneldm@pweh.com> 3 Subject: Building a VAX 3100 from the ground up 8-( I Message-ID: <BB93374116D9D41199200002A51341CD14C673@pusehe04.eh.pweh.com>   J Looks like we lost a 3100's system disk last night.  It also looks like it4 had been improperly backed up and is not restorable.I Apparently on site are the original systems tapes but no documentation of E course.  Some hints would be welcome for starting the rebuild of this H system.  Do we have to boot SDA from the tape first or should one of the3 tapes boot directly into the system load procedure?   " Any help is welcome.  Thanks, Dave   ------------------------------  % Date: Sun, 18 Mar 2001 17:36:04 -0500 ' From: "Bill Todd" <billtodd@foo.mv.com> Y Subject: Re: I seem to be in a different reality today, one where VMS and Marketing go to ( Message-ID: <993cse$jgj$1@pyrite.mv.net>  ; John Gemignani, Jr. <john@ossc.DELETE.net> wrote in message % news:3ab4eef5$1@newsfeed.vitts.com... + > nothernlight.com has a serach engine too?   E Absolutely.  But the oil industry has viciously suppressed that fact, * because it gets over 100 miles per gallon.   - bill   >  >  >    ------------------------------  % Date: Sun, 18 Mar 2001 11:55:03 -0500 * From: "Botchis, Peter" <botchipe@pweh.com>A Subject: Looking for Installation & Operations Guide for VAX 3100 L Message-ID: <076F630CE159D411A70300805F156091022A3C1D@ehposrv14.eh.pweh.com>  G Following up my earlier post, it looks like I am looking for either/or;   % a)  VMS Install and Operations Manual * 	VAXstation 3100, MicroVAX series	AA-NY74B b)  MicroVAX 3000-series  + 	Installation and Operations Guide	AA-KV93A   ? If someone could clue me in on where to find a copy (preferably   downloadable) I'd appreciate it.  J Initial problem is the system backup was not done in a manner that left usH with a usable backup so we have to build a new system from the ground upI using the original tapes that apparently came with the system.  Of course 3 the original docs don't exist any longer either 8-(   K Do we have to boot SDA and then load the system or just what IS the correct 8 procedure.  I don't seem to find much in the FAQ either.  E The system IS down and it's a production system so we're in sort of a  crunch.    Thanks, Dave Cannell mailto:canneldm@pweh.com	(W)  mailto:dcannell@voicenet.com	(H)   ------------------------------  % Date: Sun, 18 Mar 2001 17:55:41 -0700 % From: Dan O'Reilly <dano@process.com> E Subject: Re: Looking for Installation & Operations Guide for VAX 3100 A Message-ID: <5.0.2.1.2.20010318175406.00a6ea78@ntbsod.psccos.com>   K Assuming you have a VMS installation guide for the version of VMS you have, I read it and follow directions.  It should tell you how to install VMS for ! the distro and hardware you have.   C The first tape of the set (I'm assuming they're TK50's)At 09:55 AM    3/18/2001, Botchis, Peter wrote:H >Following up my earlier post, it looks like I am looking for either/or; > & >a)  VMS Install and Operations Manual: >         VAXstation 3100, MicroVAX series        AA-NY74B >b)  MicroVAX 3000-series : >         Installation and Operations Guide       AA-KV93A > @ >If someone could clue me in on where to find a copy (preferably! >downloadable) I'd appreciate it.  > K >Initial problem is the system backup was not done in a manner that left us I >with a usable backup so we have to build a new system from the ground up J >using the original tapes that apparently came with the system.  Of course4 >the original docs don't exist any longer either 8-( > L >Do we have to boot SDA and then load the system or just what IS the correct9 >procedure.  I don't seem to find much in the FAQ either.  > F >The system IS down and it's a production system so we're in sort of a >crunch. >  >Thanks, Dave Cannell $ >mailto:canneldm@pweh.com        (W)$ >mailto:dcannell@voicenet.com    (H)   ------I +-------------------------------+---------------------------------------+ I | Dan O'Reilly                  |                                       | I | Principal Engineer            |  "Why should I care about posterity?  | I | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    | I +-------------------------------+---------------------------------------+    ------------------------------  % Date: Sun, 18 Mar 2001 23:58:04 -0500 2 From: rdeininger@mindspring.com (Robert Deininger)E Subject: Re: Looking for Installation & Operations Guide for VAX 3100 L Message-ID: <rdeininger-1803012358040001@user-2ivebij.dialup.mindspring.com>  
 In articleA <076F630CE159D411A70300805F156091022A3C1D@ehposrv14.eh.pweh.com>, + "Botchis, Peter" <botchipe@pweh.com> wrote:   I > Following up my earlier post, it looks like I am looking for either/or;  > ' > a)  VMS Install and Operations Manual : >         VAXstation 3100, MicroVAX series        AA-NY74B > b)  MicroVAX 3000-series  : >         Installation and Operations Guide       AA-KV93A  I I think these are just hardware installation; they won't help you install 8 the OS.  In any case, I don't know where to find either.  A > If someone could clue me in on where to find a copy (preferably " > downloadable) I'd appreciate it. > L > Initial problem is the system backup was not done in a manner that left usJ > with a usable backup so we have to build a new system from the ground upK > using the original tapes that apparently came with the system.  Of course 5 > the original docs don't exist any longer either 8-(  > M > Do we have to boot SDA and then load the system or just what IS the correct : > procedure.  I don't seem to find much in the FAQ either.  F You may boot standalone backup.  I don't think there was ever a way to boot the System Dump Analyzer.   G > The system IS down and it's a production system so we're in sort of a 	 > crunch.   / First, get the VMS FAQ.  It's linked from here: !    http://www.openvms.compaq.com/   = (Oops, I just noticed you _did_ read the FAQ already. Sorry.)   P Second, look at the Installation and Upgrade Manual.  The on-line version is at::    http://www.openvms.compaq.com:8000/ssb71/6487/6487p.htm$ (also linked from the VMS home page)  I This manual is pretty complete.  The exact steps depend on what media you E have, and whether you want to try to salvate what's left on your sick  disk.   G The chapter "After Installing OpenVMS VAX" will tell you to back up the J system disk, among other things.  Now you know why.  Don't let this happen again.   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Mon, 19 Mar 2001 01:02:31 GMT - From: goathunter@goatley.com (Hunter Goatley) * Subject: Re: Obtaining 7.2-1 and TCPIP 5.11 Message-ID: <3ab55a57.276447420@swen.process.com>   N On Wed, 14 Mar 2001 04:20:30 GMT, "Zane H. Healy" <healyzh@shell1.aracnet.com> wrote:  K >Out of curiosity, is there an affordable way for a Hobbyist to get OpenVMS " >7.2-1 or TCPIP 5.1 for the Alpha?  G In response to the original post, I wanted to remind everyone that both 0 MultiNet and TCPware are available to Hobbyists:  , http://www.process.com/openvms/hobbyist.html   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------   Date: 19 Mar 2001 05:10:29 GMT! From: briannfo@aol.com (BrianNFO) ' Subject: One For the CI Cluster Experts : Message-ID: <20010319001029.02156.00001048@ng-cg1.aol.com>  M I had a problem with something tonight and I can't figure this one out.  I am N replacing a 6320 with a 6620.  The 6320 has a CIBCA, and the 6620 has a CIXCD.  N When I booted the 6620 off the 6320's system disk, my plan was to do licenses,H system params, etc.  Shortly after the system joins the cluster, I startE getting "port has closed virtual circuit" to the other nodes.  Up and O down...every few minutes.  When the system finally came up, it was logging PEA0  errors constantly.    N I pulled a CIXCD out of another good system, thinking I might have a bad boardO or a rev level issue, but the problem remained.  Someone at Compaq said "reboot O your cluster."  I sceptically did, and still the same problem.  So for now, I'm I back on the old system.  Any thoughts??  Oh, and if I'm missing something + blatently obvious, be gentle.  Thanks much.    Brian    ------------------------------   Date: 19 Mar 2001 05:37:37 GMT! From: briannfo@aol.com (BrianNFO) + Subject: Re: One For the CI Cluster Experts : Message-ID: <20010319003737.04419.00003339@ng-fi1.aol.com>  + I should add this system is running VMS 6.2    Brian    ------------------------------  # Date: Mon, 19 Mar 2001 00:56:48 GMT $ From: Scott Vieth <svieth@wi.rr.com>8 Subject: Re: Open VMS Experience with Enterprise Storage) Message-ID: <3AB55978.4E6640CE@wi.rr.com>   % How about IDX on ISM?  IDX on Cache'?   L Can you share more details on the config of your storage?  I was thinking of* doing big 0+1 arrays to hold our IDX UCIs.  & Are you using HBVS on your IDX system?  J If you're using the faster drives, you must be working with an EMA12000 or MA8000.....  I'm stuck with the 10k drives.  
 -Scott :^)  
 Koloth wrote:   R > If you are running IDX on DSM then you will be doing lots of 1 KB I/O.  You willP > be needing lots of spindles.  We looked at EMC and they had few spindles and aE > very large cache.  It may work for you but I would be very careful.  > : > We are using the HSG80 and the 15K RPM disk.  Very nice! >  > Cass Witkowski >  > Mike Gray wrote: >  > > Thanks.  > > P > > Aside from cost, does anyone have EMc or IBM connected to VMS? Any problems?; > > I am looking at running IDX (healtchare package) on it.  > >  > > MiD > > "Steeples, Oliver" <Oliver.Steeples@compaq.com> wrote in messageL > > news:F498D199EDB12D468CD2C66680D3080116D541@reoexc04.emea.cpqcorp.net...I > > > IBM's shark storage is nice but very expensive.  EMC's is nice too.  > > > P > > > However Compaq's enterprise storage isn't bad and as far as I know cheaperO > > > than the other two.  And if you do get problems Compaq will be a lot more 1 > > > helpful if it's their storage on the system  > > >  > > > Oliver > > >   > > > -----Original Message-----* > > > From: Mike Gray [mailto:me@home.com], > > > Sent: Saturday, March 17, 2001 5:13 PM > > > To: Info-VAX@Mvb.Saic.Com : > > > Subject: Open VMS Experience with Enterprise Storage > > >  > > > 	 > > > Hi,  > > > M > > > I am wondering what experiences you may have with Open VMS & Enterprise P > > > Storage (such as IBM Shark or EMC Symmetrix)? Can anyone offer any advice. > > >  > > > Mi > > >    ------------------------------  % Date: Sun, 18 Mar 2001 20:39:32 -0500 1 From: "Forster, Michael " <MFORSTER@PARTNERS.ORG> 8 Subject: RE: Open VMS Experience with Enterprise StorageP Message-ID: <709CDBE6CA13D311B4DF0008C7EAD0C604443C32@phsexch13.mgh.harvard.edu>  H Hi, may I chime in? We're in the process of bringing up IDX on Cache 3.2H (only CACHE version certified so far by IDX), on a GS80 cluster. For theJ time being, it'll be a VMS cluster, not a CACHE cluster. We've got to wait@ for IDX to certify the CACHE clustering. We also run a couple of
 Alphaservers.   J Since all current versions of MUMPS and CACHE still have the 16GB limit onK UCI sizing, it's best to run your RAID 0+1 arrays only a little bigger, say J 18.2GB, and split across many dual redundant controllers. We triple shadowJ 9.1GB 15K disks, with a few sets of 18GB 10K drives for inactive/extremelyH low use archive UCI's. Once InterSystems increases the limit, then we'll resize the drives.  K What I've noticed is that bigger sizing causes people to put too many "hot" L UCI's on the same disks or they try to put other high use directories there.   m    > -----Original Message-----+ > From:	Scott Vieth [SMTP:svieth@wi.rr.com] & > Sent:	Sunday, March 18, 2001 7:57 PM > To:	Info-VAX@Mvb.Saic.Com : > Subject:	Re: Open VMS Experience with Enterprise Storage > ' > How about IDX on ISM?  IDX on Cache'?  > K > Can you share more details on the config of your storage?  I was thinking  > of, > doing big 0+1 arrays to hold our IDX UCIs. > ( > Are you using HBVS on your IDX system? > L > If you're using the faster drives, you must be working with an EMA12000 or
 > MA8000.....   > I'm stuck with the 10k drives. >  > -Scott :^) >  > Koloth wrote:  > J > > If you are running IDX on DSM then you will be doing lots of 1 KB I/O.
 > You willL > > be needing lots of spindles.  We looked at EMC and they had few spindles > and a G > > very large cache.  It may work for you but I would be very careful.  > > < > > We are using the HSG80 and the 15K RPM disk.  Very nice! > >  > > Cass Witkowski > >  > > Mike Gray wrote: > > 
 > > > Thanks.  > > > H > > > Aside from cost, does anyone have EMc or IBM connected to VMS? Any > problems? = > > > I am looking at running IDX (healtchare package) on it.  > > >  > > > MiF > > > "Steeples, Oliver" <Oliver.Steeples@compaq.com> wrote in message > > > J > news:F498D199EDB12D468CD2C66680D3080116D541@reoexc04.emea.cpqcorp.net...K > > > > IBM's shark storage is nice but very expensive.  EMC's is nice too.  > > > > J > > > > However Compaq's enterprise storage isn't bad and as far as I know	 > cheaper L > > > > than the other two.  And if you do get problems Compaq will be a lot > more3 > > > > helpful if it's their storage on the system  > > > >  > > > > Oliver > > > > " > > > > -----Original Message-----, > > > > From: Mike Gray [mailto:me@home.com]. > > > > Sent: Saturday, March 17, 2001 5:13 PM! > > > > To: Info-VAX@Mvb.Saic.Com < > > > > Subject: Open VMS Experience with Enterprise Storage > > > >  > > > >  > > > > Hi,  > > > > D > > > > I am wondering what experiences you may have with Open VMS & > EnterpriseJ > > > > Storage (such as IBM Shark or EMC Symmetrix)? Can anyone offer any	 > advice.  > > > > 
 > > > > Mi > > > >    ------------------------------  # Date: Mon, 19 Mar 2001 03:23:22 GMT & From: "Kevin" <get_the_puck@yahoo.com>8 Subject: Re: Open VMS Experience with Enterprise Storage= Message-ID: <KYet6.21100$mH4.4683899@typhoon.ne.mediaone.net>   D I'm using both EMC and Storageworks in a fiberchannel configuration.  K Both are fast and reliable, EMC can be shared across multiple OS platforms, L comes with HW/SW support and is very fast. Storageworks can be configured toI support different OS's and is also very fast. Like other, respondents I'm J partial to hardware I'll have more control over, is less expensive, and is  provided by the OS manufacturer.   EW  * "Mike Gray" <me@home.com> wrote in message4 news:BWMs6.240879$v.25782841@typhoon.nyroc.rr.com... > Hi,  > I > I am wondering what experiences you may have with Open VMS & Enterprise L > Storage (such as IBM Shark or EMC Symmetrix)? Can anyone offer any advice. >  > Mi >  >    ------------------------------  # Date: Mon, 19 Mar 2001 06:29:10 GMT  From: Dirk Munk <munk@home.nl>8 Subject: Re: Open VMS Experience with Enterprise Storage' Message-ID: <3AB5A735.5DA0076E@home.nl>   J I choose HSG80 with 15000 rpm disks for the VMS systems, because I did notH want to experiment with EMC. Fibrechannel SAN is just a bit to new in my0 opinion to experiment with multi-vendor storage.  N My Unix collegues where more or less forced to use EMC fibre channel for theirK Wildfire cluster. They have BIG problems, system crashes etc. Seems the EMCaN Command Console Lun is changing identity from 'disk' to something else all theK time, and Unix doesn't like that very much. In VMS we can see a EMC Command M Console Lun as a DGA device (= disk) whereas the HSG80 Command Console Lun is-
 a GGA device.    Regards,   Dirk   Mike Gray wrote:   > Hi,  >CI > I am wondering what experiences you may have with Open VMS & EnterpriseVL > Storage (such as IBM Shark or EMC Symmetrix)? Can anyone offer any advice. >t > Mi   ------------------------------  % Date: Sun, 18 Mar 2001 19:05:31 -0500   From: Ben Sego <bsego@clark.net>( Subject: Re: OpenVMS Educational Program) Message-ID: <3AB54D4A.B7853F9A@clark.net>r   Christof Brass wrote:d <snip>   > Ben Sego wrote:-   >-N > > > there is of no help as this definitely won't attract any non-VMS people. > > [ > > First off, I believe you're wrong.  Having more software available for a platform makesd[ > > the platform more versatile.  Which means it can serve more functions.  Which means the X > > overall cost to the company is lower.  And CIO's, CTO's, CFO's, and CEO's definitely > > care about that. >oB > This may seem so without sound analysis. From my perspective and@ > experience which is in synch with all I heared from others VMS: > is at places where its strengths/advantages can be used.  \ I agree, mostly. Let me state it this way.  Those sites which still use VMS do it for one ofU two reason.  First, and perhaps most virtuously, it is used because of its particular0] strengths and advantages.  For the most part, those are safe customers, entrenched in the VMSf\ way, and it would be very difficult to convince their people to remove VMS in favor of using some other system.  ^ Other sites, however, are using VMS because it was already there, the company already paid for^ the licenses, they have a support agreement and staff to run the system, and the software they[ want to run is available to be run under VMS.  The people at that kind of a site may or may-\ not be deriving significant benefit from VMS strengths/advantages.  And if they are derivingZ that benefit, they may not know that they are.  So, if, at this sort of a site, one of the] users requires some new piece of software, and that software is only available on NT or Unix, \ the user who wants will have no particular reason to demand that VMS remain available.  OnceS the number of users of the VMS system dwindle below a particular point, the cost ofn[ maintaining the VMS system will be prohibitive.  And it will be de-installed.  This is muchl] less likely to happen if the new whiz-bang Electronic Document Management System (to name onem( high-end app) was also available on VMS.    J > Despite its higher entry level costs it has a lower TCO in the mid-term.  [ Perhaps in your environment, but in the many cases I've seen, the VMS side of the operation [ needs its own staff.  Whereas the rest of the systems are frequently administered by sharedr staff.   >eB > Having UNIX crap app there won't supply any of its strengths andB > therefore at best not attract anybody at worst even drive people  > away who make bad experiences.= > Unfortunately you seem to rely on CIOs, CTOs, CFOs and CEOs-; > behaving rational, economical or reasonable. In fact they'9 > aren't. That's why crap-crap so-called-OSs from a BASICl= > programmer shop called Micro$oft (IIRC) are haevily in use.2 > Don't count on your managers!c  ^ Actually, I'm not counting on them to make rational long term decisions.  I'm counting on them] being unable to get past next year's license fee, and next year's VMS staffing costs.  As you [ say, MS software is in heavy use, so they have to fund that support effort.  Then, if theirtD high-end server side apps run only on Unix, why would they fund VMS?  [ I'm also counting on this:  Companies that make their money by developing high-end apps areMZ going to develop for the largest market place.  They won't fund full-up VMS development if\ only a few of their potential customers use VMS.  The customers won't use VMS unless certain\ high-end applications run on it.  COE compliance helps break the deadlock.  And yes, I agree\ with you that a quickly ported application against a compatibility layer won't be as good as] something written for VMS.  But I do believe (and this is where we differ most) that having aiC less-than-optimal application is better than no application at all.D    X > > Secondly, it isn't simply an issue of whether more non-VMS people will be attracted.W > > What would be nice is if there were some reason for shops that are running multiplerZ > > architectures not to _remove_ the VMS systems.  It isn't just about gaining new users,* > > it's also about keeping existing ones. >-< > Great. But as explained several times (if you followed theA > thread) this won't help as these quickshot ported UNIX crap app 4 > won't fulfill what they had to to be of any value. >u  \ As I said above, we differ on this point.  I believe that a less-than-optimal application isX better than no application at all.  I have come to this decision slowly over time.  I am] personally surprised at the low level of software quality customers will accept.  And I don't-Z believe you should take advantage of your customers and ship seriously deficient software.[ However, it is hard to ignore the message of the marketplace--and the marketplace says poor-$ software is better than no software.  * > > > The problem of the COE/"UNIX on VMS"A > > > advocates is that they don't understand that their proposal E > > > doesn't help. Competition can only be won with unique features.e > >tU > > "Unique features" hasn't been enough to keep the VMS share from dropping.  If thea[ > > "unique features" are widely desired, other environments will have them eventually.  If Z > > only a niche group wants them, then if the niche can afford to pay the price, VMS will
 > > continue.  >yB > Well agreed. But it's common knowledge (at least within this NG)? > that VMS suffered from severe damage. If the money VMS earneda< > for the companies who owned it had spent appropriately for> > research, development and marketing (let alone the Micro$oftA > contract which should have guaranteed to have crap-crap WNT and B > crap-crap office apps on Alpha - though this isn't a cov related@ > topic unfortunately; we see that it's not easy to negotiate if8 > your position is weak because of you current financial; > situation) I'm personally sure that market share would be  > different (much bigger).  V Agreed.  As they say, "Mistakes were Made."  Whether they were on purpose or not isn't	 relevant.s  ' > Anyway I can't prove this and this isn; > history. The point stays that without sound analysis yourh= > statement about the reason for VMS' fall is not >>better<<.:< > I'm even not sure if paying is enough to keep VMS. What if? > Compaq decides to drop it actively (again) because told so bynA > Micro$oft and Intel? Are there any means to do anything againstn > that?q  \ Yes, that's a concern.  Compaq could say "We don't want to sell this anymore.  We don't want[ to support it anymore."  There's little that can be done about it.  This is one of the waysaX that I believe Unix has an advantage over VMS.  No single company nor any combination of companies can take it away.m  [ I think it's a safe bet, though, that Compaq won't just shut down VMS development.  If theyi] decide to get out of the business, they'll sell it to someone else.  In some ways, some parts0Z of the VMS world would have been better off if DEC had folded.  There would, in that case,S have been lost of talented and motivated programmers available to work on Free VMS.0   <snip>    0 > In any case it eats up engineering power which+ > should have been spent on other features.a  \ If you change "should have been" to "could have been" then your point is inarguably correct.  9 > Am I wrong that the changed behaviour of the having theNB > directory modification date set if the directory file expands or9 > shrinks beyound a block limit (to put it simple: if therA > directory file needs more or less space on disk) and having the ? > permission to delete a file if the permission to write to the-> > directory is granted which obviously can compromise existingB > security schemes and definitely changes the genuin VMS behaviour= > is one of the first bad consequences of this crap COE nicheh > market initiative?  ^ The directory modification issue is problematic; however, it still would be possible to expose^ that sort of behavior through the COE layer.  The "write implies delete" issue doesn't seem asJ harsh.  And separate security modules aren't the worse thing in the world.   >e? > I'm personally sure that the outcome of this COE towards UNIXn@ > development will be lower technical quality for VMS, a loss in? > market share overall (we add the DoD gain if there is any ando6 > reduce the loss in other market areas) and a lowered > attractivity for novices.h  Z Obviously, we disagree on this point.  The current attractiveness for novices is down nearF zero.  I believe COE will improve it; if I didn't, I wouldn't want it.   <snip>  [ > > Adding a set of compatibility calls needn't harm the underlying design. I doubt there's-Y > > anything in the COE that requires underlying changes.  On the issue of "complicating"aW > > VMS...uh...VMS is complex.  Despite that, it still has significant advantages.  But0N > > don't kid yourself.  It's simple to you, because you know it.  (I could be\ > > misunderstanding you here.  If you mean it's simple from the perspective of it's design, > > you have a better point.): >eA > As pointed out the COE/DoD/UNIX crap will probably added to the6@ > kernel. Other behaviouravely changes and bad consequences have! > been mentioned to disprove you.g/ > VMS is complex, both the API and the DCL CLI.+> > But the API and DCL CLI are designed and regular. UNIX shellB > command language is broken and the names and options of the UNIXB > system programs are irregular. The behaviour of UNIX wrt its ownA > principles is inconsistent e.g. wrt pipeing. The "concepts" aren! > not thought through thoroughly..  Z I disagree with your point that Unix shell is broken, but what I think about it is (on the^ whole) unimportant.  Currently, more people know and use Unix shell variants than know and use\ DCL.  Having more people know and use it is not a claim of superior technology.  But it is a claim of superior profit.r    : > > Let me see...so, are you saying that Unix is crap? :-) >?B > Not only ;-) It has been clamed that offering close to UNIX like= > APIs will make it simpler to port apps from UNIX to VMS. NorA > doubt it will. The problem is that these apps will be even moree@ > unreliable than on their natural habitats because porting them< > to VMS will need some sort of adjustment which is not done@ > properly because it shouldn't cost anything, it should be done? > in minimum time and (less obvious) the pitfalls are even lesseA > obvious because the API resembles VMS to be UNIX like (which in  > fact isn't the case). = > These quickshot ported apps won't take advantage of the VMStA > features and will therefore be a poor replacement of their UNIX B > counterparts/siblings. The business cases are rare which make it@ > attractive to run these apps on VMS instead of running them on > UNIX.g >a  T As I stated above, the world will accept, use, and (most importantly) pay for crappy5 software.  I wish it wouldn't, but it certainly does.      >    <snip>   >-
 > > > Wrt app-A > > > availablity is only one chance: to write real VMS apps thatt= > > > fully take advantage of VMS and fulfill the VMS qualityx > > > standards. > >e\ > > Well, if it's the only way, then you better get on with it.  I'm currently de-installingY > > two VMS systems because the businesses can no longer afford to keep them running, andoS > > they decided the only reasonable way to upgrade was to kick out the VMS system.u >r? > Really interesting case. To understand and comment on that weCB > need to know all the important conditions and numbers. Otherwise= > I have to make a note about that in the chapter of anecdots ? > which aren't relevant to the business and current discussion.l >i  ] Yes, without the details you can't really tell much about it, and I can't tell much about the  details.  Sorry about that.B   >dZ > > In one case, (in an agency of the state of New Jersey) there are 0 VMS people in theirX > > IT services shop.  How does a VMS system run without a system manager or at least anX > > operator?  Not well.  The system is used to run only a single application.  (It's anY > > important application, mind you.)  Digital helped develop the app about 10 years ago. V > > The State sought a way to upgrade the capacity of the system, and to get some moreX > > modern features in the software.  Staying with VMS was cost prohibitive.  While theyQ > > could have bought new hardware, they would have needed consultants (or Compaq \ > > professional services) to move the app from the VAX to the new gear.  And the underlyingY > > license cost of all the pieces was much higher in VMS than on Unix.  And they already0W > > were having trouble finding VMS managers and operators.  And they wanted to be able / > > to run some other apps on the new hardware.i > >tX > > This New Jersey agency decided to go with a system that runs on Unix.  (I don't even[ > > know which flavor of Unix, since the app runs anywhere.)  They hired my company to movef
 > > the data.  > >eY > > If VMS is to survive, and especially if it is to grow, there need to be fewer storiese > > like this. > >  > > Ben Sego > 6 > Agreed. But in this case - sorry to state that - the> > availability of UNIX (I leave out "crap" here) apps wouldn'tB > have helped because without VMS managers this wouldn't have been > a success.  X Yes, but they have other system admin people running other related systems.   If some of^ _those_ systems ran on VMS, then there would have been other VMS managers in-house to help out- when the system we're replacing got orphaned.p  5 > And honestly what you told is unfair to VMS because = > they put more constaints on the VMS system than before. Youm  A > wrote that before it was a dedicated system and later it should < > have been a multi-purpose system. If the other solution is> > better for them I personally wouldn't have recommended using$ > VMS. I'm not a VMS sentimentalist.  [ Yes, in this situation, it was unfair to VMS because they (the customer) changed the rules. \ But if the new software could have been available on VMS, then VMS would at least have had a shot at the opportunity.   >n >SB > I'm sure that the VMS way is more economical because of its best= > TCO resulting from administration power and simplicity, and / > system reliability which results in unrivaledo= > uptime/availability/speed compared to UNIX and WNT. If this.@ > isn't true then VMS has to go away from the business area. But= > if VMS is thrown out because of the morons of managers that ; > attended a "Micro$oft we're conquering the business area"r9 > seminar or because Compaq has decided milking their VMSo* > customers to death I fight against that.   I can't argue much with that.e   B.S.   ------------------------------  % Date: Mon, 19 Mar 2001 03:43:12 +0000r) From: Christof Brass <brass@infopuls.com>l( Subject: Re: OpenVMS Educational Program, Message-ID: <3AB58050.95575098@infopuls.com>   Ben Sego wrote:m >  > Christof Brass wrote:  > <snip> >  > > Ben Sego wrote:n >  > >.P > > > > there is of no help as this definitely won't attract any non-VMS people. > > >r] > > > First off, I believe you're wrong.  Having more software available for a platform makes ] > > > the platform more versatile.  Which means it can serve more functions.  Which means the Z > > > overall cost to the company is lower.  And CIO's, CTO's, CFO's, and CEO's definitely > > > care about that. > >hD > > This may seem so without sound analysis. From my perspective andB > > experience which is in synch with all I heared from others VMS< > > is at places where its strengths/advantages can be used. > ^ > I agree, mostly. Let me state it this way.  Those sites which still use VMS do it for one ofW > two reason.  First, and perhaps most virtuously, it is used because of its particulard_ > strengths and advantages.  For the most part, those are safe customers, entrenched in the VMSw^ > way, and it would be very difficult to convince their people to remove VMS in favor of using > some other system.  
 Agreed :-)  ` > Other sites, however, are using VMS because it was already there, the company already paid for` > the licenses, they have a support agreement and staff to run the system, and the software they] > want to run is available to be run under VMS.  The people at that kind of a site may or may ^ > not be deriving significant benefit from VMS strengths/advantages.  And if they are deriving\ > that benefit, they may not know that they are.  So, if, at this sort of a site, one of the_ > users requires some new piece of software, and that software is only available on NT or Unix,r^ > the user who wants will have no particular reason to demand that VMS remain available.  OnceU > the number of users of the VMS system dwindle below a particular point, the cost ofo] > maintaining the VMS system will be prohibitive.  And it will be de-installed.  This is muchs_ > less likely to happen if the new whiz-bang Electronic Document Management System (to name one * > high-end app) was also available on VMS.  > Sorry, I don't agree although I think I completely and exactly= understand what you mean. To disprove you I have to make some > assumptions which may not be correct at all places but at more6 than 99% which renders the rest as pretty neglectible." 1.There aren't any pure VMS shops.= 2.The quickshot ported UNIX crap app will not be more stable r1   than on UNIX crap where it unluckily came from.i3 3.The qspUca (quickshot ported UNIX crap app) will h"   not be well integrated into VMS.@ 4.The licence for the qspUca will be more expensive than on UNIX crap.u  > I'm sure that the likelihood to select a VMS version of a UNIX< crap app is very, very small. And I expect the SW vendors to think similarly.@ Do you know of any example in which your solution already worked% because a qspUca available was there?i  L > > Despite its higher entry level costs it has a lower TCO in the mid-term. > ] > Perhaps in your environment, but in the many cases I've seen, the VMS side of the operationT] > needs its own staff.  Whereas the rest of the systems are frequently administered by sharedl > staff.  = This will only result in higher TCO if the work load taken byp= the VMS sysadmins is smaller per person. I read of an examplei9 where fewer VMS sysadmins contributed more the work done.l  D > > Having UNIX crap app there won't supply any of its strengths andD > > therefore at best not attract anybody at worst even drive people" > > away who make bad experiences.? > > Unfortunately you seem to rely on CIOs, CTOs, CFOs and CEOsi= > > behaving rational, economical or reasonable. In fact theyd; > > aren't. That's why crap-crap so-called-OSs from a BASICt? > > programmer shop called Micro$oft (IIRC) are haevily in use.t! > > Don't count on your managers!t > ` > Actually, I'm not counting on them to make rational long term decisions.  I'm counting on them_ > being unable to get past next year's license fee, and next year's VMS staffing costs.  As youo] > say, MS software is in heavy use, so they have to fund that support effort.  Then, if their F > high-end server side apps run only on Unix, why would they fund VMS?   Why are they managers?  ] > I'm also counting on this:  Companies that make their money by developing high-end apps are \ > going to develop for the largest market place.  They won't fund full-up VMS development if^ > only a few of their potential customers use VMS.  The customers won't use VMS unless certain^ > high-end applications run on it.  COE compliance helps break the deadlock.  And yes, I agree^ > with you that a quickly ported application against a compatibility layer won't be as good as_ > something written for VMS.  But I do believe (and this is where we differ most) that having auE > less-than-optimal application is better than no application at all.a  ; I know that we and many others like you don't agree on that.> point. But I think it's really more important to find out why.@ Honestly, as longer I think about my own perspective of the case@ as more dangerous and less attractive the COE thing looks to me.  Z > > > Secondly, it isn't simply an issue of whether more non-VMS people will be attracted.Y > > > What would be nice is if there were some reason for shops that are running multiplet\ > > > architectures not to _remove_ the VMS systems.  It isn't just about gaining new users,, > > > it's also about keeping existing ones. > >s> > > Great. But as explained several times (if you followed theC > > thread) this won't help as these quickshot ported UNIX crap appt6 > > won't fulfill what they had to to be of any value. > >c > ^ > As I said above, we differ on this point.  I believe that a less-than-optimal application isZ > better than no application at all.  I have come to this decision slowly over time.  I am_ > personally surprised at the low level of software quality customers will accept.  And I don'te\ > believe you should take advantage of your customers and ship seriously deficient software.] > However, it is hard to ignore the message of the marketplace--and the marketplace says poors& > software is better than no software.  : Yes, the desktop and UNIX market area tells this. The high? quality SW market share is almost neglectible and so is the VMSy> and NSK. To put it simple (sorry for repeating myself): VMS is8 the Mac of enterprise computing. From my perspective the< conclusions are obvious and opposite to COE and other Compaq= management decisions. I personally think also that all Compaq = VMS related decisions which haven't been demanded by true VMSn> advocates for a long time should be regarded with outmost care' because they may only fake to help VMS.l  , > > > > The problem of the COE/"UNIX on VMS"C > > > > advocates is that they don't understand that their proposalSG > > > > doesn't help. Competition can only be won with unique features.  > > >hW > > > "Unique features" hasn't been enough to keep the VMS share from dropping.  If thet] > > > "unique features" are widely desired, other environments will have them eventually.  Ift\ > > > only a niche group wants them, then if the niche can afford to pay the price, VMS will > > > continue.r > >fD > > Well agreed. But it's common knowledge (at least within this NG)A > > that VMS suffered from severe damage. If the money VMS earnede> > > for the companies who owned it had spent appropriately for@ > > research, development and marketing (let alone the Micro$oftC > > contract which should have guaranteed to have crap-crap WNT andfD > > crap-crap office apps on Alpha - though this isn't a cov relatedB > > topic unfortunately; we see that it's not easy to negotiate if; > > your position is weak because of your current financialm= > > situation) I'm personally sure that market share would be. > > different (much bigger). > X > Agreed.  As they say, "Mistakes were Made."  Whether they were on purpose or not isn't > relevant..  @ It is - though technically not. If they were made on purpose the< people responsible must pay for this. If they don't pay make them pay in court.@ Wrt our case the conditions *are* important because they tell us8 something about remedy. Here is the chance to learn from history.  ) > > Anyway I can't prove this and this ism= > > history. The point stays that without sound analysis yourd? > > statement about the reason for VMS' fall is not >>better<<.a> > > I'm even not sure if paying is enough to keep VMS. What ifA > > Compaq decides to drop it actively (again) because told so byhC > > Micro$oft and Intel? Are there any means to do anything against"	 > > that?h > ^ > Yes, that's a concern.  Compaq could say "We don't want to sell this anymore.  We don't want] > to support it anymore."  There's little that can be done about it.  This is one of the waysnZ > that I believe Unix has an advantage over VMS.  No single company nor any combination of > companies can take it away.n  < That is not a UNIX crap feature. This is because some people> implemented an open source UNIX crap clone despite copyright -= even stupider and crappier than the "original" but it worked,o? sort of. The analogous action of the VMS community if I may sayt so seems to be clear.e  ] > I think it's a safe bet, though, that Compaq won't just shut down VMS development.  If they _ > decide to get out of the business, they'll sell it to someone else.  In some ways, some parts \ > of the VMS world would have been better off if DEC had folded.  There would, in that case,U > have been lost of talented and motivated programmers available to work on Free VMS.   9 Very interesting thought. I would bet against you becausei? shutting down could be more profitable than selling for Compaq.a@ The financial transactions and business agreements between these9 big players aren't clear. Intel and Micro$oft could offers@ conditions to Compaq which put Compaq ahead of other competitors for shutting down VMS.   > <snip> > 2 > > In any case it eats up engineering power which- > > should have been spent on other features.  > ^ > If you change "should have been" to "could have been" then your point is inarguably correct.  * From my analysis I stand up to my wording.  ; > > Am I wrong that the changed behaviour of the having the,D > > directory modification date set if the directory file expands or; > > shrinks beyound a block limit (to put it simple: if the C > > directory file needs more or less space on disk) and having therA > > permission to delete a file if the permission to write to theg@ > > directory is granted which obviously can compromise existingD > > security schemes and definitely changes the genuin VMS behaviour? > > is one of the first bad consequences of this crap COE niche  > > market initiative? > ` > The directory modification issue is problematic; however, it still would be possible to expose` > that sort of behavior through the COE layer.  The "write implies delete" issue doesn't seem asL > harsh.  And separate security modules aren't the worse thing in the world.  ; I'm not sure if I completely understand your answer. But itu? seems to me that your answer isn't a clear indication that thise? stuff keeps VMS in shape let alone makes it better. Honestly its@ sounds to me as if there are some nasty tricks in pandora's box.@ I'm sure we don't need this. VMS was wrt the mentioned points as@ good as it could be. No change needed at all. How many hours did< this cost to implement? How many hours will this cost in the< field to cope with? Unecessary, stupid, superflous, harmful,	 damaging.l  A > > I'm personally sure that the outcome of this COE towards UNIXtB > > development will be lower technical quality for VMS, a loss inA > > market share overall (we add the DoD gain if there is any anda8 > > reduce the loss in other market areas) and a lowered > > attractivity for novices.  > \ > Obviously, we disagree on this point.  The current attractiveness for novices is down nearH > zero.  I believe COE will improve it; if I didn't, I wouldn't want it.  < I include with novices also the students who aren't in touch8 with VMS. To give up VMS' uniqueness means giving up its( potential of attracting young engineers.   > <snip> > ] > > > Adding a set of compatibility calls needn't harm the underlying design. I doubt there's [ > > > anything in the COE that requires underlying changes.  On the issue of "complicating"MY > > > VMS...uh...VMS is complex.  Despite that, it still has significant advantages.  ButdP > > > don't kid yourself.  It's simple to you, because you know it.  (I could be^ > > > misunderstanding you here.  If you mean it's simple from the perspective of it's design, > > > you have a better point.)d > >oC > > As pointed out the COE/DoD/UNIX crap will probably added to the B > > kernel. Other behaviouravely changes and bad consequences have# > > been mentioned to disprove you.n1 > > VMS is complex, both the API and the DCL CLI.b@ > > But the API and DCL CLI are designed and regular. UNIX shellD > > command language is broken and the names and options of the UNIXD > > system programs are irregular. The behaviour of UNIX wrt its ownC > > principles is inconsistent e.g. wrt pipeing. The "concepts" are # > > not thought through thoroughly.V > \ > I disagree with your point that Unix shell is broken, but what I think about it is (on the` > whole) unimportant.  Currently, more people know and use Unix shell variants than know and use^ > DCL.  Having more people know and use it is not a claim of superior technology.  But it is a > claim of superior profit.   > Not even the profit point is true but I'm happy that you agree= about the pointless million flies argument. Profit cames fromt< win per unit multiplied with units. Where are the profits of; selling bash? Anyway if you don't agree on the basics whichi< makes VMS superior to UNIX crap why are you participating in this NG?? My position is very simple: I'm sure that a few basic things (I = don't repeat them here) are true if VMS is compared with UNIXa@ crap. If you don't agree on that you should propose a test (as I< did in this thread) to find out what is correct. Otherwise I? don't see why a UNIX crap advocat should do any good for VMS inv this NG?7 Could you write/port a UNIX crap app that it becomes anh( excellent VMS app? Would you like to do?   > < > > > Let me see...so, are you saying that Unix is crap? :-) > >eE > > Not only ;-) It has been claimed that offering close to UNIX likeg? > > APIs will make it simpler to port apps from UNIX to VMS. NoyC > > doubt it will. The problem is that these apps will be even moresB > > unreliable than on their natural habitats because porting them> > > to VMS will need some sort of adjustment which is not doneB > > properly because it shouldn't cost anything, it should be doneA > > in minimum time and (less obvious) the pitfalls are even lesseC > > obvious because the API resembles VMS to be UNIX like (which inr > > fact isn't the case).t? > > These quickshot ported apps won't take advantage of the VMShC > > features and will therefore be a poor replacement of their UNIX D > > counterparts/siblings. The business cases are rare which make itB > > attractive to run these apps on VMS instead of running them on	 > > UNIX.. > >e > V > As I stated above, the world will accept, use, and (most importantly) pay for crappy7 > software.  I wish it wouldn't, but it certainly does.   > Unfortunately you are right. But what do you think to have one; area, one OS to withstand this trend/fact? Shouldn't be oneo place on earth different?    > >m >  > <snip> >  > >i > > > > Wrt app C > > > > availablity is only one chance: to write real VMS apps that/? > > > > fully take advantage of VMS and fulfill the VMS qualitya > > > > standards. > > >e^ > > > Well, if it's the only way, then you better get on with it.  I'm currently de-installing[ > > > two VMS systems because the businesses can no longer afford to keep them running, andhU > > > they decided the only reasonable way to upgrade was to kick out the VMS system.  > >.A > > Really interesting case. To understand and comment on that we1D > > need to know all the important conditions and numbers. Otherwise? > > I have to make a note about that in the chapter of anecdots.A > > which aren't relevant to the business and current discussion.  > >  > _ > Yes, without the details you can't really tell much about it, and I can't tell much about thep > details.  Sorry about that.,  ' I made the note in chapter of anecdots.a  \ > > > In one case, (in an agency of the state of New Jersey) there are 0 VMS people in theirZ > > > IT services shop.  How does a VMS system run without a system manager or at least anZ > > > operator?  Not well.  The system is used to run only a single application.  (It's an[ > > > important application, mind you.)  Digital helped develop the app about 10 years ago.dX > > > The State sought a way to upgrade the capacity of the system, and to get some moreZ > > > modern features in the software.  Staying with VMS was cost prohibitive.  While theyS > > > could have bought new hardware, they would have needed consultants (or Compaqd^ > > > professional services) to move the app from the VAX to the new gear.  And the underlying[ > > > license cost of all the pieces was much higher in VMS than on Unix.  And they alreadyuY > > > were having trouble finding VMS managers and operators.  And they wanted to be ablet1 > > > to run some other apps on the new hardware.  > > >eZ > > > This New Jersey agency decided to go with a system that runs on Unix.  (I don't even] > > > know which flavor of Unix, since the app runs anywhere.)  They hired my company to moveo > > > the data.n > > > [ > > > If VMS is to survive, and especially if it is to grow, there need to be fewer storiest > > > like this. > > >  > > > Ben Sego > > 8 > > Agreed. But in this case - sorry to state that - the@ > > availability of UNIX (I leave out "crap" here) apps wouldn'tD > > have helped because without VMS managers this wouldn't have been > > a success. > Z > Yes, but they have other system admin people running other related systems.   If some of` > _those_ systems ran on VMS, then there would have been other VMS managers in-house to help out/ > when the system we're replacing got orphaned.o  @ Yes, surely. If there were a business analysis showing them that@ their UNIX crap apps aren't reliable they would have thrown them@ out. You unfortunately had to add another condition to make your> story a VMS success story. If go further in detail analysis of9 this case additional conditions will show up. It's prettyl; obvious that this app availabilty idea is doomed to failure = because it is helpless in its isolation. I'm sure most peoplec6 will find this out after a while. I'm also sure Compaq6 management could have found it out. Maybe they did ...: Anyway its again an uncoordinated not well thought through action to calm VMS community.'  7 > > And honestly what you told is unfair to VMS becauseX? > > they put more constaints on the VMS system than before. YouhC > > wrote that before it was a dedicated system and later it shoulde> > > have been a multi-purpose system. If the other solution is@ > > better for them I personally wouldn't have recommended using& > > VMS. I'm not a VMS sentimentalist. > ] > Yes, in this situation, it was unfair to VMS because they (the customer) changed the rules.e^ > But if the new software could have been available on VMS, then VMS would at least have had a > shot at the opportunity.  = Honestly, I'm sure if you really think about all my argumentsx9 you will sooner or later come to the conclusion that this = COE/UNIX crap initiative is much more harmful than helpful tos: VMS and its customer base. Think especially about the last? point: if chances are that small how many chances are needed to 	 win once?l  D > > I'm sure that the VMS way is more economical because of its best? > > TCO resulting from administration power and simplicity, andc1 > > system reliability which results in unrivaledr? > > uptime/availability/speed compared to UNIX and WNT. If thisnB > > isn't true then VMS has to go away from the business area. But? > > if VMS is thrown out because of the morons of managers thatn= > > attended a "Micro$oft we're conquering the business area"t; > > seminar or because Compaq has decided milking their VMSo, > > customers to death I fight against that. >  > I can't argue much with that.p >  > B.S.  8 I'm sorry for not snipping out - you did. But I miss one+ important section: What are VMS' strengths?t   ------------------------------  % Date: Sun, 18 Mar 2001 16:52:06 -0700t From: Kevin Handy <kth@srv.net>n Subject: Q-Bus hardwareo' Message-ID: <3AB54A26.E7477BB8@srv.net>   8 I have a pile of qbus hardware in the Idaho Falls, Idaho9 area that I would like to get rid of. Don't have any mores5 clients using this hardware, so it is now just taking 3 up space (which I am short of). May be a few unibusl boards mixed in.  5 I would like to trade for something more useful to men6 (Pentium PC's/boards/disks, SCSI disks/tapes, Alpha's,1 memory, etc), but willing to send to a good home.o  + It is too large to mail most of this stuff,k0 unless someone want's to spend a lot doing that * (including my time in doing the shipping),, so would like someone willing to pick it up.  2 Willing to ship small parts, but expect you to pay2 for shipping. 11/83 is probably too large to ship.  2 Should probably go to someone with experience with Q-Bus based machines.   2 It includes a working PDP11/83 with RD54 disk in a/ fairly large cabinet, TK50, couple of DHV11's, e. TSV05, and a multitech modem rack (1200/2400).  4 Also two BA23 boxes, one with a MicroVaxII cpu in it5 with a dead console port (works ok, but you can't seee/ what it types on the console), one memory boardw 300Mb? disk, TK50, DHV11.t  B Other BA23 box has only 11/73 CPU + memory board, but gives random6 error code when you try to start. Nothing else in box.  ; Microvax 2000 (functional, but missing disk), has ethernet.e2 couple of TK50Z boxes with the TK50 drives removed (used to replace customers).  8 Box full of random boards (CPU's, Memory, DHV11's, TK25,; rqdx{1/2} controllers, KDA50's, RQDX2's, cables, bulkheads,u etc.)   5 Random Disk drives (rd51?, rd52?, rd53, rd54, Maxtor,s= rx50, tk25, ...), unknown status (I don't want to test them).r  + RSTS/E manuals for Version 8 and Version 9.t   Large pile of Magtapes.w   etc...   -- dE If they're not putting secret messages to me in their music, then whyr> do they keep putting my picture on the other side of the CD's?   ------------------------------  % Date: Sun, 18 Mar 2001 17:34:53 -0500.' From: "Bill Todd" <billtodd@foo.mv.com>   Subject: Re: RMS and file types.( Message-ID: <993cq8$j95$1@pyrite.mv.net>  7 Paul Repacholi <prep@prep.synonet.com> wrote in messagec* news:87vgp78ema.fsf_-_@prep.synonet.com...   ...   E > Undefined records type. All sorts of things on RSX where UDF recordaH > type, .OBJs and .TSKs come to mind, but don't quote me. VMS set all ofB > these as 512 byte records, and does not use the UDF type at all.   ...'  G > The UDF -> 512 fixed has had practical impact I think. One is gettingUB > a 'not-defined' file as 512 fixed, and it has embedded CC chars.  I It's not clear whether you're saying that VMS just chose to use fixed/512wK for things like .OBJs (which seems as if it should be nobody's business buttH VMS's) or that VMS maps all handling of UDF files to fixed/512 (which isI simply a bug - perhaps a design bug, but a bug nonetheless, though likelytL one that has no chance of being fixed at this late date due to the number of  things that may depend upon it).  I IIRC (it's been kind of a long time...), the intent of UDF was to support H unformatted-stream-style files in the 'fill my buffer with bytes' idiom,K with RMS doing the internal buffering rather than using a Unix-style systemn cache.  L All the other stream formats were attempts to simulate record-level handlingF that on Unix is managed by application code, with the added feature ofC making the choice of delimiters at least semi-transparent such that E properly-written applications in a language used to using one kind ofnL delimiter could process files written by a language using some other kind of
 delimiter.  K This was related to the option to use 'stream access mode' (IIRC a 'fill myrL buffer with bytes, including delimiters' mode) or 'record access mode' (giveL me the next record, up to its delimiter - this was the one that offered someA inter-language transparency), both of which could be used on bothnI record-structured (counted) and stream-structured (delimited) files - andtJ could even possibly be interleaved on a single RAB, though I don't know ifD that was ever supported (and ISTR that Unix-style 'seek' positioningL operations into a record-structured file had problems, for obvious reasons).; This left UDF a raw-bytes mode that was neither record- noroF stream-structured and thus, I think, only accessible as a byte stream.  I But, as I said, it's been rather a long time since those discussions tookUJ place - I may not have remembered them exactly, and don't in any case know exactly what VMS implemented.    - bill   ------------------------------   Date: 18 Mar 2001 21:47:19 GMT* From: "Keith Donaldson" <keith@cabali.com>J Subject: Volunteer Board Members Wanted for the Plex86 Software Foundation0 Message-ID: <993ad7$f3q@dispatch.concentric.net>  A Volunteer Board Members Wanted for the Plex86 Software Foundationt  K The Organizing Committee of the Plex86 Software Foundation is looking for a D few talented and diligent volunteer board members to help us provideL organizational, legal, and financial support for Plex86 open-source software projects (www.plex86.org).  H The goal of the Plex86 project is to create an extensible open source PCL virtualization software program that will allow PC, and workstation users toK run multiple operating systems concurrently on the same machine. What makesaF it challenging on the PC, is that the x86 processor is not "naturally"L virtualizable. That is to say, it was not designed to run multiple operatingG systems concurrently. However, with some manipulation and use of systemcL level features, this can be done. The Plex86 environment makes the processorL virtualization more flexible and controllable than commercial products whereA developers do not have access to the source code, such as VMware.   J If you can contribute one evening a month and have skills or contacts thatI can aid us in the management of funds, intellectual property, accounting,kE publicity, fundraising or allocation of resources to projects, pleasenL contact Keith Donaldson at 617.576.9555 or keith@cabali.com to find out more: about whether this volunteer opportunity is right for you.   kd   ------------------------------   End of INFO-VAX 2001.155 ************************