1 INFO-VAX	Mon, 24 Apr 2000	Volume 2000 : Issue 228       Contents:, Catastrophic EVE/TPU documentation error :-)! Re: Dropping DECnet..don't do it! ! Re: Increase Card Record Count -- , Re: Infoserver CD-R (was: Verify of Backups)* SV: VAX CI storage vs served fibre channel" The Movie "Breaking Point" + PDP11& TPU/EVE : decwindows vs character cell UCX TCP/IP Packet Window Size  VAX - Alpha upgrade assistance  F ----------------------------------------------------------------------  % Date: Mon, 24 Apr 2000 00:48:12 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>5 Subject: Catastrophic EVE/TPU documentation error :-) / Message-ID: <3903D1FB.64A2D223@vl.videotron.ca>    VMS VAX, 7.2   EDIT/TPU  
 Then HELP EVE   % "EVE Runs on VMS or ULTRIX" :-) :-)     L Shouldn't that be a variable which automatically dials into Compaq's systemsE to find out what name Compaq's version of UNIX is this week ? :-) :-)    ------------------------------  % Date: Mon, 24 Apr 2000 00:10:36 -0400 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>* Subject: Re: Dropping DECnet..don't do it!7 Message-ID: <200004240010_MC2-A241-4DD9@compuserve.com>   J         There is one very big reason that many VMS shops resist upgrading=   to the latest release.  Cost!   F         When I worked for Princeton University, a VMS upgrade meant myC sacrificing a long weekend to do an image backup of the system disk / (RA81/RA82 to TU80/TU81) and doing the upgrade.   J         At McGraw-Hill, we had well over three thousand man hours investe= d H in an upgrade from VMS V5.5-2 to VMS V6.2.  Why?  Many reasons.  We wereH running RDB which meant that we had to upgrade RDB.  Upgrading RDB meantJ that we had to upgrade CDD. . . .  It was a production cluster and it *HA= D D TO WORK* on Monday morning.   This meant that we had to build a testC cluster, a clone of our production cluster.  We had to run baseline J benchmarks of our applications.  We upgraded the test cluster and reran t= heJ benchmarks.  Where we found performance problems, the DBA team had to wri= teH "hints files"  (I forget the correct terminolgy) to tell RDB how best toJ handle the problem transaction.   The we had to rerun the benchmarks agai= n.  J         Finally, on upgrade weekend, we broke all our shadow sets and wri= teE protected one member of each.  We booted with only one member of each J shadow set and upgraded VMS, RDB, and a bunch of other layered products. =  H On Sunday we got users in, on overtime, for go/nogo testing.   On MondayC morning, we were ready to shut down, write protect all the upgraded E shadowset members,  turn of the write protect on all of our carefully J preserved unupgraded shadow set members and bring up the original cluster=   if need be.   J         The figure I heard was 3200 man hours for everything.  How much d= id. it cost?  I will leave it to your imagination!  G         Upgrading a system your business depends on is neither easy nor ( cheap.  You do it only when you have to.    % Message text written by Terry Kennedy  <snip>J >  There were/are *huge* groups of customers parked at V4.7 and V5.5 (and=  J the V5.5 dash releases) who simply said "hell no, we won't go" because th= eyJ saw no benefit to upgrading. Until most of my customers migrated to Alpha= s : at V7.2-1, they all ran VMS V5.5-2H4 and similar releases.  J   Rather than using progressively larger sticks to hit the customers (lik= e G PVS uplifts, and then saying "yup, it's a bug but we won't fix it, even J though you're paying extra for us to support you"), Compaq should find ou= t J why the customers don't want to upgrade and, in the cases where it is pos= -  sible, address those issues.<  <snip>   ------------------------------  % Date: Sun, 23 Apr 2000 17:13:35 -0400 . From: Michael Austin <maustin@nc.prestige.net>* Subject: Re: Increase Card Record Count --/ Message-ID: <3903677F.849EB7B3@nc.prestige.net>   , This is a multi-part message in MIME format.& --------------2AC22C6924FB858102C13FF8* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit   G A simple call to the senior official at this company with a threat of a L lawsuit for not supplying all details for a patch that has already been paidJ for should jog their support team to actually do their job and provide the necessary information.  M I would suggest using PATCH or an Alpha equivilent, but that could invalidate  any support agreements.   E Other than this, as has been suggested before:  try de-installing any K installed images for this application, see if there are any new versions of K either the database or the application.  Do they use LMF?  See if there are % any hard-coded limits in the License.   I To see what files get changed when you use the CHOPTION log in to a fully D priv'ed account and before doing the CHOPTION, de-install any imagesB associated with this application, use $SET WATCH/CLASS=ATTRIB FILEK (exactly as shown).  Now issue the CHOPTION command.  You will see a LOT of H XQP access information, but the application will still operate normally.K The information will tell you when each file is accessed and whether or not  it was successful.   Michael AustinJ DBA Consultant (and pretty good VMS non-destructive hacker/troubleshooter)     Richard Wright wrote:   K > No we paid for the patch, which is why we don't want to pay an additional J > expense (i.e. a service technician) to install the patch we already paidF > for.  The patch came from SCI Video Scan for the Ultra software from > SoftwareHouse. > & > Anyone familiar with SCI Video Scan? >  > Thanks for the responses --   & --------------2AC22C6924FB858102C13FF8- Content-Type: text/x-vcard; charset=us-ascii;   name="maustin.vcf"  Content-Transfer-Encoding: 7bit , Content-Description: Card for Michael Austin  Content-Disposition: attachment;  filename="maustin.vcf"    begin:vcard  n:Austin;Michael   tel;work:704-947-1089  x-mozilla-html:FALSE org:Michael Austin, Inc 
 adr:;;;;;; version:2.1 + email;internet:michaelaustininc@hotmail.com  title:President  x-mozilla-cpt:;0 fn:Michael E. Austin	 end:vcard   ( --------------2AC22C6924FB858102C13FF8--   ------------------------------  # Date: Mon, 24 Apr 2000 01:29:44 GMT 2 From: sysrld@erebus.physics.uiowa.edu (Rick Dyson)5 Subject: Re: Infoserver CD-R (was: Verify of Backups) 3 Message-ID: <06VND1OsWlC2@erebus.physics.uiowa.edu>   V In article <8dqhvu$113d$1@Mars.mcs.net>, rjordan@Mars.mcs.net (Richard Jordan) writes: > J >> 	The other method uses an Infoserver 1000 (which I recent picked up for >> a few hundred $).I >> If you upgrade it to the last release of the software (v3.5a, I think)  >> there is a RECORDI >> command you can use to make an ODS-2 format CD-R disc *IFF* you have a  >> recorder on their >  > Rick, F >      last I heard you had to buy an Infoserver that already had the F > scribe or CDR option enabled or find some way to get the license andF > enabling software.  Unless something has changed, the V3.5a softwareD > by itself will not allow CDR operations unless those functions are" > specifically enabled by license.  B     I did not do anything special.  Just plugged it in and away itG went...  The first IS1000 I got years ago new.  I picked up another one B recently from a VAR and it came with nothing.  I have never seen a1 "license" of any kind for either IS1000 I have...    Sorry, rick   ------------------------------  % Date: Sun, 23 Apr 2000 23:03:27 +0200 0 From: "LEIF JANSSON" <leif.jansson.1@swipnet.se>3 Subject: SV: VAX CI storage vs served fibre channel 7 Message-ID: <rBJM4.10233$uJ1.24316@nntpserver.swip.net>    Hi John     @ Sorry to say, to secure the data Your need host based shadowing.E To speed up the shadow-server there are some neat logicals to set up. ( They are described in the release notes.  D Because CI is a 'cluster interconnect' and Your plans is to leave CI9 You probably need a Memory Channel connection between the J VMS-system to work as the 'Cluster Interconnect', really nice performance.  E The fibre channel works fine as 'Storage Interconnect' but be sure to - use host based shadowing to secure Your data.    /Regards Leif Jansson OpenVMS System Manager/ John Nixon <jorlnixon@worldnet.att.net> skrev i L diskussionsgruppsmeddelandet:T_NL4.25554$fV.1427898@bgtnsc05-news.ops.worldn
 et.att.net...  > Ryan,  > I > How do I get multi-site shadow sets without host based shadowing.  That 5 > would appeal to me, but I have never heard of that.  > I > As for the math,  that part is simple, if you believe that in real life  the L > math numbers hold up.  You only get the theoretical thruput numbers if youJ > eliminate every bottleneck.  With CI I have come close and  can actuallyK > sustain 7MB/second, but I am not sure what kind of config I would need to  > maintain FC thruput maximums.  >  > 7 > "Ryan C. Price" <pricerc@ihug.co.nz> wrote in message & > news:8do7mf$sbh$1@news.ihug.co.nz...2 > > CI = 140Mb/s, shared, maximum distance 30m (?)9 > > FC = 1000Mb/s, switched, maximum distance 2km (IIRC).  > > I > > The math is fairly simple. FC also gives you HS-to-HS shadowing (at a  > > price), soH > > you can have multi-site shadow sets without host-based shadowing (if > > that appeals > > to you). > > I > > Your biggest problem is getting data from FC to your VAXen. I suspect  > > that leavingJ > > your existing connections (CI and FDDI), would allow you to get access
 > > to the FC G > > disks just about as fast as you can get to your existing disks (the  > > Alphas won't addH > > much latency). You'll still want some CI attached stuff for booting, > > but you indicate& > > that you'd be keeping that anyway. > > 	 > > /Ryan  > > > > > "John Nixon" <jorlnixon@worldnet.att.net> wrote in messageE > > news:L%DL4.25856$WF.1002460@bgtnsc04-news.ops.worldnet.att.net... G > > > I know Fibre channel is faster than CI, but can someone give me a  > > subjective0 > > > description of how much faster and better? > > > + > > > My current configuration consists of: C > > >  T hree CI based VAX 7860s (each with four CIXCDS),  FDDI and  > > 10baseT  > > > EthernetI > > >  One Alhpa 8400 with four CIPCAs, FDDI, 10baseT and a bunch of SCSI  > > adapters6 > > >  One Alpha 2100 5/300 with  dual Faster Ethernet > > > B > > > The three VAXes and the Alpha 8400 are attached to four Star > > couplers with a 6 > > > farm full of HSJ52s and (ugh) MTI Stingray IIIs. > > > F > > > I am trying to decide if I should replace the MTI Stingrays with
 > > HSJ82s so 0 > > > that my VAXes can have direct connections,G > > > or should I get Fibre Channel adapters for the Alphas and connect  > > into our' > > > developing Compaq SAN that we are J > > > installing for our Unix systems (Tru64 and Solaris).  (Actually, the > > dataJ > > > would be moved from the HSJ52s to the new storage, and the data from > > the . > > > StingRays would be moved to the HSJ52s). > > > J > > > Our eventual goal is to get rid of the VAXes and move all processing
 > > to theI > > > Alphas, which would mean Fibre Channel would be the only way to go, 	 > > but I F > > > will have to make sure I don't hinder the VAX performance for at > > least a  > > > year or so.  > > >  > > >  > > >  > >  > >  >  >    ------------------------------  % Date: Sun, 23 Apr 2000 22:11:04 -0400 + From: "David Turner" <d_b_turner@yahoo.com> + Subject: The Movie "Breaking Point" + PDP11 / Message-ID: <sg7b57c5cdo172@corp.supernews.com>   L Anyone ever noticed the title in the beginning of the movie Breaking Point ?  L In the "music by" section it gives some guy's name with "his PDP11 computer"   Wow !   . Shame they never pushed Alpha's that way huh ?   How about this:   C "Indepedence day  - rendering by Digital Alpha Technology  Personal  Workstation 433a) Call 1 800 Digital for sales information"   K Instead it was Shhhhhhh... don't let them know they were using Linux on our E Alpha's - in fact, don't let them know they were using Alpha's at all    Can we say Pathetic ?????    -- David Turner Island Computers US Corporation  2700 Gregory Street  Savannah GA 31404  Tel: 912 447 6622  Fax:912 201 0096 sales@islandco.com   ------------------------------  % Date: Sun, 23 Apr 2000 21:50:37 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>/ Subject: TPU/EVE : decwindows vs character cell / Message-ID: <3903A869.635A5A3E@vl.videotron.ca>   R Something has been troubling me for a while... (ok, so that isn't news to most :-)  F If, from a DECTERM window, I  SET HOST node, and access that node as aF character cell terminal, show term reveals I am a VT300 type terminal.  J However, when I start edit/tpu, the tpu program will in fact receive mouseT events, even though DECwindows is not installed on the node on which TPU is running.  L KERMIT on the MAC will convert mouse events into arrow movement sequences toK position the curors to where you clicked. To the application, it is totally 9 transparent since it only sees arrow movements sequences.   L However, in this case, since the TPU application will issue messages such asM "no user mouse botton defined", it means that the application itself receives 
 mouse events.    Which prompts these questions:  J Does DECTERM convert mouse events into some ANSI character sequences which
 CTERM blindly N tranmits to the remote node which passes it to the application as it would any other keyboard key sequence ?   L Does DECTERM cooperate with CTERM and the remote non-decwindows node to pass8 mouse events as separate entities from keyboard events ?  M When I issue the command TPU SET (MOUSE,OFF) on the remote node, this changes J not only the TPU behaviour, but also the DECTERM behaviour since the laterE will now process mouse events locally (allowing local cut/paste etc).     J Is there a document which fully describes the type of communications whichI goes on between DECTERM and a remote host through CTERM in terms of mouse M handling ? Would the same happen if I were to telnet to a host instead of SET % HOST (CTERM) to it ? What about LAT ?    ------------------------------  % Date: Sun, 23 Apr 2000 22:36:16 -0400 0 From: arturo saavedra <arturo.saavedra@wcom.com>& Subject: UCX TCP/IP Packet Window Size> Message-ID: <000001bfad95$dd9dc560$a9f80d18@alex1.va.home.com>   Hi all..  B I have been digging around the UCX documentation but I'm a little D confused as to the correct way to define the size of packet through  UCX.    D I know that the Ethernet standard size is 1500 bytes.  If I were to E want to match Windows's NT default size of 8760 bytes/packet, is this A done through $ UCX set prot tcp/quota=(send:8760,receive:8760) or D through $ UCX set service/socket=(send:8760,receive:8760) XXX  where. XXX is whichever service I'm trying to modify?  D To confuse me even more, there is also a mentioning of TCP qualifier@ that either enables or disables MTU (Maximum Transmission Unit)  sizing.    Thanks in advance!  A p.s. reason for the attempt to match NT configuration was that of D troubleshooting a pesky emulation software to server network related problem.    A UCX version 4.2 eco 2 running on Alpha Server 8400, OpenVMS 7.1-2    ------------------------------  % Date: Mon, 24 Apr 2000 00:09:25 -0400 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>' Subject: VAX - Alpha upgrade assistance 7 Message-ID: <200004240009_MC2-A241-4DCA@compuserve.com>   J         I think you may have already been through the worst of things!  V= AXJ C allowed a lot of sleazy coding practices, including many of the sort th= atJ would trip you up in a VAX to Alpha conversion.  For example, DECC should=  J object to treating pointers as ints.  On the VAX both occupy four bytes b= utJ that is no longer necessarily true.  If you have dependencies on a 512 by= teC page size, you'll have to fix them.  If you have boundary alignment " problems, you'll have to fix them.  7         Your Macro code may require a little tinkering.   J         Compile and link on the Alpha to see how much trouble you are in.=  =  - If you get a clean compile and link, test it!     $ Message text written by "John Nixon"F >My company is finally about to make the decision to tackle the VAX to Alpha J VMS conversion.   I am looking for recommendations for  software conversi= onJ tools or consulting services, either within Compaq or external.  We are i= nT the Atlanta GA. area.:  J The application is a fairly complex one that has evolved over the past 15=  J years and is mostly written in DECC.  There are some remnants of VAX MACR= Oa code.h  G We have a programming staff, although an undermanned one.   We recentlyCC completed a huge project to convert from VAXC to DECC.  It was very-C difficult and took a long time.  Everyone is leery of another majoraJ coversion project at this time, so all we may really need is a little han= drB holding and assurance that this project won't be as difficult as C conversion.D   <4   ------------------------------   End of INFO-VAX 2000.228 ************************