1 INFO-VAX	Sun, 07 Mar 2004	Volume 2004 : Issue 132       Contents: Anyone need a MicroVax 2000 + Re: Best Backup Blocksize for 110SDLT Tape? + Re: Best Backup Blocksize for 110SDLT Tape? & Cheap CPU, RAM. PIV2.8E only US$200!!!# Check out these new VT flat panels! P Customers to purchase VMS (was: The Inquirer:   HP re-thinking its IA-64 strateg  Re: GTECH, Lotteries and OpenVMS( Re: How to Ping Between OpenVMS and Unix Interface question.  Re: Interface question. : Re: It is almost certain now, INTEL will have 64bit x86 !!% Re: Libary/CDD Question for Vax-Basic # RE: Not meaning to feed Andrew..... G Re: OpenVMS virus proof while other disks get zapped by latest viruses! G Re: OpenVMS virus proof while other disks get zapped by latest viruses! G Re: OpenVMS virus proof while other disks get zapped by latest viruses! G Re: OpenVMS virus proof while other disks get zapped by latest viruses! D Re: Professional Agitator - Harrison, Andrew. Confimed on sun.com!!!D Re: Professional Agitator - Harrison, Andrew. Confimed on sun.com!!! Re: SIMH and TK50/TK70 tapes?  Re: SIMH and TK50/TK70 tapes?  Re: SSH login problem -- Bug?  Re: SSH login problem -- Bug?  Re: SSH login problem -- Bug?  Re: Sun On The Run?  Re: Sun On The Run? 6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy?6 Re: The Inquirer:   HP re-thinking its IA-64 strategy? Re: Two Node Cluster Config  Re: Two Node Cluster Config C Two problems: qui$ external and procedure division using (external)  Re: Zip/update Issue Re: Zip/update Issue Re: Zip/update Issue$ [OT] I won 2 million euros. So what?3 Re: [OT] We've always know that Solaris is junk.... 3 Re: [OT] We've always know that Solaris is junk....  Re: [TCPIP V5.4] More rants   F ----------------------------------------------------------------------  # Date: Sat, 06 Mar 2004 02:37:47 GMT 0 From: Randy Park <rjpark@mindspring.nospaam.com>$ Subject: Anyone need a MicroVax 20008 Message-ID: <ctdi40p0en1evsqinufmqd85rvkbip7ukj@4ax.com>  E I'm cleaning out the office and I no longer need my MicroVax 2000.  I L know it's old.  I basically used it for testing installs and other stuff.  IF used it both as a satellite node in a cluster and booting from its own@ disk.  It has VMS 5.2 loaded on an RD53 (~72MB).  It also has an expansion box on the bottom.  E I'm currently in Seattle, Washington but will be driving to San Diego 
 in early May.   D Anyone interested?  I would rather not toss in in the garbage can ifM someone can use it.  I doubt that it's worth the trouble to list it on E-Bay.   G E-Mail me at   rjpark  _at_  mindspring _dot_ com if you're interested.    ------------------------------  % Date: Fri, 05 Mar 2004 22:06:46 -0600 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>4 Subject: Re: Best Backup Blocksize for 110SDLT Tape?6 Message-ID: <40494E56.2A0EA75E@NeOaSrPtAhMlNiOnWk.net>   Bob Koehler wrote: > { > In article <4047E32E.9BFEABAF@NeOaSrPtAhMlNiOnWk.net>, "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  > L > > So, while that may have been an issue in the past, I believe it has beenL > > cleared up since VMS V7.1 and later (including mandatory BACKUP patches)) > > when BACKUP got some major revisions.  > F >    News to me.  I've been doing multi-volume backup and restore everD >    since standalone backup was introduced with VMS 3.0.  Never had9 >    a problem on any media (9-track, TK, 4mm, 8mm, ...).   H Same here. This is not the first I've *EVER* heard of it, just the first! I've heard in a *VERY* long time!    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 05 Mar 2004 22:08:41 -0600 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>4 Subject: Re: Best Backup Blocksize for 110SDLT Tape?6 Message-ID: <40494EC9.5036D55D@NeOaSrPtAhMlNiOnWk.net>   Bob Koehler wrote: > k > In article <xjP1c.41090$ko6.355664@attbi_s02>, "Tom Simpson" <thomas.simpson1@nospam.comcast.net> writes:  > > N > > One other (obvious) thing that was not pointed out here is that if you areM > > writing small save sets (smaller than your selected block size), the tape I > > has to write the whole block, so space and time may be wasted in that 6 > > situation.  On image backups, that's not an issue. > D >    What kind of tape has that problem?  Every tape technology I'veG >    looked that deeply into can write the last block of a file shorter  >    than the blocksize.  E Then again, it's not really a hardware issue. As long as the software ? can handle a tape record spanning physical media, hey - whiskey 	 tango...?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 7 Mar 2004 05:26:27 GMT * From: " Sales" <hologrammachinery@vsnl.net/ Subject: Cheap CPU, RAM. PIV2.8E only US$200!!! 3 Message-ID: <c2ebq3$dtt1677@imsp212.netvigator.com>   < We sell cheap computer hardwares, CPU, RAM, Motherboard etc.! Call: +86 13708077010 for a quote    ------------------------------   Date: 6 Mar 2004 18:39:04 -0800 ( From: bob@instantwhip.com (Bob Ceculski), Subject: Check out these new VT flat panels!; Message-ID: <d7791aa1.0403061839.db8e99@posting.google.com>   1 I have one on order to test ... they are awesome!   - http://www.midcomdata.com/terminal/planar.htm    ------------------------------  % Date: Sat, 06 Mar 2004 07:58:51 +0100 " From: Didier Morandi <no@spam.com>Y Subject: Customers to purchase VMS (was: The Inquirer:   HP re-thinking its IA-64 strateg 2 Message-ID: <404976dd$0$296$626a14ce@news.free.fr>   Bob Ceculski wrote:  ../.. A > forget intel ... many of those alpha engineers would, given the < > chance, love to come back and continue EV8-9 if they saw a? > commitment by HP ... and if they drop itanium, they will have > > to start back up alpha support ... or they will lose massiveC > amounts of high end high margin customers who pay for support and @ > services, because hospitals and banks and stock markets cannot> > just go to unix/linux/windows and watch there businesses get8 > hacked to pieces by hackers, viruses and downtime../..   All,  K I generally avoid these endless discussions, but Bob, you raised a crucial  N point, which is the focus point of all we think and are talking about in this ! forum since COMPAQ took over DEC.    Why do we fight for VMS?  7 1. because is is one of the best operating systems ever    2. because we love it   E 3. because the current users love it too and do not want to consider  / replatforming to anywhere (or they already did)    Conclusion:   O Let's set up a financial operation which would allow the existing community of  . VMS users to purchase VMS engineering from HP.   Terry?   D.   ------------------------------   Date: 6 Mar 2004 15:01:59 -0800 7 From: jones.computer.srv@worldnet.att.net (Daryl Jones) ) Subject: Re: GTECH, Lotteries and OpenVMS = Message-ID: <8a646952.0403061501.40d8bcd0@posting.google.com>    Dear John Smith:  A What you are taunting about is theory. What I am talking about is A real. I was there fixing the 11.x server build just after VMS was F abandon. So, when I said the reason was financial rather than anythingC else, this was reason being said internal to Sybase in 1997. At the D end of 1997, Sybase was supposed to be in the black. However, it wasA found out that Sybase Japan had counted 90-day licenses as sales. B Supposedly, all of the Japanese personnel were let go. Sybase wentC from black to red, which cause the laying off of all contractors. I D wasn't affected. I already had another contract setup. Sybase neededE to financially grow out of their problems. VMS didn't have the growth A potential. Sybase/VMS had some big customers like GTECH and a big E financial company in NYC that had a lot of weight in Sybase. So, they = had to give the VMS users until 2004 before pulling the plug.   ? I believe the reason GTECH stayed with Sybase was the number of A conversion (500 routines)that needed to be done before going with B Oracle as stated by another poster who works at GTECH. He can talk" further for himself on that issue.  E As for the lost of base users, that was expected and seen starting in A 1992 by DEC. The low end systems went to the cheaper systems. The B graphics stations were lost to the UNIX stations. The back lash to? propiety OS and cost had come about. Ken Olsen was trying to be > another IBM when he should have been like Intel and Microsoft.2 Remember, DEC was a hardware and software company!  D In my mind, the blame lands squarely on Palmer shoulders for sellingD Rdb. I believe Rdb was #3 amongst databases at that time frame. HereF was the reason to buy a VMS platform and later DEC UNIX and MS NT. YouC must have a reason to buy and an OS by it self isn't enough. By the D time Compaq bought DEC, the damage was already done! Now, HP is left with a shell to promote.  . I still have hope. IBM mainframes still exist!     Regards, Daryl Jones   r "John Smith" <a@nonymous.com> wrote in message news:<WH%1c.87329$sl.43631@news01.bloor.is.net.cable.rogers.com>... > Daryl Jones wrote: > > Dear John Smith: > > J > > When Sybase made the decision to go to fewer platforms to support, VMSE > > was going to be one of them. However, Sybase was in such terrible J > > financial problems with red ink. They had to go for the platforms thatF > > had growth potential to dig their way out of red ink to black. The% > > problem wasn't VMS but Sybase!!!!  >  > N > No. The reason Sybase dropped VMS was that Digtial/Compaq were doing nothing, > to ensure that the VMS market was growing. > J > With Digital/Compaq doing ZERO advertising and marketing for VMS, SybaseM > rightly concluded that for them to continue banging their heads against the L > wall in the VMS space made no financial sense as they'd never recoup theirG > investment in develpong and supporting new versions of Sybase ASE (or  > whatever) on VMS.  > K > Customers are generally more loath to switch db vendors than they are o/s L > vendors, so when Sybase said to its VMS customers that it was time to moveI > to unix just how many of Sybase's customers decided to switch to Rdb or I > Oracle just so they could stay with VMS long term? The majority of them K > decided to slowly migrate from VMS/Sybase to Unix/Sybase. Sybase kept the  > customer, not VMS. > J > Time has proven that Sybase's decision was correct as the VMS market hasM > shrunk considerably since their decision, as it has also proven correct for $ > may other former VMS ISV partners. > @ > THe blame falls squarely on the shoulders of the executives at > Digital/Compaq, and now HP.    ------------------------------  $ Date: Sat, 6 Mar 2004 11:24:47 +0100; From: "Nico van der Boom" <posthere-answerhere@hotmail.com> 1 Subject: Re: How to Ping Between OpenVMS and Unix = Message-ID: <4049a6e4$0$3880$3a628fcd@reader1.nntp.hccnet.nl>    You need a router to do this. , A router has ip adresses in both ip-subnets. You can use a host as a router.    suggestion: A add a second ip adress on the interface of the unix or vms system   6 In the VMS environment you can add a pseudo interface.   example & when you use the UCX of TCPIP package.: suppose you have an interface called we0    (ucx show int) add a pseudo interface  @ $ ucx set interface wea0 /host=192.1.2.250/network=255.255.255.0 /broad=192.1.2.255. (check syntax, i am not on a system right now)  4 a pseudo interface has an 'a' in the interface name.  A so with ewa0 device, ucx interface we0, ucx pseudo interface wea0   F now the vms system is reachable from the unix machine with 192.1.2.250! (assuming this is a free address) 7 the unix system is reachable with the original address.   F i use this to do subnet hopping , because you can add and change these1 interface addresses without restarting anything !   D (eg, old lexmark printer interfaces used 192.0.0.192 as a default ipH adress., when somebody plugged in a new printer on a remote network, addE pseudo interface 192.0.0.193 and you can connect for configuration of  printer)  
 greetings. Nico  : "Yong Boon, Lim" <limyb@megasteel.com.my> wrote in message$ news:c29kte$5bm$1@news4.jaring.my...	 > Friend,  > D >     l've one OpenVMS server and one Unix server on SINGLE physical network  > WITHOUT gateway in between. / >     These systems have different subnet, i.e.  > 
 >     OpenVMS  >         IP : 192.168.3.2  >         Subnet : 255.255.255.0 > 
 >     Unix >        IP : 191.1.2.2  >        Subnet : 255.255.255.0  > D >    In order for both system to be able to "PING" each others, what exact ' > configuration (and command like Route 5 >    or UCX Add Route?) should l add to both systems?  >  >     Thank in advance!  > 
 > Regards, > Lim  >  >    ------------------------------   Date: 6 Mar 2004 19:11:33 -0800  From: schocm01@yahoo.com (Mike)  Subject: Interface question.= Message-ID: <b46df3d5.0403061911.5dd251c2@posting.google.com>   = I was wondering if anybody knew of a linux package that would C communicate with DecmessageQ.  I am trying to build a low cost test E environment at work and I need to send messages via the DecmessageQ.  C I am interfacing with a Vax 4100 running VMS 6.2 with DecmessageQ.   Thanks for any assistance.   ------------------------------  % Date: Sat, 06 Mar 2004 23:36:31 -0500 - From: "John E. Malmberg" <wb8tyw@qsl.network>   Subject: Re: Interface question.1 Message-ID: <ZpidnflvuPRSO9fdRVn-jQ@adelphia.com>    Mike wrote: ? > I was wondering if anybody knew of a linux package that would E > communicate with DecmessageQ.  I am trying to build a low cost test G > environment at work and I need to send messages via the DecmessageQ.  E > I am interfacing with a Vax 4100 running VMS 6.2 with DecmessageQ.   > Thanks for any assistance.  H I do not really follow DecmessageQ, but IIRC, there was an announcement G about a LINUX offering that would communicate with the current OpenVMS  7 offering.  I do not know about backwards compatability.    -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------  % Date: Sat, 06 Mar 2004 13:25:34 +0100  From: Dirk Munk <munk@home.nl>C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! 2 Message-ID: <c2ch18$nqa$1@news4.tilbu1.nb.home.nl>  ( Andrew Harrison SUNUK Consultancy wrote: > Dirk Munk wrote: > + >> Andrew Harrison SUNUK Consultancy wrote:  >> >>> Rick Jones wrote:  >>> ' >>>> Andrew Harrison SUNUK Consultancy  3 >>>> <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  >>>> >>>>> Rick Jones wrote:  >>>>> ) >>>>>> Andrew Harrison SUNUK Consultancy  5 >>>>>> <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  >>>> >>>> >>>> >>>> >>>>F >>>>> What exactly don't you understand ? the MAXCPU configs on F15K'sF >>>>> or the differences between this and the configuration of a 8400. >>>> >>>> >>>> >>>> >>>>H >>>>> Discussions about trading the 17 I/O slots (you need 1) for MAXCPUL >>>>> cards in F15K's are irrelevent in a discussion about the configuration* >>>>> restrictions of an AlphaServer 8400. >>>> >>>> >>>> >>>> >>>>J >>>> Tell you what - you can pick first - which would you like to be?  The. >>>> pot? Or the Kettle?  I'll take the other. >>>>C >>>> I didn't say the tradeoffs were identical, I said they sounded I >>>> similar.  They are similar in that if you want the maximum CPU count I >>>> on the 15K, you have to have the minimum I/O count.  If you want the H >>>> maximum I/O, you could not have the maximum CPUs on the 15K.  I see) >>>> that as similar, perhaps you do not.  >>>> >>> H >>> However since this discussion was about a 64bit OS to support a DBMSA >>> being able to open very large amounts of memory the fact that D >>> you can do this on a F15K with a very large number of CPU's (72)H >>> a very large amount of memory (576 GB) and a very high I/O bandwidth7 >>> tends to rather destroy the point of your argument.  >> >> >>I >> Was there a F15K when the 8400 was on the market? By the way the 8400  J >> max. I/O configuration was 12 hoses with 12 PCI slots each, or 144 PCI  >> slots in total. >> > = > No but the E10000K was, do you need to know anything else ?   5 No, we still have some of those old dinosaurs around.    > H >> What is the purpose of writing about the ancient 8400? Most of those > >> will have been scrapped by now. We did over the past years. >> > D > And that from someone who introduced the PDP11 into the discussion2 > do I really need to respond ????????????????????  1 I could have known you would not understand this. N I did not "introduce the PDP11" , I just used it to show that a certain trick ) had been performed some odd 30 years ago. O I made remark about the 8400 because *you* are comparing it with a present day   F15K.      >  > H >> The point was that a 64 bit *architecture* was developed on which 64 H >> bit operating systems could run that were capable of addressing lots F >> of memory. It was all about *vision*, about future directions, and E >> setting up a path to that future. At the time the Alpha appeared,  J >> memory was still very expensive, about a 100 times more expensive then I >> now. I doubt if anyone could have build a working computer with let's   >> say 128GB at the time.  >> > C > You cannot compute anything on Vision or Roadmap and the sad fact A > is that at the time of the Digital 64bit marketing BS fest they A > hadn't managed to design a system that allowed you to make much 5 > practical use of the 64bit features being marketed.  > > > That only arrived sort of with higher density memory and the > GS140.  O Rubbish. At the time they bumped into the 32 bit barrier, and the next logical  I step was the 64 bit cpu. Even doubling the max. 32 bit memory space in a  P computer system was a big step forward. Maybe Digital could have done the PDP11 P trick again (or other slow memory management tricks), but they did not. Instead L they went for a true 64 bit system, that was the vision. To think that they Q would have had to build computer systems with some 600GB internal memory at that  + time to justify a 64 bit cpu is ridiculous. I At this moment VMS is capable of addressing 8TB internal memory. Are you  P suggesting that this is only justified if we can actually purchase systems with 	 8TB ram ?    >  > @ >>> A fully configured F25K has 54 x 66Mhz 64 bit PCI busses and" >>> 18 x 33 Mhz 64 bit PCI busses. >> >> >>I >> Busses or slots? How many slots in a bus ? A standard PC for instance  I >> has 1 PCI bus, with 5 slots. All slots have to share the bandwidth of   >> the bus.  >> > , > Busses thats what the post said wasn't it.  Q I know what the post said, I just wanted to verify that busses, slost and bridges    > H >> By the way, you accused me of having the facts wrong on the E4900. I F >> showed you where the information came from (the SUN web site), and C >> since then it was very quiet, I haven't seen any reply from you.  >>K > http://www.sun.com/products-n-solutions/hardware/docs/pdf/805-7362-12.pdf   Q That pdf is about the 6800/4810/4800/3800 systems. But thank you for pointing me  M   to this site. Now at last I can help my SUN support collegues with usefull  N information about the I/O subsystems of SUN systems. Trying to find the right A information on the SUN web site is hopeless according to them(!!)    > 	 > regards  > Andrew Harrison  >  >    ------------------------------  # Date: Sat, 06 Mar 2004 02:49:44 GMT 0 From: Randy Park <rjpark@mindspring.nospaam.com>. Subject: Re: Libary/CDD Question for Vax-Basic8 Message-ID: <snei401agafvks59k1v2tmbdfec734n5eq@4ax.com>  J On 4 Mar 2004 15:21:30 -0800, vibroplex@mindspring.com (Derek Cohn/WB0TUA) wrote:   >Dear Friends, > A >You guys have been very helpful in the past and I'd like to pose B >another question.  Currently, I have a data file with a structureG >defined in a CDD.  I have a text library entry that points to the data F >in the CDD.  In my VAX Basic code, I use a %include statement for theC >text library and the structure in the CDD is brought in at compile  >time just fine. > F >My question is about using a parallel data structure identical to theD >entry in the CDD.  I need to create another file that must have theE >identical structure to the first file.  I thought the best way to do G >this was to try to use the same CDD entry for both (so I wouldn't have D >to maintain two entries to keep them synchronized).  My bright idea >didn't work (compile errors). >  >Here's the record in the CDD: >  >DMU> lis edidb_record           >   EDIDB_RECORD;1 <CDD$RECORD>  >DMU>                            > A >Here are the two library objects pointing to the same CDD entry:  > 2 > %INCLUDE %FROM %CDD "FILES.EDIDB_RECORD"        2 > MAP ( EDIDB.MAP ) EDIDB_RECORD    EDIDB         2 > MAP ( EDIDB.MAP ) STRING EDIDB_T_RECORD =  512  2 >                                                 2 > %INCLUDE %FROM %CDD "FILES.EDIDB_RECORD"        2 > MAP ( AEDIDB.MAP ) AEDIDB_RECORD          AEDIDB2 > MAP ( AEDIDB.MAP ) STRING AEDIDB_T_RECORD =  512 > ) >Here are examples of the compile errors:  > D >%BASIC-E-CDDDUPREC, (1) record EDIDB_RECORD from CDD/Repository has >duplicate name  > G >%BASIC-E-CDDAMBFLD, (1) ambiguous field name EDIDB_RECORD::T_PONO from  >CDD/Repository  > D >Can anyone suggest how I can use the single CDD entry to define twoD >identical structures in my program?  I'm a novice with both the CDD= >and the Library utility so any detailed explanation would be  >gratefully accepted!  >  >Thanks, >  >Derek Cohn   N I've never used includes from CDD, but I have used DEC style BASIC for over 25 years.  I'd try the following:  ( %INCLUDE %FROM %CDD "FILES.EDIDB_RECORD"( MAP ( EDIDB.MAP ) EDIDB_RECORD    EDIDB ( MAP ( AEDIDB.MAP ) EDIDB_RECORD   AEDIDB  A This allows you to have the same record layout with two different  MAPs.      ------------------------------  $ Date: Sat, 6 Mar 2004 19:22:07 -0500' From: "Main, Kerry" <kerry.main@hp.com> , Subject: RE: Not meaning to feed Andrew.....R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB2795FA@tayexc19.americas.cpqcorp.net>   > -----Original Message-----, > From: Andrew Harrison SUNUK Consultancy=203 > [mailto:Andrew_No.Harrison_No@nospamn.sun.com]=20  > Sent: March 5, 2004 7:44 AM  > To: Info-VAX@Mvb.Saic.Com . > Subject: Re: Not meaning to feed Andrew..... >=20 > Main, Kerry wrote: >=20 > >=20H > > Check this out: an extract from what you posted as a means of not=20A > > attacking OpenVMS, but attacking HP while at the same time=20  > trying to=20 > > put Sun on a pedestal. > >=20
 > > [snip ..]  > >=20 > >=20. > >>From: Andrew Harrison SUNUK Consultancy=202 > >>[mailto:Andrew_No.Harrison_No@nospamn.sun.com]" > >>Sent: January 23, 2004 6:01 AM > >>To: Info-VAX@Mvb.Saic.Com + > >>Subject: Re: 500.000 AMD64's shipped...  > >=20 > >=20I > >>There is a huge difference between being late to deliver a product=20 @ > >>(every IT vendor is guilty of this) to not delivering the=20 > product at=20 E > >>all because you have decided to axe it without consulting your=20  > >>customer base. > >>B > >>Sun is the first category along with Intel, IBM, SGI etc HP=20 > is in the=20 > >>second category. > >=20 > >=20* > > To which I replied and pointed out:=20 > >=20 > > ++++=20 8 > > Re: Sun not in category of axing products without=20 > consulting Customers.. > >=20 > > ROTFL !! > >=20 >=20  > Ohhh dear ohhh dear ohhh dear. >=20 >=20D > Firstly was there a mass outcry when we dropped the Cobalt brand ? >=20
 > yes or no ?  >=20  E Well, there is this article which you might find interesting feedback G from some of those involved in that whole $2B fiasco. Also, it has some D valuable insight into just how much (or rather little) the Sun folks think of Linux.   2 http://www.theregister.co.uk/content/35/34673.html) "Sun and Cobalt left me with a dinky toy"   E [snip..]...You obviously have read a bunch of propaganda. Those of us E that use server appliances are scrambling to create a replacement for E the Cobalt line. There are a few GUIs available, but the cost in some  cases is prohibitive."  G So, answer me this Andrew, do you think this was a good decision by Sun 0 i.e. promote a product and then totally kill it?  @ > How about the one example you really didn't want to mention=209 > Solaris x86, Sun dropped it, our users complained we=20 ? > reinstated it and Solaris 10 for x86 is available for beta=20  > customers etc. >=20  + Come on Andrew, lets not get silly here.=20   H This is exactly the type of marketing crap that I was talking about. TheF back tracking decision had little to do with end users, but rather theD black eye Sun was receiving in the press and with its Customer base.  H Sun simply dropped their Solaris/x86 Customers with little thought givenD to protecting their existing investments. What were they supposed toH move to? Their only option was Solaris on SPARC i.e. buy more SPARC hw -% which no doubt was the original idea.   D They also only gave their end users a few months notice telling themF that Solaris 9 would not be available on the x86 platform when it came out.  , Needless to say, the public outcry was huge.  H It was only after all those Solaris users threatened to install Linux orE Windows on their Solaris / X86 boxes and made the issue a very public E one before Sun realized the size of their mistake and back tracked on  the decision.=20  
 Reference:3 http://www.eweek.com/article2/0,1759,1500963,00.asp   E "Sun Microsystems Inc.'s refusal to release Solaris 9 for non-Sun x86 G hardware could backfire and drive developers and users to Linux or even ' Microsoft Corp. platforms, users said."   D Disgruntled x86 community developers and customers charge that Sun'sH refusal to reach a compromise is effectively making their investments in? non-Sun x86 hardware obsolete. Supporters are so irked by Sun's F intransigence that last week they placed an open letter in The MercuryC News, of San Jose, Calif., accusing Sun Chairman, President and CEO < Scott McNealy of taking the developer community for granted.  @ "Sun has now obsoleted [my] x86 hardware investment," Al Hopper,D president of Logical Approach Inc., of Plano, Texas, told eWeek lastE week. Hopper's company bought several dual-processor x86 systems from D Advanced Micro Devices Inc. last year. "We can't afford to scrap ourH hardware infrastructure just because Sun decides [Solaris on x86] wasn't? a viable product or that they could make more money elsewhere."   G Alan DuBoff, president of consultancy Software Orchestration Inc., also B of San Jose, and one of the "secret six" community representativesH negotiating with Sun over the Solaris-on-x86 issue, said he supports theC anti-Sun campaign. "Unless we get a stand-alone product for non-Sun H hardware, we will be hard pressed to use Solaris x86 in the enterprise," DuBoff said.  	 [snip ..]   F ""I now have to decide whether to stick with Sun over the long term or? move to solutions like Red Hat [Inc.] on Dell [Computer Corp.], E [Hewlett-Packard Co.] or IBM. While I'm skeptical about Linux, Sun is # forcing our hand," Groenveld said."    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  Email: kerryDOTmainAThpDOTcom . (remove the DOT's and AT for email address)=20   ------------------------------  % Date: Fri, 05 Mar 2004 22:07:16 -0500 ' From: Stuart Fuller <stufuller@usa.net> P Subject: Re: OpenVMS virus proof while other disks get zapped by latest viruses!0 Message-ID: <49fb2c.pbn.ln@dadsys2.fuller.local>   Bob Ceculski wrote:   K > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> ? > wrote in message news:<c29u2b$6fq$1@new-usenet.uk.sun.com>...  >> Bob Ceculski wrote:? >> > I don't know if anyone has noticed, but a lot of companies ; >> > are getting creamed by the latest round of viruses ... < >> > My boss has 4 friends from other companies who have all> >> > lost servers ... but our "unhackable" virus proof OpenVMS< >> > servers just keep humming along 24X7 ... isn't it great >> > to be on OpenVMS?  :) >>  = >> It may have escaped your notice but the only OS's infected 9 >> by the viruses you refer to are Windows based. By your 7 >> definition that makes all other OS's from Solaris to  >> Palmos unhackable.  >>  
 >> Regards >> Andrew Harrison > < > go look at the latest certs for slowaris and linux and VMS- > then come back and tell us all about it ...   % Geez, haven't you two had enough yet?    --             Stu    ------------------------------   Date: 6 Mar 2004 18:09:08 -0800 ( From: bob@instantwhip.com (Bob Ceculski)P Subject: Re: OpenVMS virus proof while other disks get zapped by latest viruses!= Message-ID: <d7791aa1.0403061809.292099b5@posting.google.com>   j bill@cs.uofs.edu (Bill Gunshannon) wrote in message news:<c2d0rh$1rv0t1$3@ID-135708.news.uni-berlin.de>... > K > Uhhhh....  Bob just said he runs "powerterm for vt emulation".  Powerterm J > is a Windows program, not a VMS program. He may not see it, recognize itJ > or be willing to admit it, but he is running Windows, just like everyoneI > else.  He doesn't have VMS to the desktop and his employers systems are & > just as vulnerable as anyone else's. >  > bill  9 we use both vt's and where internet/mail access is wanted < we use thin clients w/built in powerterm and either internet; exploder or mozilla ... their are no disks ... the software ; is built in to the thin screen along with speakers ... they 9 are not vulnerable as VMS is also not ... there have been : vt emulation thin clients for years now ... unhackable and< a good option for a vt when someone wants internet and email= access along with VMS access ... you can run all of your apps 9 on VMS ... Word11 for word processing, 20/20 or lotus for > spreadsheets, Goldfax, Yahmail ... the list goes on and on ...9 we have very few windoze clients ... with VMS no need for  that virus trap garbage ...    ------------------------------   Date: 6 Mar 2004 18:31:52 -0800 ( From: bob@instantwhip.com (Bob Ceculski)P Subject: Re: OpenVMS virus proof while other disks get zapped by latest viruses!= Message-ID: <d7791aa1.0403061831.40921384@posting.google.com>   j bill@cs.uofs.edu (Bill Gunshannon) wrote in message news:<c2d0rh$1rv0t1$3@ID-135708.news.uni-berlin.de>... > K > Uhhhh....  Bob just said he runs "powerterm for vt emulation".  Powerterm J > is a Windows program, not a VMS program. He may not see it, recognize itJ > or be willing to admit it, but he is running Windows, just like everyoneI > else.  He doesn't have VMS to the desktop and his employers systems are & > just as vulnerable as anyone else's. >  > bill  > try this company bill ... they can get you a thin client built; with garbage linux and just about any vt emulator you would  want loaded on ...  1 http://www.midcomdata.com/thinclient/Welcome.html    ------------------------------   Date: 6 Mar 2004 18:37:41 -0800 ( From: bob@instantwhip.com (Bob Ceculski)P Subject: Re: OpenVMS virus proof while other disks get zapped by latest viruses!= Message-ID: <d7791aa1.0403061837.35daa4b8@posting.google.com>   j bill@cs.uofs.edu (Bill Gunshannon) wrote in message news:<c2d0rh$1rv0t1$3@ID-135708.news.uni-berlin.de>... > K > Uhhhh....  Bob just said he runs "powerterm for vt emulation".  Powerterm J > is a Windows program, not a VMS program. He may not see it, recognize itJ > or be willing to admit it, but he is running Windows, just like everyoneI > else.  He doesn't have VMS to the desktop and his employers systems are & > just as vulnerable as anyone else's. >  > bill  = and check out this vt flat panel terminal bill ... I have one  on order to test ...  - http://www.midcomdata.com/terminal/planar.htm    ------------------------------  $ Date: Sat, 6 Mar 2004 12:03:05 -0800* From: "Jack Peacock" <peacock@simconv.com>M Subject: Re: Professional Agitator - Harrison, Andrew. Confimed on sun.com!!! 2 Message-ID: <fN2dnVUPG5Pns9fdRVn_iw@mpowercom.net>  / "GreyCloud" <mist@Cumulus.com> wrote in message 1 news:XUm2c.726$Wc4.1392@bcandid.telisphere.com...S > J > Well, it is rather obvious that a Sun rep. would troll a VMS news group.I > By injecting biased comments into a vms newsgroup he can show potentialsH > customers that are thinking of OpenVMS as a solution to look into thisD > newsgroup for the various problems that crop up.  But then one canI > always go into a Solaris newsgroup and find that they too have many andE > various problems.  > I First, it's not very likely any future VMS customers (for argument's sake K we'll assume they exist though this is based on facts not in evidence) willeA be hanging out in the VMS newsgroup in order to evaluate systems.s  E Second, everyone who expresses an opinion is biased, so what?  I findsI Andrew's comments to be relevant and useful.  Not that I'd ever buy a Sun K Sparc system, but I do respect Sun for seeing the future and moving to AMD.rI If we also assume Itanium (again, for argument's sake only) will flourishdI then it will be facing real competiton from Sun AMD64 servers, so a voice-# from the opposition is appropriate.   E If all we had on this newsgroup were the "blind to the outside world"nB postings of the most loyal VMS followers it would be a dull place.    Jack Peacock-   ------------------------------  # Date: Sat, 06 Mar 2004 23:16:14 GMT4" From: GreyCloud <mist@Cumulus.com>M Subject: Re: Professional Agitator - Harrison, Andrew. Confimed on sun.com!!!r7 Message-ID: <2Zs2c.733$Wc4.1408@bcandid.telisphere.com>t   Jack Peacock wrote:   1 > "GreyCloud" <mist@Cumulus.com> wrote in messager3 > news:XUm2c.726$Wc4.1392@bcandid.telisphere.com...r > J >>Well, it is rather obvious that a Sun rep. would troll a VMS news group.I >>By injecting biased comments into a vms newsgroup he can show potential H >>customers that are thinking of OpenVMS as a solution to look into thisD >>newsgroup for the various problems that crop up.  But then one canI >>always go into a Solaris newsgroup and find that they too have many andj >>various problems.' >> > K > First, it's not very likely any future VMS customers (for argument's sake-M > we'll assume they exist though this is based on facts not in evidence) will C > be hanging out in the VMS newsgroup in order to evaluate systems.  > G > Second, everyone who expresses an opinion is biased, so what?  I findkK > Andrew's comments to be relevant and useful.  Not that I'd ever buy a SunVM > Sparc system, but I do respect Sun for seeing the future and moving to AMD.rK > If we also assume Itanium (again, for argument's sake only) will flourishsK > then it will be facing real competiton from Sun AMD64 servers, so a voices% > from the opposition is appropriate.  > G > If all we had on this newsgroup were the "blind to the outside world"nD > postings of the most loyal VMS followers it would be a dull place. >    Jack PeacockI >  > 6 It's still obvious that he is trolling for Suns' sake.   ------------------------------  % Date: Sat, 06 Mar 2004 02:49:49 -0500-( From: David Froble <davef@tsoft-inc.com>& Subject: Re: SIMH and TK50/TK70 tapes?, Message-ID: <4049829D.3080501@tsoft-inc.com>   Lee Roth wrote::  ? > I have an old Microvax with a TK70 tape drive that I'd reallyEB > like to get rid of... (hint: it has a low WAF - "Wife Acceptance= > Factor") but I still have some TK50 and TK70 tapes that I'm"B > interested in (maybe, someday) reading the files from- they wereB > all made with VMS BACKUP. Most of the data is text, but some are > binaries.n > D > I was wondering if I got a TKxx/DLT2000 SCSI tape drive (that willA > handle reading TK50/TK70 format tapes) if I could do one of the  > follwing:b > ? > 1) Find some kind of Linux-compatable program that could readi@ > the *.BCK file savesets from tape onto Linux (and then on into > VMS running via SIMH)h > D > 2) Use 'dd' to suck the entire tape into an image file under Linux* > and then mount it somehow under SIMH/VMS > A > Or... do I just need to get a cheapie little Alpha with SCSI tof > do all of this?e > 	 > Thanks!w >   L Forget the tape drive.  TK50s and TK70s aren't real capable, so the storage Q cannot be much, unless you have LOTS of tapes.  Restore the data, then put it on  R CD or DVD.  Don't know what type of data, might be some things to play with a bit.   Dave   -- O4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Roadn Vanderbilt, PA  15486t   ------------------------------  # Date: Sat, 06 Mar 2004 13:30:00 GMTl4 From: "Roert G. Schaffrath" <rschaffrath@yahoo.com>& Subject: Re: SIMH and TK50/TK70 tapes?% Message-ID: <4049D259.3F4F@yahoo.com>h  F I just went through a similar situation myself although with 4mm tapesF instead of DLT's.  I am hoping, shortly, to recreate an old VMS V5.5-2B environment I used to run 7 1/2 years ago using the VAX simulator:  ? > 1) Find some kind of Linux-compatable program that could readt@ > the *.BCK file savesets from tape onto Linux (and then on into > VMS running via SIMH)   B There are two versions of a utility floating around the net calledF VMSBACKUP that run under Unix/Linux systems.  It will read a VMSBACKUPG directly from a tape drive and the latest and best version I have foundh so far (V4) is available atpX http://groups.google.com/groups?selm=118451%40philabs.Philips.Com&oe=UTF-8&output=gplainH in .shar format.  The V4 version will also read a BCK file directly fromF disk but first you have to get the saveset off of the tape without the
 ANSI headers.   B Unfortunately, this was a problem for me due to lack of a suitableG hardware environment to get a 4mm tape drive running under a Unix/Linux.E system (I have a narrow SCSI 4mm tape drive but; no SCSI card on handtH for the Linux box, an IBM AIX RS6000 system that only supports Wide SCSIG and a Solaris RISC box with an IDE drive and no SCSI card).  However, IsF have a Windows NT system with both a 40/80 DLT and 4mm drive.  Using aG freeware Windows utility called tapeio (http://www.lowth.com/tapeio/) IrG was able to grab both a raw TAP image (which should be suitable for theaB SIMH simulator) and the main saveset itself without the ANSI stuffH (VOL1, HDR1, HDR2).  Then I copied the image over to my Linux system andH ran VMSBACKUP V4 against it and was able to extract most of my data.  ItF should be noted that the Unix VMSBACKUP tool is 14+ years old and doesE not recognize all of the record formats in newer savesets.  It chokedtA with an "unknown record type 34" on .mai, .qman$queues, sysuaf.*, C .vue$dat, and .ldb files to name a few.  I had to modify the sourceeD several times to ignore these files and then rerun to get a complete extract of my source files.    > D > 2) Use 'dd' to suck the entire tape into an image file under Linux* > and then mount it somehow under SIMH/VMS > A > Or... do I just need to get a cheapie little Alpha with SCSI tow > do all of this?c > 	 > Thanks!t   ------------------------------  % Date: Sat, 06 Mar 2004 05:03:27 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)& Subject: Re: SSH login problem -- Bug?; Message-ID: <40494d8f.524144494f47414741@radiogaga.harz.de>i  2 [No SSH logins to accounts with expired passwords]  4 Alan Frisbie (Usenet01REMOVE@Flying-Disk.com) wrote:? > OK, I can buy that.   What would be a good work-around for usG  > given the following situation: >-? >    1. All the accounts in question are captive accounts (i.e.h >       no DCL prompt allowed).  >u8 >    2. All user account passwords expire every 90 days. >i> >    3. Some users need access to our application from outside> >       the building, using their laptop computer, an Internet= >       connection, and (most likely) Kermit-95 v2.1 (we loven
 >       it!).s >aD >    4. We are paranoid about security, so we would like to use SSH. >a@ >    5. Some of these users are outside sales people who may not@ >       visit our facility more than once a year, if that, so we@ >       have to handle expiring passwords without their physical >       presence.r  ? How about using public key authentication instead of passwords?o   The userA - generates a public/private key pair, encrypting the private keys   with a passphrase.I - loads (via scp and password, of course) his public key onto the server.a8 - copies the server's public host key onto his computer.4 - feeds his private key into his SSH client program.) - upon connecting, enters his passphrase.t  > That way, the server is authenticated (via the host key), too.  ' The SSH manual should have the details.    cu,    Martin  D P.S.: I'm a strong supporter of Kermit, too. Didn't know that it has        SSH now. Well done, Frank! -- wA  Your mouse has moved.     | Martin Vorlaender  |  OpenVMS rules!e4  Windows must be restarted | work: mv@pdv-systeme.deG  for the change to take    |   http://www.pdv-systeme.de/users/martinv/h;  effect. Reboot now? [OK]  | home: martin@radiogaga.harz.deE   ------------------------------  % Date: Fri, 05 Mar 2004 21:15:34 -0800e3 From: Alan Frisbie <Usenet01REMOVE@Flying-Disk.com>b& Subject: Re: SSH login problem -- Bug?. Message-ID: <40495E76.4090505@Flying-Disk.com>   Bob Ceculski wrote:   C > if you are worried about security, I hope you are using ssh2, not.5 > ssh, and TCPware ssh2 is very easy to configure ...y  $ It is ssh2, according to the manual.   Alan   ------------------------------  % Date: Sat, 06 Mar 2004 12:11:03 +0100e* From: Paul Sture <nospam@sture.homeip.net>& Subject: Re: SSH login problem -- Bug?0 Message-ID: <4049BFD7.18FC88CE@sture.homeip.net>   Alan Frisbie wrote:  >  > Rob Young wrote:h > > In article <4048C171.4060607@Flying-Disk.com>, Alan Frisbie <Usenet01REMOVE@Flying-Disk.com> writes: > >a > >>Martin Vorlaender wrote: > >c > >rB > >> OK, I can buy that.   What would be a good work-around for us# > >> given the following situation:  > >>A > >>   1. All the accounts in question are captive accounts (i.e. ! > >>      no DCL prompt allowed).  > >>: > >>   2. All user account passwords expire every 90 days. > >>@ > >>   3. Some users need access to our application from outside@ > >>      the building, using their laptop computer, an Internet? > >>      connection, and (most likely) Kermit-95 v2.1 (we lovep > >>      it!).c > >>F > >>   4. We are paranoid about security, so we would like to use SSH. > >>B > >>   5. Some of these users are outside sales people who may notB > >>      visit our facility more than once a year, if that, so weB > >>      have to handle expiring passwords without their physical > >>      presence.t > D > > How many connections (unique login/out) per day on average?  Any > > metric on that?w > @ > Unknown at this time, but I'll guess that it will be less than@ > 10 initially (across all accounts).   That would probably grow@ > to 30 or more over the next year as they discover how useful aA > tool it is for making sales.   Eventually, we're hoping that iti > will grow much larger. > @ > On a somewhat related note, I see that telnet connections haveD > the terminal name as "TNAxxx", while SSH connections are "FTAxxx".@ > Unfortunately, console logins are also "FTAxxx".   Is there an@ > easy way to distinguish an SSH login from a console login (in, > say, SYLOGIN.COM)? >    I don't know if this helps...   , Are you running TCP/IP, Multinet or TCPWARE?   On a TCPWARE system I see that  2 $ write sys$output f$getdvi("TT","TT_ACCPORNAM")    * returns my ISP address prefixed by "ssh/".  4 On a Multinet system it returns just my ISP address.  F Using ssh into my own TCP/IP system (from either of the above systems) it returns nothing.   $ All 3 products use an FTAnnn device.   --  
 Paul Sture   ------------------------------  $ Date: Sat, 6 Mar 2004 00:45:24 +0100  From: "Dr. Dweeb" <dr@dweeb.com> Subject: Re: Sun On The Run?, Message-ID: <c2b3ek$e48$1@news.cybercity.dk>   Daryl Jones wrote: > Dear Andrew Harrison:  >t > First: >nB > Why is Andrew Harrison trying to argue with this article in this' > forum? You need to go the Linux site!  >m	 > Second:a >nF > What is being done to SUN by LINUX it is the same thing SUN has beenG > doing to HP, IBM, Compaq, and others and vise versa. Take over a DatanF > Center by initially cutting its prices and then later boosting them.$ > Business as usual in the IT world. >p > Third: >a4 > What does Andrew Harrison have to do with OpenVMS? >o   Why, I thought everyone knew?!  J Andrew is Suns official, highly paid, professional agitator.  He providesK sport, and very often (ie. when not talking about VMS) some astute insightseH into the goings on in the big server marketplace. Eg. His Itanic take isK pretty close to the mark IMHO.  He gets paid to shit on VMS.  He wins some, J he retires from other threads when he cannot win.  I never go to the otherG OS forums, so I do not know whether he agitates there or another person J does.  Either way, he gives c.o.v colour and the PSBs here someone at whom to vent.  
 Dr. Dweeb.  
 > Regards,
 > Daryl Joness >  >b7 > Andrew Harrison SUNUK Consultancy <Andrew No.Harrisono& > No@nospamn.sun.com> wrote in message. > news:<c29tha$669$1@new-usenet.uk.sun.com>... >> Daryl Jones wrote: ' >>> Home > Technology > Enterprise Tech- >>>-	 >>> Linux- >>> Sun On The Run? & >>> Daniel Lyons, 03.03.04, 9:52 AM ET >>>mG >>> NEW YORK - Gerry Louw is a longtime fan of Sun Microsystems and its5E >>> powerful Unix-based computers. In fact, he has been running Sun'snE >>> pricey machines at various companies for more than ten years. YetuC >>> today, Louw, chief information officer of VMS, a 1,000-employee E >>> company in New York, is ripping out hundreds of Sun servers in 162G >>> locations and replacing them with inexpensive servers running Intel-2 >>> processors and Linux, a free operating system. >>>  >> >> Sigh. >>
 >> FirstlyC >> Linux will not be free unless they intend to only use OpenSourceRD >> components and in reality they are highly unlikely to save money.B >> This is one of the most pervasive Linux myths. There are placesC >> where Linux saves mone, but general purpose tier 2 and 3 serving  >> is not one of them. >>@ >> Just for grins pull the HP sponsored Linux TCO studies or the? >> RedHat ones, spot the obvious attempts to make Linux cheapertB >> than Solaris/AIX etc, remove them and hey presto it costs more. >>? >> Makes you wonder why they had to assume that a company would A >> use Sun 6800s as tier 1 web servers and then compare that with A >> the costs of using 2 way Xeons running Linux as one study did.- >>? >> Secondly everything is cyclical, the project I am working on A >> is for a company with 120000 employees, we are replacing everya> >> single HP and IBM server and thats over a 1000 systems with? >> a rather smaller number of Sun's and 2 years in we know thatt >> this has saved money. >>B >> Or how about the NHS, Sun is replacing a range of small systemsC >> some windows some not with much larger centralised stystems. TheuB >> deal is worth  250,000,000 to Sun or put another way almost theF >> same revenue as 2 years worth of worldwide OpenVMS server revenues. >>
 >> ThirdlyH >> What does this have to do with OpenVMS except to compare and contrastF >> the revenues Sun is getting from one project in one customer in the4 >> UK with the total worldwide revenues for OpenVMS. >>
 >> Regards >> Andrew Harrison >> >>> For more of this article:A >>> 5 >>> http://www.forbes.com/technology/2004/03/03/cz dlo >>> 0303linux.html?partne 
 >>  r=newscom  >>>p/ >>> As you can see, the article is from FORBES.> >>>  >>> Regards, >>> Daryl Jones    ------------------------------  # Date: Sat, 06 Mar 2004 02:07:32 GMT # From: "John Smith" <a@nonymous.com>r Subject: Re: Sun On The Run?G Message-ID: <Ena2c.100468$sl.9854@news01.bloor.is.net.cable.rogers.com>a  + "Dr. Dweeb" <dr@dweeb.com> wrote in messageh& news:c2b3ek$e48$1@news.cybercity.dk... > Daryl Jones wrote: > > Dear Andrew Harrison:x > >C
 > > First: > >ID > > Why is Andrew Harrison trying to argue with this article in this) > > forum? You need to go the Linux site!  > >  > > Second:S > > H > > What is being done to SUN by LINUX it is the same thing SUN has beenI > > doing to HP, IBM, Compaq, and others and vise versa. Take over a DataeH > > Center by initially cutting its prices and then later boosting them.& > > Business as usual in the IT world. > > 
 > > Third: > >e6 > > What does Andrew Harrison have to do with OpenVMS? > >0 >   > Why, I thought everyone knew?! >sL > Andrew is Suns official, highly paid, professional agitator.  He providesD > sport, and very often (ie. when not talking about VMS) some astute insightsJ > into the goings on in the big server marketplace. Eg. His Itanic take isG > pretty close to the mark IMHO.  He gets paid to shit on VMS.  He winsi some,tL > he retires from other threads when he cannot win.  I never go to the otherI > OS forums, so I do not know whether he agitates there or another personlL > does.  Either way, he gives c.o.v colour and the PSBs here someone at whom
 > to vent.    K So what you're really saying is that if Andrew weren't here, we'd just have  to invent him anyway?  ;-)   ------------------------------  $ Date: Sat, 6 Mar 2004 14:27:09 -0500* From: "Bill Todd" <billtodd@metrocast.net>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy?a2 Message-ID: <U7idnaKswqV0uNfdRVn-uA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:rBluam+XAleS@eisner.encompasserve.org...e4 > In article <40495F50.9F454B0B@istop.com>, JF Mezei# <jfmezei.spamnot@istop.com> writes:e > >>G > > IA64 isn't seen as winner on both technological and business sides.  >s1 > Depends who or what sources you read or ignore.e >y  > www.computerbusinessreview.com >dK > "This is probably one reason why the uptake for Itanium-based ES7000s has  beenL > stronger than Unisys expected. According to Mark Feverston, vice president of@ > platform marketing for enterprise servers at Unisys, last year
 Itanium-basedsH > ES7000s accounted for about 30% of sales, about twice what the company > expected."  J Gee, Rob:  that might sound impressive if '30% of sales' actually amounted. to a hill, or even a smallish mound, of beans.  G But since *total* Itanic sales are still, to be generous, sluggish, andtG since HP accounts for something over 90% of that smallish total, Unisys H clearly isn't selling enough Itanic ES7000s to signify squat - except toL their own spinmeisters (who, you will note, carefully avoided mentioning any1 absolute sales numbers in the article you cited).i  L This is hardly surprising, of course:  back when Compaq and (IIRC) HP resoldL ES7000s, they decided that the sales volume wasn't worth continuing to do soK and cut the cord, even though they had no home-grown substitute for them toa offer their customers.   - bill   ------------------------------  # Date: Sat, 06 Mar 2004 23:16:16 GMTd& From: John Reagan <john.reagan@hp.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy?s0 Message-ID: <4Zs2c.365$Li5.190@news.cpqcorp.net>   JF Mezei wrote:a   > K > Nop. the digital compiler people (except for John Reagan) were donated asBP > slaves to Intel. And when/if IA64 is dumped, it will more likely be Intel that > is happy to dump it.  F Well, thanks for the "shout out", but the number is closer to several A dozen of us compiler folks left (people doing front-end work and -G back-end work).  However, you are correct.  There are fewer of us then 0 there used to be.t   -- t John Reaganr# HP Pascal/{A|I}MACRO Project Leadert Hewlett-Packard Companyu   ------------------------------  $ Date: Sat, 6 Mar 2004 18:36:17 -0500* From: "Bill Todd" <billtodd@metrocast.net>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy? 2 Message-ID: <r5KdnYsaktLQ_dfdRVn-gg@metrocast.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messageM# news:404A3036.93D2C721@istop.com...n   ...a  F > HOWEVER, if HP were to adopt Alpha, it could transform itself into a leading5D > enterprise vendor with technologically suprior products of Digital combined4 > with HP's marketing, mind share and customer base.  J That would almost certainly have been true in 2001, around the time of theI Alphacide.  After nearly three additional years of market- and mind-share I losses (due both to the Alphacide itself and continued lack of enthusiasmnH for the Digital products by its owners), it's far less likely to be true today.  I I doubt that there's any way now for HP to escape the fate that it has sonK assiduously crafted for itself:  the best it can likely do is slow the rate.J of descent to a point where it might achieve a soft landing as a shadow ofJ its former (composite) self rather than have to seek a buyer as Compaq didK (though Compaq could have recovered, given competent leadership:  Alpha andp1 its systems were still very viable at that time).(   >lI > Tandem was partly ported to Alpha. Not sure how far away they were, but  EV7 J > was the first chip capable of supporting NSK (with lockstepping). So one wouldrF > expect that NSK should have been ready more or less coinidental with release%	 > of EV7.E  D Not according to the roadmaps back then:  NSK wasn't scheduled to be) released on Alpha until around now, IIRC.    >2J > It would probably be easier to port HP-UX bits to Tru64 then the reverse sinceSK > the stuff ported from Tru64 to HP-UX is core stuff, not fluffy utilities.   K Not necessarily.  1) AFAIK, there was no attempt to create a complete Tru64 I environment on HP-UX, just to port some of the more critical goodies (but/E moving the HP-UX base would likely require pretty much complete HP-UXsE environment support on Tru64 to be feasible).  2) AFAIK, there was nonL attempt to soften the potential impact of moving from little-endian Tru64 toK big-endian HP-UX (and any attempt to move HP-UX users to a Tru64 base woulds% likely *have* to address that issue).g   - bill   ------------------------------  $ Date: Sat, 6 Mar 2004 00:40:44 +0100  From: "Dr. Dweeb" <dr@dweeb.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy?M, Message-ID: <c2b35r$dca$1@news.cybercity.dk>   Sue,  D The Inquirer is almost always VMS positive, and also Alpha positive.L However the Itanic is not high on the popularity stakes there - and for goodL reason.  Also, you know what, all the gossip about the Alpha was dead right,K despite pontifications to the contrary by a now no longer existing company.gK There are very good reasons to suspect thet the IA64 is in some trouble.  I K personally do not think that Intel is ready to dump $2B in investment yet - K but time is definitely running out - with disastrous ramifications for VMS.:  J Enjoy your job, while you still have one - unlike the VMS professionals of4 the world who have moved on due to lack of a future.  
 Dr. Dweeb.   Sue Skonetski wrote: > Folks, >aF > The sky is still not falling.  If we were to spend our time writtingD > rebuttals to everything the Inquirer said, we would spend our lifeF > doing it instead of real work, and while that may please some folks,A > we would not make our roadmaps.  Lets face it how many negativeaF > articles have there been about (you choose) companies, CEO's, chips,> > printers, people, plain gossip.  I can not believe that this7 > intelligent bunch of people gives credence to gossip.  >>C > Terry Shannon has posted a note on his page with permission of hpcC > http://www.shannonknowshpc.com/stories.php?story=04/03/05/2668752n >o > Sue  >> >t; > fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in messaget; > news:<f30679fb.0403041647.28a64584@posting.google.com>...  >> THE DARKNESS IS FALLING ... >> >>, >> http://www.theinquirer.net/?article=14521 >> >>. >> Sending a message to Intel about the Itanic >> >>7 >> By INQUIRER staff: quinta-feira 04 maro 2004, 17:21h >>H >>  RUMOURS - and they remain just that as we write this ? suggest HP isD >> thinking about making big changes to its IA-64 (Itanium) line up,B >> with May Day expected to be the day when it's all change at theE >> company. One rumour has it that HP could even EOL the IA-64, whichaH >> would certainly drop a bombshell on planet Intel - and which we think >> somewhat unlikely.w >>F >> HP has a complicated set of roadmaps which place the Itanium at the4 >> centre of its future for large scale enterprises. >>F >> But we understand that HP is more than a little upset at Intel over< >> its recent announcement of 64-32 bit Xeons and Prescotts. >>D >> How HP would square the end of the line of the IA-64 to its largeA >> corporate and federal customers remains unclear. It has made apD >> commitment to migrate OpenVMS to the IPF platform, and there's no+ >> word of change from that division of HP.o >>G >> But we're watching closely to see just what it intends to do towardso$ >> the end of April and early May.    ------------------------------  % Date: Fri, 05 Mar 2004 19:06:11 -0500 * From: Chuck Chopp <ChuckChopp@rtfmcsi.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy?l: Message-ID: <Hy82c.49632$0l1.24160@bignews3.bellsouth.net>   JF Mezei wrote:s  P > Alpha solves only the raw performance problem of IA64. It doesn't solve binaryI > compatibility. And it doesn't solve the fact that the 8086 will be massh8 > produced while Alpha would still be a low volume chip.    K What ever happened to the FX-32 product that Digital had developed?  I had sG my little Multia running WinNT v4.0 with FX-32 installed and was quite sK successfully running x86 applications at that time.  Did the technology at tJ the heart of FX-32 get canibalized and turned into the IA32/x86 emulation G services for Windows running on IA64?  I know Intel released this very aH recently for Microsoft to use with Win64, but I'm curious as to whether H Intel developed it completely from scratch or if they used FX-32 as the  underlying basis for it.     -- 0 Chuck Choppn  8 ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com1                                    ICQ # 22321532s@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 774 0718 pagerC                                    8007740718 (at) skytel (dot) coms  , Do not send me unsolicited commercial email.   ------------------------------  $ Date: Fri, 5 Mar 2004 21:01:44 -0500* From: "Bill Todd" <billtodd@metrocast.net>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy? 2 Message-ID: <OLednSQhxal5rdTdRVn-vg@metrocast.net>  > "Sue Skonetski" <susan_skonetski@hotmail.com> wrote in message7 news:857e9e41.0403051434.1f13f8ef@posting.google.com...b > Folks, >  > The sky is still not falling.   1 Pay no attention to the man behind the curtain...r  '   If we were to spend our time writtingtD > rebuttals to everything the Inquirer said, we would spend our lifeF > doing it instead of real work, and while that may please some folks,! > we would not make our roadmaps.c  F That's all right:  informed observers wouldn't believe such statementsF anyway, given cHumPaq's history of misrepresentation and outright liesE (that's a corporate slur, Sue, not aimed specifically at you - thoughuK well-meaning HP employees have been known to propagate lies quite earnestly $ when they believed them to be true).      Lets face it how many negativeF > articles have there been about (you choose) companies, CEO's, chips,> > printers, people, plain gossip.  I can not believe that this7 > intelligent bunch of people gives credence to gossip.d  J Only from sources that have proven at least somewhat accurate in the past,J and when the gossip conforms to what one might reasonably expect.  In such8 cases, it's far more credible than what comes out of HP.   >-C > Terry Shannon has posted a note on his page with permission of hpFC > http://www.shannonknowshpc.com/stories.php?story=04/03/05/2668752h  K Ah, yes - the mellifluous sound of spin continues to emanate from the usualeI orifices.  However, Terry seems to be in some mild disagreement even withdB the memo which he quotes (and which Fred just echoed, in his usualK uncritical manner).  The memo and Fred claim that HP's inclusion of Opteron B systems is a pure 32-bit play (of course, that still means that HPK acknowledges that AMD has an edge over Intel in that space, but while InteleJ might not be happy with that statement it doesn't cost HP anything), whileG Terry opines that it's to cover the 64-bit ISS gap until Intel's me-tootL implementation becomes available (something HP might well be loath to admit,L since it would acknowledge that the 64-bit server space is not the exclusiveK province of the wallowing Itanic - even in the sacred temple of HP itself).k   - bill   ------------------------------  % Date: Fri, 05 Mar 2004 22:26:00 -0500l* From: Chuck Chopp <ChuckChopp@rtfmcsi.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy?y9 Message-ID: <zsb2c.60426$Tn.17254@bignews5.bellsouth.net>-   Bill Todd wrote:  9 > "Chuck Chopp" <ChuckChopp@rtfmcsi.com> wrote in message 6 > news:Hy82c.49632$0l1.24160@bignews3.bellsouth.net... >  > ...t >  > L >>What ever happened to the FX-32 product that Digital had developed?  I hadH >>my little Multia running WinNT v4.0 with FX-32 installed and was quite5 >>successfully running x86 applications at that time.a >  > F > Reportedly ISVs were reluctant to certify (and sometimes even merelyG > support) their IA32 software running under FX!32, good though it was.tJ > Whether any relatively normal IA32 code (that would run under 32-bit NT)0 > *actually* had problems on FX!32 I don't know.  H I was able to run WinDoom [the Win32 version of Doom II] just fine, and K after an hour or two of playing it the profiler had converted enough of it e, ot native code that it played very smoothly.     >  >   Did the technology atr > K >>the heart of FX-32 get canibalized and turned into the IA32/x86 emulationb' >>services for Windows running on IA64?  >  > L > Not according to a conversation I had last year with Anton Chernoff, IIRC:D > while the functions were similar, the development was independent.  L I was just curious... when you've seen a duck before and somebody claims to G have invented something new that walks, quacks, flies and swims like a .F duck... you get curious about the origins of that new duck-like thing.     -- b Chuck Chopp-  8 ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com1                                    ICQ # 22321532j@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 774 0718 pagerC                                    8007740718 (at) skytel (dot) comi  , Do not send me unsolicited commercial email.   ------------------------------  % Date: Sat, 06 Mar 2004 00:19:47 -0500M* From: JF Mezei <jfmezei.spamnot@istop.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy? ) Message-ID: <40495F50.9F454B0B@istop.com>h   Sue Skonetski wrote:    > The sky is still not falling.     	 Dear Sue,s  N IA64 isn't seen as winner on both technological and business sides. So when HPJ announces it is moving to a better CPU, it will be seen as an improvement.9 There is no loyalty to IA64 like there is/was with Alpha.   L When Compaq annouced it was moving from the techonogically superior Alpha toJ the very chip that Digital employees had been lambasting, it was seen as aL downgrade. And when it became evident that IA64 wouldn't replace the 8086 asL industry standard (as had been touted initially), the business case for IA64
 fell through.1  L Also, from a customer point of view, remember that on June 24th 2001, CompaqN was still promising a very bright future and long roadmap for Alpha. There hadN been plenty of warnings since Curly got the job as head of Compaq. On June 25, Compaq did a 180.t  8 Fool me once, shame on you. Fool me twice, shame on me.   N In light of what is happening to and around IA64, HP's promises of business asL usual for iA64 are less credible than Compaq's promises about alpha prior to June 25.   ------------------------------  % Date: Sat, 06 Mar 2004 21:29:10 -0500-. From: Glenn Everhart <Everhart-nospam@gce.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy?s3 Message-ID: <404a891f$0$3101$61fed72c@news.rcn.com>m  B FX-32 was an excellent idea. Its problem was that it emulated userA mode stuff only, not the kernel stuff, and had to depend on theren= being a version of the kernel stuff that was "the same" as on  the x86 platform.l  A Microsoft was "supposed" to provide that. They did not. Also theyu@ kept changing DLLs around so it was pretty nearly impossible for@ any third party to keep up with the changes. (That was somethingA they probably thought of as self protection.) With x86 apps usingw? constantly changing DLLs, no way to follow them yourself and no = way to get updates fast enough from the OS vendor being used, = maintaining compatibility with everything x86 was impossible.o  C This does NOT mean that a more complete emulation, including kernelo@ stuff, could not be done using the same methods. That would mean> a "more virtualized" machine but at least the interface, beingE hardware, would be slowly changing enough to follow. It would howeverr< result in running something like a VMware box on top of your@ other OS, with a real copy of whatever x86 OS you wanted running= in there (having had to be bought with real money of course).,B Communication with it might work less transparently than one might= like too. However it would give a way to have high throughputn" x86 code on J random architecture.    > In the real world, this sort of thing is feasible if your host? architecture is way faster than x86. So the key question is: is > IA64 way faster than X86-64, or is it not? If not, then a full6 bore kernel-mode-too FX-32 is a lot of work, for what?  ? Far as VMS goes, its code is undoubtedly much more portable nowGA (having been through ports from VAX -> Alpha -> IA64) than it was4= 15 years ago, and maybe a port to x86-64 is now easy. GettingoA demand for such a thing though would seem to depend on convincinga@ people they need its security and care for their data as well as> its scalability. As long as IA64 chips are being made, though, this seems an odd request.  < Think about this: if VMS sells because it gives much greater> security than other OSs, is it really wise to try to find ways? to put miserably insecure x86 code onto the platform and try toS= get it to work? Might this not simply enable whole classes ofu? security holes to which VMS has hitherto been immune? If you'ret> not interested in anything on 32 bit x86, too, what differenceB does it make that you use IA64 for your safe computing rather than x86-64?s  = (It would be nice to see more mention of VMS security and theV> fact it still is made out in commercial space. I just got doneD reading a RISKS forum comment speaking of the late VAX/VMS platform.? It is probably true most of the world does not even realize VMSnA is still made and runs on currently available processors. Howevero= much people speak of VMS' advantages, if they don't know that A it is still made and runs on some processor that hasn't been deadi9 for 5+ years, how will it get considered for any uses???)s   Glenn Everhart   Chuck Chopp wrote:   > JF Mezei wrote:- > E >> Alpha solves only the raw performance problem of IA64. It doesn't   >> solve binaryfJ >> compatibility. And it doesn't solve the fact that the 8086 will be mass9 >> produced while Alpha would still be a low volume chip.  >  >  > I > What ever happened to the FX-32 product that Digital had developed?  I  G > had my little Multia running WinNT v4.0 with FX-32 installed and was KE > quite successfully running x86 applications at that time.  Did the fG > technology at the heart of FX-32 get canibalized and turned into the  I > IA32/x86 emulation services for Windows running on IA64?  I know Intel tG > released this very recently for Microsoft to use with Win64, but I'm  I > curious as to whether Intel developed it completely from scratch or if r1 > they used FX-32 as the underlying basis for it.r >  >    ------------------------------  % Date: Sat, 06 Mar 2004 21:39:18 -0500o* From: JF Mezei <jfmezei.spamnot@istop.com>? Subject: Re: The Inquirer:   HP re-thinking its IA-64 strategy? ) Message-ID: <404A8B38.1166351C@istop.com>a   Bill Todd wrote:K > Alphacide.  After nearly three additional years of market- and mind-share K > losses (due both to the Alphacide itself and continued lack of enthusiasm J > for the Digital products by its owners), it's far less likely to be true > today.  M However, consider that HP, should it decide to adopt Alpha next monday, would L have a couple of years to work on Alpha before all its products would run onM it. And while you think EV8 is a holy grail, HP could probably produce one orlK two more shrinks to bump the speed up until Alpha is back on track. And youaJ can bet that there would not be any sticks in Alpha engineers's wheels and2 they'd have the right budgets to get the job done.  M  Despite being very late and purposefully slowed down, EV7 still packed quiteeM a punch. Imagine what they could do to the architecture if the engineers weree+ given carte blanche and the right budgets ?   K > I doubt that there's any way now for HP to escape the fate that it has soa! > assiduously crafted for itself:   H We can arguem about Carly's hairstyles, but she seems to be very good atM convincing the press and the wall street casino analysts. I suspect she would G have no problem finding a face saving way out of the current situation.i  L As long as PARISC and Alpha still have some punch, there is no urgency sinceG customers will avoid IA64 like the plague. There is however a window ofbK opportunity where NSK and VMS could be widthheld from commercial release onl* IA64, avoiding support issues for 5 years.  , > the best it can likely do is slow the rateL > of descent to a point where it might achieve a soft landing as a shadow ofL > its former (composite) self rather than have to seek a buyer as Compaq did  M I am not so sure. HP could ride IA64 for a few years, or it could ride PARISCnN and Alpha for a couple of years. To me, admitting the IA64 mistake would raise my respect for HP.  D The problem with HP is that the Alpha murder has compromised its ownK credibility when it says that IA64 is safe and has a 3 year roadmap. (heck,i4 didn't Alpha have something like a 7 year roadmap ?)   ------------------------------  % Date: Sat, 06 Mar 2004 08:01:52 +0100H" From: Didier Morandi <no@spam.com>$ Subject: Re: Two Node Cluster Config2 Message-ID: <40497792$0$303$626a14ce@news.free.fr>   Jack Trachtman wrote:   / > I have a two node cluster with a quorum disk.t > : > I want a configuration where either node can continue toB > run even if both the other node and quorum disk are unavailable. > B > Is giving each node its own quorum disk the only way to do this?   No.u  3 To me, the best way is not to use any quorum disks.tN I have build dozen of clusters since more than 20 years and never created any Q quorum disk. I even do not see why this feature exist. The way of thinking which pM states "if one of my systems crashes, I'll stop the whole production" is not   understandable to me.d   My 2 euros.i   D. -- p2 VAXUS - Your new helpful friend in the DEC Family!2 EHQ: 19 chemin de la Butte, 31400 Toulouse, France/       Phone: +336 7983 6418 Fax: +335 6154 1928h$                 http://www.vaxus.org   ------------------------------  * Date: Sun, 7 Mar 2004 02:40:48 +0000 (UTC)7 From: moroney@world.std.spaamtrap.com (Michael Moroney)s$ Subject: Re: Two Node Cluster Config( Message-ID: <c2e23g$23l$1@pcls4.std.com>  . "Hans Vlems" <hvlems.dotweg@zonnet.nl> writes:  K >With network interconnects there's no way to have the quorum disk attachedcK >to both nodes at the same time (unless you're running 11/750's with sharedrJ >RA8x or RM80's). There's no way to configure votes that either or the two+ >nodes can fail and keep the other running.   H Ever hear of fibrechannel drives?  How about shared SCSI busses?  QuorumG disks work just fine on either.  It is certainly true that quorum diskse4 simply don't make sense unless it's on a shared bus.  > >"Jack Trachtman" <Jack.Trachtman@vmmc.org> schreef in bericht >>C >> Is giving each node its own quorum disk the only way to do this?   J >As you write, the only way to do this is to give each node its own quorum >disk.  I aaaargh!  There can only be one quorum disk in a cluster.  Unfortunately, J there is no checking of this so this abuse of quorum disks can easily lead to partitioned clusters.  C > We had a two node VAX3100 cluster set up like that, with shadowedsK >disks on both nodes. It ran for a year before a DEC service engineer foundoJ >out that not only was this unsupported, it was also guaranteed to corruptI >our disks. Since that hadn't happened during that year the claim did notlM >cause panic. But DEC wanted to stop all maintenance contracts on the cluster J >unless at least one quorum disk was replaced. Eventually a third node was >added.o  H The DEC engineer was correct (except I very much doubt he said 'at least: one quorum disk).  If you ever had two nodes running each D thinking they were their own cluster (a partitioned cluster) withoutF being aware of the other, and they have something shared between them,E (usually a disk, but it could be something like a machine the clusternD controls), you WILL get weirdness when both try to access the sharedG widget.  The simpest example is a disk on a shared scsi bus between two I alphas (or a fibrechannel drive).  First cluster mounts the drive, all is,H OK.  Second node/cluster mounts it, thinks the last mounter crashed (theJ drive metadata will say it's mounted), and rebuilds the drive.  There goesH all the headers/lbns the first node cached for itself.  One node createsK a file.  The second node also creates a file, perhaps using the same header.H as the first node since it thinks it's free, effectively deleting it, or- perhaps using the same blocks, corrupting it.e  G With shadowing, you'll lose data.  Your shadowset will be split between E the two clusters.  Update a database on the shadowset on one cluster.oB Update it on the second (which will have no knowledge of the firstJ update, of course).  Later the nodes form a single cluster.  The shadowsetI when mounted will go into a full copy, since the shadowing metadata won't E match.  One drive will copy over the other.  Poof! There goes all the @ updates performed on one of the nodes!  (Which one?  Depends...)  I >There were no multiply allocated blocks or other errors on any disk. Thet& >PEdriver is the "shield" so to speak.  J Except the lost changes to the shadowset on one side, which you apparently didn't notice.  L PEDRIVER isn't any sort of shield.  The quorum hang (which you defeated) is.       --   -Mike    ------------------------------  # Date: Sat, 06 Mar 2004 23:15:08 GMTs" From: tutor_removespam_@cfl.rr.comL Subject: Two problems: qui$ external and procedure division using (external)8 Message-ID: <5omk40540fam4aqdrbbqop351tqbodnf9t@4ax.com>  C Two problems: qui$ external and procedure division using (external)o  3 Email your answer to    tutor AT cfl DOT rr DOT comf
 Thank you.    ' =======================================h HELP !  - The old vax computer allowed almost anything.w> The new alpha computer stops at almost every little detail (or oversite of the vax?).  A Do you have a solution or explanation for the following problems:r  = 1) Procedure division can no longer use an external variable.l    (implicitly defined).          LINKAGE SECTION.   '        COPY "COM$CPY:FUNCTION-INFO-SP".     .        PROCEDURE DIVISION USING FUNCTION-INFO.          P0000-MAINLINE.  &            CALL "LIB$GET_SYMBOL" USING0                BY DESCRIPTOR "LSS_COMPANY_CODE",/                BY DESCRIPTOR FNCI-COMPANY-CODE,S                OMITTED,n                OMITTED,f                 GIVING WS-STATUS.  D 2) qui$_display_form (etc) can not be external defined within Cobol.  %    Do not understand this one at all.-D    What is the error and what change was made, and more importantly, how do we correct it?O  4 01  QUI$_DISPLAY_FORM           PIC 9(09) COMP VALUE7                             EXTERNAL QUI$_DISPLAY_FORM.i4 01  QUI$_QUEUE_DESCRIPTION      PIC 9(09) COMP VALUE<                             EXTERNAL QUI$_QUEUE_DESCRIPTION.   ------------------------------  # Date: Fri, 05 Mar 2004 23:15:58 GMTm& From: Don Sykes <paladin@mydomain.com> Subject: Re: Zip/update Issuee< Message-ID: <OS72c.6392$8X1.5874@newssvr27.news.prodigy.com>   David J. Dachtera wrote: > Don Sykes wrote: >  >>David J. Dachtera wrote: >> >> >>>Don Sykes wrote:H >>>o >>>e
 >>>>[snip]I >>>>All the SEzip files and standard zip files are created on the NT then K >>>>zipped together and then ftp'd (as bin) to VMS. Then I just do an unzipw >>>>on VMS.n >>>u >>>)K >>>O.k. There's the piece that was ambiguous. At first it appeared that you I >>>were trying to use VMS ZIP to update a file within an archive produced  >>>on a non-VMS system.r >>F >>Yes. That IS it. Once the SEzip files have been unzipped onto my VMSH >>server they are ready to be distributed (downloaded to customers), BUTJ >>they still don't contain a valid license, because I need the customer toF >>enter stuff on my VMS web server to create the valid license, THEN IE >>need to update the files with the newly created licenses and that's H >>where the problem comes in. If I didn't have to update them they couldD >>be downloaded from VMS and they would work fine(they just wouldn't >>contain the right licenses). >  > 8 > O.k. Let's see if I understand the sequence of events: >  >  1. UNZIP selfextr.exeG >     ?: If you only need to update one file in the archive, why do youn >        bother to UNZIP?i > B >  2. Replace one file in the directory tree(s) with a new version > * >  3. ZIP/UDPATE selfextr.exe vms_filespec5 >     (which actually makes both 1 and 2 unnecessary)o > = >  4. Make "selfextr.exe" available to customer for download.s > K > Seems to me the problem occurs somewhere between steps 1 and 2, and that >+ > ZIP is not really involved at that point.l    E No. I was originally trying to explain how I got my SEzip files that  H were created on NT to my VMS server and the answer is I zipped them all E together. In other words, I have 4 SEzip files on my NT, which I zip ,G together and ftp the composite zip to my VMS server. Then I unzip that >F composite zip file onto VMS, leaving 4 SEzip files now on VMS. If you @ look at the VMS file attributes of any of these, they look like:  @ Organization: SEQ   RecordFormat: STMLF     RecordAttributes: CR$ MaxRecordSize: 0    LongestRecord: 0    F Now if I just downloaded any of these SEzip files back to my NT, they  would execute on NT just fine!   I'll try to illustrate:i  H -------NT------------                ---------VMS-----------------------F SEzip1.exe \                                     /SEZip1.exe(STMLF/CR)G SEzip2.exe  \ Make BIG.ZIP ---->  BIG.ZIP unzip / SEzip2.exe(STMLF/CR) i:         SEZip3.exe  /                                   \  SEzip3.exe(STMLF/CR)F SEzip4.exe /                                     \SEZip4.exe(STMLF/CR)       > F > The answer may be as simple as adding a CONVERT/FDL into the process > that  updates the archive. > = > Hint: The following is equally as effective as CONVERT/FDL:w >  > $ COPY NLA0: filespecv& > $ SET FILE/ATTR=(RFM=STMLF) filespec  > $ APPEND license_file filespec > J > So, based on your original observations and problem statements, I'd only > add to that: > I > o Make sure your file transfers are binary when passing the SE archivesA > between NT and VMS > C > o Make sure the file to be updated has the correct RMS attributes2  > BEFORE  attempting the update.  * The "correct RMS attributes" meaning what?   >  >  >  >>> C >>>>Remember, all these files work fine on NT (or other fine M$ OS)-J >>>>after they're downloaded from VMS. It's only after I do an update to a" >>>>SEzip that I have the problem. >>>>7 >>>>After the unzip on VMS all the SEzip files show as:i >>>. >>>. >>>Please define "SEzip files".w >> >>Self Extracting Zip  >  >  > Errrr, I gathered that.. > ; > However, you're using "SEzip files" in multiple contexts:i > & > o referring to the SE archive itselfH > o referring to the contents of the SE archive, as unzipped on your VMS	 > system.   * I hope my statements above explained that.   >  >  >  >>>sH >>>>    Organization: SEQ   RecordFormat: STMLF     RecordAttributes: CR, >>>>    MaxRecordSize: 0    LongestRecord: 0 >>>>J >>>>and as I said I can download them back to my NT at this point and they >>>>work fine. >  >  > What are "they" ("them")?e >  > ...the SE archives?o   Yes.   >   > ...the files they contain(ed)?; Yes, once executed on NT, the files within them are ok too.e   >  >  >>>rA >>>Maybe you should post (or e-mail) the commands you're using to G >>>accomplish the task you're attempting. We're getting too confused byp >>>terminology here. >>>s >>  >>What I'd like to use is just :) >>$ zip/update MySEzip.exe newLicense.keyt >> >>When it's just a regular zip:n$ >>$ zip/update My.zip newLicense.key
 >>works fine., >  > , > That first command should work fine, too.  > 5 > Please post the results of this sequence of events:e >   >  1. FTP the SE archive to VMS. > K >  2. Directory/FULL MySEzip.exe; (if it doesn't show Fixed-512, your file  E >     transfer method is improper; the archive is already corrupted).   G No it isn't, because as I said if I just turn around and download back  G to my NT without doing anything to the file, it executes fine and it's - defined as STMLF/CRR   > I >  3. Directory/FULL vms_filespec	! The file to be updated in the archive  > ) >  4. ZIP/UPDATE MySEzip.exe vms_filespec  > @ >  5. Directory/full MySEzip.exe; (should still show Fixed-512). > ' > ...and we'll work forward from there.e >   F While I don't think updating them while in a Fixed-512 structure will   work either, I'll give it a try.   -- w   Have VMS, Will Travelc Wire paladin, San Franciscon   (paladinATalphaseDOTcom)   ------------------------------  % Date: Fri, 05 Mar 2004 22:04:36 -0600g@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: Zip/update Issues5 Message-ID: <40494DD4.BDFA6FD@NeOaSrPtAhMlNiOnWk.net>0   Don Sykes wrote: >  > David J. Dachtera wrote:
 > > [snip]: > > O.k. Let's see if I understand the sequence of events: > >t > >  1. UNZIP selfextr.exeI > >     ?: If you only need to update one file in the archive, why do youe > >        bother to UNZIP?  > >cD > >  2. Replace one file in the directory tree(s) with a new version > > , > >  3. ZIP/UDPATE selfextr.exe vms_filespec7 > >     (which actually makes both 1 and 2 unnecessary)  > >u? > >  4. Make "selfextr.exe" available to customer for download.  > >iL > > Seems to me the problem occurs somewhere between steps 1 and 2, and that- > > ZIP is not really involved at that point.v > F > No. I was originally trying to explain how I got my SEzip files thatI > were created on NT to my VMS server and the answer is I zipped them all F > together. In other words, I have 4 SEzip files on my NT, which I zipH > together and ftp the composite zip to my VMS server. Then I unzip thatG > composite zip file onto VMS, leaving 4 SEzip files now on VMS. If youcB > look at the VMS file attributes of any of these, they look like: > B > Organization: SEQ   RecordFormat: STMLF     RecordAttributes: CR& > MaxRecordSize: 0    LongestRecord: 0  F O.k. There's your first problem. These are being unzipped incorrectly. See:  5 http://www.djesys.com/vms/support/zipunzip/sld045.html	 ...and...o5 http://www.djesys.com/vms/support/zipunzip/sld043.htmr  > Note, however, that UNZIP without CLI support does not have an/ equivalent to the /BINARY=AUTO qualifier+value.o  G > Now if I just downloaded any of these SEzip files back to my NT, they   > would execute on NT just fine!  B ...as long as you transfer them back as binary, yes - they should.   > [ASCII art snipped]  > > H > > The answer may be as simple as adding a CONVERT/FDL into the process > > that  updates the archive. > >i? > > Hint: The following is equally as effective as CONVERT/FDL:E > >i > > $ COPY NLA0: filespect( > > $ SET FILE/ATTR=(RFM=STMLF) filespec" > > $ APPEND license_file filespec > >sL > > So, based on your original observations and problem statements, I'd only > > add to that: > >uK > > o Make sure your file transfers are binary when passing the SE archives. > > between NT and VMS > >aE > > o Make sure the file to be updated has the correct RMS attributest" > > BEFORE  attempting the update. > , > The "correct RMS attributes" meaning what?  D Assuming the target system is non-VMS, either STM(Windows or DOS) or) STMLF(UN*X) as appropriate to the target.s  ! > >>>Please define "SEzip files".s > >> > >>Self Extracting Zipr > >  > >s > > Errrr, I gathered that.t > >e= > > However, you're using "SEzip files" in multiple contexts:a > >t( > > o referring to the SE archive itselfJ > > o referring to the contents of the SE archive, as unzipped on your VMS > > system.e > , > I hope my statements above explained that.   Gotcha, Capt.!  
 > > [snip]7 > > Please post the results of this sequence of events:s > >p" > >  1. FTP the SE archive to VMS. > >pL > >  2. Directory/FULL MySEzip.exe; (if it doesn't show Fixed-512, your fileG > >     transfer method is improper; the archive is already corrupted).k > H > No it isn't, because as I said if I just turn around and download backH > to my NT without doing anything to the file, it executes fine and it's > defined as STMLF/CR   F ...but is not actually STMLF (record (carriage control) attributes areA meaningless in this context), it just got the wrong record formattE courtesy of VMS UNZIP. So, if transferred back to (source machine) asg% binary, yes - it should be just fine.l   > >yQ > >  3. Directory/FULL vms_filespec       ! The file to be updated in the archive   
 See above.  + > >  4. ZIP/UPDATE MySEzip.exe vms_filespeca  G Since the archive(s) have the wrong record format, RMS will hose up the G data while reading it. *THAT's why it's *GOTTA* be Fixed-512! *THIS* is / where NT "executability" is getting scrambled. -  C To update the archive, ZIP has to read/copy it until it gets to the.D segment representing the file to be replaced, process the file to beG replaced, then read/copy the remainder of the source archive until EOF. H If RMS sees the archive as STMLF, it will read records until <LF>, stripH the <LF> out (may be a portion of a machine instruction, an operand or aG byte of compressed data), and pass the remaining portion of each recordtA to the program (ZIP). Thus, data is actually lost in the process.h  
 Reference:6 http://www.djesys.com/vms/freevms/mentor/rms.html#rfmt  B > >  5. Directory/full MySEzip.exe; (should still show Fixed-512). > > ) > > ...and we'll work forward from there.- > >  > G > While I don't think updating them while in a Fixed-512 structure wille" > work either, I'll give it a try.  % Try it. I'm fairly sure it'll be o.k.f   -- r David J. Dachtera  dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Sat, 06 Mar 2004 09:09:47 GMTe& From: Don Sykes <paladin@mydomain.com> Subject: Re: Zip/update Issuem; Message-ID: <vzg2c.6789$_x.4099@newssvr27.news.prodigy.com>s   David J. Dachtera wrote:   > Don Sykes wrote: >  >>David J. Dachtera wrote: >>	 >>>[snip]I  
 <big snip>  * >>> 4. ZIP/UPDATE MySEzip.exe vms_filespec >  > I > Since the archive(s) have the wrong record format, RMS will hose up therI > data while reading it. *THAT's why it's *GOTTA* be Fixed-512! *THIS* is/1 > where NT "executability" is getting scrambled. o > E > To update the archive, ZIP has to read/copy it until it gets to the4F > segment representing the file to be replaced, process the file to beI > replaced, then read/copy the remainder of the source archive until EOF.eJ > If RMS sees the archive as STMLF, it will read records until <LF>, stripJ > the <LF> out (may be a portion of a machine instruction, an operand or aI > byte of compressed data), and pass the remaining portion of each recordeC > to the program (ZIP). Thus, data is actually lost in the process.t >    That makes sense!rH However..., I just ftp'd a single SEzip from NT to VMS and it showed up 	 on VMS as B      Organization: SEQ   RecordFormat: FIX       RecordAttributes:+      MaxRecordSize: 512  LongestRecord: 512l  ( which is what we want, right? Then did :  " $ zip/update EXPRESSBE.EXE AEX.KEYG DKA100:[FASTRACK.ROOT.DOCS.AEX.TTEST]EXPRESSBE.EXE;1: found a preamble > of 31357 bytesn updating: AEX.KEY (stored 0%)r  C File block size remains the same size (as it should) and format is oF unchanged. But alas, when I download back to NT and try to execute, I H get the "Zip file is damaged, truncated or has been changed..." message.  I If I convert/fdl=stream.fdl on the updated file then download back to NT l? and try to execute, I get the "ExpressBE.exe is not a valid NT p application" message.   / I tried the same using zip/freshen same result.   . If I do an unzip/list before the update, I see 3496601 bytes    241 files   After the zip/update :   3496541 bytes   241 filese  H a difference of 60 bytes, which is ok, since the newer file is a little A smaller. BUT wait. The new key is only 48 bytes smaller than the s existing key....  D So I try resending the new key I'm using in this test from NT again  without zipping it up first.  	 Then I do " $ zip/update EXPRESSBE.EXE AEX.KEYG DKA100:[FASTRACK.ROOT.DOCS.AEX.TTEST]EXPRESSBE.EXE;1: found a preamble   of 31357 bytesn  updating: AEX.KEY (deflated 77%)   Note the differen  ^^^^^^^^^^^^6  3 But then I unzip/list again and now the SEzip showsh   3496963 bytes  241 files  . Now 362 bytes LARGER than the original! Why...   Unzip/list EXPRESSBE.EXE  showsI      ...#      512  03-05-04  23:52   aex.keyM      ...   for the updated file.  The original file showed :	       ... #      150  01-03-03  12:11   aex.key       ...   Ah ha. A diff of 362 bytes.iI But the bottom line is none of these updated files work when transferred r back to NT :";:*&*&!  ( It's late. I'm tired. I'll report again.     -- t   Have VMS, Will Travel  Wire paladin, San Francisco0   (paladinATalphaseDOTcom)   ------------------------------  % Date: Sat, 06 Mar 2004 15:33:59 +0100 " From: Didier Morandi <no@spam.com>- Subject: [OT] I won 2 million euros. So what? 2 Message-ID: <4049e18b$0$284$636a15ce@news.free.fr>   Just got this today. First time.0 Course it is wrong.m Where is the problem?@  4 > REF NUMBER: 014/060/532 BATCH NUMBER: 762901-PCD03 >  > Sir/Madam, > C > We are pleased to inform you of the result of the Lottery WinnerssO > International programs held on the 5th of February, 2004. Your e-mail addressfN >  attached to ticket number 27522465896-6453 with serial number 3772-554 drewL > lucky numbers 7-14-18-23-31-45 which consequently won in the 2nd category,N > you have therefore been approved for a lump sum pay out of EU2,000,000 EUROS) > (TWO MILLION EUROS). CONGRATULATIONS!!!w > I > For security purpose and clarity, we advise that you keep your winning aO > information confidential until your claims have been processed and your moneymH > remitted to you. This is part of our security protocol to avoid doubleJ > claiming and unwarranted abuse of this program by some participants. AllM > participants were selected through a computer ballot system drawn from overoO > 20,000 companies and 30,000,000 individual email addresses and names from all(B > over the world. This promotional program takes place every year. > K > This lottery was promoted and sponsored by eminent personalities like the L > Sultan of Brunei. We look forward to your active participation in our next > year USD50 million slot. > J > You are requested to contact our clearance office to assist you with theJ > claim and transfer of your winnings fund into your instructed account byF > acknowledging the receipt of this mail with the email address below. > ( > Email address: timklotto1@netscape.net >  > N > Note that, all winnings must be claimed not later than one month. After this1 > date all unclaimed funds will be null and void.t > N > Please note in order to avoid unnecessary delays and complications, rememberI > to quote your reference number and batch numbers in all correspondence.s > K > Furthermore, should there be any change of address do inform our agent asa > soon as possible.i > K > Congratulations once more and thank you for being part of our promotional 
 > program. > L > NOTE: YOU ARE AUTOMATICALLY DISQUALIFIED IF YOU ARE BELOW 18 YEARS OF AGE. >  >  > Sincerely yours, >  > Tim Kennedy. > 0 > Payment Officer Email: timklotto1@netscape.net   ------------------------------   Date: 6 Mar 2004 12:18:36 -0800o( From: bob@instantwhip.com (Bob Ceculski)< Subject: Re: [OT] We've always know that Solaris is junk....= Message-ID: <d7791aa1.0403061218.6fb6340f@posting.google.com>h  r "John Smith" <a@nonymous.com> wrote in message news:<pS62c.90457$sl.68165@news01.bloor.is.net.cable.rogers.com>...N > http://story.news.yahoo.com/news?tmpl=story&ncid=1208&e=1&u=/ap/20040305/ap_/ > on_bi_ge/sun_micro_credit_rating&sid=955736498 >  >   > ...now Standard & Poors agrees >  > ) > S&P Downgrades Sun Microsystems to Junk  > 5:00pm ET  > M > NEW YORK - Standard & Poor's cut its credit rating on Sun Microsystems Inc.2E > two notches to double-B-plus, the top speculative, or junk, rating,a. > affecting about $1.3 billion of public debt. > F > The computer company hasn't "had investment-grade predictability andF > profitability in two-plus years," said S&P analyst Martha Toll-Reed.K > Management "has been slow to adapt to market changes since the downturn,"23 > when the tech bubble burst in the spring of 2000.2 > K > May Petry, a spokeswoman at Santa Clara, Calif.-based Sun Micro, said theiI > company has a "strong financial foundation of $5.16 billion in cash andlM > marketable securities, which is over three times our outstanding debt." ShedL > said the company's cash position, coupled with its products and customers,9 > makes Sun Micro "well-positioned to achieve its goals."y  8 sounds like that they have $300 million available to buy5 OpenVMS ... let's hear Andrews answer on this one ...c2 then you would have us as a customer Andrew ... :)   ------------------------------  % Date: Fri, 05 Mar 2004 22:20:10 -0600m@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>< Subject: Re: [OT] We've always know that Solaris is junk....6 Message-ID: <4049517A.3D1FF5FD@NeOaSrPtAhMlNiOnWk.net>   John Smith wrote:Q > [snip]  > ...now Standard & Poors agrees  @ Well, I've only taken Solaris Admin. classes. To me, however, as/ commercial UN*X goes, Solaris is pretty fair...    ...it's just not VMS.    --   David J. Dachtera  dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/-   ------------------------------   Date: 6 Mar 2004 16:59:24 -0800p. From: Jack.Trachtman@vmmc.org (Jack Trachtman)$ Subject: Re: [TCPIP V5.4] More rants< Message-ID: <69d784c4.0403061659.8b5b4ec@posting.google.com>  E We run BMC PATROL here and just discovered that the VMS agent doesn't C work with the Scalable Kernal. (Today I got a chance to reboot withnC the SK disabled and the PATROL agent started and connected with the  PATROL server.)t   ------------------------------   End of INFO-VAX 2004.132 ************************chonogically s	<a|n|M-|O4ߍM]-[_-m|x|]00z	o|b&Vs;7,a|9nMk"D+r\
 |ݚ| _ໜW<0N0j7	
U<&zV?g|K _)6ooc0{Wu>dlQm~+1(REZ<AgZ1S26I^˪4Fipihؐ`Oa1Bds޻]ɲqpG{swx}}o'ӷVua7@}OQߧBǯn0}Qw "`z˯7X{ۉv)o{e}ͮo;f
}
g1}5Է
f f묯[3}}o1[~K[=$]wo
껑A}K5Log|tR7x?sjE+gܜf	l8Qr	#Q'K~Q9AcW1n&{Tha*3߅-UV
N1{VMAO^WK>${<ݓ7!xRp
70)PIU«swymze{mRSZE<@Oi/׭aKS=ˮ<$H$r#Q/.\XPA0ay,/F>]:׍y:<pBHJV1}=pЍ3`Xj&ʍ\1AevP)X(dSwH