1 INFO-VAX	Sun, 18 Mar 2001	Volume 2001 : Issue 154       Contents: Re: DCL minute of the day < DECnet V on a hobbyist system vs replacing it with DECnet IV@ Re: DECnet V on a hobbyist system vs replacing it with DECnet IV@ Re: DECnet V on a hobbyist system vs replacing it with DECnet IVP Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMS   Educational     Prog8 Re: How to adjust screen resolution with a S3Trio64 2MB?P Re: I seem to be in a different reality today, one where VMS and Marketing go toP Re: I seem to be in a different reality today, one where VMS and Marketing go to/ Re: LDAP Client - Anyone Ported to OpenVMS Yet? / Re: Open VMS Experience with Enterprise Storage / Re: Open VMS Experience with Enterprise Storage  Re: OpenVMS Educational Program  Re: RMS and file types.   F ----------------------------------------------------------------------    Date: 18 Mar 2001 16:53:57 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> " Subject: Re: DCL minute of the dayH Message-ID: <y4y9u3xecq.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 rdeininger@mindspring.com (Robert Deininger) writes:  G > It's not clear that VMS upgrades replace DCLTABLES.EXE anymore.  I've K > certainly had my private commands survive upgrades.  A particular command ? > might get clobbered if you pick a name that VMS wants to use.   I The upgrade uses tools similar to VERB to do this - since aroudn V5 IIRC.    	Jan   ------------------------------  % Date: Sun, 18 Mar 2001 12:41:54 +0000 ) From: Christof Brass <brass@infopuls.com> E Subject: DECnet V on a hobbyist system vs replacing it with DECnet IV , Message-ID: <3AB4AD12.CC8D7E1D@infopuls.com>  > I know that DECnet V/OSI is complex. I only want to connect an? old DECnet IV node to my new system. Is there any simple way? I 7 played around with NCP on the new system but it behaves = differently which I knew already. E.g. I can't simply add the ? remote node to the volatile and permanent databases even though @ the DEFINE NODE 37.1 NAME <name> seems to work (the SET NODE ...= isn't working "%NCP-W-UNRCMP, Unrecognized component , Node") = the LIST KNOWN NODES doesn't show anything than the executor.   > Is it necessary/worthwhile/recommended to study DECnet OSI? At> the moment I think DECnet IV would do the job just fine for my
 two nodes.  = Is there a safe procedure to remove DECnet OSI and replace it  with DECnet IV? @ I think that similar questions have already been discussed but I= don't find them in the google archive. I found that DECnet IV ; should run just fine on VMS 7.2 which is running on the new - node. The old node has VMS 6.2 running on it.    ------------------------------  % Date: Sun, 18 Mar 2001 09:35:19 -0500 2 From: rdeininger@mindspring.com (Robert Deininger)I Subject: Re: DECnet V on a hobbyist system vs replacing it with DECnet IV L Message-ID: <rdeininger-1803010935200001@user-2ivebbd.dialup.mindspring.com>  ; In article <3AB4AD12.CC8D7E1D@infopuls.com>, Christof Brass  <brass@infopuls.com> wrote:   @ > I know that DECnet V/OSI is complex. I only want to connect anA > old DECnet IV node to my new system. Is there any simple way? I 9 > played around with NCP on the new system but it behaves ? > differently which I knew already. E.g. I can't simply add the A > remote node to the volatile and permanent databases even though B > the DEFINE NODE 37.1 NAME <name> seems to work (the SET NODE ...? > isn't working "%NCP-W-UNRCMP, Unrecognized component , Node") ? > the LIST KNOWN NODES doesn't show anything than the executor.    $ MCR DECNET_REGISTER   C This is the way to add node/address information.  It's an SMG-style I menu-driven application by default.  NCL, the interface that handles most E DECnet-plus setup, does NOT do node registration.  The namespaces are , quasi-separate from the rest of DECnet-plus.  F I prefer DECnet V, since it does decnet over tcpip.  It clearly scalesE better to large networks, which isn't too relevant for you two nodes.   D You'll want to set it up with the LOCAL namespace, or with LOCAL and8 DOMAIN if you want decnet over tcpip.  See DECNET_CONFIG  J The manual you want to look at is "Installation and Basic Configuration". F Stay away from the NCL reference unless you need details.  If you needI details at the beginning of a simple setup, you are probably going in the H wrong direction.  I can try to answer simple questions if you get stuck.  @ > Is it necessary/worthwhile/recommended to study DECnet OSI? At@ > the moment I think DECnet IV would do the job just fine for my > two nodes. > ? > Is there a safe procedure to remove DECnet OSI and replace it  > with DECnet IV?    PRODUCT REMOVE
   followed by  PRODUCT INSTALL ?   > I think the OS installation and upgrade manual discusses this.  B > I think that similar questions have already been discussed but I? > don't find them in the google archive. I found that DECnet IV = > should run just fine on VMS 7.2 which is running on the new / > node. The old node has VMS 6.2 running on it.    --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Sun, 18 Mar 2001 15:37:02 +0000 ) From: Christof Brass <brass@infopuls.com> I Subject: Re: DECnet V on a hobbyist system vs replacing it with DECnet IV , Message-ID: <3AB4D61E.B2E846AD@infopuls.com>   This was fast, thanks!   Robert Deininger wrote:  > = > In article <3AB4AD12.CC8D7E1D@infopuls.com>, Christof Brass  > <brass@infopuls.com> wrote:  > B > > I know that DECnet V/OSI is complex. I only want to connect anC > > old DECnet IV node to my new system. Is there any simple way? I ; > > played around with NCP on the new system but it behaves A > > differently which I knew already. E.g. I can't simply add the C > > remote node to the volatile and permanent databases even though D > > the DEFINE NODE 37.1 NAME <name> seems to work (the SET NODE ...A > > isn't working "%NCP-W-UNRCMP, Unrecognized component , Node") A > > the LIST KNOWN NODES doesn't show anything than the executor.  >  > $ MCR DECNET_REGISTER  > E > This is the way to add node/address information.  It's an SMG-style K > menu-driven application by default.  NCL, the interface that handles most G > DECnet-plus setup, does NOT do node registration.  The namespaces are . > quasi-separate from the rest of DECnet-plus. > H > I prefer DECnet V, since it does decnet over tcpip.  It clearly scalesG > better to large networks, which isn't too relevant for you two nodes.  > F > You'll want to set it up with the LOCAL namespace, or with LOCAL and: > DOMAIN if you want decnet over tcpip.  See DECNET_CONFIG  @ I've chosen the LOCAL namespace already. For the moment I'll use3 only DECnet to connect the disks and for using X11.   K > The manual you want to look at is "Installation and Basic Configuration". H > Stay away from the NCL reference unless you need details.  If you needK > details at the beginning of a simple setup, you are probably going in the J > wrong direction.  I can try to answer simple questions if you get stuck.  > Very nice offer. At present I think it makes more sense to use@ DECnet IV because I knew it once sufficiently. I'll try the "MCR? DECNET_REGISTER" but I think I won't bother you with questions.   B > > Is it necessary/worthwhile/recommended to study DECnet OSI? AtB > > the moment I think DECnet IV would do the job just fine for my > > two nodes. > > A > > Is there a safe procedure to remove DECnet OSI and replace it  > > with DECnet IV?  >  > PRODUCT REMOVE >   followed by  > PRODUCT INSTALL ?  > @ > I think the OS installation and upgrade manual discusses this.  @ Had forgotten this, thanks. I don't have the new manuals yet. My? doc set is VMS 6.2 which unfortunately doesn't cover DECnet OSI # and AFAIR the product command also.   D > > I think that similar questions have already been discussed but IA > > don't find them in the google archive. I found that DECnet IV ? > > should run just fine on VMS 7.2 which is running on the new 1 > > node. The old node has VMS 6.2 running on it.  >  > -- > Robert Deininger > rdeininger@mindspring.com   6 While playing around on my old system I made a strange observation while in NCP: > I purged my executor unintentionally because I detected that a> remote node definiton was there with the same name and address: as the executor and then issued a purge command which also@ removed the executor. I then tried to DEFINE EXECUTOR to put the@ executor node data. I issued an SHOW EXECUTOR CHARACTERISTICS to; get the current values which I planned to supply during the @ DEFINE EXECUTOR. Unfortunately after putting all the data in the0 DEFINE EXECUTOR ended up with an error message:   , Node address           (1.1-63.1023): "37.1"! %NCP-E-INVVAL, unrecognized value   * Node address           (1.1-63.1023): 37.1( State    (ON, OFF, SHUT, RESTRICTED): ON+ System id string     (32 characters): FIRST ) Buffer size          (1-16384 bytes): 576 * Maximum address             (1-1023): 1023) Maximum buffers            (1-65535): 100 * Maximum cost                (1-1022): 1022( Maximum hops                  (1-30): 30( Maximum circuits              (1-64): 16( Maximum visits               (1-255): 63* Pipeline quota       (0-65535 bytes): 40323 %NCP-W-INVPGP, Invalid parameter grouping , Address   @ I don't know if I solved the problem but I then issued an DEFINE6 EXECUTOR ADDRESS 37.1 which worked and a LIST EXECUTOR9 CHARACTERISTICS showed all desired values. I wonder why I < couldn't fill in the node address with the dialog procedure.   ------------------------------    Date: 18 Mar 2001 16:47:40 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> Y Subject: Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMS   Educational     Prog H Message-ID: <y41yrvyt7n.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / Tim Llewellyn <tim.llewellyn@bbc.co.uk> writes:   . > However, 1-JAN-19970 is a unix thing anyway.  L I would have thought time_t and its interpretation is in the ISO C standard?   	Jan   ------------------------------  % Date: Sun, 18 Mar 2001 11:52:02 +0000 ) From: Christof Brass <brass@infopuls.com> A Subject: Re: How to adjust screen resolution with a S3Trio64 2MB? , Message-ID: <3AB4A162.18A690C3@infopuls.com>   Martin Vorlaender wrote: > , > Christof Brass (brass@infopuls.com) wrote: > > Carl Perkins wrote: 3 > > > Christof Brass <brass@infopuls.com> writes... 8 > > > } Does anybody know what the maximum resolution isO > > > } the S3Trio64 video card with 2MB RAM can provide and how I can persuade 4 > > > } the DECwindows X11 display server to use it? > > > = > > > The relevant key phrases are "decw$xsize_in_pixels" and E > > > "decw$ysize_in_pixels". These are set up in DECW$DEVICE.COM and I > > > appear as logical names in the DECWindows server logical name table $ > > > (SHOW LOG/TABLE=DECW* *SIZE*). > > < > > Thanks! This was the trick. I changed DEC$DEVICE.COM and  > > restarted the server: bingo! > H > IMHO, that's not the way to do it (DECW$DEVICE.COM can be changed by aE > patch / installation - isn't there a "Do not modify" comment in the J > header?). You can use it to look up the global symbols to define and the> > values to use, but your customizations should really go intoJ > SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM (copy it from the .TEMPLATE if > it doesn't exist). >  > cu, 
 >   Martin > --L > One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer9 > One OS to find them           | work: mv@pdv-systeme.de L > One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/@ > And in the Darkness bind them.| home: martin@radiogaga.harz.de  ; You are completely right but this is a little bit different ? case. I wrote irroneously "DEC$DEVICE.COM" because that was the + important hint. Starting from there I found @ DECW$DEVICE_CONFIG_GQ.COM which didn't contain this warning note> about changing and it is that simple (well written DCL easy to0 understand) and the right place technically (not< organisationally/administrationally) to change it because it8 simply sets this resolution in the case of this graphics adapter.: If I get a new version of the file I simply change the two symbols to the value I want.   ------------------------------  # Date: Sun, 18 Mar 2001 09:06:11 GMT 1 From: CSABA  HARANGOZO   <csabah@zipworld.com.au> Y Subject: Re: I seem to be in a different reality today, one where VMS and Marketing go to 8 Message-ID: <7U_s6.792$CN.127498@nostril.pacific.net.au>  & LJEB <LJEB@somewhere.out.there> wrote:  6 	I hope in the real article it was spelt correctly, as 	northernlight.com	:-| 					Cheers,		Csaba     J > Just opened the new ComputerWeekly (15th March), and found an advert for; > Alpha & OpenVMS, not only that it is a WHOLE PAGE advert!   M > Description: Simple red background, a small image, with the following text:   N > HOW DO YOU FIND OUT WHICH ALPHASERVER OPERATING SYSTEM IS THE MOST RELIABLE? > ASK A SERACH ENGINE.  B > More specifically, ask America's number one rated search engine.   > Ask nothernlight.com.   % > They'll give you an instant answer:   K > Compaq's OpenVMS, the operating system which had made their search engine C > home the largest text retrieval database ever created. Of course, K > nothernlight.com is just one of hundreds of thousands of businesses world 6 > wide now profiting from their investment in OpenVMS.   > Ask them the same question. # > They'll give you the same answer.     I    ---------------------------------------------------------------------- E    * Csaba I. Harangozo     |    'To err is human', said the hedgehog E    * csabah@zipworld.com.au |           as he dismounted a wirebrush. I    ---------------------------------------------------------------------- ;    EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:    ------------------------------  % Date: Sun, 18 Mar 2001 12:20:28 -0500 2 From: "John Gemignani, Jr." <john@ossc.DELETE.net>Y Subject: Re: I seem to be in a different reality today, one where VMS and Marketing go to + Message-ID: <3ab4eef5$1@newsfeed.vitts.com>   ) nothernlight.com has a serach engine too?    ------------------------------  % Date: Sun, 18 Mar 2001 12:49:50 -0500 ) From: Anamika Anamika <hemanir@yahoo.com> 8 Subject: Re: LDAP Client - Anyone Ported to OpenVMS Yet?) Message-ID: <3AB4F53E.25D1AEE0@yahoo.com>   3 Netscape 4.* is a LDAP client (I hope also on VMS).    -A   Warren Spencer wrote:    > Hello All, > J > It looks like we can't wait for OpenVMS 7.3 to get an LDAP client.  HaveB > any of you ported a current *or* older version of it to OpenVMS? >  > ws >  > --3 > << Marriage is Grand.  Divorce is Fifty Grand. >>  >  > Warren Spencer > Senior Software Engineer > The Associated Press > A > ** My employer does not necessarily agree with my statements **    -- Remove "-nospam" to reply.   ------------------------------  % Date: Sat, 17 Mar 2001 23:02:51 -0800 ! From: Koloth <koloth@tmisnet.com> 8 Subject: Re: Open VMS Experience with Enterprise Storage+ Message-ID: <3AB45D9B.E20626A6@tmisnet.com>   P If you are running IDX on DSM then you will be doing lots of 1 KB I/O.  You willN be needing lots of spindles.  We looked at EMC and they had few spindles and aC very large cache.  It may work for you but I would be very careful.   8 We are using the HSG80 and the 15K RPM disk.  Very nice!   Cass Witkowski   Mike Gray wrote:  	 > Thanks.  > N > Aside from cost, does anyone have EMc or IBM connected to VMS? Any problems?9 > I am looking at running IDX (healtchare package) on it.  >  > MiB > "Steeples, Oliver" <Oliver.Steeples@compaq.com> wrote in messageJ > news:F498D199EDB12D468CD2C66680D3080116D541@reoexc04.emea.cpqcorp.net...G > > IBM's shark storage is nice but very expensive.  EMC's is nice too.  > > N > > However Compaq's enterprise storage isn't bad and as far as I know cheaperM > > than the other two.  And if you do get problems Compaq will be a lot more / > > 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 8 > > Subject: Open VMS Experience with Enterprise Storage > >  > >  > > Hi,  > > K > > I am wondering what experiences you may have with Open VMS & EnterpriseCN > > Storage (such as IBM Shark or EMC Symmetrix)? Can anyone offer any advice. > >e > > Mi > >    ------------------------------    Date: 18 Mar 2001 19:43:23 +0800, From: Paul Repacholi <prep@prep.synonet.com>8 Subject: Re: Open VMS Experience with Enterprise Storage- Message-ID: <87zoej8fqc.fsf@prep.synonet.com>n  4 "Richard B. Gilbert" <DRAGON@compuserve.com> writes:  D > I'm a hands on type of guy and I prefer Storageworks.  My managers? > prefer to pay EMC and not have to depend on me for production 
 > systems.  E > As a result, I run EMC for production and Storageworks for test andt > development.  B > It's a matter of budget and management style.  Were I a manager,B > with my ass on the line, to say nothing of the whole business, ID > might prefer EMC.  On the other hand, there's that 50% premium you > pay. . . .  D I wonder how you are SURE EMC will respond on time? He is paying 50%C of someones budget ( not his I suspect ) for the fiction that it isl 'their problem'.  C If it was the biz and your arse on the line, and no excuses, if EMCwD screw or are late, *you* are out or pay the cost, would you feel the same?I  C Also to get good results, his answer requires the EMC peole to havea# very good knowledge of cluster IO. y     --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.-@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Sun, 18 Mar 2001 11:36:12 +0000e) From: Christof Brass <brass@infopuls.com> ( Subject: Re: OpenVMS Educational Program, Message-ID: <3AB49DAC.72D51247@infopuls.com>   Ben Sego wrote:h >  > Christof Brass wrote:d > <snip> >  > > Ben Sego wrote:bX > > > Unix is a good system, and has some excellent and elegant features.  Blind bigotryV > > > won't help your cause, and hating Unix won't make it go away.  But a lack of newT > > > applications will make VMS go away.  Currently, when a company has to choose aT > > > target environment for their new software, VMS isn't very high up on the list.W > > > This is a business reality, and all the praise in the world for the purity of VMSdW > > > won't change it.  Making it cheaper and easier to get applications onto VMS mightIV > > > change it.  Compaq's expanded license scheme will help; so would COE compliance.Q > > > COE won't kill VMS, but a lack of new applications might well do the trick.d > >j > > UNIX is a crap system. > ) > Got it.  You needn't belabor the point.S   Too late ... (see below) ;-)  -- > > Because of this in the first place VMS is:< > > there. Making VMS UNIX like is definitely the wrong way. >  > Uh...Got it.  @ This is independently of the quality of UNIX - I'll come to that later.   > > Having UNIX crap apps- > G > ...Uh...Still got it.  (That "Unix is crap" is your opinion, I mean.),  > Not only mine - unfortunateley all the offered profs and tests haven't been accepted.  L > > there is of no help as this definitely won't attract any non-VMS people. > Y > First off, I believe you're wrong.  Having more software available for a platform makes Y > the platform more versatile.  Which means it can serve more functions.  Which means theaV > overall cost to the company is lower.  And CIO's, CTO's, CFO's, and CEO's definitely > care about that.  @ 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. Despite@ its higher entry level costs it has a lower TCO in the mid-term.@ Having UNIX crap app there won't supply any of its strengths and@ 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 CEOsa9 behaving rational, economical or reasonable. In fact they 7 aren't. That's why crap-crap so-called-OSs from a BASICi; programmer shop called Micro$oft (IIRC) are haevily in use.E Don't count on your managers!   V > Secondly, it isn't simply an issue of whether more non-VMS people will be attracted.U > What would be nice is if there were some reason for shops that are running multiplerX > 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 the? thread) this won't help as these quickshot ported UNIX crap appe2 won't fulfill what they had to to be of any value.  ( > > The problem of the COE/"UNIX on VMS"? > > advocates is that they don't understand that their proposal C > > doesn't help. Competition can only be won with unique features.s > S > "Unique features" hasn't been enough to keep the VMS share from dropping.  If the Y > "unique features" are widely desired, other environments will have them eventually.  If X > only a niche group wants them, then if the niche can afford to pay the price, VMS will > continue.-  @ Well agreed. But it's common knowledge (at least within this NG)= that VMS suffered from severe damage. If the money VMS earnedh: for the companies who owned it had spent appropriately for< research, development and marketing (let alone the Micro$oft? contract which should have guaranteed to have crap-crap WNT ando@ crap-crap office apps on Alpha - though this isn't a cov related> topic unfortunately; we see that it's not easy to negotiate if6 your position is weak because of you current financial9 situation) I'm personally sure that market share would bem> different (much bigger). Anyway I can't prove this and this is9 history. The point stays that without sound analysis youre; 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 byO? Micro$oft and Intel? Are there any means to do anything againstE that?G  D > > Turning VMS to another UNIX especially destroys this uniqueness. > X > COE compliance doesn't even come close to "turning VMS to another Unix."  And having aV > layer of compatibility calls available in no way chips away at the strengths of VMS.  = I only agree in parts. Having a layer will not compromise theo< kernel. What we know from the NG contributions it's probably: done in the kernel what will compromise the kernel wrt two: dimensions: cleanlyness of design and unecessary increased: complexity. In any case it eats up engineering power which? should have been spent on other features. Additionally offeringn7 the simplistic UNIX approach on VMS will make life moreg< complicated as there are then different (and from the design6 perspective incompatible) ways of accomplishing tasks.  7 Am I wrong that the changed behaviour of the having thee@ directory modification date set if the directory file expands or7 shrinks beyound a block limit (to put it simple: if theo? directory file needs more or less space on disk) and having the = permission to delete a file if the permission to write to thel< directory is granted which obviously can compromise existing@ security schemes and definitely changes the genuin VMS behaviour; is one of the first bad consequences of this crap COE niched market initiative?  = I'm personally sure that the outcome of this COE towards UNIXr> development will be lower technical quality for VMS, a loss in= market share overall (we add the DoD gain if there is any andh4 reduce the loss in other market areas) and a lowered attractivity for novices.   < > > If VMS can't survive with its own strengths this clearly& > > indicates that the market is gone. >  > Well, it's certainly leaving.  >  > > Lowering the design qualitye > > by introducing UNIX crap >  > (need I say it...)  @ One main reason that I insist on the UNIX crap paradigm (and the@ UNIX crap app paradigm) is that it's true from many perspectives; (not only my own) and it's crucial for my argumentation. Ifi< Navigator on UNIX (let alone on VMS) were a good program one@ important obstacle of thinking about UNIX app's quality wouldn't	 be there.t  ' > > and complicating things on VMS willa- > > destroy one of the few advantages of VMS.  > >a > Y > Adding a set of compatibility calls needn't harm the underlying design. I doubt there's W > anything in the COE that requires underlying changes.  On the issue of "complicating"HU > VMS...uh...VMS is complex.  Despite that, it still has significant advantages.  ButEL > don't kid yourself.  It's simple to you, because you know it.  (I could beZ > misunderstanding you here.  If you mean it's simple from the perspective of it's design, > you have a better point.)a  ? As pointed out the COE/DoD/UNIX crap will probably added to theR> kernel. Other behaviouravely changes and bad consequences have been mentioned to disprove you.7- VMS is complex, both the API and the DCL CLI. < But the API and DCL CLI are designed and regular. UNIX shell@ command language is broken and the names and options of the UNIX@ system programs are irregular. The behaviour of UNIX wrt its own? principles is inconsistent e.g. wrt pipeing. The "concepts" areN not thought through thoroughly.o   > > > <snip> > > >oU > > > > > That's an interesting point, and I see why you're worried about the type ofcS > > > > > users it will attract -- after all, there's a slim chance that if they're U > > > > > all unix people, compaq would be tempted to make VMS itself more unix-like.-0 > > > > > (Correct me if this isn't the problem) > > > >o? > > > > We don't need the masses to destroy the quality of VMS.j > > >:V > > > Cool.  If everyone holds onto that attitude, then you'll get to enjoy the purityU > > > of VMS all alone.  While I understand that holds appeal, it doesn't do much forlN > > > the corporate types who decide where to spend their development dollars. > >oA > > There are others who also don't like a spoiled VMS. There ared@ > > other ways to attract business managers to VMS than to offer& > > unrealiable UNIX crap apps on VMS. > >< > 8 > Let me see...so, are you saying that Unix is crap? :-)  @ Not only ;-) It has been clamed that offering close to UNIX like; APIs will make it simpler to port apps from UNIX to VMS. No@? doubt it will. The problem is that these apps will be even morea> 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 lesse? obvious because the API resembles VMS to be UNIX like (which inz fact isn't the case). ; These quickshot ported apps won't take advantage of the VMS ? features and will therefore be a poor replacement of their UNIXL@ counterparts/siblings. The business cases are rare which make it> attractive to run these apps on VMS instead of running them on UNIX.s: Furthermore having this new API there will tempt to change? existing VMS apps to be more UNIXish and will make it easier to ? port them to UNIX which can end up in having even less real VMS 
 apps left.  U > Seriously, though, I'm sure there are other ways.  But just because there are otherI9 > ways, does that mean that this one should be abandoned?d  < If this were the only reason you would be right. In fact the= situation is more complicated. This way is harmful and shouldn< have been taken only if there weren't any other way. Because= there are other and by far better ways to follow this way wasa? the wrong decision wrt different perspectives: economically andh technically.  T > > > > > On the other hand, it's my belief that most people who use computers don'tS > > > > > care what software they're running.  They care that they can use it to doW > > > > > XYZ, > > >h > > > <snip>T > > > The users might not care, but the people who control the budget do.  Right nowR > > > internal IT shops at nearly all companies have to pay for support of WindowsS > > > machines; some companies buy support for Unix (or Linux); fewer still buy IBMsU > > > mainframe support.  Clearly, some pay for VMS support.  (When I say "pay for" IvX > > > mean they employ people to administer the systems.)  Any time they can cut out oneU > > > of the architectures, their infrastructure support costs go down.  Right now iteW > > > seems it's the VMS boxes that are being kicked to the curb.  That's a tough trendsT > > > to turn around, but it will likely have to start with people getting more (andW > > > more modern) software to run on VMS.  Anything that furthers that goal would seemu+ > > > to be desirable to the VMS community., > > >u > > > Ben Sego > >l> > > This is another example how badly this kind of analysis is- > > performed. VMS has by far the lowest TCO., > B > That's simply not true in every case, if it's true in any cases.  < If it weren't true what is true? What are the VMS' strengths then?s   > > The consequence wouldmB > > be to cut down the other OS areas and to increase the VMS area5 > > to reduce costs and keep the standard of service.h > W > Yes, and to do that, the apps currently running on the other OS's need to be replacedaW > with something that will run on VMS.  COE compliance will help with that by making itfS > easier, faster, and cheaper to re-target the apps to VMS.  The apps, will not, ofhT > course, take full advantage of VMS.  Still, they will be on a common system with aV > common backup procedure and a common set of administrators.  That is a cost savings.  < I have to agree partially. The problem I see that these apps7 won't behave like real VMS apps from the perspective of-? sysadmins. I remember having to support a real crap (no I don't @ know if it came from UNIX so I leave "UNIX" out here) app on VMS= which was written in DSM (Digital Standard MUMPS or something : like this). MUMPS was available on AIX and some other UNIX9 platforms. The VMS port was a pain in the arse and proper * resource management was nearly impossible.   > > Wrt apps? > > availablity is only one chance: to write real VMS apps that ; > > fully take advantage of VMS and fulfill the VMS quality9 > > standards. > Z > Well, if it's the only way, then you better get on with it.  I'm currently de-installingW > two VMS systems because the businesses can no longer afford to keep them running, andoQ > they decided the only reasonable way to upgrade was to kick out the VMS system.c  = Really interesting case. To understand and comment on that wey@ 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.o  X > In one case, (in an agency of the state of New Jersey) there are 0 VMS people in theirV > IT services shop.  How does a VMS system run without a system manager or at least anV > operator?  Not well.  The system is used to run only a single application.  (It's anW > important application, mind you.)  Digital helped develop the app about 10 years ago.IT > The State sought a way to upgrade the capacity of the system, and to get some moreV > modern features in the software.  Staying with VMS was cost prohibitive.  While theyO > could have bought new hardware, they would have needed consultants (or CompaqsZ > professional services) to move the app from the VAX to the new gear.  And the underlyingW > license cost of all the pieces was much higher in VMS than on Unix.  And they already U > were having trouble finding VMS managers and operators.  And they wanted to be ablem- > to run some other apps on the new hardware.C > V > This New Jersey agency decided to go with a system that runs on Unix.  (I don't evenY > know which flavor of Unix, since the app runs anywhere.)  They hired my company to moves > the data.w > W > If VMS is to survive, and especially if it is to grow, there need to be fewer stories  > like this. > 
 > Ben Sego  4 Agreed. But in this case - sorry to state that - the< availability of UNIX (I leave out "crap" here) apps wouldn't@ have helped because without VMS managers this wouldn't have been> a success. And honestly what you told is unfair to VMS because; they put more constaints on the VMS system than before. Youe? wrote that before it was a dedicated system and later it shouldI: 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.  @ I'm sure that the VMS way is more economical because of its best; TCO resulting from administration power and simplicity, andn- system reliability which results in unrivaledu; uptime/availability/speed compared to UNIX and WNT. If thise> 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 thatI9 attended a "Micro$oft we're conquering the business area"e7 seminar or because Compaq has decided milking their VMSy( customers to death I fight against that.   ------------------------------    Date: 18 Mar 2001 20:07:25 +0800, From: Paul Repacholi <prep@prep.synonet.com>  Subject: Re: RMS and file types.0 Message-ID: <87vgp78ema.fsf_-_@prep.synonet.com>  ) "Bill Todd" <billtodd@foo.mv.com> writes:)  C > That's a good explanation of what I remember, but, though I spent C > quite a bit of time working with the VMS developers trying to getoD > streams of various types to work 'right', I never knew exactly howE > everything turned out.  Did the VMS implementation wind up strayingw* > from what we did on RSX, and if so, how?   Two places, woops, 3 places.  ; RSX treated the record length as a 16 bit unsigned with the = majik-happens reserved value of 177777 as 'go to next block', E VMS/ODS-2 defines it as a signed value. ( Makes you wonder what a -42- byte record means... )  > VFC record with no Carriage Control used the control word as a@ sequence number. This was used by several utilities for patchingA etc. Tops-10 had the same sort of facillity, but used bit 35=1 to 5 indicate it was a sequence number, not 5 7 bit bytes.o  C Undefined records type. All sorts of things on RSX where UDF recordeF type, .OBJs and .TSKs come to mind, but don't quote me. VMS set all of@ these as 512 byte records, and does not use the UDF type at all.  C The first was a non-event for RSX, I never saw a >32K record from at7 RSX system. Given the 64K address limit, not a suprise!u  E Sequence numbered files, likewise are a pretty small odd corner case,h( but I have been bitten by that long ago.  E The UDF -> 512 fixed has had practical impact I think. One is gettingiD a 'not-defined' file as 512 fixed, and it has embedded CC chars. TheE new free record boundaries give you extranious line breaks. I used tolD have a TECO macro to re-mung these. I also suspect this is tied into( the 'user buffer exceded' error message.  D As a late thought. Tops used to define an end of line as a 'verticalD format effector'. IE Vertical Tab, Form Feed, Line Feed, and perhaps< some of the 'End...' codes. I wonder if STM records do this?. That is <stuff...VT> rather than <stuff...CR>.  C ( I'm doing a Tops-10 install right now, in case you wondered wherer that came from. ;) )   -- ,< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------   End of INFO-VAX 2001.154 ************************