1 INFO-VAX	Wed, 31 May 2000	Volume 2000 : Issue 302       Contents:I Re: Absolute fastest way to get a 100% correct record count for RMSfiles?  Re: Capellas supports Microsoft  Re: CCagent. Re: Comments on ABS v3.0 Re: Compaq BASIC, Re: Compaq not as bad as Andrew says (wish?) DECserver 90L+ Problem Re: DECserver 90L+ Problem Re: DECserver 90L+ Problem Re: Efficient Sleep function Re: ES40 Configuration Re: ES40 Configuration Re: ES40 Configuration Re: ES40 Configuration FTP problem  Re: FTP Server Logs. Re: General discussion comment Re: General discussion comment Re: General discussion commentF Hoff or Andy G., Please! Re: VAX VMS 7.2 Bug? ; backup/image/(no)aliasJ Re: Hoff or Andy G., Please! Re: VAX VMS 7.2 Bug? ; backup/image/(no)aliasJ Re: Hoff or Andy G., Please! Re: VAX VMS 7.2 Bug? ; backup/image/(no)alias" HSZ80 - was Re: ES40 Configuration looking for blast.com  Re: looking for blast.com  Migrating from VMS to AIX  Re: Migrating from VMS to AIX  Re: Migrating from VMS to AIX  Re: Migrating from VMS to AIX  Re: Migrating from VMS to AIX 
 MOZILLA M16 ?  Re: MOZILLA M16 ?  Re: MOZILLA M16 ? * Re: OpenVMS vs Tru64 Pathworks performance& Re: Prob w/DCPS 1.7,HP4050, and HPGL/25 Re: problem linking to ucx$ipc.olb on AXP/VMX71-UCX40  Re: Problem with resource locks # Remote Print From Vax/VMS to AS/400 : Some recent postings on the SKC Corner of www.acersoft.com, Re: ver 7.1 Openvms will run on the new Ds20 Re: VMS what's VMS Re: VMS what's VMS$ Re: Which is the language of VAX/VMS RE: Wildfire Announcement  RE: Wildfire Announcement  RE: Wildfire Announcement  Re: Wildfire Announcement " Yet more ignoring of VMS by Compaq& Re: Yet more ignoring of VMS by Compaq Re: [DOCUMENTATION]: Help me ?& RE: [humor] UNIX/OpenVMS email "virus"& Re: [humor] UNIX/OpenVMS email "virus"  F ----------------------------------------------------------------------  % Date: Tue, 30 May 2000 13:39:21 -0400 * From: David A Froble <davef@tsoft-inc.com>R Subject: Re: Absolute fastest way to get a 100% correct record count for RMSfiles?- Message-ID: <3933FCC9.F1660276@tsoft-inc.com>    Jan Vorbrueggen wrote: > . > David A Froble <davef@tsoft-inc.com> writes: > P > > Actually, I'm not sure what happens with an indexed file when the bucket and > > buffer differ. > M > That can't happen 8-) - by definition, a buffer fro non-sequential files is N > the same size as a bucket. For sequential file, there's also the multi-block* > count (IIRC) which sets the buffer size. > 
 >         Jan   L Gotta confess, I don't understand.  If left in the default state, RMS bufferP sizes (the RMS system multi-block count) are 16 blocks.  Are you saying that forP an indexed file, the buffer(s) allocated when the file is opened are the size ofN the buckets for the file?  Actually, that makes sense.  I can't see any way itJ would be anything other than some multiple (including 1) of this size, but$ didn't want to deny the possibility.   Thanks for the insight.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  # Date: Tue, 30 May 2000 20:36:17 GMT 0 From: "Terry C. Shannon" <shannon@world.std.com>( Subject: Re: Capellas supports Microsoft& Message-ID: <FvE3tu.5K2@world.std.com>  - <steven.reece@quintiles.com> wrote in message 8 news:802568EB.0054181F.00@qedilc01.qedi.quintiles.com... >  >  > Terry Shannon wrote:K > >>>Yeah, maybe. But Capellas can run a spreadsheet just as well as anyone  else. A > Gawd knows that the margins don't come from consumer PCs or the  still-losing2 > (albeit not for much longer) commercial PC unit. > . > NSK, OVMS, and Tru64 deliver the margins.<<< > > > So if it's "not for much longer", does this mean that CompaqJ > - are going to sell the PC division to someone (like Dell or IBM - let's say IBM $ > cos their machines are too pricey)  ; Not bloody likely. In fact I have heard quite the opposite.    ------------------------------  % Date: Tue, 30 May 2000 20:17:57 +0200 2 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: CCagent. ; Message-ID: <393405d5.524144494f47414741@radiogaga.harz.de>   # Elmar Dam (elmar@casema.net) wrote: 2 : In UCX ive got a dervice running called CCagent,- : but i have no idea what this does, anybody?  : its runnning on port 4997   G It's a StorageWorks Agent, to be connected to by a (NT) client program.    cu,    Martin --D                        |  Martin Vorlaender  |  VMS & WNT programmer1   OpenVMS: When you    |  work: mv@pdv-systeme.de H   KNOW where you want  |        http://www.pdv-systeme.de/users/martinv/8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  # Date: Tue, 30 May 2000 21:56:51 GMT  From: itjck01@my-deja.com ! Subject: Re: Comments on ABS v3.0 ) Message-ID: <8h1der$vn6$1@nnrp1.deja.com>   8 In article <8gm3kv$71u$1@fizban.fizban.pprd.abbott.com>,4   "Dave Gudewicz" <david.gudewicz@abbott.com> wrote:@ > We've been trying for a few months now to get ABS v3.0a to run > reliably.  > E > Policy engine failures, media off-line and several other items seem  > to be preventing this. > ; > Support has been involved all along.  Still no solutions.  > ( > We heard there's a 3.0b out there now. > D > Anyone here using - or put another way - trying to use this stuff? > 	 > Dave...  >  >   1 ABS 3.0b is on the June 2000 Cosolidated CD-DIST.   H We hired Compaq to come in and install and configure about 2 months ago.  G Comparing to our current backup software (ISE Media/BCKMGR/SCHEDULE) we D have fould ABS to be very much less integrated.  I have had to writeF DCL script to use the Media Robot Utility software to inject and ejectC tapes to our TL896, and then follow up with Media Device Management G System commands to keep it in sync with what we did in MRU.  We use MRU F so we do not have to open up TL896 door, but rather use injection port and ejection port.  G We had some code beyond 3.0b put in to allow us to do media compression B with our tape drives, and this has worked out well allowing better throughput to tape.   G To date, and this is only about a month into it, ABS 3.0b (yeah, we got @ 3.0b ahead of CD distribution) has done ok.  I have not seen theB problems the others have posted, but then again I am not using ABS# completely yet nor for a long time.   E I expect to do benchmark on tape backup performance in a few days.  I - will try to post, once I have done benchmark.    :) jck   --$ Free personal opinion is what I post    & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  # Date: Wed, 31 May 2000 00:17:27 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com> Subject: Re: Compaq BASIC 1 Message-ID: <rSYY4.3$ru5.230@typhoon.aracnet.com>   ( Neil Rieck <n.rieck@sympatico.ca> wrote:F > If you use either VAX-BASIC or DEC-BASIC (Alpha), both the "LanguageB > Reference Manual" as well as the "User Manual" are now online atB > http://www.openvms.digital.com/commercial/basic/basic_index.html  G COOL!  Nice to have these on line, though it would be nicer if they had - links to them from the documenation web page.   G Hmmm.... Hey!  A quick check of the C page shows they've got the latest  manuals online there also!8 http://www.openvms.digital.com/commercial/c/c_index.html/ Unfortunatly again no link form the Doc's page.    			Zane    ------------------------------  % Date: Tue, 30 May 2000 21:04:14 -0500 * From: Keith Brown <kbrown780@usfamily.net>5 Subject: Re: Compaq not as bad as Andrew says (wish?) , Message-ID: <3934731E.176D4688@usfamily.net>   David Mathog wrote:  > T > In article <8gs3ga$jbg$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > > J > >And of course that last dovetails neatly with your own observation thatM > >people seldom bother with much performance optimization:  for such typical N > >non-performance-optimized applications, Unix therefore makes more efficientJ > >use of the hardware than VMS does, hence is correctly perceived as more > >cost-effective. > F > Exactly.  And it all boils down to (essentially) a SINGLE differenceL > between the OS's.   On a typical lightly loaded, memory rich, workstation,B > Linux (and probably most other Unices, but I can't say for sure)C > automatically utilize the unused portions of memory to cache file H > operations.  This results in huge increases in write performance and aL > substantial increase in read performance in a typical workstation job mix,L > which consists of a lot of small files being written, read, and then oftenK > deleted.  Only when file sizes reach up into the hundreds of megabytes or L > the system becomes heavily loaded do the returns for this automatic systemI > break down. At that point RMS tuning on OpenVMS can outperform the Unix H > workstations.  However, in the normal mix of things for lightly loadedK > machines, the "out of the box" Unix configurations do "disk I/O" about an E > order of magnitude faster than VMS does.   That's in quotes because I > oftentimes the data never hits the disk. You can tune VMS processes and K > programs to give better performance, but on the lightly loaded systems at I > best you can get really close on the read speeds and you can never come K > anywhere close on the write speeds (defining write as "program wrote data I > to 'disk' successfully, without worrying about if the data ever hit the G > physical disk).  And you had to work at it.  Whereas on Linux it just ? > happened automatically.  Consequently, something as simple as  >  > % tar xf whatever.tar  > % cd whatever  > % make > H > runs blindingly fast on Unix, and crawls on VMS.  And here I'm talkingH > about two nearly identical DS10s, one running RedHat 6.2 and the otherK > OpenVMS 7.2-1.  (It doesn't help that the Elsa graphics card and DECterms K > don't scroll very quickly - sometimes you're just waiting for the text to  > scroll through.) > L > Typically in these "lightly loaded" environments, the safety of having theM > data hit the disk is of little importance.  So VMS really is slow and Linux H > (Unix) is fast for typical programmer/technical workstation workloads.M > And Linux gets this boost without anybody having to twiddle RMS parameters, K > which is a good thing, because, well, WHY NOT make good use of the unused B > memory in a system?  Lord knows you pay enough for it on a DS10! > 
 > Regards, >  > David Mathog > mathog@seqaxp.bio.caltech.edu @ > Manager, sequence analysis facility, biology division, CaltechL > **************************************************************************L > *                                RIP VMS                                 *L > **************************************************************************  > I was going to respond sooner but Linux crashed and I was busy doing an fschk. > Seriously, this is the trade off. You can argue that Unix uses< the better default config and it may be appropriate for your= environment but again it may not be for others. At my site we < tend to run bigger (than Workstations) OpenVMS machines that? have HSxxx controllers that do the writeback caching and we use : them on the 3 DU boxes too BTW, but write performance does? become a non-issue with the HSxxx controllers.  I know, I know, > Bill Todd already railed me for suggesting a hardware solution< but we felt that the HSxxx's were a better solution to serve? external disks than a SWXR or some such thing like that. As you > pointed out earlier David, you can get a significant I/O boost= by tweeking RMS and even you pointed out that it was a 1 line @ tweek. I think even NT people could manage that. I don't mean to> be blunt but my point is that nothing is perfect all the time.     --   Keith Brown  kbrown780@usfamily.net   ------------------------------  # Date: Tue, 30 May 2000 18:20:30 GMT 3 From: Eric Dittman <dittman@narnia.int.dittman.net>  Subject: DECserver 90L+ Problem > Message-ID: <ODTY4.12542$v7.902607@news-west.usenetserver.com>  6 I've got a DS90L+ that I'm trying to connect to remote5 devices.  I've set the name to TS90 in the DS90L+ and 7 created a LAT terminal pointing to PORT_8 (which is the 3 name of port 8).  The system (OpenVMS Alpha V7.2-1) 4 can't find the DS90L+ so the LAT terminal never gets8 created.  I can SET HOST/MOP TS90 and connect.  Is there8 something else that must be done?  I've also got a DS7005 that I am able to create LAT terminals on, so I'm not * sure what I'm doing wrong with the DS90L+. --   Eric Dittman dittman@dittman.net    ------------------------------    Date: 30 May 2000 23:55:21 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)# Subject: Re: DECserver 90L+ Problem * Message-ID: <393438c9$1@news.kapsch.co.at>  t In article <ODTY4.12542$v7.902607@news-west.usenetserver.com>, Eric Dittman <dittman@narnia.int.dittman.net> writes:7 >I've got a DS90L+ that I'm trying to connect to remote 6 >devices.  I've set the name to TS90 in the DS90L+ and8 >created a LAT terminal pointing to PORT_8 (which is the4 >name of port 8).  The system (OpenVMS Alpha V7.2-1)5 >can't find the DS90L+ so the LAT terminal never gets 9 >created.  I can SET HOST/MOP TS90 and connect.  Is there 9 >something else that must be done?  I've also got a DS700 6 >that I am able to create LAT terminals on, so I'm not+ >sure what I'm doing wrong with the DS90L+.   I MOP is not LAT. If you can reach the DS90L with MOP doesn't mean LAT will  be working.   ? Where did you enter the name of the DS90L ? In the MOP(=DECnet) 7 	database on VMS or additionally in the DS90L+ server ? E Did you configure the server name in the permanent _and_ the volatile > 	database of the DS90 ? In other words did you reboot the DS90 	after the configuration ?1 Do you have LAT enabled on your VMS host system ? * 	What does $ MC LATCP SHOW CHAR show you ?. 	What does $ MC LATCP SHOW SERVICES show you ?N Is LAT a protocol you network still transmits (not filtered in the switches) ?  J Why do you think, a LAT port can't be created to a non-responding server ?> 	It can be created (eg. during boot time) but it can't be used@ 	without a connection to the destination, then (which may happen3 	many times during the uptime of the VMS system) !!    --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------  # Date: Wed, 31 May 2000 02:07:10 GMT 3 From: Eric Dittman <dittman@narnia.int.dittman.net> # Subject: Re: DECserver 90L+ Problem ? Message-ID: <it_Y4.15298$v7.1041339@news-west.usenetserver.com>   + Peter LANGSTOEGER <eplan@kapsch.net> wrote: v : In article <ODTY4.12542$v7.902607@news-west.usenetserver.com>, Eric Dittman <dittman@narnia.int.dittman.net> writes:8 :>I've got a DS90L+ that I'm trying to connect to remote7 :>devices.  I've set the name to TS90 in the DS90L+ and 9 :>created a LAT terminal pointing to PORT_8 (which is the 5 :>name of port 8).  The system (OpenVMS Alpha V7.2-1) 6 :>can't find the DS90L+ so the LAT terminal never gets: :>created.  I can SET HOST/MOP TS90 and connect.  Is there: :>something else that must be done?  I've also got a DS7007 :>that I am able to create LAT terminals on, so I'm not , :>sure what I'm doing wrong with the DS90L+.  K : MOP is not LAT. If you can reach the DS90L with MOP doesn't mean LAT will 
 : be working.   = I know that MOP is not LAT.  I mentioned that I could connect ; via MOP because if I didn't someone would ask if I'd tested % whether it had Ethernet connectivity.   A : Where did you enter the name of the DS90L ? In the MOP(=DECnet) 9 : 	database on VMS or additionally in the DS90L+ server ?   5 I put the name in the MOP database and in the DS90L+.   G : Did you configure the server name in the permanent _and_ the volatile @ : 	database of the DS90 ? In other words did you reboot the DS90 : 	after the configuration ?   Yes.  3 : Do you have LAT enabled on your VMS host system ?:, : 	What does $ MC LATCP SHOW CHAR show you ?0 : 	What does $ MC LATCP SHOW SERVICES show you ?  A Yes LAT works.  If I use a terminal connected to the DS90L+ I canS connect to the VMS system.  P : Is LAT a protocol you network still transmits (not filtered in the switches) ?   Yes (see above).  L : Why do you think, a LAT port can't be created to a non-responding server ?@ : 	It can be created (eg. during boot time) but it can't be usedB : 	without a connection to the destination, then (which may happen5 : 	many times during the uptime of the VMS system) !!G  E I create the port and set the port, but a mcr latcp show port LTAxxx:yD shows the target port and node name as specified but the actual port@ and node name are blank.  The local port state is also inactive. --   Eric Dittman dittman@dittman.netn   ------------------------------  % Date: Tue, 30 May 2000 14:55:00 -0400e" From: Dan Sugalski <dan@sidhe.org>% Subject: Re: Efficient Sleep function 8 Message-ID: <4.3.1.0.20000530145043.0217c760@24.8.96.48>  6 At 05:24 PM 5/30/00 +0000, bbrzwski@my-deja.com wrote:; >We have been having difficulty coming up with an efficient G >Sleep(TimeInMs) function that is accurate to within 1ms. The followingrD >is the code we are using and our timing results.  It appears we areG >incurring an overhead of 1ms for every function call but is not due tomH >the actual call on the stack since we ran the sleep in a loop with timeF >to sleep of 0 and received a timing of 30ms for 1000 sleeps.  We have= >tried several different Sleep routines, but we come out withc  >approximately the same timings.  J Well, have you checked your math in the time slept calculations to see if J maybe you're not doing something silly like rounding wrong? Sleeping 10.1 / ms might show as 11 if you do that incorrectly.-  G Also, just because you got woken doesn't mean your program is actually rI running. If some other process with the same priority's running it won't  I get interrupted just because your process got an AST. Sleeps are usually 6K minimum times, not guaranteed times. If you absolutely *must* get woken up sK ASAP, jack the priority of your process a bit. Not a guarantee, mind (in a eL non-realtime system there are no time guarantees), but it'll be closer. You K can also make the QUANTUM sysgen parameter smaller. This means things task bG switch more often, which increases responsiveness at the cost of extra wD overhead in the task switch code. (Since you'll be in it more often)   					Dan  I --------------------------------------"it's like this"-------------------c2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and evene;                                       teddy bears get drunk    ------------------------------  % Date: Tue, 30 May 2000 17:13:37 -0400(* From: David A Froble <davef@tsoft-inc.com> Subject: Re: ES40 Configurations- Message-ID: <39342F01.8C2483DF@tsoft-inc.com>e   Stanley Hippler wrote: > G > Thanks to all those who replied.  My interpretation of the replies ismI > that 1) the 9 gig drives should be replaced with the 18 gig (at least), D > 2) dual HSZ80s is probably a good thing, and 3) I need to ask more/ > questions as to the setup of the system disk.. > F > What I Plan to Do:  as many physical disk drives as possible will beG > put in a single Raid5 set, with this set being broken up into variousEG > logical drives as needed by the applications.  This would spread datatF > access across as many physical spindles as possible and minimize theF > storage loss due to Raid5.  A hot spare would be configured as well.G > As to the number of physical drives in a Raid5 set,  I have not hearduE > that there was a point of diminishing return, so if there is one, ItH > want to know!   The sales rep has suggested that we use a 9 gig systemG > disk using the ES40's "onboard" SCSI controller.  Dual disks would behG > supplied, so shadowing would be possible.  I would prefer to keep theuF > system disk as part of the raid configuration, and not have internalC > disks at all.  I am interested in knowing what others use for then1 > system disk, given similiar i/o configurations.. > F > To answer some other questions:  this is a single ES40 with dual 677I > mhz processors; a DS-TZ89N-VW DLT drive will be used for backup; expectaJ > approximately 400 concurrent telnet sessions to SCT's Plus2000 software. > - > Thanks again.  All replies are appreciated.r  L Before you decide what type of RAID configuration to use, be sure to ask theK question "what do I want to do, and why am I considering RAID?"  Every RAIDwI configuration is a set of trade-offs.  There is no perfect solution.  ForoP example, if you have all your data disks in one set, you cannot easily segregateP data by device.  Not saying you would want to do this, but I have seen instances  where this was desired/required.  O Now, as for your system disk.  You did ask for opinions, and I have some strongtN ones in this area.  Your system disk should be used for VMS, swapping, paging,P possibly some static storage if there's room, and nothing else. This disk shouldL not be part of any RAID configuration.  This disk should be easily backed upL while running, with no possibility of impacting application data, and littleM impact on the data on the system disk.  You might ask what's so special aboutwN the system disk.  Unless running off the CD, you need a VMS system disk beforeN you can do anything else on your system.  It's important to be able to restoreM just the system, should the need arise, and then do whatever you have to with/L the applications and such.  Remember, you may not be restoring onto the sameK system, and you may not have all your regular options available should somedN hardship occur.  You want to be able to get back your minimal system as easilyL and generically as possible.  Why?  I don't know, and neither do you.  If weN knew all possibilities, we could prepare for them.  Since we don't, we prepareL to be as flexible as possible.  Now to violate the "nothing else".  What youL should keep on the system disk are any utilities, tools, and such that wouldM prove useful should you have to re-construct much of your system.  And alwaysaI with the thought that your old system is smashed, under water, burned up,eO whatever, and that you are recovering on a completely different configuration. yN Possibly on a spare disk on someone else's system.  Possibilities are endless, be as flexible as possible.t  O I usually have used 1 GB or 2 GB system disks.  These are becoming unavailable, L and using the 9GB as a system disk probably will give you more performance. O Just don't let anyone start to covet all the free storage on your system disk. HM The extra space can come in handy when re-configuring your swap and/or pagingYF file(s), allowing contiguous or near contiguous files to be allocated.   Dave   -- u4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.come Vanderbilt, PA  15486.   ------------------------------  % Date: Tue, 30 May 2000 18:11:25 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net>e Subject: Re: ES40 Configurationk7 Message-ID: <0d9501bfca8c$626ebd40$020a0a0a@xile.realm>l  1 Stanley Hippler <shippler@my-deja.company> wrote:c  < > Thanks to all those who replied.  My interpretation of the> > replies is  that 1) the 9 gig drives should be replaced with: > the 18 gig (at least), 2) dual HSZ80s is probably a good< > thing, and 3) I need to ask more questions as to the setup > of the system disk.D >3F > What I Plan to Do:  as many physical disk drives as possible will beG > put in a single Raid5 set, with this set being broken up into various G > logical drives as needed by the applications.  This would spread dataoF > access across as many physical spindles as possible and minimize the > storage loss due to Raid5.  L Raid 5 can not tolerate losing more than 1 disk.  On a multiple channel raid@ controller I would recommend not more than one disk per channel.  K Otherwise if a bad device jams a channel, you do not spend all of your time  restoring files.  J You can take more risks if you are using some method of mirroring the RAID  set on a different disk cabinet.    J You also need to examine your application.  If you have a couple of drivesK that have heavy access, making them logical drives carved out of a raid setoL will hurt you.  In this case you are better off with multiple raid or mirror sets.   8 > The sales rep has suggested that we use a 9 gig systemG > disk using the ES40's "onboard" SCSI controller.  Dual disks would beeG > supplied, so shadowing would be possible.  I would prefer to keep thetF > system disk as part of the raid configuration, and not have internalC > disks at all.  I am interested in knowing what others use for then1 > system disk, given similiar i/o configurations.   J As Dave Froble pointed out in his response, it is better to have a smallerI SYSTEM disk, just in case you need to restore it.  Unlike data disks, thee7 system disk needs to be backed up with an Image backup.   J Your considerations there have a lot to do with do you ever plan to expand5 your system by adding more systems in a SCSI cluster.d  H On your drive array, you can allocate a pair of drives for a mirror set,I leaving room next to them for your hot spares.  This way multiple systems  can share one installation.s  I A mirror set allows you to break the mirror, upgrade, test, and if neededd* quickly fall back to the previous release.  H > I can set up and run a cluster.  However, this is a single machine.  IA > would prefer a more simple I/O solution, without the clusteringi > management overhead.  J What clustering management overhead would be avoided with a single system?  K A single node with the cluster parameters activated behaves the same as onelK that does not have it.  Having the cluster software on the machine and some L pre-planning allows you to add on to it with out having those nasty reboots.  J But if you do not need a cluster, and the license is not bundled with your unit, why pay for it?p   -Johnr wb8tyw@qsl.network   ------------------------------  % Date: Tue, 30 May 2000 21:33:21 -0500w* From: Keith Brown <kbrown780@usfamily.net> Subject: Re: ES40 Configurationg, Message-ID: <393479F1.B1590C68@usfamily.net>   Stanley Hippler wrote: > G > Thanks to all those who replied.  My interpretation of the replies isaI > that 1) the 9 gig drives should be replaced with the 18 gig (at least),hD > 2) dual HSZ80s is probably a good thing, and 3) I need to ask more/ > questions as to the setup of the system disk.V > F > What I Plan to Do:  as many physical disk drives as possible will beG > put in a single Raid5 set, with this set being broken up into variousuG > logical drives as needed by the applications.  This would spread datatF > access across as many physical spindles as possible and minimize theF > storage loss due to Raid5.  A hot spare would be configured as well.G > As to the number of physical drives in a Raid5 set,  I have not heardiE > that there was a point of diminishing return, so if there is one, IsH > want to know!   The sales rep has suggested that we use a 9 gig systemG > disk using the ES40's "onboard" SCSI controller.  Dual disks would be G > supplied, so shadowing would be possible.  I would prefer to keep thesF > system disk as part of the raid configuration, and not have internalC > disks at all.  I am interested in knowing what others use for thes1 > system disk, given similiar i/o configurations.p > F > To answer some other questions:  this is a single ES40 with dual 677I > mhz processors; a DS-TZ89N-VW DLT drive will be used for backup; expectlJ > approximately 400 concurrent telnet sessions to SCT's Plus2000 software. > - > Thanks again.  All replies are appreciated.  >  > Stanley Hipplern > McNeese State University > + > In article <8glrmu$2i4$1@nnrp1.deja.com>,-1 >   Stanley Hippler <shippler@my-deja.com> wrote:oJ > > From our local sales rep, we requested an ES40 configuration; dual 667E > > processors, 4 gigabytes ram, roughly 200 gigabytes Raid-5 capablenJ > > disk.  The response included dual HSZ80 controllers, twenty-four 9 gig( > > disks to meet the disk requirements. > > H > > While this is skimpy information I am supplying, what I want to know > is:l/ > >     1) Is this really a one-node "cluster"?t> > >     2) Does this seem like a reasonable disk configurationC > >     3) Given the associated costs of using the HSZ80s, is thereeB > >        some other I/O configuration that should be considered? > > J > > I can set up and run a cluster.  However, this is a single machine.  IC > > would prefer a more simple I/O solution, without the clustering. > > management overhead. > >tH > > The main software applications will include SCT's Plus2000 packages,1 > > email for up to 8000 students, OSU webserver.  > >c. > > Any responses will be greatly appreciated. > >e > > Stanley Hipplero > > McNeese State University > >m* > > Sent via Deja.com http://www.deja.com/ > > Before you buy.  > >+ > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.S  E >What I Plan to Do:  as many physical disk drives as possible will be F >put in a single Raid5 set, with this set being broken up into variousF >logical drives as needed by the applications.  This would spread dataE >access across as many physical spindles as possible and minimize the  >storage loss due to Raid5.   = My personal opinion is that in a RAID 5 set no matter how you ? try to slice it you cannot guarantee on which spindle the filesr get placed.t  ? I used 18GB drives mirrored at the controller for system disks. > I wanted plenty of space for larger pagefiles if I need to add; more ram. You can put 16GB in an es40 so you may need a bigw? system disk. Some like to use host based shadowing and they mayp have some valid points.    -- t Keith Browne kbrown780@usfamily.net   ------------------------------  % Date: Tue, 30 May 2000 22:59:13 -0400 " From: Dan Sugalski <dan@sidhe.org> Subject: Re: ES40 Configurationo8 Message-ID: <4.3.1.0.20000530224655.00eb6c20@24.8.96.48>  - At 09:33 PM 5/30/00 -0500, Keith Brown wrote:) >Stanley Hippler wrote:NJ > > > The main software applications will include SCT's Plus2000 packages,3 > > > email for up to 8000 students, OSU webserver.S  K I missed the original post, but here's my experience from managing systems  @ running SCT's Banner product (which is layered on top of Oracle)  L 1) Keep your system disk *separate*. Mirror it. Stripe too, if you can. (Do B *not* RAID-5 it if you have much in the way of auditing turned on)  H 2) Keep the disk that holds the Oracle software (i.e. wherever ORA_ROOT H points) *separate*. Mirror it. Stripe it if you can. Do *not* RAID-5 it.  G 3) Wherever your page and swap files are should *not* be RAID-5 if you EJ think you'll actually use them much. You probably won't, but it's hard to 
 say for sure.m  L 4) Oracle's redo logs should be on their own mirrored disk if possible. The G Archive logs should be on their own mirrored disk if possible. *DO NOT  K RAID-% THE DRIVE WITH YOUR ORACLE ARCHIVE LOGS AND REDO LOGS!* Performance  F will *suck* unless you have the cache from hell on the HSx controlers.  L 5) RAID-5 is OK for the actual data files, though do your best to make sure A the tablespaces that get written to a lot (your main transaction oK tablespaces at least) are on non-RAIDed drives if you can. RAID-5 has good e; read performance, so the ones that get queried a lot are OKf  I 6) Twiddle with the MAX_CACHE parameter (or whatever it is) on the units  J that get configured on the HSx controllers. The default for my HSJ50s was J 32, which was small enough that most of the database and executable stuff I didn't cache well. Changing it from 32 on the Oracle software disk to 64 n8 took me from a cache read hit rate of about 47% to 99.8%  H 7) If the system's on a reliable UPS (and it is, *right*?), then enable J write-back caching on all the drives. You *will* see a win on drives that " are written to with any frequency.  G > >What I Plan to Do:  as many physical disk drives as possible will beAH > >put in a single Raid5 set, with this set being broken up into variousH > >logical drives as needed by the applications.  This would spread dataG > >access across as many physical spindles as possible and minimize theS > >storage loss due to Raid5.  > > >My personal opinion is that in a RAID 5 set no matter how you@ >try to slice it you cannot guarantee on which spindle the files >get placed.  K Well, that sort of is the point. With a file of any size, the file will be  I strewn across all the RAID spindles. For reads, this is generally a win.  K For writes too, as long as they're infrequent enough that the cache on the h( controllers drains faster than it fills.   					Dan  I --------------------------------------"it's like this"------------------- 2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even-;                                       teddy bears get drunka   ------------------------------  % Date: Wed, 31 May 2000 11:21:57 +120046 From: "Antony Wardle" <antony.wardle@nospam.met.co.nz> Subject: FTP problem1 Message-ID: <__XY4.4984$N4.187425@ozemail.com.au>u   Hi.i  A I am having a problem with ftp'ing out from an OpenVMS 7.1 systemt@ and ucx 4.2eco2. Does anyone know if there is an outgoing limit?  D It is quite hard to reproduce, but going to a few different sites weB can get it to stop working. Upgrading to 5.0a is on the plans, butH we first have to fix all the bugs that came out the last time we did it.    
 Cheers Antony0   ------------------------------   Date: 30 May 2000 20:51:49 GMT) From: leslie@clio.rice.edu (Jerry Leslie)i Subject: Re: FTP Server Logs.y' Message-ID: <8h19l5$dg1$1@joe.rice.edu>o  3 Martin Vorlaender (martin@RADIOGAGA.HARZ.DE) wrote:o4 : If you want to completely get rid of all of those: :d: : UCX> (or TCPIP>) SET SERVICE FTP /LOG_OPTIONS=(FILE=NL:)  J We tried this to suppress UCX$RSHD_STARTUP.LOG and UCX$REXECD_STARTUP.LOG K files, after first disabling the service, and reenabling it after the "SET  I SERVICE" command. But new LOG files were still created, after the change.o  ( Here's the relevant version information:     $ ucx show version  G    Digital TCP/IP Services for OpenVMS Alpha Version V4.1 - ECO Level 2 =    on a AlphaServer 8400 Model 5/625 running OpenVMS V7.1-1H1h  6 Is a restart of UCX required to implement the change ?   Thanks in advance,  4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Tue, 30 May 2000 14:37:38 -0400	' From: "Bill Todd" <billtodd@foo.mv.com>-' Subject: Re: General discussion comment ( Message-ID: <8h11jp$rus$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in messagey' news:39335FB3.ECABDED9@tsoft-inc.com...  > Bill Todd wrote: > > H > > I've been aware for a while now both in discussions here and privateG > > extensions of them that my wording has gotten, shall we say, rather4 bluntgK > > rather often with people with whom I actually enjoy interacting.  Sincer the J > > bluntness may be much more apparent than the appreciation, I'd like toI > > explain it - especially as it's not my preferred method of discourse.  > K > For you Bill, I have to find another word.  'Blunt' isn't quite adequate.n :-)t  5 It's all relative:  Cutler would call me a pussy cat.:   >mK > > By and large, comp.os.vms comprises a set of die-hards, people who havetJ > > stuck with VMS through thick and thin (more the latter for a long time now)G > > because they appreciate it.  Not only does this make them decidedlye partisanJ > > as individuals, voicing opinions often more strident than informed andK > > balanced when discussing the relative merits of other environments, butv itJ > > makes the environment self-reinforcing, since dissenting opinions tend to. > > get drowned out regardless of their merit. >t6 > You got a point.  However, it's not always that way.  I As I said, it's a tendency, not a universal truth.  But as someone on theoJ receiving end, I can assure you that it's very real even if not pervasive.  H It's also understandable, and I'm inclined to give people credit for notL being more partisan than they actually are:  they've long had good reason toF circle the wagons against perceived external threats of many differentI kinds, and instinctive reactions are often necessary to avoid the arrows.p   > J > > My normal inclination is to avoid such groups, since I don't much care whatG > > other people think if I've considered their opinions and found themp wanting.G > > The problem here is that I really *do* appreciate VMS, believe that  other K > > systems are by and large technically inferior, and would really like toT seeiL > > Compaq take the steps necessary to make VMS palatable (without sacrifice toK > > its existing strengths) to the world at large - and automatic fanaticaloJ > > opposition by current VMS customers to all things non-VMS seems likely toC > > make Compaq think twice before undertaking any such initiative.t >nJ > I believe you do appriciate VMS.  I've seen the honest effort.  However, we'vebI > seen that the 'Palmer Doctrine' appears to be dead and behind us.  I do  believerL > we both see positive and pragmatic actions starting.  I'll also admit that thewJ > last part of your grossly over-run sentence does have a valid point, but doesn'th > apply to everybody.h  J Again, I agree.  But the people it does apply to tend to be the more vocalK ones, at least in this venue.  And this seems to be a venue to which Compaqt pays at least some attention.o   >uL > > People here often do seem willing at least to contemplate new directionsL > > once they've gotten past their initial automatic responses, so I've come toL > > tend to phrase things in a manner that grabs their attention in a mannerD > > difficult just to slough off ("First, you have to get the mule'sD > > attention...").  Should the environment become more receptive to balanced= > > discussion of such input, I will happily revert to a lesse confrontationale
 > > approach.i > G > Having been nice, I'll now say that when you start stating opinion asn	 fact, and J > go on to build a case with such 'facts', the 2x4 up alongside the mule's head ise > a bit too much.y >  > Your statement:a >iH > Not to mention the related point that you need *more* expertise to get goodH > performance out of VMS than out of Unix, which gives most applications good# > performance right out of the box.s >sA > In my experience it DOES NOT require more expertise to get good  performance out H > of VMS.  You based your statement on some porting of Unix code to VMS, withoutaI > re-doing the I/O in a VMS manner.  Sort of like pounding the square pegn throughoF > the round hole.  You used a bad example, and then classified all VMS performance  > based upon that example. >n > Another example: >aJ > 'Good' is a subjective term, so let's just say that default, unoptimizedA > Unix file system performance is noticeably better than default,  unoptimizedIL > VMS file system performance for typical applications, mostly due to Unix'sB > default system caching (my vague recollection is that VMS can be
 configuredH > to read-cache at the disk level, though possibly only in non-clusteredG > environments, though that may no longer be a restriction, which helps0 some -G > though the path to such a cache is considerably longer than that to anG > file-level cache - but in any case doesn't cover write-back caching).t > J > You make the assumption that a VMS solution will use the same techniques as aH > Unix solution.  Yes, if I write Unix code for VMS, VMS will sometimes, probablyF > many times, be at a disadvantage.  But I would not do that.  I would
 design theL > application to use the strengths of VMS, and many times do better than the UnixH > system.  You tout the Unix caching of data, rather than go to disk for eachJ > read.  Yeah, not a bad thing.  But, to be cached, the data still must be readL > one time, and when done, any updates written back to disk.  There are manyG > methods in VMS to achieve the same result, and many times they can beeA > implemented in a manner that will allow VMS to provide the bests performance.K > I'll observe that caching data at the file system level doesn't allow anyeF > intellegence to be built into how the data is handled, and sometimes intellegenta@ > handling of the data can be faster than the file system cache.  H John Malmberg's very pertinent point is that most applications don't getI much optimization:  they just use the system defaults, whatever they are. K So while a nearly-optimized application can perform well (and usually abouteI equally well) in both environments, it's completely legitimate to comparea; typical, out-of-the-box-without-much-massaging performance.t  D Unix provides centralized system caching of data, while VMS providesH process-level caching (save for below-file-system-level disk caching, ifJ configured - and I have no idea whether the memory devoted to such cachingK can be shared flexibly among a group of disks and with other non-I/O systemdD use as central Unix file cache memory can be).  The defaults for VMSJ process-level caching are relatively small (recent posts if I've read themL correctly suggest that default RMS buffer sizes may be 8 KB, a pittance) andJ (again, by default) include no read-ahead/write-behind facilities, whereasC common (e.g., IIRC, Sun's) Unix system cache is sensitive to accesslF patterns, automatically reads ahead and writes behind in progressivelyG larger increments on detecting sequential activity, and within settabletC limits dynamically gives applications access to the amount of cachehD beneficial to them and to overall system throughput - in addition toE providing LRU read-caching at least equivalent to the sub-file-systemaH disk-caching that the VMS system manager may or may not have configured.  F If you don't understand that such (default) performance advantages areG absolute, rather than somehow dependent upon operating-system-dependentnI application-development 'idioms', then you don't understand file systems. E It takes noticeable effort tweaking multitudinous RMS options just to H *equal* the file system performance that Unix systems provide by defaultG (and even then, the per-process isolation of the mechanisms allows less K balancing across the entire system than the central Unix cache allows), and7K if you manage to gain any actual advantage, then it's an advantage that cansK be erased by expending a bit of effort on the Unix application side - sincevG there's really nothing RMS can do in its process-based buffers that yourH couldn't emulate exactly in a Unix application should you choose to (andH while some things, like asynchronous multi-buffered operation, might getI complicated to emulate, they're the things you don't have to, because theb, system cache is already doing them for you).  J As I said, I'm not a Unix user, but David Mathog has provided two examplesK (and appears confident that they represent typical behavior) supporting the C above conclusions and John Malmberg also seems to have some relatedlG experience, though he wasn't specific about it.  Leaving aside built-iniJ support for things like multi-key indexed files (since I have no idea whatK the quality of the third-party Unix implementations may be), there's reallyII nothing special about the way RMS handles data:  it may be *conceptually*bD more approachable for people (like me) accustomed to record-orientedK processing, but when it comes to moving the data to and from disk the bytesnH are just like any other bytes, and this movement is what typically forms, user perceptions of how good performance is.  G The Unix central cache does a better job of minimizing such movement byvL default than RMS does by default.  It sometimes, by virtue of its ability toF balance cache use across the entire system according to demand, does aJ better job than RMS could do even with unlimited optimization effort.  ItsH Achilles' heel is the difficulty Unix vendors have had extending it to aK clustered environment, but Tru64 seems to have done so with the help of theaK ported VMS DLM (though distributed caching remains an area in which both it  and VMS could do better).s  H Just because you may not understand the details of a discussion does notF make the assertions of those who do understand them 'unfounded' simplyK because they are based on analysis rather than experiment - especially when"I they are consistent with those who *have* some experimental evidence.  If I you've got either evidence or detailed analysis to the contrary, you have  yet to present it.   - bill   >hC > I really don't mind your doses of reality.  But please don't makeH	 unfoundedsI > statements, declare them fact, and then build more arguments upon theseo 'facts'. >r > Dave >a > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596= > 170 Grimplin Road               E-Mail: davef@tsoft-inc.comb > Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 30 May 2000 18:22:34 -0500D7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> ' Subject: Re: General discussion commento- Message-ID: <39344D3A.4892787D@earthlink.net>a   Bill Todd wrote: > K > VMS as you know it is in no danger of disappearing any time soon, so yourk > livelihood is secure.   D Come look for an OpenVMS job here in Metro Chicago. You may discover
 otherwise.  7 > But it also has no likelihood of growing market shareaJ > by continuing business as usual (the past decade-plus should be adequateF > proof of that, despite hardware that *should* have helped it do so).  D Exactly what we've been pounding on Compaq about (and Digital beforeH them) for a *VERY* long time now. I think we're starting to make a dent,H but that's less than half a step in a journey of several hundred million miles.  F > Extending (rather than morphing) VMS to be more palatable to a widerA > audience can only improve matters, both for you and for Compaq.-  G Agreed. However, would you care to elucidate the concept of "extending"sG an o.s. which is already a superset of most of the others we encounter?0  0 > >2K > > OpenVMS feeds, houses and supports us and our families. Assault that in C > > *ANY* way, and you *WILL* provoke a confrontation - guaranteed.n > N > If asserting that VMS is not perfect and trying to improve it constitutes an > assault, so be it.  G Well, improving it is one thing. Let's continue rather than expand thisaG because I think you have a point further down that needs clarification.i  B > David J. Dachtera <djesys.nospam@earthlink.net> wrote in message) > news:39333AF1.7CF905CC@earthlink.net...u >  > > E > > My advice? Knock off the confrontations. Period. They are neitherO > > appropriate nor productive.. > >pC > > 2. There's room in the world for other o.s.-es - just not here.p > >s0 > > This is "comp.os.vms", not "comp.os-dujour". > >aD > > If you want to proselytize on the merits, advantages, etc. otherJ > > o.s.-es, feel free to participate in other newsgroups, but be preparedK > > to encounter an equal (or possibly greater) degree of bigotry regardingT< > > those systems in those groups. It's not unique to c.o.v. > J > No, I'll continue to feel free to point out their comparative advantagesM > here:  VMS is a lot more capable of incorporating their strengths than they F > are of incorporating VMS's (the old 'quality built in, not added on'N > advantage), so VMS is the logical place to start if you want to wind up with- > a system that's superior in *all* respects.e  ? Yeah... So? You seem to agree with the great bulk of the c.o.v.h) participants. So, why the confrontations?i  eK > The definition of 'proselytizing' involves conversion, not extension.  If L > you think I've been encouraging people to convert to other systems, you've > missed the point entirely.  D Indeed. Would you care to clarify EXACTLY what your point is? PleaseH state your case succinctly and to the point. Where necessary, do like my5 6th grade teacher said: "Be specific, cite examples".w  A Again, how can you EXTEND that which is already a SUPERSET of the  others?   G As a host of has-been vendors have discovered, you can side step almost F everything in the OpenVMS environment that makes it look and feel likeG OpenVMS (but why would you?). You can do physical I/Os and bypass ODS-2 D as well as RMS. You can write your own device drivers and everythingB else that uses the OpenVMS kernel without any of its outer layers.  G PORTING UN*X-land software to OpenVMS is one thing (i.e., getting it toiE compile and run clean). INTEGRATING a program (read:application) with B OpenVMS (ODS, RMS, DLM, etc.) is something else entirely. Just ask) Informix why they dropped their VMS port.   E _THAT_, IMHO, is where we should be focussing. Make applications moret= intelligent, rather than dumbing OpenVMS down to their level.-  H About the only "extension" I can see for OpenVMS is a more open approachC to graphics card drivers as well as SCSI device drivers. OpenVMS is C *WAY* behind the curve on device support in these areas. One way to D mitigate that might be to get HSx's to talk to (de-facto) "standard"F SCSI disks and then let OpenVMS talk to the HSx's. Not an "affordable"( approach, but still better than nothing.   --   David J. Dachtera4 dba DJE Systemsm" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/t   ------------------------------  % Date: Tue, 30 May 2000 23:24:28 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>r' Subject: Re: General discussion commentr( Message-ID: <8h20fl$mhp$1@pyrite.mv.net>  H Since my previous response, I've seen that David Mathog has presented anK additional example of Unix's relative performance advantage in this area ineI the 'Compaq not as bad...' thread, explaining it pretty much as I did.  IoH also stumbled onto the following from 3/14/00 while skimming through oldI email I'd sent (quoted from another post the date of which I don't know):P  7 Francoise Becker <francoise@lsoft.com> wrote in messageS news:229878429@MVB.SAIC.COM...   ...O   > The page you pointed out:g- > http://www.lsoft.com/products/ease_plum.asp E > is slightly outdated. We still heavily rely on OpenVMS for reliablenE > uptime, so the page is still mostly accurate, but if you follow then$ > link to our delivery records page:4 > http://www.lsoft.com/ease-stats/records-today.htmlD > you will note that the *records* are no longer held by the OpenVMS# > machines but by a Tru64 Unix box.  >hC > The Tru64 box, LIME, is an AlphaServer 1200, just like the 2 mainw> > OpenVMS boxes, except that it only has one CPU versus 2 CPUs > in GRAPE.	 >r= > So this is more an Alpha success story than an OpenVMS one.sG > The alpha is wonderfully fast, and that's why we're able to get thoseb? > kinds of delivery records out of those boxes. But OpenVMS has9A > some unfortunate limitations.  I have to cringe as I write thisoF > because I'm a bit of a VMS bigot. The first limitation we ran across4 > was in UCX. UCX 4.2, instead of using VMS's memory4 > management routines, apparently had its own memoryB > management routines, which imposed a hard limit on the amount of; > memory we could use. So even though the Alpha chips could-D > handle much faster throughput, we were forced to put a throttle on> > it because of UCX's artificial limitations. We complained toD > Compaq, and they were kind enough to include us in field tests forB > VMS 7.2, which included UCX 5.0, a complete re-write -- really a= > port of the Unix TCP/IP stack, and which did not have theser > limitations. >l9 > But then we ran across the other slow-down: RMS. RMS iso@ > wonderful in some ways, but it's slow. When we ported LSMTP toB > Tru64, we discovered that Tru64, with its more light-weight fileA > management system could process the mail deliveries much faster 7 > than the VMS systems, so it is now the record-holder.o >iA > So we are now keeping a watchful eye on Compaq's directions. If = > Tru64 really gets into *true* VMS-type clustering, we wouldiD > probably move from OpenVMS to Tru64 Unix for our critical servers.B > On the other hand, if RMS improves, we would probably stick with? > OpenVMS. On the other hand, if some other player comes on the G > field (a reliable NT? a fast Sun?) that blows both of them out of the C > water, we might go in a different direction altogether. WhicheveraH > way we move, it will be to improve our services, taking all facts intoC > account; not because Francoise thinks VMS is really cool, and notu? > because of a pronouncement by some technologically challengedi8 > CEO under the influence of the latest article he read. >  > Francoise  > francoise@lsoft.comd >a  G To all appearances this indicates that an native VMS application portedlF *from* VMS *to* Tru64 performed significantly better in the Tru64 fileI system environment.  Sounds pretty much like the kind of example you werer0 looking for, though not the result you expected.   - bill  0 Bill Todd <billtodd@foo.mv.com> wrote in message" news:8h11jp$rus$1@pyrite.mv.net...   ------------------------------  # Date: Tue, 30 May 2000 19:17:50 GMTv- From: "Richard D. Piccard" <piccard@ohio.edu>eO Subject: Hoff or Andy G., Please! Re: VAX VMS 7.2 Bug? ; backup/image/(no)aliasd( Message-ID: <393413D4.962816CC@ohio.edu>  F I am concerned that a gratuitous incompatible change in the meaning of the I BACKUP command has been inflicted on the user community, or that an errorh/ in the documentation has been inflicted on us. t  F For at least the last 17 years, you could always get a bootable backup copy e of a bootable system disk by   $ BACKUP/IMAGE  source:  dest:  N (with /VERIFY if you wanted).  Any new qualifier that is permitted with /IMAGEG <RANT>SHOULD PRESERVE THAT BEHAVIOR</RANT>.  That is, the default valuer of sN the new qualifier should permit the above command, using /IMAGE all by itself,G to guarantee that a bootable copy will be created.  Any other behavior  I threatens to break many lines of customer batch job files, in a way that eD threatens reliable operation and disaster recovery, the very core of what l- makes VMS worth more than {unix, NT, etc.}...a  G May we please have some authoritative clarification:  will BACKUP/IMAGE  always oH produce a bootable system disk if the source is a bootable system disk?  If eG not, under what versions and circumstances, and when can we expect thatl to bei fixed?  
 							RDP   Another poster quotes    The VMS 7.2 manual says:  E "Specifying the /IMAGE qualifier without also specifying /NOALIAS canuD result in incomplete disk or file restoration operations. Therefore,E Compaq strongly recommends that you specify /NOALIAS with /IMAGE when ) performing image mode backup operations."u     "Richard B. Gilbert" wrote:a > J >         No, you are not the only one to be concerned!  It's not only theL > possibility that the BACKUP utility may be broken but also the fact that IK > had no suspicion that this might have happened until this thread started.' > M >         It was only last week that I brought up my first OpenVMS/Alpha V7.2b > system.  Now I realize thate= > a.  My backup of a week's work may be no more than garbage.t@ > b.  I don't know how to be certain that I get a usable backup. > M >         And just when the memory of the VMS V5.2 BACKUP debacle had finallyo > begun to fade!G > Remember the "cumulative" backup patch?  The one that was added to orp9 > revised about every three weeks for two or three years?l > L >         Could someone from VMS Engineering please let us know what's going
 > on here? > $ > Message text written by Huw Davies > >>  > > > > The VMS 7.2 manual says: > > > > M > > > > "Specifying the /IMAGE qualifier without also specifying /NOALIAS canbL > > > > result in incomplete disk or file restoration operations. Therefore,M > > > > Compaq strongly recommends that you specify /NOALIAS with /IMAGE whenh1 > > > > performing image mode backup operations."o > J > Am I the only one to be concerned that a piece of magic that I have been2 > using successfully for the last 20 years, namely > 5 >      $ backup/image/fast sys$sysdevice: backup$disk  > M > may no longer work correctly? (I know that the /fast is redundant, but I've  > M > been typing it that way for the last 20 years and I can hardly stop myself,  > K > even in e-mails). Of course, I'm fairly sure the above command would haveeK > failed under V2.x as sys$sysdevice wouldn't have been defined either, buta > you get the point. >  > <    -- tB ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------   Date: 30 May 2000 19:59:19 GMT* From: helbig@astro.rug.nl (Phillip Helbig)S Subject: Re: Hoff or Andy G., Please! Re: VAX VMS 7.2 Bug? ; backup/image/(no)aliasr. Message-ID: <8h16in$bj2$1@info.service.rug.nl>  = In article <393413D4.962816CC@ohio.edu>, "Richard D. Piccard"h <piccard@ohio.edu> writes: i  G >I am concerned that a gratuitous incompatible change in the meaning ofs >the sJ >BACKUP command has been inflicted on the user community, or that an error0 >in the documentation has been inflicted on us.   G Ditto.  I never got a response to my question as to what should happen KI and if this is documented: /IMAGE or not, /ALIAS or not, regular file or fG directory, on backup or on restore.  That's 16 possibilities.  In some tI cases, the behaviour is non-intuitive and/or not compatible with what it oH was in the past.  Also, the interrelationship of qualifiers used during 4 the backup and during the restore needs to be clear.   ------------------------------   Date: 30 May 2000 22:01:30 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)S Subject: Re: Hoff or Andy G., Please! Re: VAX VMS 7.2 Bug? ; backup/image/(no)aliasn6 Message-ID: <8h1dnq$gr2$1@mailint03.im.hou.compaq.com>  X In article <393413D4.962816CC@ohio.edu>, "Richard D. Piccard" <piccard@ohio.edu> writes:G :I am concerned that a gratuitous incompatible change in the meaning ofhI :the BACKUP command has been inflicted on the user community, or that an  6 :error in the documentation has been inflicted on us.   G   If BACKUP/IMAGE needs /NOALIAS to work, then it should default to it.eH   (This DCL syntax change is something that I personally consider to be H   a bug in OpenVMS -- Andy and/or I need to do some research on this to %   figure out what happened, and why.)a  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 30 May 2000 22:46:11 -0400e/ From: "Andrew C. Stoffel" <acs@cyberportal.net>l+ Subject: HSZ80 - was Re: ES40 Configuration D Message-ID: <acs-E947A7.22461130052000@premium.news.fcgnetworks.net>  A In article <8gmakh$ecj$1@nnrp1.deja.com>, d.webb@mdx.ac.uk wrote:s  < > What are you doing about a backup device ? Stackable DLT ?G > Will it connect to the HSZ80's using up a channel or be directly of au > PCI slot on the system ?  A Is that possible (now?) ? My reading/interpretation of available bC info on the HSZ80 is that it DOESN'T currently support tape devicesn (Unlike the older HSZ70).o   -Andy-   -- uH ------------------------------------------------------------------------! Witty sayings are a dime a dozen.d* Unfortunately, I'm down to my last nickel.   ------------------------------  % Date: Tue, 30 May 2000 11:40:18 -0700 / From: Terry Marosites <TMarosites@unitedad.com>d Subject: looking for blast.comM Message-ID: <1137A4A23A51D311B2D600105A1D5213019AEE50@seantexch.unitedad.com>o  
 Hello all,  > Does anyone have a copy of blast.com that they could email me.A It was posted here back in 1994-5 and I can't find it in the FAQs, Thanks e Terry     5 *****************************************************r    5 *****************************************************i4 Any views or opinions are solely those of the author) and do not necessarily represent those oft United News& Media.e5 *****************************************************h4 The information transmitted is intended only for the1 person or entity to which it is addressed and mayl3 contain confidential and/or privileged material. If 3 you are not the intended recipient of this message,i. please do not read, copy, use or disclose this3 communication and notify the sender immediately. Itn0 should be noted that any review, retransmission,2 dissemination or other use of, or taking action in- reliance upon, this information by persons ora- entities other than the intended recipient ist prohibited.l5 *****************************************************u **   ------------------------------  % Date: Tue, 30 May 2000 17:37:36 -0500l) From: "John E. Malmberg" <wb8tyw@qsl.net> " Subject: Re: looking for blast.com/ Message-ID: <sj8gb7tg5pj130@corp.supernews.com>l  3 Terry Marosites <TMarosites@unitedad.company> wrotel  @ > Does anyone have a copy of blast.com that they could email me.C > It was posted here back in 1994-5 and I can't find it in the FAQs1  K I am assuming that you do not mean http://www.blast.com/products/vms.html ?c   -Johnn wb8tyw@qsl.network  G Not affiliated with blast.com or was consciously aware of their product  until today :-)o   ------------------------------  # Date: Tue, 30 May 2000 18:34:50 GMTd From: maztang@my-deja.como" Subject: Migrating from VMS to AIX) Message-ID: <8h11k8$m62$1@nnrp1.deja.com>t  F We are looking into converting our one remaining VMS system to AIX forD ease of support and consistency amongst our mid-range servers.  I'veE found Sector7's software for running RMS and DCL on unix systems, and'G Boston Business Computing's VCL and EDT+.  Are there any other productslE out there along these lines?  RMS and DCL are what we really need, tohE make the transition as smooth as possible.  We'd like to have as manye@ choices as possible to test before we make a commitment with one2 vendor.  Any help you all can give would be great.   Thanks.q   Jayg    & Sent via Deja.com http://www.deja.com/ Before you buy.t   ------------------------------  % Date: Tue, 30 May 2000 22:12:05 +0200u" From: "Hans Vlems" <hvlems@iae.nl>& Subject: Re: Migrating from VMS to AIX( Message-ID: <8h16rp$6mm$1@news.IAEhv.nl>  I I've tested Soctor7's DCL product on W98 and I found it very encouraging.sJ Support (even though I was just a pc user, not a customer) was quite good.: In fact I wish Compaq was just as quick and knowledgeable. Of course, YMMV.  
 Hans Vlems  / maztang@my-deja.com heeft geschreven in berichti  <8h11k8$m62$1@nnrp1.deja.com>...G >We are looking into converting our one remaining VMS system to AIX foriE >ease of support and consistency amongst our mid-range servers.  I'veoF >found Sector7's software for running RMS and DCL on unix systems, andH >Boston Business Computing's VCL and EDT+.  Are there any other productsF >out there along these lines?  RMS and DCL are what we really need, toF >make the transition as smooth as possible.  We'd like to have as manyA >choices as possible to test before we make a commitment with onea3 >vendor.  Any help you all can give would be great.d >T >Thanks. >y >Jay >t >e' >Sent via Deja.com http://www.deja.com/  >Before you buy.   ------------------------------  # Date: Tue, 30 May 2000 20:40:10 GMT ! From: jim@accelr8.com (Jim Reiss)h& Subject: Re: Migrating from VMS to AIX; Message-ID: <KGVY4.11858$5k2.28195@dfw-read.news.verio.net>d  G In article <8h11k8$m62$1@nnrp1.deja.com>,  <maztang@my-deja.com> wrote: G >We are looking into converting our one remaining VMS system to AIX for E >ease of support and consistency amongst our mid-range servers.  I'vefF >found Sector7's software for running RMS and DCL on unix systems, andH >Boston Business Computing's VCL and EDT+.  Are there any other productsF >out there along these lines?  RMS and DCL are what we really need, toF >make the transition as smooth as possible.  We'd like to have as manyA >choices as possible to test before we make a commitment with oned3 >vendor.  Any help you all can give would be great.iE We at Accelr8 also have tools for this sort of migration.  Please see C our web site at www.accelr8.com or call us at 303-863-8088 for morea information. --I  Jim Reiss (jim@accelr8.com)    Accelr8 Technology, Denver, Colorado, USAw   ------------------------------    Date: 31 May 2000 00:01:20 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)& Subject: Re: Migrating from VMS to AIX* Message-ID: <39343a30$1@news.kapsch.co.at>  E In article <8h11k8$m62$1@nnrp1.deja.com>, maztang@my-deja.com writes:iG >We are looking into converting our one remaining VMS system to AIX for E >ease of support and consistency amongst our mid-range servers.  I'veoF >found Sector7's software for running RMS and DCL on unix systems, andH >Boston Business Computing's VCL and EDT+.  Are there any other productsF >out there along these lines?  RMS and DCL are what we really need, toF >make the transition as smooth as possible.  We'd like to have as manyA >choices as possible to test before we make a commitment with ones3 >vendor.  Any help you all can give would be great.h  L Iff you switch to U**X (which is a bad decision anyhow) then why do you planL to switch to AIX ? Support for AIX is as much or less declining just like as7 for VMS. SOLARIS, LINUX, HP/UX ? Ok. AIX ? IRIX ? Why ?p  H And yes, I know that AIX is more stable or usable than SOLARIS or HP/UX.> But problem with AIX is applications, price and performance...K (sounds again equal to VMS - but IBM never pissed their customers like DEC)r   just my 0.02   -- d< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888p< FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------    Date: 30 May 2000 14:55:50 -0700* From: dunnett@mala.bc.ca (Malcolm Dunnett)& Subject: Re: Migrating from VMS to AIX, Message-ID: <B0KMCXsv8DOV@malvm2.mala.bc.ca>  < In article <KGVY4.11858$5k2.28195@dfw-read.news.verio.net>, &    jim@accelr8.com (Jim Reiss) writes:I > In article <8h11k8$m62$1@nnrp1.deja.com>,  <maztang@my-deja.com> wrote:fH >>We are looking into converting our one remaining VMS system to AIX for@ >>ease of support and consistency amongst our mid-range servers. ... G >>out there along these lines?  RMS and DCL are what we really need, toh, >>make the transition as smooth as possible.  D   If you really need RMS and DCL, what is it that makes the software% easier to support on AIX than on VMS?    ------------------------------    Date: 30 May 2000 23:02:46 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: MOZILLA M16 ?( Message-ID: <39342c76@news.kapsch.co.at>  ' What has happened with MOZILLA M16 ? Ins  5 http://www.mozilla.org/projects/seamonkey/milestones/   I is the current date listed for the milestone 17 but still no sign of M16.s  
 Any insight ?'   -- y< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------  # Date: Tue, 30 May 2000 22:27:09 GMTt' From: Colin Blake <colin@theblakes.com>i Subject: Re: MOZILLA M16 ?- Message-ID: <3934408A.802947E8@theblakes.com>    Peter LANGSTOEGER wrote:  ) > What has happened with MOZILLA M16 ? Inw >i7 > http://www.mozilla.org/projects/seamonkey/milestones/a >eK > is the current date listed for the milestone 17 but still no sign of M16.s >s > Any insight ?e  I Its not out yet (on any platform). That milestone list is not up to date.c   ------------------------------    Date: 31 May 2000 00:52:54 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: MOZILLA M16 ?* Message-ID: <39344646$1@news.kapsch.co.at>  W In article <3934408A.802947E8@theblakes.com>, Colin Blake <colin@theblakes.com> writes:  >Peter LANGSTOEGER wrote: * >> What has happened with MOZILLA M16 ? In >>8 >> http://www.mozilla.org/projects/seamonkey/milestones/ >>L >> is the current date listed for the milestone 17 but still no sign of M16. >> >> Any insight ? >eJ >Its not out yet (on any platform). That milestone list is not up to date.  3 I know that M16 and M17 are not out, yet. But why ?nG And the milestone list did get updated the last weeks more than once...f   --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888l< FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------  % Date: Tue, 30 May 2000 19:38:16 +0111h9 From: Mark Iline - Info-VAX account <ivax@meng.ucl.ac.uk> 3 Subject: Re: OpenVMS vs Tru64 Pathworks performance.0 Message-ID: <009EADF7.10AF3AB2.2@meng.ucl.ac.uk>  G From:	MX%"rpjung@mb.sympatico.ca"  "Randy Jung" 28-MAY-2000 03:20:17.60n  E Cheers for the comparison, but we really need to be lookig at recent sD versions. I understand that recent versions of ASDU (Tru64 PW) have I significantly increased performance over earlier versions (several 100%).K  L > As someone mentioned, the best performing server for a Windows environment( > will probably be a Winodows NT server.  F This isn't an accurate comparison, but installing Office97 off a file  service gives something like:v   Elapsed time	Server platform( 5 minutes	NTAS 4 (450 MHz Proliant 1600) 2 minutes	ASDU (PW500AU)* >10 minutes	PW 6.0 dual CPU DS20, VMS7.1-2  ' All servers on 100Mbit switched ports. e     Mark   ------------------------------  % Date: Tue, 30 May 2000 17:01:35 -0700 # From: Jethro Bodine <Me@nospam.com>./ Subject: Re: Prob w/DCPS 1.7,HP4050, and HPGL/2f< Message-ID: <Me-BFE5B7.17013530052000@svlnews.lmms.lmco.com>  F In article <panderson-D393D3.12085430052000@news.earthlink.net>, Paul ' Anderson <panderson@genicom.com> wrote:w  F > In article <Me-B46894.15213726052000@svlnews.lmms.lmco.com>, Jethro  > Bodine <Me@nospam.com> wrote:i > J > > It would be nice if DCPS would skip the PCL to postscript translation H > > for unrecognized printers as long as the DATA_TYPE=PCL parameter is  > > specified. > I > I'll have to check with others to see why this was not implemented.  I uI > have a feeling that when the DCPS PCL translator was written, not many oG > PostScript printers had native PCL and the PCL 4 translator was more l > than adequate. > F > Something like a DATA_TYPE=PCL /TRUST_ME_REALLY_MY_PRINTER_DOES_PCL  > might be good. >  > Paul   Sounds Great! Thanks.a -J   ------------------------------   Date: 30 May 2000 21:55:26 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)> Subject: Re: problem linking to ucx$ipc.olb on AXP/VMX71-UCX406 Message-ID: <8h1dce$gr1$1@mailint03.im.hou.compaq.com>  n In article <gV1Y4.916$Gh.45498@typhoon.austin.rr.com>, "Lorraine Profeta RR" <lprofeta@houston.rr.com> writes:E :I don't have the original posting in front of me, but I think it wasoD :Multinet; not TCPIP.  Multinet still uses ucx$lib.olb (thought theyL :recommend you use the shareable library, instead).  Previous to OpenVMS 6.2F :(maybe 6.2) the library was ucx$ipc.olb, and therein was the poster'sK :confusion.  I have 7.1-2 at work and it still came with UCX; my version of  :7.2-1 has TCPIP on it.   E   Can't speak for what MultiNet does here, nor how one links with it.m;   (The title says "UCX", so I had assumed TCP/IP Services.)f  J   The version of TCP/IP Services is of central interest here, as versions H   V5.0 and later use the prefix TCPIP$ and not UCX$.  Versions of TCP/IPI   Services prior to V5 use the prefix UCX$.  TCP/IP Services V5.0 can be sI   installed and used on OpenVMS V7.1 and later, and V5.0A is the current ,   and prefered version.p  * :              Do you really work for DEC?  G   Assuming I am the antecedent of that question, no, I work for Compaq.t  K   Given that your news server reports itself with Texas, consider stopping eL   by Dallas this weekend.  Various Compaq OpenVMS Engineering folks will be L   visiting Texas -- where even the thermometer readings are big :-) -- June 1   2nd through June 4th, 2000.  For details, see: c       http://dfwdays.dfwcug.org/  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 31 May 2000 01:09:33 GMTd+ From: Jonas Lindholm <jlindholm@nyc.rr.com>m( Subject: Re: Problem with resource locks* Message-ID: <39346609.5BC2F496@nyc.rr.com>  K You can use the LCK$M_EXPEDIATE flag to force a NL lock to be granted for aa? new request all the time regardles of any queing lock requests.o  B >>> LCK$M_EXPEDITE  This flag is valid only for new lock requests.I Specifying this flag allows a request to be granted immediately, provided.D the requested mode when granted would not block any currently queuedL requests in the resource conversion and wait queues. Currently, this flag isL valid only for NLMODE requests. If this flag is specified for any other lockC mode, the request will fail and an error of SS$_UNSUPPORTED will bea returned.  <<<  	 /Jonas L.e       Adrian Lumsden wrote:s  F > Platform MV3100-80 & VS3100-M38, VMS 6.2, also various Alphas VMS7.1 >-E > I have been developing a distributed application that uses locks tod > co-ordinate the I > various components and to distribute small amounts of data out over the;
 > cluster.J > I have had problems with certain aspects of what I'm doing which I think > I'veI > found a workaround to. I'd like to know if this is the "solution" or is: > thereo > something I've missed. >oJ > I have a single process, MP, running on one of the nodes in the cluster, > andsH > several slave processes, SPn, running on various nodes of the cluster,
 > possiblyJ > including the one that MP is running on. The SPs can't do anything untilI > MP is up and running and acquiring data. The SPs have to be aware if MP J > has died or exited for any reason so they can warn the user applications7 > that the distributed data is no longer being updated.- >-C > I implemented support for this by having a system lock MP_STATUS.nG > If MP starts first it creates an EX lock on MP_STATUS and carries on.- >-C > When the SPs start they attempt  to obtain a CR lock on MP_STATUSdG > with a blocking AST. If this succeeds then MP does not have EX so canfB > be assumed to be inactive. SPs then $hiber(). When MP starts and
 > attemptsD > to get EX, the SP blocking AST fires and converts the lock CR->NL.B > This lets MP's EX lock complete to EX. SPs then enqueue a NL->CRI > conversion with completion AST. If MP subsequently dies, the completionCB > AST fires and SPs know that MP has gone away and can wait for it
 > to restart.a >bH > If the SP's initial attempt to obtain CR on MP_STATUS fails, then theyE > assume that MP already holds EX and can enqueue a NL->CR conversion- > with AST completion as above.- >-J > My problem was that this worked fine when I had only a single SP waitingE > for the MP to start (either on the same cluster member as the MP or0C > on a different one). If I had two SPs waiting for MP to start the 	 > initialoJ > creation of the MP_STATUS lock by MP would get queued  and not complete. >eH > Both SPs were sitting with the lock at CR blocking the MPs EX request.@ > However my debugging code showed that the SPs blocking AST hadE > fired and that the locks had dropped to NL and then gone back up to*$ > CR without MP getting the EX lock. >*J > I finally fixed the problem by having MP initially create the lock at NL4 > and then immediately enqueuing a conversion to EX. >eF > What I figure was happening was that MP would enqueue a new EX lock.F > This triggered the blocking ASTs in the two SPs. The ASTs would drop@ > the lock CR->NL and then $wake(). SP1 would wake and enqueue aD > NL->CR conversion. By this time the other SP had also got a NL->CR@ > conversion into the conversion queue. VMS seems to process allF > requests in the conversion queue before looking at the waiting queueC > so both of these would complete (since they weren't being blockedoB > by anything) and then they would block the completion of the MPs
 > EX request.h >tD > By having MP create the lock at NL first and then enqueue a NL->EXH > conversion, MP would get into the conversion queue before the blockingC > ASTs triggered and dropped the locks CR->NL. Now when they try towE > go back up to CR, MP is already there in the conversion queue aheadjH > of them and that conversion happens first. This then blocks the NL->CRG > conversions and they hang around in the conversion queue where I want.
 > them to be.e >eG > Moral?? Always create your locks as NL first and then manipulate themy > with conversions./ >.F > Is this right? Have I missed something obvious in the way $enq worksG > and should be doing it a different way. The moral is not right anywayoC > because I had problems with two SPs starting. When one of them is1A > already up, its NL->CR queued conversion blocks another SP fromM@ > creating an NL lock and then queuing its own conversion to CR. >gH > By the way, I have always been using the LCK$M_QUECVT flag. This seemsD > to put them at the back of the conversion queue but still ahead of
 > anything > in the waiting queue.n >sG > PS If you need a utility to spy on locks please e-mail me. As soon ash > youuE > start messing with DEBUG you alter all of the timing and everything, > works. >e
 > regards, >s > Adrian >i > --* > Adrian Lumsden, XDT Computer Systems, UK > AdotLumsden at xdtdotcodotuk   ------------------------------  # Date: Wed, 31 May 2000 02:31:36 GMTh& From: "Walter G. Bennett" <me@you.com>, Subject: Remote Print From Vax/VMS to AS/400' Message-ID: <39347960.9ACCE846@you.com>   C I am trying to send reports from a Vax computer to an AS/400 outputR queue.B I was able to send a report to the printer queue but was unable toG display or print the report.  The error I received on the AS/400 stated D that the file was ASCII meant for a PC Printer.  The report was sentF using a DCL PRINT command that contained the system name and the queue name.M  B Is there another /PARAMETER that I should include to translate the report to the proper format?   Walt Bennett   ------------------------------  # Date: Wed, 31 May 2000 03:37:30 GMTp0 From: "Terry C. Shannon" <shannon@world.std.com>C Subject: Some recent postings on the SKC Corner of www.acersoft.comy& Message-ID: <FvEnC4.MB2@world.std.com>   Folks,  D The following issues of Shannon Knows Compaq have been posted on the www.acersoft.com website.e    = SKC V7N2: Compaq Gets An ODM Infusion from Inacom Acquisitiona    > SKC V7N3: Compaq's 4FQ99 Earnings Report Card: Not Bad, But...    OpenVMS Viewpoint (May 20, 2000)   Enjoy,     -- Terry C. Shannon. Consultant and Publisher, Shannon Knows Compaq shannon@world.std.comf http://www.acersoft.com-  K PS-- Planning to make a purchase from Amazon.com? If so, why not access the.& site through the SKC Book Review page!   ------------------------------  # Date: Wed, 31 May 2000 01:55:31 GMTn$ From: Ed Wilts <ewilts@mediaone.net>5 Subject: Re: ver 7.1 Openvms will run on the new Ds20k, Message-ID: <39347113.60AB0798@mediaone.net>   "Jean-Franois Marchal" wrote: > 3 > "Ed Wilts" <ewilts@mediaone.net> wrote in messageu( > news:393318FA.5D9B2FC5@mediaone.net... > > Keith Brown wrote: > > >oF > > > I have been running OpenVMS 7.1-2 on a DS20 for about 10 months. > > > No problems so far.R > >dH > > And I've been working with Compaq for over 2 months to get our DS20sL > > actually working in our cluster without crashing HSJ-50 controllers.  WeJ > > have not succeeded yet although Compaq does seem to be working hard to > > resolve the issues.o > L > Did you look at the console parameter SCSI_POLL (mentionned in the cluster
 > manual)?E > I had a problem with 2 PWS433 crashing alone under the SRM console, % > due to incorrect SCSI_POLL setting.S >  > Jean-Franois Marchal-  @ Actually, the problem is that HSJ-50s are crashing.  They're not) connected to the DS20 systems via SCSI...f   	.../EdA -- e Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  # Date: Tue, 30 May 2000 20:40:35 GMTn0 From: "Terry C. Shannon" <shannon@world.std.com> Subject: Re: VMS what's VMSn& Message-ID: <FvE410.6qp@world.std.com>  G <d.webb@mdx.ac.uk> wrote in message news:8gm7d5$bm1$1@nnrp1.deja.com...a+ > In article <8gm399$8dm$1@nnrp1.deja.com>,. >   lori5015@my-deja.com wrote:o  > > Again....No mention of VMS!! > >LF > > http://www.zdnet.com/eweek/stories/general/0,11011,2577181,00.html > >'* > > Sent via Deja.com http://www.deja.com/ > > Before you buy.k > >o >tH > How accurate are other parts of the report ? I thought Intel still had7 > to manufacture Alpha chips for a few more years yet ?n >y  J Under the memorandum of understanding surrounding the sale of Fab-6, IntelI was obligated to produce Alpha chips for seven years IF DEC/Compaq wantedn them to do so.  J Seems pretty evident that Compaq is getting a better deal elsewhere, which isn't particularly surprising.   ------------------------------  # Date: Tue, 30 May 2000 20:38:57 GMTr0 From: "Terry C. Shannon" <shannon@world.std.com> Subject: Re: VMS what's VMS & Message-ID: <FvE3yA.69D@world.std.com>  K <lori5015@my-deja.com> wrote in message news:8gm399$8dm$1@nnrp1.deja.com...- > Again....No mention of VMS!! >AD > http://www.zdnet.com/eweek/stories/general/0,11011,2577181,00.html >   J I'm not surprised. When I was interviewed for the story, the questions all< involved the Alpha chip, not any of the OSes that run on it.   ------------------------------  # Date: Wed, 31 May 2000 00:11:00 GMTm2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>- Subject: Re: Which is the language of VAX/VMSs1 Message-ID: <oMYY4.2$ru5.230@typhoon.aracnet.com>$  3 Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:mE >   but there is at least one local Ada adherent busily coding up newtJ >   OpenVMS routines, and I am also also seeing Perl and Java and various < >   other languages being checked into the source libraries.  B Does this mean that the next version of OpenVMS will include Perl?   		Zane   ------------------------------  % Date: Tue, 30 May 2000 20:51:13 -0400 + From: "Main, Kerry" <Kerry.Main@compaq.com>t" Subject: RE: Wildfire AnnouncementJ Message-ID: <910612C07BCAD1119AF40000F86AF0D80528431D@kaoexc4.kao.dec.com>   Hello Andrew ..0  I Just catching up on email and could not let you slide still more fud into-, the newsgroup without some sort of response:  A >>> Compaq have not given OpenVMS the shot in the arm that peoplemJ expected/hoped for and have treated it no better or worse than Digital did in the Bob era.<<<    G Check out the followng url and see if you recognize some of these names I (like ETrade- one of top onlne investing site, Northernlight - the numberB  one Internet search engine etc):4 <http://www.openvms.digital.com/gsseries/index.html>   Or in the press:G <http://www.boston.com/dailyglobe2/150/business/Hardware+.shtml> Bostons Globe on Alpha May 29, 2000i  & On Alpha/OpenVMS/Tru64 and ISV supportL <http://www1.compaq.com/pressrelease/0,1494,wp%7E14583_2%21ob%7E30093_1_1,00 .html>I "Larry Ellison, Chairman and Chief Executive Officer, Oracle Corporation,M said:MG "Compaq and Oracle have embraced the Internet as the standard model for I computing, and today are taking customers to the forefront of e-business.lJ Oracle software, coupled with the power of Compaq's AlphaServer GS series,D creates one of the industry's most robust and reliable platforms for
 e-business."     From same url:L "Josh Levine, Chief Information Officer at E*Trade, said: "When we pioneeredE online investing years ago, we didn't know E*Trade today would be theEK world's most visited online investing site. Our partnership with Compaq has  helped us toK accommodate this business and infrastructure growth. From the beginning, we B have leveraged enterprise solutions from Compaq-particularly theirJ AlphaServers and OpenVMS clusters, along with ProLiant NT servers, storageK and mission-critical services-to enable the computing environment necessary>K to meet the high demands of our growing business. The AlphaServer GS seriessH provides us with features we can't do without: reliability, performance, speed and scalability."    From same url:A "ISV Recruitment Program: Compaq is working closely with existing E application partners, such as Oracle and SAP, and emerging ISVs(5) to.E deliver full e-business solutions for Compaq's Tru64 UNIX and OpenVMS@ operating systems."H  2 And another url promoting both Tru64 and OpenVMS -L <http://www1.compaq.com/pressrelease/0,1494,wp%7E14583_2%21ob%7E30094_1_1,00 .html>  H Now, if I was really into fud, I would post the 1997 Sun announcement onE Sparc III (now not expected in large servers until 2001), or question1F whether a single solution vendor is more capable than a multi-solutionK vendor to respond to Customers requirements, but I am not into that type of2 stuff, so I won't.   :-)X   Regards,  
 Kerry Main Senior Consultant,
 Compaq Canada6 Professional Servicesm Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.comd       -----Original Message-----' From: Andrew Harrison SUNUK Consultancyf! [mailto:andrew.nospam@uk.sun.com]r# Sent: Tuesday, May 30, 2000 4:45 AM  To: Info-VAX@mvb.saic.comf" Subject: Re: Wildfire Announcement    ! steven.reece@quintiles.com wrote:i   > You tell him Terry.o3 > Oh, but I forgot.  Andrew doesn't listen does he? I > And VMS is dead and Compaq are just a PeeCee company.  Dream on Andrew.  >l  ? Neither of which I have ever said. The  fact is there are a lotS9 of people on this alias with a vested interest in OpenVMS 6 surviving who seem to take the view that you attribute. to me namely that OpenVMS is dead or dying and0 Compaq is just a PeeCee Company who don't give a damn about OpenVMS.s  : I don't, I simply question what Compaq are doing to ensure8 that they don't ultimately lose OpenVMS/Tru64 and become a PC company by default.  9 Gallingly for those people who simply dismiss my posts as68 FUD the simple facts are that over a period of 18 months5 my posts have been shown with hindsight to be largelys< correct with respect to Compaqs/Digitals handling of OpenVMS$ and the state of the OpenVMS market.  2 OpenVMS boosters who no doubt you agree with wholeE heartedly in general proven with hindsight to have been spectacularlyg wrong.  A Alpha hasn't eaten Intel's lunch or anyone elses, one prediction.t  ? ISV's havn't shown any interest in Galaxies, another predictionu> in fact the opposite is true the number of commercial software6 vendors supporting OpenVMS/Tru64/NT/Alpha has steadily	 declined.n  @ NT on Alpha is not going to trash NT on Intel nor is it going to< reinvigorate the Alpha market. In fact Compaq dropped it not/ long after this particular prediction was made.P  6 Compaq have not given OpenVMS the shot in the arm that@ people expected/hoped for and have treated it no better or worse  than Digital did in the Bob era.  5 Alphaservers have not had Sun's lunch or anyone elsesi lunch.  3 eBay has not moved from Sun to OpenVMS or any otherM: OS and has recently announced a further comitment to using Sun's to host their site.   5 I have never said that OpenVMS is dead, I have simplya4 questioned the amount of resource being allocated to9 keeping it alive and one good example of this is the lacky5 of collateral Compaq had to justify their performance  leadership claims at launch.     Regardsn Andrew HarrisonT Enterprise IT Architect    ------------------------------    Date: 31 May 2000 03:11:51 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)" Subject: RE: Wildfire Announcement( Message-ID: <393466d7@news.kapsch.co.at>  x In article <910612C07BCAD1119AF40000F86AF0D80528431D@kaoexc4.kao.dec.com>, "Main, Kerry" <Kerry.Main@compaq.com> writes: >Hello Andrew .. > J >Just catching up on email and could not let you slide still more fud into- >the newsgroup without some sort of response:, >wB >>>> Compaq have not given OpenVMS the shot in the arm that peopleK >expected/hoped for and have treated it no better or worse than Digital didM >in the Bob era.<<<   J I hate to second Andrew in this, but from my personal point of view, thereK is now finally some kind of change in the way DEQ sees VMS, but in the eyesaJ of most (and this is what brings expectations and over the loooong run theC money), nothing has changed. No VMS mentioned. It's dead (or soon).   I eg. http://www.idg.at is a local computer magazine (IMHO the most popular3N Austrian IT magazine) where Q run some ads, but of course not for VMS. So evenK the Q sales/marketing still hasn't got the (new ?) message (and I think, it + is unfortunately not a local Q problem) ...c   -- l< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------  # Date: Wed, 31 May 2000 03:55:20 GMTl* From: young_r@eisner.decus.org (Rob Young)" Subject: RE: Wildfire Announcement+ Message-ID: <gjGFFRM+qpfv@eisner.decus.org>0  x In article <910612C07BCAD1119AF40000F86AF0D80528431D@kaoexc4.kao.dec.com>, "Main, Kerry" <Kerry.Main@compaq.com> writes:   > J > Now, if I was really into fud, I would post the 1997 Sun announcement onG > Sparc III (now not expected in large servers until 2001), or questioncH > whether a single solution vendor is more capable than a multi-solutionM > vendor to respond to Customers requirements, but I am not into that type of. > stuff, so I won't. >   9 	You mean if you go out and search their searchable presss: 	releases for ultrasparc iii and look at the first one you 	find, what do you get?y  D http://www.sun.com/smi/Press/sunflash/1997-10/sunflash.971006.1.html  M "The UltraSPARC-III microprocessor is expected to sample during the summer of M 1998. It will be manufactured by Texas Instruments using TI's EPIC-5 process.hN Production will begin with .25 micron CMOS technology and rapidly scale to .18 micron."  > 	Worst part about it was they were chattering like it was just# 	around the corner (Scotty, et al).e  : 	Weirdest thing about it is their UltraSparc III web page:  3 http://www.sun.com/microelectronics/UltraSPARC-III/e   	Points to the announcement:  A http://www.sun.com/smi/Press/sunflash/9710/sunflash.971006.1.htmla  - 	And we moan about some of the VMS web pages.f  > 	Continuing this little peak at USIII, if you click on the PDF
 	you find:  C http://www.sun.com/microelectronics/UltraSPARC-III/docs/ultra_3.pdfq  ? 	"With 8MB of cache the UltraSparc III delivers an estimated 35g 	SpecInt95 and 60 SpecFp95"   " 	Wheee... not bad for a 1999 part.  - 	"Having achieved first silicon in May 1999."   ( 	Hummm.  Must be volume shipping by now. 	 : 	Roadmaps are funny things too.  UltraSparc IV in 2000 butB 	we haven't seen the 600 MHz USIII yet, supposed to be here by now: 	even with a conservative reading of the roadmap, oh well.  6 http://www.sun.com/microelectronics/roadmap/CPULRG.jpg     				Robt   ------------------------------  % Date: Tue, 30 May 2000 22:58:27 -0400P' From: "Bill Todd" <billtodd@foo.mv.com> " Subject: Re: Wildfire Announcement( Message-ID: <8h1uup$jm2$1@pyrite.mv.net>  ' Then again, Rome wasn't built in a day.   J While much more aggressive promotion *outside* the OpenVMS Web site (whichL is still largely preaching to the converted) would be nice to see, that kindK of upheaval does take some time to organize - and it's at least nice to seeqC VMS now tooting its own horn instead of fading diffidently into thet6 background like a good second-class corporate citizen.  H If Compaq actually does follow through (as DEC failed to for a decade orL more), then there will be reason for celebration.  As of yet, there's mostlyJ only reason for guardedly-increased optimism, but that's still better than has been true for a long time.   - bill  5 Peter LANGSTOEGER <eplan@kapsch.net> wrote in messageb" news:393466d7@news.kapsch.co.at...L > In article <910612C07BCAD1119AF40000F86AF0D80528431D@kaoexc4.kao.dec.com>,- "Main, Kerry" <Kerry.Main@compaq.com> writes:n > >Hello Andrew .. > >LL > >Just catching up on email and could not let you slide still more fud into/ > >the newsgroup without some sort of response:d > >pD > >>>> Compaq have not given OpenVMS the shot in the arm that peopleI > >expected/hoped for and have treated it no better or worse than Digital  didn > >in the Bob era.<<<k >hL > I hate to second Andrew in this, but from my personal point of view, thereH > is now finally some kind of change in the way DEQ sees VMS, but in the eyesL > of most (and this is what brings expectations and over the loooong run theE > money), nothing has changed. No VMS mentioned. It's dead (or soon).e >tK > eg. http://www.idg.at is a local computer magazine (IMHO the most populartK > Austrian IT magazine) where Q run some ads, but of course not for VMS. Sok evenJ > the Q sales/marketing still hasn't got the (new ?) message (and I think, it- > is unfortunately not a local Q problem) ...L >M > --> > Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651= > Network and OpenVMS system manager  Fax.    +43 1 81111-888 > > FBFV/Information Services           E-mail  eplan@kapsch.netH > <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANJ > A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"D > "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998-   ------------------------------  % Date: Tue, 30 May 2000 15:20:03 -0700.7 From: "Arthur E. Ragosta" <ragosta@merlin.arc.nasa.gov>S+ Subject: Yet more ignoring of VMS by Compaqu3 Message-ID: <39343E93.A23D9B27@merlin.arc.nasa.gov>u  C I just received a questionare from Compaq and the first question isi
 "What type ofwC hardware is your agency considering?"  The possible answers includeh "Unix-basede2 Servers" and "Intel-based Servers", but no VMS!!!!  F Can't someone at Compaq get your marketing people to subscribe to this group?!t   This is getting sad.   ------------------------------   Date: 30 May 2000 22:58:02 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)/ Subject: Re: Yet more ignoring of VMS by Compaq06 Message-ID: <8h1h1q$hua$1@mailint03.im.hou.compaq.com>  m In article <39343E93.A23D9B27@merlin.arc.nasa.gov>, "Arthur E. Ragosta" <ragosta@merlin.arc.nasa.gov> writes:oD :I just received a questionare from Compaq and the first question isK :"What type of hardware is your agency considering?"  The possible answers IG :include "Unix-based Servers" and "Intel-based Servers", but no VMS!!!!e  *   What was the purpose of the questionare?  H   Without details on the questionare, I suspect this particular mailing .   is from one of the PC groups here at Compaq.  G :Can't someone at Compaq get your marketing people to subscribe to thisc :group?!  J   Please look for the list of email addresses that I posted a while back, G   and consider asking them why.  (If you do choose to directly ask this<I   question of the folks on that list, you will want to more specifically k<   identify the source of the particular Compaq questionare.)  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 31 May 2000 00:19:23 GMTp2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>' Subject: Re: [DOCUMENTATION]: Help me ?21 Message-ID: <fUYY4.4$ru5.230@typhoon.aracnet.com>s  1 Vecchiato Michele <mvecchiato@mail.tim.it> wrote:y > Hi ,  > Is there somebody can help me?G > I 'm looking for free OpenVMS 7.1 manual ( for Student or Similar) ina > the PDF  file. > I thank yuo for all answers.  % 	http://www.openvms.digital.com:8000/s  D Not quite what you're looking for, but it's the closest you'll find.   		Zane   ------------------------------  % Date: Wed, 31 May 2000 08:33:43 +0800g? From: "Samson, Hugh (PiC at Alcoa)" <Hugh.Samson2@alcoa.com.au>./ Subject: RE: [humor] UNIX/OpenVMS email "virus"oL Message-ID: <E9CFD28F6991D111A45B0000F67E4D21035CF177@aua_kwi.kwi.alcoa.com>  G The site I was at prior to this one still has in excess of 100 nodes in:L production, ranging from VLC's through clusters of 7800's running OVMS. Also  many nodes/clusters using Tru64.  B Here, we still have about two or three dozen or so across sites...  K The Uni's here are mainly still VMS, one of them is the biggest VMS site in D WA. A couple of large financial institutions are also big VMS shops.  J I am told Optus here is also quite a large site - in excess of 50 nodes in production.a  0 'Course, I have the odd cluster at home as well.  G Mind you, for the amount of VMS shops here, there's incredibly few jobsn< going - when you're on a good thing, stick to it, I suppose!   Cheers,   0 -- insert purely personal opinion disclaimer --    Hugh Samsonw   A/ Systems Administrator Alcoa Of Australia Kwinana Refinery WA      > -----Original Message-----F > From:	Geoff Roberts [SMTP:geoffrobx@stmarksx.ppx.catholicx.edux.aux]% > Sent:	Tuesday, May 30, 2000 2:58 PMT > To:	Info-VAX@Mvb.Saic.Coml1 > Subject:	Re: [humor] UNIX/OpenVMS email "virus"D >  > B > "Christopher Smith" <chriss@Mufasa.pubserv.com> wrote in messageF > news:Pine.LNX.4.05.10005241508190.15858-100000@Mufasa.pubserv.com.... > > On Tue, 23 May 2000, David A Froble wrote: > >7J > > > Darn, I only got 13 VMS systems.  Now I feel left out.  Wait, I have > 6 more atsF > > > another site!  How's 19 sound? Anybody else got a better number? > >-B > > No, but add mine to the whole count.  I've got four VAXen.  MyD > > significant-other has one -- given to her as a present actually. > Thosea
 > > are fine.  > >gH > > I know of one at a university (yes, really), and have a friend who's > gotd7 > > at least four going -- well, three vaxen and an alpd > H > Got a 6000-440 and a VS4000-90 cluster here at a K-Yr12 school, the 6KC > is the schools Web/Proxy/FTP/Mail/POP3 server, and is as close tooE > unbreakable as it gets, which is why it's still here.  Plus severalM> > VS3100's, a UvaxII, a Uvax 3400 and a 6000-430 at home......G > I know of Vaxen and Alphas in use at at least one major university ini
 > Melbourne..  > Listening Huw? > :^)o >  > Cheers >  > Geoff RobertsD > Computer Systems Manager > Saint Mark's College
 > Port Pirie,0 > South Australiap8 > geoffrob at stmarks dot pp dot catholic dot edu dot au > ICQ: 1970476 >  >   _ Alcoa World Alumina Australia is a trading name of Alcoa of Australia Limited,  ACN 004 879 298t   ------------------------------  % Date: Wed, 31 May 2000 11:53:39 +0930eA From: "Geoff Roberts" <geoffrobx@stmarksx.ppx.catholicx.edux.aux>z/ Subject: Re: [humor] UNIX/OpenVMS email "virus"o1 Message-ID: <UI_Y4.5080$N4.190714@ozemail.com.au>n  B "Samson, Hugh (PiC at Alcoa)" <Hugh.Samson2@alcoa.com.au> wrote in messagehF news:E9CFD28F6991D111A45B0000F67E4D21035CF177@aua_kwi.kwi.alcoa.com...  E > The Uni's here are mainly still VMS, one of them is the biggest VMSV site inaF > WA. A couple of large financial institutions are also big VMS shops.   Hmm, ok.  C > I am told Optus here is also quite a large site - in excess of 50  nodes in
 > production.d   Interesting.  2 > 'Course, I have the odd cluster at home as well.   Of course. ;^)  D > Mind you, for the amount of VMS shops here, there's incredibly few jobs> > going - when you're on a good thing, stick to it, I suppose!  H Seems to be the case.  The uni I was thinking of is Latrobe, another Huw is 'the man' there.    Cheers  
 Geoff Robertsn Computer Systems Manager Saint Mark's College Port Pirie,e South Australiaa6 geoffrob at stmarks dot pp dot catholic dot edu dot au ICQ: 1970476   ------------------------------   End of INFO-VAX 2000.302 ************************