1 INFO-VAX	Fri, 15 Mar 2002	Volume 2002 : Issue 145       Contents:P A more balanced explanation: Why not ODBC Direct Access? Codasyl DBMS Data on OrP Re: A more balanced explanation: Why not ODBC Direct Access? Codasyl DBMS Data o' Re: Adding Disks to a Alpha Server 2100 ' Re: Adding Disks to a Alpha Server 2100  analyse/system tool for unix  Re: analyse/system tool for unix Re: Andrew's back !  Re: Andrew's back !  Re: Andrew's back !  Re: Andrew's back ! * Re: Another big block votes against merger* Re: Another big block votes against mergerE Re: another VMS event in NYC which you are welcome to attend (update)  Re: Antigen found =*.exe file  Re: bottleneck bufferd I/O?  Compaq HP Merger/ Re: DEC C: why does exit(0) really exit with 1? 2 Re: DFU report wrong number of free file headers ?2 Re: DFU report wrong number of free file headers ? Re: DLT Degausser / Bulk Eraser  ES40s have bandwidth to burn? 0 GTK+ 2.0: Are there plans to port it to OpenVMS?" Has Anyone Set Up a Merger Pool???G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G RE: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux G Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux  Re: HSZ10 looking for info...  Re: Itanium troubles Re: Itanium troubles Re: Itanium troubles Re: Itanium troubles- L.A. Times article on HP mailings and proxies 1 Leveraging Mixed Format with Uniform Format Types ! Re: Netcraft Uptime For OpenVMS ? ! Re: Netcraft Uptime For OpenVMS ? 4 Re: Online reference guide to ANSI/VT-ESC-commands ?* Re: Opening a SYS$OUTPUT file in VMS Basic, OT: AOL "whiners" for suing MS over Netscape Re: Plan B for Compaq  Re: Plan B for Compaq  RE: Plan B for Compaq  RE: Plan B for Compaq  RE: Plan B for Compaq  Re: Plan B for Compaq  Re: Plan B for Compaq  Re: Plan B for Compaq  Question for Andrew  RE: Question for Andrew  RE: Question for Andrew  Re: Question for Andrew P Re: R.I.P. OpenVMS - ISS Recommends That H-P Holders Vote in Favor of Compaq Acq Resource block chains - Re: sending all data as out-of-band in TCP/IP D Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)D Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)D Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)D Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)D Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)D Re: TCPIP, sharing sockets via $QIO (programming, long and detailed). There is nothing like performing a REALM walk? Re: VFC File Problem8 Re: Viability of a Commercial ISO-9960 formatter for VMS8 Re: Viability of a Commercial ISO-9960 formatter for VMS8 Re: Viability of a Commercial ISO-9960 formatter for VMS7 Re: Viability of the VMS Market for third party vendors 7 Re: Viability of the VMS Market for third party vendors 5 Walter Hewlett says HP board is really against merger P Re: Why no DEFINE /GROUP=nnnn? (was re: define "group-logicals" at system startu? Re: Why not ODBC Direct Access? Codasyl DBMS Data on Oracle Rdb 9 Re: Win one - Lose one - more pfunds seigh in on the deal  XP1000 (EV6) Going Cheap !@ Re: [OT] US/Europe living costs, was: Re: VMS sys admin salaries  F ----------------------------------------------------------------------  # Date: Thu, 14 Mar 2002 18:24:43 GMT $ From: "Tim Peer" <peert@envysys.com>Y Subject: A more balanced explanation: Why not ODBC Direct Access? Codasyl DBMS Data on Or C Message-ID: <LV5k8.11335$Jo4.2806866104@newssvr14.news.prodigy.com>    Alan,   I I should balance my explanation by stating that Interpreted Direct Access J technologies work for many sites. In fact, I know of a few sites where RdbH and SQL databases are used with Direct Access technologies as a completeL solution.  Direct Access technologies have the advantage of real-time accessG to Codasyl data. Real-time data access is not available in the SQL only K environment. Best case for real-time data is usually every 1-2 minutes from  the time of the Codasyl update.   H Given the power of SQL database technologies, Direct Access queries needH only execute against data where a Codasyl Set exists,  all other queries; usually execute against the Rdb or companion  SQL database.    -- Timothy E. Peer  eNVy Systems Inc.  4960 Almaden Exp. #330 San Jose, CA 95118 Voice: (408) 363-8896  Fax:    (408) 363-8897   http://envysys.com  / "Tim Peer" <peert@envysys.com> wrote in message = news:FR4k8.11225$zM7.2788029596@newssvr14.news.prodigy.com...  >  > <Why did you do this?> > 6 > And a response regarding direct access technologies: > K > Since Codasyl DBMS is not a relational database, it was necessary to copy H > the Codasyl data to a relational database to enable data access to theK > users. The overhead incurred using traditional data extraction approaches L > such as, 3 G/L, 4 G/L  and  "direct access ODBC", was too high.  ExecutionE > performance of traditional data access is strictly dependent on the L > complexity of the query and the data access paths available (Codasyl Sets)K > as defined in the Codasyl DBMS storage schema.  Defining new access paths E > require a storage schema change and reorganization of the database.  Imagine L > performing a pattern-match query on a CHARACTER type data element, perhaps a B > description field, in a storage area with say 1,000,000 records.H > Unfortunately, you would probably not find a Codasyl Set for this dataK > element. Using traditional data access, the query will probably perform a E > storage area realm walk and the IT department will probably have an . > opportunity to meet their transaction users. > I > The net-change approach used by the Rdb Warehouse works well as the Rdb G > database stays synchronized with Codasyl without the overhead defined  above. > F > Beyond ad-hoc SQL queries, the real benefit is seen in a developmentL > environment. Developing web and SQL-based applications is rather simple toI > do and besides there is a rich selection of tools available with native E > interfaces (such as Oracle Developer 2000) to relational databases.  >  > >But Attunity B > > works fine and lets us do whatever we need with ODBC accessingG > > underlying MANMAN databases. However I'm not sure if that  would be 3 > > the case if we allowed updates via this method,  > 4 > Why one would use Rdb in place of Interpreted SQL: > L > The I/O, CPU and memory overhead incurred in executing queries is isolated > to an off-line system.L > Ability to use relational database functions and objects without having toD > modify the Codasyl schema or Codasyl application, examples: storedD > procedures, functions, triggers, views, hashed and sorted indexes, synonyms > to name a few.J > Ability to open the data to user/analysts for use with OLAP (data cubes) > tools. > 5 > Why wouldn't someone implement Codasyl data in Rdb?  >  > -- > Timothy E. Peer  > eNVy Systems Inc.  > 4960 Almaden Exp. #330 > San Jose, CA 95118 > Voice: (408) 363-8896  > Fax:    (408) 363-8897 >  > http://envysys.com > 4 > "Alan Greig" <a.greig@virgin.net> wrote in message4 > news:t9609u831fhk79dhfhappfrue4l1e97ti3@4ax.com...D > > On Thu, 14 Mar 2002 02:57:54 GMT, "Tim Peer" <peert@envysys.com>
 > > wrote: > >  > > L > > >We needed to create an Rdb data warehouse using the Codasyl DBMS schema > as aJ > > >model. Since Codasyl DBMS is not a relational model, it was necessary toG > > >"reverse-engineer" the Codasyl DBMS schema and create a relational 
 > databaseH > > >that preserved Codasyl DBMS Owner and Member relationships.  In our	 > Codasyl J > > >DBMS database, PRTREC is stored in PRTAREA.  We preserved the orginal > > D > > MANMAN eh? Did you evaluate using ISG Navigator/Attunity to justG > > automatically map the DBMS database to a relational  model. Or even I > > use RDB/DBMS transparent gateway - although I wouldn't recommend that E > > method as we found it slow and buggy during testing. But Attunity B > > works fine and lets us do whatever we need with ODBC accessingG > > underlying MANMAN databases. However I'm not sure if that  would be 3 > > the case if we allowed updates via this method,  > > J > > >Codasyl structure in Rdb.  Companion storage areas and tables use the > sameG > > >name as the Codasyl DBMS counterpart. Storage maps were created to  place  > the L > > >row in the PRTAREA_NV.RDB storage area. Records are stored in Rdb usingK > > >ordinals from the Codasyl DBMS DBKEY (rowid). We broke apart the DBKEY J > > >"1:22:5" , formatted as: area=1, page = 22, line = 5.  The Rdb schema was L > > >designed with a MIXED format storage area (MFSA) to store "unique" keysG > > >(since we are using the DBMS DBKEY, there is one and only one DBMS  DBKEY  > for J > > >each record). A HASHed index was created for the composite DBKEY withL > > >placement in the MFSA. Data are stored to tables via a storage map in aK > > >UNIFORM format-storage area (not RDB$SYSTEM).  When inserted, rows are H > > >appended to the table, unique key lookups occur via the composite - > HASHed > > >index.  > > > H > > >This is put to test as we read the Codasyl DBMS After Image Journal fileH > > >(AIJ) and obtain changes, insertions and deletions made to Codasyl. These H > > >AIJ rows are inserted, changed and deleted in Rdb using the Codasyl > DBKEY. > > >Performance is excellent. > > > K > > >Create SORTed indexes when selecting data using a RANGE of key values.  > Store F > > >the sorted indexes in the storage with the data or in a dedicated UNIFORM H > > >storage area. A dedicated storage for sorted indexes may work best. > > > K > > >We retrieve data via ODBC using AREA,PAGE,LINE - our application moves = > > >copies data to a database servers running Oracle 8i, SQL G > > >Server, and SYBASE.  SORTed index keys take the form: NVTIMESTAMP, K > > >PAGE,AREA,LINE. The sorted index compares the timestamp on the Rdb row  to > a  > > >saved VMSF > > >timestamp (when the table was copied last to the PC/UNIX database server > the K > > >time the transfer started is stored in a transfer table).  Only new or F > > >changed rows are ever moved to the database server. Deletions are handled K > > >using a different method.  There was a bug in Oracle's Rdb ODBC driver  > whenD > > >selecting records via a timestamp key, "WHERE timestamp-value >I > > >other-timestamp-value."  The bug walked the table and did not use an  > index.K > > >For larger tables, performance was unacceptable, adding additional key < > > >segments provided a reasonable performance work-around. > > > 6 > > >Here is the Rdb schema information for reference: > > >   > > >create storage area PRTAREA > > >filename 'PRTAREA_NV.RDA' > > >-- read write storage area  > > >locking is row level  > > >page format is UNIFORM  > > >page size is 2 blocks > > >allocation is 2 pages? > > >extent is (minimum 2000, maximum 20000, percent growth 20)  > > >   > > >create storage area NVINDEX3 > > >filename 'NV$DISK:[ENVY.002]MANDB_NVINDEX.RDA'  > > >-- read write storage area  > > >locking is row level  > > >page format is MIXED  > > >page size is 3 blocks > > >allocation is 251386 pages < > > >extent is (minimum 98, maximum 9998, percent growth 20)< > > >snapshot filename 'NV$DISK:[ENVY.002]MANDB_NVINDEX.SNP'' > > >snapshot allocation is 32464 pages E > > >snapshot extent is (minimum 98, maximum 9998, percent growth 20)  > > >interval is 216; C > > >    CREATE STORAGE MAP PRTREC_MAP FOR PRTREC STORE IN PRTAREA; & > > >    CREATE INDEX NV_PRTREC_HSHIDX) > > >        ON PRTREC (PAGE, AREA, LINE) > > > >        TYPE IS HASH ENABLE COMPRESSION STORE IN NVINDEX; > > > H > > >Our observations revealed this to be a simpler alternative to using > hashedE > > >insertions and row clustering--data warehousing on Rdb without a  DatabaseH > > >Administrator on staff. Send me an e-mail and I will send you a DCL? > > >procedure that you can use to calculate allocation values.  > >  >  >  >    ------------------------------  % Date: Fri, 15 Mar 2002 04:51:39 +0000 & From: Alan  Greig <a.greig@virgin.net>Y Subject: Re: A more balanced explanation: Why not ODBC Direct Access? Codasyl DBMS Data o 8 Message-ID: <76v29ugcomv442ctf6vpksta6eh10cvsvb@4ax.com>  @ On Thu, 14 Mar 2002 18:24:43 GMT, "Tim Peer" <peert@envysys.com> wrote:   >Alan, > J >I should balance my explanation by stating that Interpreted Direct AccessK >technologies work for many sites. In fact, I know of a few sites where Rdb I >and SQL databases are used with Direct Access technologies as a complete M >solution.  Direct Access technologies have the advantage of real-time access H >to Codasyl data. Real-time data access is not available in the SQL onlyL >environment. Best case for real-time data is usually every 1-2 minutes from  >the time of the Codasyl update.  F Not sure what you mean here? If I execute a transaction in MANMAN then@ that will be immediately seen by an Attunity/Navigator SQL query0 directly from the VMS $ prompt.  Soemthing like:   $ NAVSQL MANDB3 SELECT PRTDESC FROM PRTREC WHERE PRTNO = 'DP-XXX' ;   + If I've got the field names right off hand. I >Given the power of SQL database technologies, Direct Access queries need I >only execute against data where a Codasyl Set exists,  all other queries < >usually execute against the Rdb or companion  SQL database.   ------------------------------  % Date: Fri, 15 Mar 2002 04:24:57 +0000 & From: Alan  Greig <a.greig@virgin.net>0 Subject: Re: Adding Disks to a Alpha Server 21008 Message-ID: <4nt29u8ivqlehgn18juporkfmpnbr1e8u9@4ax.com>  - On Thu, 14 Mar 2002 11:45:30 -0500, "rob kas" ! <rob@paychoice.nospam.com> wrote:    >        Hi  > 6 >  I have a Alpha Server 2100 with 2 Raid controllers.4 > Currently one is setup as RAID 5 and one is RAID 1M >  I'd like to add disks to the RAID 5 set , is there some magic needed to do  >this?  F BACKUP the RAID 5 set. Destroy the RAID 5 set, create new RAID 5 set,,$ BACKUP to restore to new RAID 5 set.  C Alternatively create a new RAID 5 set with new disks and MOUNT/BIND ! the new RAID 5 volume to the old,   ' >                                Thanks ' >                                 Rob K  >    ------------------------------    Date: 14 Mar 2002 22:11:55 -0800  From: cor.mom@momss.nl (Cor Mom)0 Subject: Re: Adding Disks to a Alpha Server 2100= Message-ID: <774640de.0203142211.10321d54@posting.google.com>    Rob,  A I think you will have to run a special RAID Configuration console C program (I cannot remember it's exact name) from the boot prompt. I C recently did it on a AlphaServer DS10 with the console program on a < floppy disk. It should have been delivered with your system.   Regards,   Cor Mom   f "rob kas" <rob@paychoice.nospam.com> wrote in message news:<3c90d5c6$0$35567$8e9e3842@news.atx.net>... > Hi > 7 >   I have a Alpha Server 2100 with 2 Raid controllers. 5 >  Currently one is setup as RAID 5 and one is RAID 1 N >   I'd like to add disks to the RAID 5 set , is there some magic needed to do > this?  > ( >                                 Thanks( >                                  Rob K   ------------------------------    Date: 14 Mar 2002 19:00:02 -0800! From: hemanir@yahoo.com (Anamika) % Subject: analyse/system tool for unix = Message-ID: <5130f039.0203141900.4b4a3b09@posting.google.com>    HI, E    Is there a analyse/system like tool for unix. I mean as good as itC> is on VMS with comparable features. Any kind of unix would do.   Thanks,D -A   ------------------------------  # Date: Fri, 15 Mar 2002 04:36:28 GMTC4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>) Subject: Re: analyse/system tool for unix20 Message-ID: <3C9178B9.60731B0A@blueyonder.co.uk>   Anamika wrote: >  > HI,wG >    Is there a analyse/system like tool for unix. I mean as good as it @ > is on VMS with comparable features. Any kind of unix would do. >   H Yeah, I could really do with SDA> show proc/channel equivalent for Linux right now. e  F Oh, and potential wingers, I'd argue this is on topic for VMS because I you need to know its relative strengths and weaknesses if you hope to usew it effectively these days.  I Back to the linux and xfree86 docs ... If only I had a BC08 cable I could  try booting my MicroVAX 2000.    regardsn  	 > Thanks,  > -A   -- n tim.llewellyn@blueyonder.co.uk o  F * tim.llewellyn@cableinet.co.uk address will cease to work June 2002 *   ------------------------------    Date: 14 Mar 2002 18:40:32 -0000= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>s Subject: Re: Andrew's back !6 Message-ID: <20020314184032.13533.qmail@gacracker.org>  5 On Thu, 14 Mar 2002, Roy Omond <Roy@Omond.net> wrote:, >Oh what unbridled joy :-) >iG >He seems to have lost a certain "SooperDooper Architect" title though.i >o >Wonder what happened. >t >Welcome back, Andrew :-)i  J Yea, but wherever he is posting from doesn't have great peering relations.? I don't see any of his posts on my news server here in Belgium.      Doc. -- l6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.neta   ------------------------------  # Date: Thu, 14 Mar 2002 18:09:06 GMTa1 From: "Terry C. Shannon" <terryshannon@attbi.com>  Subject: Re: Andrew's back !9 Message-ID: <6H5k8.23576$44.5453404@typhoon.ne.ipsvc.net>   G "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote inu5 message news:qsuAEEprI6$Q@eisner.encompasserve.org... E > In article <3C90D978.8AA96D18@Omond.net>, Roy Omond <Roy@Omond.net>o writes:  > > Oh what unbridled joy :-)n > >rJ > > He seems to have lost a certain "SooperDooper Architect" title though. > >i > > Wonder what happened.g > >d > > Welcome back, Andrew :-) > > 
 > > Roy Omondt > > Blue Bubble Ltd. > >c >tG > Sun's probably found out through some confidential source that VMS iss going L > to be heavily promoted under HP's rule and he's been sent by his employers$ > to keep an eye on the situation...  L Only Andrew knows for sure whether he's frequenting the newsgroup on his ownC time or that of his employer. If it's the latter case, Sun is to befG commended for its due diligence. In the case of Compaq, it appears thatfG contributors and lurkers do their contributing and lurking on their own  nickel.H   ------------------------------  % Date: Thu, 14 Mar 2002 21:55:26 +0100  From: Dirk Munk <munk@home.nl> Subject: Re: Andrew's back !& Message-ID: <3C910E3E.3000507@home.nl>   Yes, welcome back Andrew !!$  I Just when everything looked grey and miserable, the Sun is back into our o newsgroup !!  $ And I even have a question for him !  ) What is the view of Sun on fibrechannel ? A The guys in my company that support Sun told me that Sun uses AL )
 fibrechannel.a Compaq uses the fabric variant.gF We have some room left on our HSG80 disk cabinets, and we may want to  connect a Sun system to it.l3 What is Sun's vision on such a multi-vendor setup ?i   Regards,   Dirk   Roy Omond wrote:   >Oh what unbridled joy :-) >mG >He seems to have lost a certain "SooperDooper Architect" title though.h >  >Wonder what happened. >t >Welcome back, Andrew :-)r >a
 >Roy Omond >Blue Bubble Ltd.y >P   ------------------------------  % Date: Fri, 15 Mar 2002 04:27:21 +0000e& From: Alan  Greig <a.greig@virgin.net> Subject: Re: Andrew's back !8 Message-ID: <utt29uc0sh4a1cemifpf2fmbbdnjmamslj@4ax.com>  D On Thu, 14 Mar 2002 17:10:15 +0000, Roy Omond <Roy@Omond.net> wrote:   >Oh what unbridled joy :-) >eG >He seems to have lost a certain "SooperDooper Architect" title though.- >- >Wonder what happened. >e >Welcome back, Andrew :-)   @ He's also got a very slow news feed or else Sun UK is three daysA behind the rest of the world. Or perhaps he's at three light days  distance from the Sun :-) :-)0  ( That would explain his absence of course  
 >Roy Omond >Blue Bubble Ltd.t   ------------------------------   Date: 14 Mar 2002 18:25:25 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)R3 Subject: Re: Another big block votes against mergerh, Message-ID: <a6qpul$2kue$1@info.cs.uofs.edu>  9 In article <WG3k8.23490$44.5388277@typhoon.ne.ipsvc.net>,d4  "Terry C. Shannon" <terryshannon@attbi.com> writes: |> L7 |> "David Mathog" <mathog@caltech.edu> wrote in messagel( |> news:3C90C640.3930306C@caltech.edu... |> a: |> >                     Just for comparison purposes, I'd |> estimate theu |> > half-lifeM |> > (purchase to disposal) of the average desktop PC to be around 1000 days.x |>  L |> And that's probably a generous estimate. My Rainbow is closing in on 6666O |> days, but then again, the thing has been languishing in the basement for thea |> past 11 years!7  E That's nothing.  I have a box in my basement that is still in regular G use that is hovering somewhere either side of 8000 days.(I really don'tWE remember exactly when I started using it, but it was in 1980 or 1981)n  H Oh and to keep this as close to OT as I can, it is a Digital LSI-11 cpu.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   c   ------------------------------  % Date: Thu, 14 Mar 2002 20:48:24 +0100 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>)3 Subject: Re: Another big block votes against mergere' Message-ID: <3C90FE88.46736D0E@aaa.com>r  8 The very first copy of BYTE I ever read had an LSI-11 on7 the front cover controling a model railway. It probablyy3 also was the very first article in any BYTE I read. , It should have been someware around 1976-77.  < I borrowed BYTE from the school library to have something to; read while the electronics teacher tried to explain how thei< instruction set of the Motorola 6800 worked. At that time my: home "hobbyist system" was built around a processor called: "Scamp" from National Semiconductor using a description in? the English paper "Elector". Home etched circuit bords and all.o- I had it to play "Smoke on the water" once...   A Today I'm sorry I sold it to a friend many years ago. I'd love tonC show it to my 15 year son, who's first "hobbyist system" plays onlyo can play Diablo-II...    Jan-Erik Sderholm.i   Bill Gunshannon wrote: > G > That's nothing.  I have a box in my basement that is still in regularaI > use that is hovering somewhere either side of 8000 days.(I really don'ttG > remember exactly when I started using it, but it was in 1980 or 1981)r > J > Oh and to keep this as close to OT as I can, it is a Digital LSI-11 cpu. >d   ------------------------------    Date: 14 Mar 2002 20:26:28 -0800) From: google@mccready.com (Gary McCready)eN Subject: Re: another VMS event in NYC which you are welcome to attend (update)= Message-ID: <6e64ea70.0203142026.49fe6db5@posting.google.com>t  k "Sue Skonetski" <susan.skonetski@compaq.com> wrote in message news:<I%Lg8.480$fL6.7693@news.cpqcorp.net>...d) > What: OpenVMS Galaxy Dynamic clustering. >   8 NY Metro Encompass Local User Group Meeting Announcement  0 Galaxy for OpenVMS: Features and Implementations  H Thursday, March 21, 2002, 1-4pm, at Compaq, 8th Floor, 2 Penn Plaza, New
 York City.E (2 Penn Plaza is directly above Penn Station, 7th Avenue at 32nd st.)   L Our agenda includes both Compaq and customer presentations on current GalaxyK features and implementations. We'll also have a demonstration of the Galaxy.L technology in Compaq's Demo center.  Lastly, we'll be looking for a few goodH volunteers to join a steering committee to plan future events. Our host,G Compaq, is again kind enough to provide us with meeting space and lighte refreshments for the meeting.y  G  Limited reserved seating available (the last meeting was standing rooma5 only!). Register via email to Barbara.Hunt@compaq.coma  L You will be met by a Compaq employee at the security desk at the entrance toH the building.  Should you arrive late, please call the reception desk at 212-856-2000 for an escort.   Agenda:t6 12:30 p.m. Check-in and old-fashioned DECUS networking  & 1:00 p.m - Welcome and LUG information%     Gary McCready, SIAC/Amex ServicescH Gary will discuss recent Encompass news and announcements, and plans for# future meetings and LUG activities.s  1 1:10 p.m.  Compaq Introductions and AnnouncementsiE     Our Host, Lynne Hummel, High Performance Sales Specialist, Compaqa  - 1:20 p.m  -  OpenVMS Galaxy: An Introduction. 0     Bill Hanley, OpenVMS Program Manager, Compaq Bill's talk will cover" - The key points of what Galaxy is: - What Galaxy means to those looking at Enterprise servers. - An explanation of hard and soft partitioning' - Typical examples of how to use Galaxyd  F 2:20 p.m. Uses of a GS80 in a Buy Firm Side Equity Trading Environment, 	Jim Walker, Director of Technical Services,  	TIAA-CREF Investment ManagementH Jim will describe the use of a GS80 for CREF Investments Equity Trading.G "The machine has provided us a way to provide application growth in our K trading applications, with minimal redesign of our legacy applications.  WesK now have more functionality and better performance with high availability."t  E 2:40 pm Inter-Process Communication using Global Sections in a Galaxyi
 Configurationr4 	Mel Brender, Consultant, Digitask Consultants, Inc.E Mel's talk will cover the implementation of a shared memory real-timetF trading application using global sections accessed by multiple OpenVMS
 instances.   3:00 p.m. Galaxy Demos# 	Edgar Zamora, Ted Burrowes, Compaq G Edgar and Ted will demonstrate the Galaxy Technology in the Compaq demo  center.   D And after the meeting and demos are over, feel free to stay for moreK networking and to discuss what we should have in future events. We are also  looking to start an OpenVMSoJ Systems Management working group to assist in a project on "BulletproofingA your OpenVMS system". Other working groups/special interest groupiL suggestions are welcome. Email NYMLUG@McCready.com for info and suggestions.  K Apologies are in order if you have received multiple versions of this emailtF message. If you did not receive an "original" version of this message,E please join our mailing list at http://groups.yahoo.com/group/NYMLUG/(   ------------------------------  # Date: Fri, 15 Mar 2002 01:43:57 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r& Subject: Re: Antigen found =*.exe file& Message-ID: <3C9153E4.F705A26@fsi.net>   Patrick Young wrote: > ^ > carl@gerg.tamu.edu (Carl Perkins) wrote in message news:<13MAR200218112152@gerg.tamu.edu>... > >c# > > Zip them and send the zip file?s/ > > Use backup on them up and send the saveset?u > >k > ? > You are missing my point. Why the ?_FREAKING HELL_? do I havee; > to adjust my behaviour and go out of my way because of ane; > incompetent OS that I don't even use and avoid where ever  > possible?e > ; > I use PMDF under OpenVMS for email but am worried if UNSWg> > place "anti virus" software on their central mail redirector? > where Initial.Surname@unsw.EDU.AU gets directed to the target ; > computer user@host.unsw.EDU.AU (in my case OpenVMS/PMDF).g > ; > If I want to email an OpenVMS .EXE, .COM or .BAS over the0> > network as an attachment, why should I have to "consider M$"+ > and rename it for crying out loud ???????e  " Two words: "Platform Transparency"   -- e David J. Dachteram dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  + Date: Thu, 14 Mar 2002 21:43:06 +0000 (UTC) 4 From: lewis@spamoffspyder.mitre.org (Keith A. Lewis)$ Subject: Re: bottleneck bufferd I/O?. Message-ID: <a6r5ha$de4$1@newslocal.mitre.org>   bes@out-fits.com (=?ISO-8859-1?Q?Bernard_Str=E4hl?=) writes in article <eb298964.0203141008.715b1d9a@posting.google.com> dated 14 Mar 2002 10:08:38 -0800:E >I can see that a process running uses up to 50% of buffered I/O. ther& >buffered I/O itself is always "full". > ( >q: how can I increase the buffered I/O? >nE >Autogen increased some parameters NPAGEDYN, PAGEDYN; the rest stayed   >the same or more or less equal.  L Buffered I/O is not a strictly-limited resource like CPU time.  I'm guessingL that you're looking at "MONITOR PROCESS/TOPBIO", which shows a rate in QIO's3 (queued I/O requests) per second, not a percentage.i  K Do a "SHOW PROCESS/QUOTA/ID=" on the process while it's working hard.  LookDK at "Buffered I/O byte count quota" and "Buffered I/O limit".  If either one0K is close to zero (relative to the SYSUAF quota values) you might be able to.7 increase throughput by raising the quotas in AUTHORIZE.i  H If you're talking about a detached process, the quotas usually come fromG somewhere other than SYSUAF.  They can be specified on the RUN command,e# $CREPRC, or system PQL_ parameters.a  + --Keith Lewis              klewis$mitre.orgi> The above may not (yet) represent the opinions of my employer.   ------------------------------    Date: 14 Mar 2002 13:41:35 -0800- From: gudehus@mindspring.com (Donald Gudehus)  Subject: Compaq HP Mergert= Message-ID: <cd5f2a9b.0203141341.1a99302b@posting.google.com>   F HP has distinguished itself with several innovative products over the = years:  high quality test equipment, state-of-the-art pocket gF calculators (with the intuitive RPN language), and unix workstations. E In recent years they have branched into PCs and printers.  Here they rE have lost their edge, since their PCs are just clones of the IBM PC, tG and the printer division, although profitable, faces heavy competition eI from high quality printers made by Epson.  HP's printers using Poscript, -A offer only a clone version of that language, which has sometimes i= created problems for people trying to print postscript files.r  E Compaq, though distinguished by being the first company to clone the TG IBM PC, has not historically been very innovative.  After all, in theiroA PC clone days they did not have an architecture, did not have an  B operating system, and did not write software applications.  In an C effort to boost their status a few years ago they acquired Digital e> Equipment Corp. Thusly they could boast a unique architecture H (VAX and Alpha), an operating system (OpenVMS, Ultrix, and True64 Unix),F software applications (numerous compilers and applications written by H Digital), as well as IT services.  Yet their market share has plummeted : and they are now contemplating phasing out the Alpha chip.  C What is the best approach for these two companies to take?  Should sF they mend their ways, or should they combine their ways?  The questionD is somewhat like the question of whether two individuals, each with D personal problems should get married.  Actually, in this case it is C an arranged marriage not one based on love.  The comparison is not eF like a doctor taking on a sick patient, since in that case one of the G two is a proven healer.  A merger of these two companies in my opinion  F would create more problems than it would solve.  Even by consolidatingD the PC branches, the combined company would still have to deal with E withering competition from aggressive shipper and packager companies  C such as Dell and offshore clone marketeers.  Furthermore, the time sG and expense of merging PC operations could prove fatal in the long run. I One also has to ask whether the Compaq staff has an interest in printers,-B and whether the HP staff has an interest in unique architectures, G operating systems, and compilers.  The latest polls show most employees3- of both companies not in favor of the merger.   @ Warnings about the HP board resigning if the merger does not go C through are quite interesting since it could easily be argued that dH what HP has needed all along is a new  board (excepting Walter Hewlett).D If the merger does indeed fall through each company should probably D seek outside advice about its future directions and seek a change in leadership.u   Donald Gudehus   ------------------------------    Date: 15 Mar 2002 06:09:33 +0800, From: Paul Repacholi <prep@prep.synonet.com>8 Subject: Re: DEC C: why does exit(0) really exit with 1?0 Message-ID: <87663yvm1u.fsf@k9.prep.synonet.com>  1 Michael Zarlenga <zarlenga@conan.ids.net> writes:t  4 > Bill Gunshannon <bill@triangle.cs.uofs.edu> wrote:  D > : Hmmmm.  How does one differentiate between exit(0) and exit(1)??  w" > That, in essence was my problem.   E > We exit with many return codes, SS$_NORMAL being the only good one.  > All work, except 0.0  F Oh, consider the $CLREF system service. It *never* returns SS$_NORMAL.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.2@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 14 Mar 2002 12:47:10 -0800HM From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@spam-be-gone.intel.com.net>n; Subject: Re: DFU report wrong number of free file headers ?t: Message-ID: <3C910C4E.2F3AFF6F@spam-be-gone.intel.com.net>   Roy Omond wrote:   > Sam wrote: > 
 > > Hi Folks.h > >nI > > On an Alpha 4100 with OpenVMS 7.2-1 with all pathes up-to-date I havei/ > > initialized an ODS5 disk volume as follows:  > > ( > > $ initialize    $1$dga131: disk131 - > >         /system -  > >         /structure=5 -$ > >         /maximum_files=2500000 - > >         /headers=5000000 - > >         /directories=256 - > >         /cluster_size=3 -o > >         /windows=40 -C > >         /nohighwater >s > [...snip...] >. > /Headers=5000000 > ands > /Maximum_Files=2500000 >sC > 5.000.000 is a little more than 2.500.000 (it's almost double :-)R >O! > Try again with sensible values.n  = But DFU is still reporting unreasonable values: only 934 freee9 headers. Either the INITIALIZE failed in some manner (wasp8 there any error message for /HEADERS > /MAXIMUM_FILES ?)8 or DFU has gotten "lost in space" on the ODS-5 volume...       -Ken --6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfieldu! F20 Automation VMS System Supporty kenneth.h.fairfield#intel.come   ------------------------------  # Date: Fri, 15 Mar 2002 02:00:25 GMTn1 From: "David J. Dachtera" <djesys.nospam@fsi.net>l; Subject: Re: DFU report wrong number of free file headers ?t' Message-ID: <3C9157BE.2FCD1BDA@fsi.net>t   "Kenneth H. Fairfield" wrote:l >  > Roy Omond wrote: >  > > Sam wrote: > >  > > > Hi Folks.  > > >-K > > > On an Alpha 4100 with OpenVMS 7.2-1 with all pathes up-to-date I haveM1 > > > initialized an ODS5 disk volume as follows:e > > >D* > > > $ initialize    $1$dga131: disk131 - > > >         /system -w > > >         /structure=5 -& > > >         /maximum_files=2500000 -  > > >         /headers=5000000 -  > > >         /directories=256 - > > >         /cluster_size=3 -h > > >         /windows=40 -p > > >         /nohighwater > >) > > [...snip...] > >q > > /Headers=5000000 > > andh > > /Maximum_Files=2500000 > >iE > > 5.000.000 is a little more than 2.500.000 (it's almost double :-)  > > # > > Try again with sensible values.i > ? > But DFU is still reporting unreasonable values: only 934 free); > headers. Either the INITIALIZE failed in some manner (wast: > there any error message for /HEADERS > /MAXIMUM_FILES ?): > or DFU has gotten "lost in space" on the ODS-5 volume... > 
 >     -Ken  # I've seen more than one bug in DFU.2  $ In Sam's case, I might have an idea:  
 Sam wrote: >  > Hi Folks.A > G > On an Alpha 4100 with OpenVMS 7.2-1 with all pathes up-to-date I haven- > initialized an ODS5 disk volume as follows:y > & > $ initialize    $1$dga131: disk131 - >         /system -o >         /structure=5 -" >         /maximum_files=2500000 - >         /headers=5000000 - >         /directories=256 - >         /cluster_size=3 -e >         /windows=40 -  >         /nohighwater > $! > J > I have some 11 big files on the disk, and now I would like to use it for6 > directory tree containing about 350.000 small files.  , YYYYEEECCCCHHH!!! Well, be that as it may...  J > But when I look at the DFU report of the disk, I'm surprised to see thatK > there is only a header count of 1010 and 934 free headers. Why is it so ?g  G Well, based on my admittedly limited understanding and leaving open the7E possibility of a DFU bug, I'd the expect the reason to be that you'vewE freshly INITIALIZEd the volume. Thus, the highwater marks in both the E INDEXF.SYS file header and in the INDEXF.SYS bitmap to be set a their  newly INIT'd positions.o  K > I would have expected at least 2 million free headers. Should I not trusta! > the numbers in the DFU report ?  >  > Sam  >  > $ dfu report disk131 > 5 >      Disk and File Utilities for OpenVMS DFU V2.7-A, >      Freeware versiong3 >      Copyright  2000 COMPAQ Computer Corporations > 3 > %DFU-I-REPORT, Reporting on DISK131: ($1$DGA131:)e > J >       ***** Volume info for ODS5 volume DISK131: (from HOME block) *****. >  Volume name                      :  DISK131% >  Volume owner                     : % >  Volume set name                  :t. >  Highwater mark. / Erase on del.  :  No / No( >  Cluster size                     :  3. >  Maximum # files                  :  2500000+ >  Header count                     :  1010o* >  First header VBN                 :  624* >  Free headers                     :  934 > 5 >       ***** File Statistics (from INDEXF.SYS) *****-= >  INDEXF.SYS fragments/ map_in_use :  4 /11 words ( 7% used)i. >  Total files (ODS2 / ODS5)        :  10 / 11( >  Empty files                      :  5) >  Files with allocation            :  16m( >  Files with extension headers     :  0( >  Files marked for delete          :  0( >  Directory files                  :  2) >  Contiguous files                 :  15e9 >  Total used/ allocated size       :  21006013 /23505027r) >  Total fragments                  :  19o, >  Average fragments per file       :  1.1889 >  File fragmentation index         :  0.410  (excellent) . >  Average size per fragment        :  1237106% >  Most fragmented file             :dH >     $1$DGA131:[000000]INDEXF.SYS;1 ( 1633/2500623 blocks; 4 fragments)  H I am troubled that INDEXF.SYS was only pre-extended by the MAXIMUM_FILESG value, instead of the HEADERS value, which is what I would expect baseda on past experience.   H My understanding of these qualifiers is that /MAXIMUM_FILES controls howG the INDEXF.SYS bitmap is pre-allocated while /HEADERS controls how many H disk blocks are actually allocated to INDEXF.SYS. Then again, the valuesE you used demonstrate a possible inconsistency. Perhaps the newer codetF corrects for this - quietly (maybe needs a -I- message to let you know you did a dum-dum).e  G It looks like I may be wrong about either or both of those. So, I'll be-F watching this thread to see where my understand needs to be clarified.   > ; >       ***** Free space statistics (from BITMAP.SYS) *****Y/ >  Total blocks on disk             :  88820885g/ >  Total free blocks                :  65315859e) >  Percentage free (rounded)        :  25c( >  Total free extents               :  4H >  Largest free extent              :  41902575  blocks at LBN: 46918308/ >  Average extent size (rounded)    :  16328964t9 >  Free space fragmentation index   :  0.000  (excellent)e > $ > %DFU-I-READY, REPORT command ready > $   E It has it's faults, but DFU is a great little piece of freeware, IMO.l  F Try writing to the author, Ton dot Dorland at compaq dot com. Maybe he knows, if he's still there.t   --   David J. Dachterat dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/w   ------------------------------    Date: 15 Mar 2002 05:20:38 +0800, From: Paul Repacholi <prep@prep.synonet.com>( Subject: Re: DLT Degausser / Bulk Eraser0 Message-ID: <87adtavobd.fsf@k9.prep.synonet.com>  6 karcher@thuria.waisman.wisc.edu (Carl Karcher) writes:  K > In a previous article, bill@triangle.cs.uofs.edu (Bill Gunshannon) wrote:    E > ->On another interesting note, I wonder what would be the result ofoE > ->passing something like a hard disk through an MRI machine??  I'll ! > ->bet that would do the trick!!   nD > Dangerous idea. Anything magnetic in the vicinity of an MRI magnetD > is likely to become a projectile heading toward the magnet. People > have died this way.e  tA I've seen a photo of an oxy bottle floating in an MRI. Nervous isn3 just not near the mark for the people who did it...   A > Plus, since you don't just "turn off" a superconducting magnet,sD > you'd never be able to extricate the drive from the magnet without1 > dumping the helium charge - which is not cheap.   @ Depends on the installation. In the case of the oxy bottle, they3 pulled it out with a cable and block and tackle. :(   B I put a large stack of IBM cartridges through a MRI to erase them.@ Worked a treat, and removed 3 weeks work plugging them through aB drive. We did check all the cartridges with a perm magnet first to@ ensure we had non-magnetic screws in the cases. Some did not IBM stated.o   -- I< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.o@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Fri, 15 Mar 2002 06:01:47 GMTa$ From: "Tim Peer" <peert@envysys.com>& Subject: ES40s have bandwidth to burn?C Message-ID: <f7gk8.11570$lA6.2980316328@newssvr14.news.prodigy.com>   J I am impressed that you are able to perform massive I/O on your system andI are able to execute queries against record segments without using Codasyl G Sets. This certainly speaks well of the combined hardware (CPU, I/O andfJ Memory subsystems). I guess running a Datatrieve query on your system also performs well.   -- Timothy E. Peert eNVy Systems Inc.m 4960 Almaden Exp. #330 San Jose, CA 95118 Voice: (408) 363-8896g Fax:    (408) 363-8897   http://envysys.com  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:c7u29ukr053h3riej12kpbd42osfba37u6@4ax.com...B > On Thu, 14 Mar 2002 17:12:05 GMT, "Tim Peer" <peert@envysys.com> > wrote: >gL > >as defined in the Codasyl DBMS storage schema.  Defining new access pathsF > >require a storage schema change and reorganization of the database. Imagine-E > >performing a pattern-match query on a CHARACTER type data element,h	 perhaps ayC > >description field, in a storage area with say 1,000,000 records.D >3G > Imagine it - we do it!. We have a Navigator SQL query interface whichuG > searches through 6 million MANMAN MATREC records for descriptions. If.G > we ran the whole thing from memory I reckon it could do it in under anG > minute on an ES40. But I guess  if you really need very fast searchesAE > through large amounts of data and don't want to start modifying theeC > underlying DBMS database then I can see why you might use the RDBeE > approach.  But don't forget that you can arrange things so that rowrD > caching and or DBMS local/global buffering and/or VIOC/XFC cachingE > means that after the first search the MATREC records are all cached E > and you don't have to walk through the entire storage realm but arefE > you sure your DBMS database is not heavily into extents and this isaA > why you are seeing a linear walk through the storage area? DBMSoF > performance can really tank if this is the case, You can easily slowG > things down by a factor of ten to one if the database is heavily intoiH > auto extents and this *will* be the case with MANMAN unless you preset6 > things correctly or load/unload the database to fix. >0I > >Unfortunately, you would probably not find a Codasyl Set for this datacL > >element. Using traditional data access, the query will probably perform aF > >storage area realm walk and the IT department will probably have an/ > >opportunity to meet their transaction users.o > >tJ > >The net-change approach used by the Rdb Warehouse works well as the RdbH > >database stays synchronized with Codasyl without the overhead defined above. > >nG > >Beyond ad-hoc SQL queries, the real benefit is seen in a development,J > >environment. Developing web and SQL-based applications is rather simple toJ > >do and besides there is a rich selection of tools available with nativeF > >interfaces (such as Oracle Developer 2000) to relational databases. > C > You can use Developer 2000 to talk to a DBMS database via variousI
 > methods. >e > >i > >>But AttunityC > >> works fine and lets us do whatever we need with ODBC accessingtH > >> underlying MANMAN databases. However I'm not sure if that  would be4 > >> the case if we allowed updates via this method, > >q5 > >Why one would use Rdb in place of Interpreted SQL:h > >oD > >The I/O, CPU and memory overhead incurred in executing queries is isolated > >to an off-line system.eJ > >Ability to use relational database functions and objects without having toE > >modify the Codasyl schema or Codasyl application, examples: stored E > >procedures, functions, triggers, views, hashed and sorted indexes,r synonyms > >to name a few.oK > >Ability to open the data to user/analysts for use with OLAP (data cubes)1	 > >tools.t > >o6 > >Why wouldn't someone implement Codasyl data in Rdb? >v >v   ------------------------------    Date: 14 Mar 2002 11:49:10 -0800- From: pdafniotis@yahoo.com (Petros Dafniotis) 9 Subject: GTK+ 2.0: Are there plans to port it to OpenVMS?y= Message-ID: <e54adf36.0203141149.7335820d@posting.google.com>h  C I have used quite a bit the v1.2.x (I think x=8) which is availablenC since some time now. Are there plans for the recently released GTK+g$ v2.0 to be ported to OpenVMS? Dates?  
 Kind regards,P Petros ---f Petros Dafniotis, PhDn pdafniotis@yahoo.com   ------------------------------  # Date: Thu, 14 Mar 2002 23:17:07 GMTt1 From: "Terry C. Shannon" <terryshannon@attbi.com>h+ Subject: Has Anyone Set Up a Merger Pool???o9 Message-ID: <Tbak8.23945$44.5637012@typhoon.ne.ipsvc.net>   L March Madness: College Rivalries Play Out in Office Pools Around the Country    J RALEIGH, N.C. (AP) - Gary "G-Money" Davis is betting on Duke in the officeL basketball pool. He actually hates Duke, but he figures whatever happens, he wins.   > March Madness is in full swing, and that means office pools...  H "If you're not in prison, you know SOMEbody who's pretty much running anE office pool," says Doug Castaneda, race and sports supervisor for ther# Stardust hotel-casino in Las Vegas.y      1 Umm, is anyone running a CPQ-HPW merger pool? ;-}t   ------------------------------   Date: 14 Mar 2002 18:45:22 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)yP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux, Message-ID: <a6qr42$2m21$1@info.cs.uofs.edu>  2 In article <wi5k8.973$fL6.22344@news.cpqcorp.net>,8  "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: |> iG |>                                                                  SUNlD |> will eventually implode trying to compete with a proprietary chip( |> architecture against Power, and IA64  |> i  @ I think we've been down this road before, but refresh my memory.> In what way is SUN's Sparc any more (or les) proprietary than  Power or IA64??    bill   -- dJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   e   ------------------------------  % Date: Thu, 14 Mar 2002 11:39:02 -0800 # From: "Tom Linden" <tom@kednos.com>oP Subject: RE: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEKAEFAA.tom@kednos.com>    > -----Original Message-----: > From: Bill Gunshannon [mailto:bill@triangle.cs.uofs.edu]) > Sent: Thursday, March 14, 2002 10:45 AMa > To: Info-VAX@Mvb.Saic.ComdI > Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helpingg
 > of Linux >p > 4 > In article <wi5k8.973$fL6.22344@news.cpqcorp.net>,: >  "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > |>I > |>                                                                  SUNsF > |> will eventually implode trying to compete with a proprietary chip) > |> architecture against Power, and IA64n > |> >@B > I think we've been down this road before, but refresh my memory.? > In what way is SUN's Sparc any more (or les) proprietary thanr > Power or IA64??i  I It's not, but that isn't the point.  Sun simply doesn't have the bucks tox compete. >h > bill >t > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h> >,   ------------------------------  # Date: Thu, 14 Mar 2002 19:48:50 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>-P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux9 Message-ID: <C87k8.23661$44.5504432@typhoon.ne.ipsvc.net>t  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIMEKAEFAA.tom@kednos.com...e >n >n > > -----Original Message-----< > > From: Bill Gunshannon [mailto:bill@triangle.cs.uofs.edu]+ > > Sent: Thursday, March 14, 2002 10:45 AMa > > To: Info-VAX@Mvb.Saic.ComOK > > Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping  > > of Linux > >  > > 6 > > In article <wi5k8.973$fL6.22344@news.cpqcorp.net>,< > >  "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > > |>K > > |>                                                                  SUNhH > > |> will eventually implode trying to compete with a proprietary chip+ > > |> architecture against Power, and IA64e > > |> > >0D > > I think we've been down this road before, but refresh my memory.A > > In what way is SUN's Sparc any more (or les) proprietary thand > > Power or IA64??A >EK > It's not, but that isn't the point.  Sun simply doesn't have the bucks to_
 > compete.  J In the long (well, maybe not so long) term I believe this will prove to beJ the case. Intel does chips for a living, IBM has the financial wherewithalL to sustain Power for as long as it so chooses, but what of Sun? I think theyL made a Big Mistake when they reversed their early commitment to IPF. I couldL be wrong, but Sun has yet to present a convincing argument that would refute this position.   ------------------------------  # Date: Thu, 14 Mar 2002 20:41:51 GMT * From: "Bill Todd" <billtodd@metrocast.net>P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of LinuxA Message-ID: <jW7k8.82317$hO6.6878197@bin4.nnrp.aus1.giganews.com>s  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message3 news:C87k8.23661$44.5504432@typhoon.ne.ipsvc.net...- > 0 > "Tom Linden" <tom@kednos.com> wrote in message5 > news:CIEJLCMNHNNDLLOOGNJIMEKAEFAA.tom@kednos.com...  > >  > >   > > > -----Original Message-----> > > > From: Bill Gunshannon [mailto:bill@triangle.cs.uofs.edu]- > > > Sent: Thursday, March 14, 2002 10:45 AM  > > > To: Info-VAX@Mvb.Saic.Com E > > > Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major  helping  > > > of Linux > > >u > > > 8 > > > In article <wi5k8.973$fL6.22344@news.cpqcorp.net>,> > > >  "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > > > |> > > > |> SUN J > > > |> will eventually implode trying to compete with a proprietary chip- > > > |> architecture against Power, and IA64e > > > |> > > >nF > > > I think we've been down this road before, but refresh my memory.C > > > In what way is SUN's Sparc any more (or les) proprietary thant > > > Power or IA64??  > >tJ > > It's not, but that isn't the point.  Sun simply doesn't have the bucks to > > compete. >sL > In the long (well, maybe not so long) term I believe this will prove to beL > the case. Intel does chips for a living, IBM has the financial wherewithalI > to sustain Power for as long as it so chooses, but what of Sun? I thinks theyH > made a Big Mistake when they reversed their early commitment to IPF. I couldaG > be wrong, but Sun has yet to present a convincing argument that would  refute > this position.  J I suspect a commitment to Hammer (as well as, not instead of, SPARC) mightI do that rather well:  Hammer should be all over IPF in the low end, whilenK SPARC should be able to compete in the high-end just as well as it competesDK with other architectures today, even faster ones than Itanic shows any sign 	 of being.s   - bill   ------------------------------    Date: 14 Mar 2002 15:02:00 -0600+ From: young_r@encompasserve.org (Rob Young)tP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux3 Message-ID: <8JHiorx3LPlG@eisner.encompasserve.org>   n In article <jW7k8.82317$hO6.6878197@bin4.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message >>M >> In the long (well, maybe not so long) term I believe this will prove to bevM >> the case. Intel does chips for a living, IBM has the financial wherewithalDJ >> to sustain Power for as long as it so chooses, but what of Sun? I think > theyI >> made a Big Mistake when they reversed their early commitment to IPF. I  > could H >> be wrong, but Sun has yet to present a convincing argument that would > refute >> this position.  > L > I suspect a commitment to Hammer (as well as, not instead of, SPARC) mightK > do that rather well:  Hammer should be all over IPF in the low end, while M > SPARC should be able to compete in the high-end just as well as it competes M > with other architectures today, even faster ones than Itanic shows any signa > of being.  >   ? 	Ah... but Intel has their finger on AMD's Oxygen supply.  AMD  ? 	will probably never get big beyond a certain point, nor garner = 	revenues beyond a certain point.  Intel folks are Masters attD 	pricing their CPUs to effectively maximize AMD pain and/or minimize? 	AMD's profits and that probably won't change much.  So whoever , 	commits to AMD will always be very nervous.   	As our friend Paul points out:   ? http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=17169068D  0 Intel's Server CPU plans for 2002 - and pricing:  N Note the RAPID drop in Xeon 2.2 GHz pricing in May - I think Intel is going toM preempt the Hamster [Hammer] - so that it is introduced as another MAD money   loser !x   	n [snip]  1 CPU          Current Price    April 14    May 26 _; Xeon 2.4                                  $615 (at launch) i/ Xeon 2.2          $615         $465       $262 c/ Xeon 2.0A         $417         $305       $224 a/ Xeon 2.0          $396         $316       $256 c/ Xeon 1.8          $251         $224       $192 u/ Xeon 1.7          $224                    $202  & Pentium III-S 1.4 $316         $294      				Robg   ------------------------------  # Date: Thu, 14 Mar 2002 21:33:31 GMT * From: "Bill Todd" <billtodd@metrocast.net>P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of LinuxA Message-ID: <LG8k8.85702$uv5.6734011@bin6.nnrp.aus1.giganews.com>   8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:8JHiorx3LPlG@eisner.encompasserve.org...LI > In article <jW7k8.82317$hO6.6878197@bin4.nnrp.aus1.giganews.com>, "Bille& Todd" <billtodd@metrocast.net> writes:   ...F  H > > I suspect a commitment to Hammer (as well as, not instead of, SPARC) mightcG > > do that rather well:  Hammer should be all over IPF in the low end,  whilewF > > SPARC should be able to compete in the high-end just as well as it competesJ > > with other architectures today, even faster ones than Itanic shows any sign
 > > of being.. > >  >n? > Ah... but Intel has their finger on AMD's Oxygen supply.  AMD/@ > will probably never get big beyond a certain point, nor garner> > revenues beyond a certain point.  Intel folks are Masters atE > pricing their CPUs to effectively maximize AMD pain and/or minimize.4 > AMD's profits and that probably won't change much.  G It will if they keep pouring their profits down the Itanic drain at thel
 current rate.o     So whoever- > commits to AMD will always be very nervous.b  H Actually, if Sun committed to AMD, it would strengthen *both* companies,, making *everyone* considerably less nervous.   >n  > As our friend Paul points out: > A > http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=17169068e >a2 > Intel's Server CPU plans for 2002 - and pricing: > G > Note the RAPID drop in Xeon 2.2 GHz pricing in May - I think Intel isu going toH > preempt the Hamster [Hammer] - so that it is introduced as another MAD moneyf	 > loser !n  J Hmmm.  Trouble is, those new, fast, hyper-threaded Xeons aren't performingF all that much better than the old, slow Xeons (see today's Inquirer, IJ think).  So rather than Xeon threatening Hammer, it seems likely to be theL other way 'round (not to mention Xeon's complete inability to compete in the
 64-bit area).e   - bill   ------------------------------  % Date: Thu, 14 Mar 2002 13:43:06 -0800W' From: David Mathog <mathog@caltech.edu>mP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux+ Message-ID: <3C91196A.E005F15B@caltech.edu>    Andrew Harrison wrote:  > > People who think this don't understand what Linux is or what> > makes an OS sucessfull. Available software is a huge factor,? > it was behind the sucess of Win32, but in the Linux world theh> > API's used to code (GNU) are freely available in source formA > making it possible for commercial UNIX vendors to impliment the ? > same API's as used on Linux without royalty or fear that theyt7 > are shooting at a undocumented moving target (win32).v  L I'm largely in agreement with this argument as it applies to common freewareK applications.  And there's no question that it's easier to get this type ofhG code up and running on Solaris (or any other Unix, from a Linux origin)w0 than on, for instance, VMS or Windows.  Just do      % ./configureq   % make   % make install  B and 99% of the time you're in business. That said, there are still> chunks of linux code around that are proprietary and that giveA Linux a growing competitive edge over the commercial Unixes.  Forn: instance, there are manufacturer supplied drivers for SCSI: adapters and graphics adapters for linux where there is no; Solaris counterpart.  (Or, at best, a Solaris Intel variantd> but none for Solaris Sparc.)  Rarely the driver issue cuts the
 other way.   > = > Linux offers the opportunity of increasing the pool of appsm@ > that will run on any commercial UNIX with the right interfaces= > whether it kills Solaris etc depends on if it advances to a09 > point where it can compete in capability terms with thea< > commercial UNIX's, at the moment its a long way off but it5 > is very competitive with Win32 in all its flavours.e >   D You're on your own there.  We're running an awful lot of linux boxesB that in previous years would have been "commercial Unixes".  LinuxI has all the capabilities we need now for small machines.  You can ask theg7 VMS engineers how much fun it is being painted into the ( "data center only" corner of the market.   Regards,   David Mathog mathog@caltech.edu   ------------------------------  % Date: Thu, 14 Mar 2002 17:25:37 -0500f- From: JF Mezei <jfmezei.spamnot@videotron.ca> P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux, Message-ID: <3C91235D.E540AB4D@videotron.ca>   Fred Kleinsorge wrote:J > geeks.  Hardware choice, capability, and performance is converging.  SUNC > will eventually implode trying to compete with a proprietary chipyM > architecture against Power, and IA64 - they don't have the money to try andi7 > compete with IBM and Intel to fab fast, cheap chips. n  B Who actually FABs SUN's chips ?   Does Intel lead the world in theK implementation of the latest and greatest in FAB technologies ? I was under J the impression that Intel tended to lag behind the high tech stuff waitingK until it is ready for high volume production. Is that a correct portrayal ?t  J Just like Digital was able to separate chip designs from FABbing and usingM whatever FAB it wanted, I don't see why SUN would be hindered. Also, the risehH of the 8086 against Alpha proves that inferior chips can be commercially/ succesful with the right marketing and pricing.n  M > common Linux kernel, and package their proprietary added-value into a Linuxe? > "product" -- call it Linux/Enterprise Edition, or Linux/Pro.    O Isn't this what they have done ? They call it "Solaris" instead of "Linux/Pro".    ------------------------------  % Date: Thu, 14 Mar 2002 17:37:12 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>sP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux, Message-ID: <3C912613.BCD2B4B3@videotron.ca>   Tom Linden wrote:pK > It's not, but that isn't the point.  Sun simply doesn't have the bucks tod
 > compete.  J Sun seemed to have done quite well against the vastly superior Alpha. WhatL counts is price-performance, not raw performance.  So Sun may not get the 10H "super computer" sales, but it may still be able to get the thousands of  serious and medium server sales.   ------------------------------  % Date: Thu, 14 Mar 2002 17:43:39 -0500y- From: JF Mezei <jfmezei.spamnot@videotron.ca>dP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux, Message-ID: <3C912796.D7E90CF8@videotron.ca>   "Terry C. Shannon" wrote:-N > made a Big Mistake when they reversed their early commitment to IPF. I couldN > be wrong, but Sun has yet to present a convincing argument that would refute > this position.  L *IF* IA64 turns out not to be a dud, there is nothing that prevents Sun fromL adopting it later on. But until then, it is wise to go full speed ahead withH our own chip that offers differentiating features. Also, if Sun controlsM Sparc, it can steer its development to be optimized for its customers and OS.-  D In trying to please everyone with its IA64, Intel will please noone.   ------------------------------  % Date: Thu, 14 Mar 2002 19:20:30 -0800e" From: GreyCloud <mist@cumulus.com>P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux/ Message-ID: <u92poad7ojn7a5@corp.supernews.com>C   JF Mezei wrote:n   > Fred Kleinsorge wrote:K >> geeks.  Hardware choice, capability, and performance is converging.  SUNvD >> will eventually implode trying to compete with a proprietary chipJ >> architecture against Power, and IA64 - they don't have the money to try; >> and compete with IBM and Intel to fab fast, cheap chips.n > " > Who actually FABs SUN's chips ?   D I've read on Suns' site once that Texas Instruments does the actual D fabrication of the sparc chips.  Who designs them is another matter.   ------------------------------  % Date: Thu, 14 Mar 2002 19:26:51 -0800:" From: GreyCloud <mist@cumulus.com>P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux/ Message-ID: <u92q46qkn3dj65@corp.supernews.com>,   JF Mezei wrote:"   > "Terry C. Shannon" wrote:wI >> made a Big Mistake when they reversed their early commitment to IPF. I H >> could be wrong, but Sun has yet to present a convincing argument that >> would refute this position. > I > *IF* IA64 turns out not to be a dud, there is nothing that prevents Sun H > from adopting it later on. But until then, it is wise to go full speedL > ahead with our own chip that offers differentiating features. Also, if SunF > controls Sparc, it can steer its development to be optimized for its > customers and OS.r > F > In trying to please everyone with its IA64, Intel will please noone. >   J Can I conclude then that Intel is trying to make the IA-64 the swiss army  knife of processors??    ------------------------------  # Date: Fri, 15 Mar 2002 03:17:23 GMTx1 From: "Terry C. Shannon" <terryshannon@attbi.com>gP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux9 Message-ID: <7Jdk8.24531$44.5824659@typhoon.ne.ipsvc.net>d  / "GreyCloud" <mist@cumulus.com> wrote in messageo) news:u92poad7ojn7a5@corp.supernews.com...' > JF Mezei wrote:x >a > > Fred Kleinsorge wrote:H > >> geeks.  Hardware choice, capability, and performance is converging. SUN F > >> will eventually implode trying to compete with a proprietary chipL > >> architecture against Power, and IA64 - they don't have the money to try= > >> and compete with IBM and Intel to fab fast, cheap chips.  > >a# > > Who actually FABs SUN's chips ?  >>E > I've read on Suns' site once that Texas Instruments does the actual.F > fabrication of the sparc chips.  Who designs them is another matter. >   H Yup, Sun's been fabless forever. DEC of course went that route when they@ sold Fab-6 to Intel. Chip design and development can be a priceyI undertaking, and unless you maintain a demonstrable performance advantagenK (little good that did for Alpha), rivals who use commodity chips are likelyn/ to put you at a serious financial disadvantage.d   ------------------------------  % Date: Thu, 14 Mar 2002 23:33:24 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>"P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux, Message-ID: <3C917993.F2D61F87@videotron.ca>   "Terry C. Shannon" wrote:iB > sold Fab-6 to Intel. Chip design and development can be a priceyK > undertaking, and unless you maintain a demonstrable performance advantagesM > (little good that did for Alpha), rivals who use commodity chips are likelyt1 > to put you at a serious financial disadvantage.V    N Do compilers cost a lot of money and should be gotten rid of, or are they seenH as an enabling technology that makes your platform far more marketable ?  F There is a huge difference between Digital/Compaq and Sun: Digital wasI incapable of selling Alpha based products, and Compaq didn't want to sell K Alpha based products. Sun on the other hand had no problems shoving its ownpK products down the throats of as many customers as it can, it has no problem I advertising iots own products and it has no problems pitching its producta( against Microsoft and other competitors.  K Failure implies an attempt at something. Alpha didn't fail since it was not M allowed to enter the competition. SUN is in the same position as Dec was withnK Alpha: a proprietary OS and a proprietary chip and proprietary systems. AndfK guess what, they are doing very well in terms of market penetration, and onaJ that metric, they are more "industry standard" than Intel's IA64 thing can! hope to be in the next few years.    ------------------------------  # Date: Fri, 15 Mar 2002 05:03:53 GMTt  From: cjt <cheljuba@prodigy.net>P Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux+ Message-ID: <3C9180E9.DA605D8C@prodigy.net>R   JF Mezei wrote:n >  > "Terry C. Shannon" wrote: D > > sold Fab-6 to Intel. Chip design and development can be a priceyM > > undertaking, and unless you maintain a demonstrable performance advantage O > > (little good that did for Alpha), rivals who use commodity chips are likelyn3 > > to put you at a serious financial disadvantage.M > P > Do compilers cost a lot of money and should be gotten rid of, or are they seenJ > as an enabling technology that makes your platform far more marketable ? > H > There is a huge difference between Digital/Compaq and Sun: Digital wasK > incapable of selling Alpha based products, and Compaq didn't want to sell M > Alpha based products. Sun on the other hand had no problems shoving its own M > products down the throats of as many customers as it can, it has no problemUK > advertising iots own products and it has no problems pitching its productp* > against Microsoft and other competitors. > M > Failure implies an attempt at something. Alpha didn't fail since it was not O > allowed to enter the competition. SUN is in the same position as Dec was with M > Alpha: a proprietary OS and a proprietary chip and proprietary systems. Andl  O About the only sense in which they are proprietary OS and chips is that they'reo non-Wintel.l  M > guess what, they are doing very well in terms of market penetration, and oneL > that metric, they are more "industry standard" than Intel's IA64 thing can# > hope to be in the next few years.B   ------------------------------  # Date: Fri, 15 Mar 2002 03:38:03 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>rP Subject: Re: HP's viewpoint on Linux, was: Re: Sun eating major helping of Linux9 Message-ID: <v0ek8.24541$44.5838046@typhoon.ne.ipsvc.net>l  / "GreyCloud" <mist@cumulus.com> wrote in messageh) news:u92q46qkn3dj65@corp.supernews.com...e > JF Mezei wrote:e >a > > "Terry C. Shannon" wrote:iK > >> made a Big Mistake when they reversed their early commitment to IPF. I J > >> could be wrong, but Sun has yet to present a convincing argument that  > >> would refute this position. > >uK > > *IF* IA64 turns out not to be a dud, there is nothing that prevents Sun J > > from adopting it later on. But until then, it is wise to go full speedJ > > ahead with our own chip that offers differentiating features. Also, if SunrH > > controls Sparc, it can steer its development to be optimized for its > > customers and OS.  > >oH > > In trying to please everyone with its IA64, Intel will please noone. > >. >tK > Can I conclude then that Intel is trying to make the IA-64 the swiss army  > knife of processors??o >o  L To the extent that IA32 is the Swiss Army Knife of 32b processors, I suppose0 the same can be said for Intel's goals for IA64.   ------------------------------  # Date: Thu, 14 Mar 2002 20:50:45 GMTe# From: "Dan" <io_crater@hotmail.com>p& Subject: Re: HSZ10 looking for info...: Message-ID: <F28k8.94832$eb.4084815@news3.calgary.shaw.ca>  F Thanks that confirmed what it is. I pulled out the module and it had aL sticker indicating HSZ10-AX.  Yes, I don't have need nor much desire for the
 DSSI version.f  G Upon closer look it isn't a MMJ port, but RJ11  (6 pin centered lockinglI pin).  Even with a RJ11 to MMJ cable and various crossing of the wires itb: doesn't want to talk to my PC emulator or Alpha COM2 port.  @ The unit does power up though. I get 2 red LEDs and 1 green lit.  C At this point I would just like to find some documentation so I canr interpret what I am seeing.    Thanks,c Dan Henigman  7 "Frank Sapienza" <sapienza@noesys.com> wrote in messageo& news:a6oo5j02fng@enews3.newsguy.com...H > The SWXRA part number you gave is for the cabinet, not the controller. >rK > You may want to remove the controller from the cabinet and check the partiK > number just to make sure it's not an HSD10, which wouldn't be very usefulr toL > you.  The other option is to get (or make) a DEConnect cable and plug in a= > VT (or emulator) into that MMJ port and power up the thing.u >)I > The single-channel controllers (HSD10, HSZ10) did not use a PCMCIA card7 for  > the firmware.4 >  >n > Frank  > 0 > "Dan" <io_crater@hotmail.com> wrote in message7 > news:f8Pj8.138271$kb.7590940@news1.calgary.shaw.ca... K > > I recently picked up what I believe is an HSZ10 at an auction that I am J > > hoping to attach to a VMS hobbyist  system (Alpha 4100 or 1000).    As > usualoK > > for auctions the HSZ10 came with no manuals or software. A model numberS on( > > the back of the unit shows SWXRA-01. > >8 > >2D > > It does not have the PC Card that I have seen in newer model HSZL > > controllers.  It has an MMJ jack on the front along with 2 68 pin female > > SCSI connectorsk > >1 > >.J > > Any pointers on documentation and software requirements for this unit? Ii7 > > am not having much luck with the internet searches.w > >s > > Dan Henigman > >) >i >c >    ------------------------------   Date: 14 Mar 2002 12:39:19 CDT= From: wayne@tachysoft.xxx.564897.killspam.00c7 (Wayne Sewell)  Subject: Re: Itanium troubles . Message-ID: <t167n6P0NJXE@tachxxsoftxxconsult>  k In article <3C8CD90B.1010307@sun.com>, Andrew Harrison <andrew_nospam.harrison_remove_this@sun.com> writes:p > ) > Where does this information come from ?d@ > Intel have only clearly indicated that Mckinley will be faster? > than a 400 Mhz Ultra IIi. At least if their own presentationsa > are to be believed.m >       K Oh, crap!  He's back.  Bloody marvelous.  And with a different address so Ip% have to change the damn filter again.a     -- lO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxi: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)mO ===============================================================================e= Society Lady:  Are you familiar with the Great Wall of China?i5        Curly:  No, but I know a big fence in Chicago!i   ------------------------------  % Date: Thu, 14 Mar 2002 17:01:57 -0500o- From: JF Mezei <jfmezei.spamnot@videotron.ca>r Subject: Re: Itanium troubles , Message-ID: <3C911DD2.33B8020F@videotron.ca>  L Andrew Harrison wrote:> Intel have only clearly indicated that Mckinley will	 be fasterd? > than a 400 Mhz Ultra IIi. At least if their own presentationsb > are to be believed.    Welcome back Andrew.   Is Sun hiring ?,   ------------------------------    Date: 15 Mar 2002 06:16:44 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: Itanium troublesL0 Message-ID: <871yemvlpv.fsf@k9.prep.synonet.com>  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  E > In article <ee5k8.379045$Aw2.31269250@bin7.nnrp.aus1.giganews.com>, . > "Bill Todd" <billtodd@metrocast.net> writes:  F > |> The major detail that surfaced recently is that Intel's claim mayA > |> be that it's 70% faster on SPECint (with code recompiled forfA > |> McKinley, rather than running code compiler for Merced) *peroE > |> clock* than Merced, in which case it would be 2.1+ times as fasteD > |> absolutely at 1 GHz (i.e., around 800 SPECint, though consensus9 > |> expectations seem to be more in the 650 - 700 area).t  eE > Interesting.  It might actually be seriously competitive if that isnB > so - not that 25% is significant, but people do so love the chip > that leads the SpecRace :-)t  ? The Inquirer reported that intel has released numbers at CeBit.t 1.5-2.0 time merced.   -- h< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.d@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Fri, 15 Mar 2002 04:02:32 +0000d& From: Alan  Greig <a.greig@virgin.net> Subject: Re: Itanium troubleso8 Message-ID: <dgs29u4q68m5aiott8uo0msmjtuvqa56ht@4ax.com>  E On 14 Mar 2002 12:39:19 CDT, wayne@tachysoft.xxx.564897.killspam.00c7p (Wayne Sewell) wrote:t  l >In article <3C8CD90B.1010307@sun.com>, Andrew Harrison <andrew_nospam.harrison_remove_this@sun.com> writes: >> f* >> Where does this information come from ?A >> Intel have only clearly indicated that Mckinley will be fasterg@ >> than a 400 Mhz Ultra IIi. At least if their own presentations >> are to be believed. >> x >a >l >hL >Oh, crap!  He's back.  Bloody marvelous.  And with a different address so I& >have to change the damn filter again.  A Sun must be getting really worried about the competition from VMSa again :)   ------------------------------    Date: 14 Mar 2002 12:08:56 -0800- From: david.colker@latimes.com (David Colker)p6 Subject: L.A. Times article on HP mailings and proxies= Message-ID: <82a90b56.0203141208.44e49260@posting.google.com>9   Hello:  E We are doing a story here at the Los Angeles Times about the numerouscA mailings and proxies that HP stockholders have received from bothm= sides of the battle over the proposed HP/Compaq merger. We'reeE interested in finding out what stockholders think of the mailings andp1 how influenced they have been by them, if at all.   C If you are a stockholder and have gotten the mailings over the lastmF several weeks, I'd greatly appreciate the chance to speak with. PleaseE send me e-mail letting me know how to contact you, or you are welcomew; to contact me at: (800) LA-TIMES (800 528-4637), ext 77496.      Best,o   David Colker Los Angeles Times    ------------------------------  # Date: Thu, 14 Mar 2002 18:47:26 GMTt$ From: "Tim Peer" <peert@envysys.com>: Subject: Leveraging Mixed Format with Uniform Format TypesC Message-ID: <2f6k8.11343$IF5.2812143871@newssvr14.news.prodigy.com>g  G Since I do not have the benefit of a complete understanding of your RdbdC schema, I can only answer in general terms. My outline describes an,I implementation similar to your configuration (I think) in terms of how to ? best leverage query I/O for a combination of transaction types.e  K You may benefit from using Mixed Format Storage Area "MFSA"  via clusteringaI and placement via Hashed index technologies,  but not without incurring a J cost to maintenance and frequent monitoring of the MFSA. At the point whenL your MFSA extends, any I/O gains are immediately lost for queries of data in the extent segments.  K The approach that I outlined may improve your I/O performance by leveraging C the two storage area format types and limit your exposure to extents	 segments.e   I hope this helps.   -- Timothy E. Peer  eNVy Systems Inc.u 4960 Almaden Exp. #330 San Jose, CA 95118 Voice: (408) 363-8896e Fax:    (408) 363-8897   http://envysys.com  7 "Frank Sapienza" <sapienza@noesys.com> wrote in messagew& news:a6qcns029ra@enews3.newsguy.com...I > I'm sure this was a great idea, but I fail to see how it would apply toC then > question I posed.a >g >s > Frank  >y1 > "Tim Peer" <peert@envysys.com> wrote in message ? > news:SkUj8.10240$vN5.2582517928@newssvr14.news.prodigy.com...oJ > > > What I'm really wondering about is the performance benefits (if any) ofI > > > using a single mixed storage area for similarly constructed tables,i > ratherL > > > than one or more uniform storage areas. The application I'm working onI > > > requires moving records among such tables and I'm looking to reducet thet > > I/O 1 > > > as much as possible during those processes.  > > H > > Why not try a hybrid approach to take advantage of the excellent I/OI > > performance from MIXED format storage areas with placement via hashed H > > indexes, and store data in UNIFORM storage areas? We have found thisI > > approach to be among the best performing with very little maintenanceoG > > required. We found the implementation described below to work best.n ManyI > > sites where this approach is deployed have little technical expertiseh > and/orL > > may not have a DBA on staff--the Corporate Controller sometimes performs > thew  > > system administration tasks. > >i > > For perspective: > >BK > > We needed to create an Rdb data warehouse using the Codasyl DBMS schemat as > a L > > model. Since Codasyl DBMS is not a relational model, it was necessary toF > > "reverse-engineer" the Codasyl DBMS schema and create a relational
 > databaseG > > that preserved Codasyl DBMS Owner and Member relationships.  In oure	 > Codasyl I > > DBMS database, PRTREC is stored in PRTAREA.  We preserved the orginalzI > > Codasyl structure in Rdb.  Companion storage areas and tables use the  sameL > > name as the Codasyl DBMS counterpart. Storage maps were created to place > the K > > row in the PRTAREA_NV.RDB storage area. Records are stored in Rdb usingnJ > > ordinals from the Codasyl DBMS DBKEY (rowid). We broke apart the DBKEYI > > "1:22:5" , formatted as: area=1, page = 22, line = 5.  The Rdb schemao wasiK > > designed with a MIXED format storage area (MFSA) to store "unique" keysnL > > (since we are using the DBMS DBKEY, there is one and only one DBMS DBKEY > for I > > each record). A HASHed index was created for the composite DBKEY withcK > > placement in the MFSA. Data are stored to tables via a storage map in aoJ > > UNIFORM format-storage area (not RDB$SYSTEM).  When inserted, rows areG > > appended to the table, unique key lookups occur via the composite -: HASHed
 > > index. > > L > > This is put to test as we read the Codasyl DBMS After Image Journal fileG > > (AIJ) and obtain changes, insertions and deletions made to Codasyl.g ThesesG > > AIJ rows are inserted, changed and deleted in Rdb using the CodasylK DBKEY. > > Performance is excellent.  > >eJ > > Create SORTed indexes when selecting data using a RANGE of key values. > StorenE > > the sorted indexes in the storage with the data or in a dedicateda UNIFORM G > > storage area. A dedicated storage for sorted indexes may work best.f > >sJ > > We retrieve data via ODBC using AREA,PAGE,LINE - our application moves< > > copies data to a database servers running Oracle 8i, SQLF > > Server, and SYBASE.  SORTed index keys take the form: NVTIMESTAMP,J > > PAGE,AREA,LINE. The sorted index compares the timestamp on the Rdb row to > aF
 > > saved VMSCL > > timestamp (when the table was copied last to the PC/UNIX database server > themJ > > time the transfer started is stored in a transfer table).  Only new orE > > changed rows are ever moved to the database server. Deletions arei handledeJ > > using a different method.  There was a bug in Oracle's Rdb ODBC driver > whenC > > selecting records via a timestamp key, "WHERE timestamp-value >nH > > other-timestamp-value."  The bug walked the table and did not use an > index.J > > For larger tables, performance was unacceptable, adding additional key; > > segments provided a reasonable performance work-around.l > >o5 > > Here is the Rdb schema information for reference:t > >o > > create storage area PRTAREAo > > filename 'PRTAREA_NV.RDA't > > -- read write storage area > > locking is row level > > page format is UNIFORM > > page size is 2 blocksi > > allocation is 2 pagesa> > > extent is (minimum 2000, maximum 20000, percent growth 20) > >  > > create storage area NVINDEXe2 > > filename 'NV$DISK:[ENVY.002]MANDB_NVINDEX.RDA' > > -- read write storage area > > locking is row level > > page format is MIXED > > page size is 3 blocks  > > allocation is 251386 pages; > > extent is (minimum 98, maximum 9998, percent growth 20)s; > > snapshot filename 'NV$DISK:[ENVY.002]MANDB_NVINDEX.SNP'b& > > snapshot allocation is 32464 pagesD > > snapshot extent is (minimum 98, maximum 9998, percent growth 20) > > interval is 216;B > >     CREATE STORAGE MAP PRTREC_MAP FOR PRTREC STORE IN PRTAREA;% > >     CREATE INDEX NV_PRTREC_HSHIDXp( > >         ON PRTREC (PAGE, AREA, LINE)= > >         TYPE IS HASH ENABLE COMPRESSION STORE IN NVINDEX;i > >mG > > Our observations revealed this to be a simpler alternative to usinga hashedD > > insertions and row clustering--data warehousing on Rdb without a DatabaseG > > Administrator on staff. Send me an e-mail and I will send you a DCLj> > > procedure that you can use to calculate allocation values. > >e > > -- > > Timothy E. Peer  > > eNVy Systems Inc.A > > 4960 Almaden Exp. #330 > > San Jose, CA 95118 > > Voice: (408) 363-8896  > > Fax:    (408) 363-8897 > >a > > http://envysys.com > >y > >  >e >k   ------------------------------  % Date: Thu, 14 Mar 2002 15:45:51 -0500t+ From: "Rick Barry" <barry@star.zko.dec.com>c* Subject: Re: Netcraft Uptime For OpenVMS ?2 Message-ID: <z_7k8.982$fL6.22426@news.cpqcorp.net>  5 "Paul Sture" <paul.sture@bluewin.ch> wrote in messagea# news:3C8B6CF5.9060900@bluewin.ch...l > GreyCloud wrote: >t > > Jerry Leslie wrote:? > >  > >r- > >>Paul Sture (paul.sture@bluewin.ch) wrote:n
 > >>: Um, trywE > >>: http://uptime.netcraft.com/up/graph/?mode_u=off&mode_w=on&site= + > >>: www.openvms.compaq.com&submit=Examineo > >> > >>This is what I got:n > >>D > >>  "No uptime is currently available for www.openvms.compaq.com." > >># > >>but I get this for www.sun.com:u > >>8 > >>  "Uptime Charts and Statistics for www.sun.com ..." > >>	 > >>Jerryo > >> > >> > > L > > I think that M$ pays netcraft in my opinion.  OpenVMS would embarass the  > > rest of the o/ses out there. > > & > It certainly _used_ to be listed :-( >  >h > Paul Sture
 > Switzerlandp >t  I I don't recall "uptime" ever being calculated for OpenVMS-based sites. WeaJ just recently got Netcraft to recognize OpenVMS as an operating system (itI used to come up as "other" or "unknown"). We'll ask the Netcraft folks ift2 they can determine that information. (If you go toL http://uptime.netcraft.com/up/accuracy.html, you'll see the list of OS's forG which they don't provide uptime statistics. They don't say what they're"( using to come up with this information.)  I Imagine the "my web site's been up longer than your's" contest that wouldD
 unfold. :)  
 Rick Barry Compaq Secure Web Server OpenVMS System Software Groupw Compaq Computer Corporationq
 Nashua, NH   ------------------------------   Date: 14 Mar 2002 23:58:37 GMT) From: leslie@clio.rice.edu (Jerry Leslie)e* Subject: Re: Netcraft Uptime For OpenVMS ?' Message-ID: <a6rdfd$9ij$2@joe.rice.edu>s  * Rick Barry (barry@star.zko.dec.com) wrote:K : I don't recall "uptime" ever being calculated for OpenVMS-based sites. WeoL : just recently got Netcraft to recognize OpenVMS as an operating system (itK : used to come up as "other" or "unknown"). We'll ask the Netcraft folks ifn4 : they can determine that information. (If you go toN : http://uptime.netcraft.com/up/accuracy.html, you'll see the list of OS's forI : which they don't provide uptime statistics. They don't say what they're.* : using to come up with this information.) :gK : Imagine the "my web site's been up longer than your's" contest that wouldt : unfold. :) :t  " And the problem with that is ? :-)  H That's just the piece of data to drop in a Windows vs. unix reliability  thread, along with:   /    o http://www.pointsecure.com/Defconwhite.pdfi$      "Virtually Unhackable: DEFCON9:  @    o info on CERT advisories per month for VMS, unixes, Windows.  .    o success stories of multi-site VMSClusters  4 --Jerry Leslie     (my opinions are strictly my own)  = "VMS: Uptime measured with a calendar instead of a stopwatch"S   ------------------------------  % Date: Thu, 14 Mar 2002 15:34:42 -0500e; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>s= Subject: Re: Online reference guide to ANSI/VT-ESC-commands ?t$ Message-ID: <3c9109b3$1@news.si.com>   Look in SYS$SYSTEM:SMGTERMS.TXT  --  A Brian Tillman                   Internet: tillman_brian at si.comaA Smiths Aerospace                          tillman at swdev.si.comm= 3290 Patterson Ave. SE, MS      Addresses modified to prevent < Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Thu, 14 Mar 2002 17:13:23 -0500   From: John Santos <JOHN@egh.com>3 Subject: Re: Opening a SYS$OUTPUT file in VMS Basic.6 Message-ID: <1020314170450.22171B-100000@Ives.egh.com>  + On Thu, 14 Mar 2002, Michael D. Ober wrote:J   > John,o > K > I just tried both your suggestions - I hadn't thought of them.  Both gaves > the following error: > 1 > %BAS-F-RECATTNOT, Record attributes not matchedt* > -BAS-I-ON_CHAFIL, on channel 92 for file) > DRA0:[WA.ERR]TEST_RUN_PROGRAM_MDO_25447.! > _DB_S.LIS;1 at user PC 00000000 6 > -BAS-I-FROGSBMOD, In GOSUB in module PROCESS_COMMAND5 > -BAS-I-FROFUN, In external function PROCESS_COMMAND0' > -BAS-I-FROSUB, In subprogram IPSERVERH" > -BAS-I-FROMOD, In module DB_TESTB > break on unhandled exception preceding SHARE$LIBRTL_CODE0+395444= > %DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PCn> >         Displaying source in a caller of the current routine > I > This is the same error I have gotten on all the other options.  I had asH > thought driving in this morning, what is the DCL command to change theK > organization of a file.  Since I delete the file immediately after I read J > it, changing the file organization on the fly is a viable option for me. >   J Sorry for the bum steer.  I just tried it again.  "organization sequentialF variable, recordtype any" seems to work fine for me fro reading a fileA produced by DCL when invoking a command file with "/output", i.e.a   $ @x/out=old.lis   $ type t.bas  E 5       open "old.lis" for input as file 1, organization sequential &l 	variable, recordtype anyi 10      for i=1 to 100 20      input line #1, a$i 30       print a$a 40      next i 1000    close #1 32767   endr   $ run ta ... works...   Using recordtype list givesa/ %BAS-F-RECATTNOT, Record attributes not matchednE -BAS-I-ON_CHAFIL, on channel 1 for file OLD.LIS;1 at user PC 0017AE87=) -BAS-I-FROLINMOD, from line 5 in module To  = I'm pretty sure several other people suggested the same thing/= (recordtype any).  Not sure what type DCL output files are ifx< they aren't "list".  They surely aren't NONE or FORTRAN, the3 other legal recordtypes, according to BASIC's HELP.=   > --	 > Thanks,= > Mike Ober. > / > "John Santos" <JOHN@egh.com> wrote in messagef0 > news:1020313200949.351E-100000@Ives.egh.com.../ > > On Wed, 13 Mar 2002, Michael D. Ober wrote:  > >eF > > > In the following code: (i've replace variables with literals for
 > brevity) > > >:5 > > > redirect = "sys$dsk:[testarea.err]MYOUTPUT.LIS"v< > > > retval = lib$spawn("RUN MYPROGRAM",,redirect,,,,,,,,,) > > > if retval = SS$_NORMAL > > >   then9 > > >      open redirect for input as file #92, [options]i	 > > > ...  > > >e > > > end if > > >aN > > > The "Open Redirect" fails with a record type mismatch.  For [options], I > > > have tried > > >m > > > <no options>$ > > > organization Sequential stream& > > > organization sequential variable) > > > organization unkown, recordtype any. > > >k > > > among others to no avail.e > > >.E > > > Dir/full reports the file is sequential with a record type VFC.t > > >r; > > > How can I open and read the text in my redirect file.e > >iE > > Did you try "organization sequential [variable], recordtype list"  > >rE > > I believe that's what DCL creates for output files.  I'm not surerD > > if you need to include "variable" in the organization clause, or* > > if the "recordtype list" implies that. > >u > > > --
 > > > Thanks,n > > > Mike Ober. > >n > > -- > > John Santos6  > > Evans Griffiths & Hart, Inc. > > 781-861-0670 ext 539 > >s >  >  >  >    -- i John Santost Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 14 Mar 2002 22:02:38 +0000s2 From: John Eisenschmidt <jweisen@eisenschmidt.org>5 Subject: OT: AOL "whiners" for suing MS over NetscapeC3 Message-ID: <20020314220238.C2878@eisenschmidt.org>    --s9fJI615cBHmzTOP* Content-Type: text/plain; charset=us-ascii Content-Disposition: inline + Content-Transfer-Encoding: quoted-printable   L This came to one of my other mailing lists. The author is an Economist. Thi=: s is why economists should have no right to comment on IT.  ' http://www.fff.org/comment/com0203c.aspc =20: Netscape Gets the Green "W"D by Sheldon Richman, March 2002  @ Imagine the nerve of a company that gives away its product in anF attempt to knock off the dominant firm in an industry. I have one such> company in mind right now. It went all out to make it easy forF consumers to have free access to its product. You couldn't turn aroundA without being handed, gratis, this company's goods. When the dust ? settled, the new company was No. 1, the old leader relegated to  also-ran status.  E No, I am not thinking of Microsoft and its effort to dethrone the webtB browser Netscape Navigator with Internet Explorer. I'm thinking ofE America Online's (AOL) move against Compuserve as an Internet servicegF provider. It's more than a little ironic that AOL Time Warner now ownsC Netscape and has just filed an antitrust suit against Microsoft fori! doing what AOL did to Compuserve.i  C AOL Time Warner Netscape should be given the Green "W," the award IeB just made up for the biggest corporate whiner in the country. (TheB competition for that distinction is fierce.) The American business> ethic today is this: Those who can do; those who can't, cry to government.n  D What is Microsoft's grave offense? Netscape says that Navigator lostC favor with the market because Microsoft began to give away InternetkD Explorer as part of its Windows operating system. Did Microsoft blowE up Netscape's facilities? No. Did it infiltrate Netscape's operationstE and sabotage them? No. Did it stop anyone from using Navigator rather B than Internet Explorer. Well, no; Microsoft didn't do that either.  F All it did was make Internet Explorer a feature of Windows. That's it.? In America today, that might be an offense for which one can bej4 assessed treble damages. At least Netscape hopes so.  C What makes some people think Microsoft did something bad is that it A supplies the market's most popular operating system. That enablesuF Microsoft to bundle Internet Explorer with Windows and gain a supposed" unfair advantage over competitors.  D The devastating question for Netscape: so what? Why is it unfair? ToF whom? Certainly not to consumers. They apparently like the convenienceE of having the browser integrated with the operating system. It surelydB reduces the hassle. Had Internet Explorer not been a good browser,@ Microsoft's strategy would have counted for naught. Netscape had@ nearly the entire market to itself even after consumers receivedC Internet Explorer for free. Earlier versions of Microsoft's producteA were not impressive, and consumers were able to use Netscape withy@ Windows. (They still can.) Only when a later version of InternetB Explorer began to impress software reviewers did consumers give itC another look and turn to it in great numbers. (In Contrast, Windows-F has not helped Microsoft bring its own Internet service provider, MSN, to dominance.)  C Netscape lost the market on the merits, not because of any "unfair"a
 advantage.  F Think of what it would mean if Netscape gets its way: government wouldF be the ultimate judge of what can go into a computer operating system.F Where's it written that a browser is not part of the operating system?F There was a time when disk, video, and printer drivers weren't part of? the operating system either. Should we be forced to live by the 2 standards of the early days of personal computing?   --s9fJI615cBHmzTOP' Content-Type: application/pgp-signatured Content-Disposition: inlineo   -----BEGIN PGP SIGNATURE-----  Version: GnuPG v1.0.4 (OpenBSD)t* Comment: For info see http://www.gnupg.org  @ iD8DBQE8kR3+H5fmozfjvvIRAnS7AJ4rzeixq+ZtVABcDB81eyA+EJaBiACfes4y e/ZEbJzl1FrNuU4p0CQvD5U= =X0xx  -----END PGP SIGNATURE-----    --s9fJI615cBHmzTOP--   ------------------------------    Date: 14 Mar 2002 11:43:48 -0800( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Plan B for Compaq= Message-ID: <d7791aa1.0203141143.112751ef@posting.google.com>   a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3C905D94.C7763BFA@videotron.ca>...DM > Carly has been quite confidently saying that within days of the approval ofmM > the Compaq euthanasia, HP woudl reveal to its customers the product radmapsnV > for the next 3 years because those product roadmaps were ready and fully developped. > N > Has Curly ever indicated that Compaq has already developped a Plan B in case > HP fails to save his butt ?a > O > In particular, I am thinking expecially of Tru64 whose death announcement wasI3 > made in prediction of Compaq being melted ino HP.e > O > Do merger laws prevent the companies from discussing their options should theo > merger fail ?b  B that's because if the merger fails, Capellas will not be around to implement a plan B!p   ------------------------------    Date: 14 Mar 2002 19:22:42 -0000= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>( Subject: Re: Plan B for Compaq6 Message-ID: <20020314192242.14529.qmail@gacracker.org>  9 On 14 Mar 2002, bob@instantwhip.com (Bob Ceculski) wrote:s9 >JF Mezei <jfmezei.spamnot@videotron.ca> wrote in messager) >news:<3C905D94.C7763BFA@videotron.ca>...lN >> Carly has been quite confidently saying that within days of the approval ofN >> the Compaq euthanasia, HP woudl reveal to its customers the product radmapsK >> for the next 3 years because those product roadmaps were ready and fullyn >> developped. >>  O >> Has Curly ever indicated that Compaq has already developped a Plan B in case  >> HP fails to save his butt ? >>  P >> In particular, I am thinking expecially of Tru64 whose death announcement was4 >> made in prediction of Compaq being melted ino HP. >> IE >> Do merger laws prevent the companies from discussing their optionsE >> should the merger
 >> fail ?  > C >that's because if the merger fails, Capellas will not be around toy >implement a plan B!  * I think that's your best post to date Bob!  J Whatever way things go with this merger I suspect we'll still be left with Plan 9 for OpenVMS.      Doc. --  6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.netL   ------------------------------  % Date: Thu, 14 Mar 2002 13:51:40 -0600 + From: Christopher Smith <csmith@amdocs.com>h Subject: RE: Plan B for CompaqH Message-ID: <7E008308CD77154485FEF878168D078E260B16@CMIMAIL1.amdocs.com>   > -----Original Message-----F > From: Doc.Cypher [mailto:Use-Author-Supplied-Address-Header@[127.1]]  @ > Whatever way things go with this merger I suspect we'll still  > be left with > Plan 9 for OpenVMS.n  C I have used Plan-9, and it's actually pretty interesting.  It woulde* be cool to see it running over top of VMS.   Chrisa      ! Christopher Smith, Perl Developerb Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");d 'i  l   ------------------------------    Date: 14 Mar 2002 20:49:20 -0000= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>o Subject: RE: Plan B for Compaq6 Message-ID: <20020314204920.16340.qmail@gacracker.org>  A On Thu, 14 Mar 2002, Christopher Smith <csmith@amdocs.com> wrote:  >> -----Original Message-----oG >> From: Doc.Cypher [mailto:Use-Author-Supplied-Address-Header@[127.1]]r >hA >> Whatever way things go with this merger I suspect we'll still : >> be left withV >> Plan 9 for OpenVMS. >tD >I have used Plan-9, and it's actually pretty interesting.  It would+ >be cool to see it running over top of VMS.5  H I was referring to Plan 9 as in the B-movie "Plan 9 from outer space". I5 originally made that reference in the following post:P  j http://groups.google.com/groups?selm=20010326144032.7112.qmail%40nym.alias.net&oe=ISO-8859-1&output=gplain   ------------------------------  % Date: Thu, 14 Mar 2002 15:17:05 -0600S+ From: Christopher Smith <csmith@amdocs.com>R Subject: RE: Plan B for CompaqH Message-ID: <7E008308CD77154485FEF878168D078E260B1A@CMIMAIL1.amdocs.com>   > -----Original Message-----F > From: Doc.Cypher [mailto:Use-Author-Supplied-Address-Header@[127.1]]  C > On Thu, 14 Mar 2002, Christopher Smith <csmith@amdocs.com> wrote:a  F > >I have used Plan-9, and it's actually pretty interesting.  It would- > >be cool to see it running over top of VMS.   ; > I was referring to Plan 9 as in the B-movie "Plan 9 from y > outer space". I 7 > originally made that reference in the following post::   I know.  It was a joke.    Chris6    ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");" 'a  @   ------------------------------  % Date: Thu, 14 Mar 2002 17:33:39 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Plan B for Compaq, Message-ID: <3C91253F.ED513F10@videotron.ca>   Bob Ceculski wrote:rD > that's because if the merger fails, Capellas will not be around to > implement a plan B!n   Are you sure of that ? p  M has anyone noticed Compaq advertising its PCs on TV ? I find this interestingoN considering that those very PCs are going to be phased out under the HP plan. N Although the advert shows a wharehouse full of PCs, I think that the intent isL to show that you can now order direct from Compaq which will build to order.? (build to order and wharehouses full of PCs don't go together).n  D I wonder if the PC sales went down so much that Compaq really has toG advertise, or whether Compaq is trying to make parts of its consumer PClL business survive under HP by showing it now has "build to order" capability.   ------------------------------  # Date: Thu, 14 Mar 2002 20:36:23 GMTM1 From: "Terry C. Shannon" <terryshannon@attbi.com>t Subject: Re: Plan B for Compaq9 Message-ID: <bR7k8.23694$44.5531193@typhoon.ne.ipsvc.net>(  J "Doc.Cypher" <Use-Author-Supplied-Address-Header@[127.1]> wrote in message0 news:20020314192242.14529.qmail@gacracker.org...; > On 14 Mar 2002, bob@instantwhip.com (Bob Ceculski) wrote:h; > >JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message + > >news:<3C905D94.C7763BFA@videotron.ca>... D > >> Carly has been quite confidently saying that within days of the approval ofuH > >> the Compaq euthanasia, HP woudl reveal to its customers the product radmaps G > >> for the next 3 years because those product roadmaps were ready andt fullyp > >> developped. > >>L > >> Has Curly ever indicated that Compaq has already developped a Plan B in case  > >> HP fails to save his butt ?  K Haven't heard MC say much, but Global Services VP and Group General ManageroJ Peter Mercury was pretty specific about this in his last quarterly analystJ concall. If the urge to merge is hewn by Walter Hewlett, Compaq's ServicesF organization will revisit the acquisition strategy it articulated lastB summer. Mercury doesn't see a heck of a lot of overlap (outside ofI management and organizational structure) between CPQ and HWP services andi' thinks the acquisition is a Good Thing.e  L Of course, Mr. Mercury is not shelling out any of the estimated $100M that'sH being spent on advertising promoting or lambasting the acquisition, so IF doubt that his voice will be heard much outside the analyst community.   ------------------------------    Date: 15 Mar 2002 06:28:39 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: Plan B for Compaq0 Message-ID: <87wuweu6lk.fsf@k9.prep.synonet.com>  - Christopher Smith <csmith@amdocs.com> writes:p   > > -----Original Message-----H > > From: Doc.Cypher [mailto:Use-Author-Supplied-Address-Header@[127.1]]  0D > > Whatever way things go with this merger I suspect we'll still be! > > left with Plan 9 for OpenVMS.e  cE > I have used Plan-9, and it's actually pretty interesting.  It would>, > be cool to see it running over top of VMS.  > I suspect Doc expects it to be more from Outer Space than from
 Bell Labs.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.a@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 14 Mar 2002 13:02:36 -0800i# From: "Tom Linden" <tom@kednos.com>4 Subject: Question for Andrew9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEKEEFAA.tom@kednos.com>o  H Recently bought an Ultra 10 from a company that went belly up.  But they didn'tG know the password.  Is there a way to login single-user and edit passwdc file?    ------------------------------  % Date: Thu, 14 Mar 2002 17:06:23 -0500D* From: WILLIAM WEBB <WWEBB1@email.usps.gov>  Subject: RE: Question for Andrew- Message-ID: <0033000056436877000002L072*@MHS>e  = =0AMade me thought I'd stumbled into alt.2600 for a second...S :^)H   WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETT& Sent: Thursday, March 14, 2002 4:10 PMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET Subject: Question for Andrew    H Recently bought an Ultra 10 from a company that went belly up.  But the= y  didn'tH know the password.  Is there a way to login single-user and edit passwd=   file?=   ------------------------------  % Date: Thu, 14 Mar 2002 14:12:32 -0800i# From: "Tom Linden" <tom@kednos.com>s  Subject: RE: Question for Andrew9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEKIEFAA.tom@kednos.com>o  K This has a threefold purpose; (1) Is Andrew a real person?, (2) If so, does  he knowdD anything about solaris? (3) If yes to the first two, can he solve my problem.   > -----Original Message-----3 > From: WILLIAM WEBB [mailto:WWEBB1@email.usps.gov]t( > Sent: Thursday, March 14, 2002 2:06 PM > To: Info-VAX@Mvb.Saic.Comu" > Subject: RE: Question for Andrew >  >  >t< > Made me thought I'd stumbled into alt.2600 for a second... > :^)  >o > WWWebb >i > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNETn( > Sent: Thursday, March 14, 2002 4:10 PMD > To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: Question for Andrew >  >nJ > Recently bought an Ultra 10 from a company that went belly up.  But they > didn'tI > know the password.  Is there a way to login single-user and edit passwdi > file?I   ------------------------------  # Date: Thu, 14 Mar 2002 23:40:48 GMTg1 From: Ed Wensell III <ewensell3@yahoo.commercial>-  Subject: Re: Question for Andrew0 Message-ID: <3C9134BA.5FB56ACF@yahoo.commercial>   Tom Linden wrote:d > J > Recently bought an Ultra 10 from a company that went belly up.  But they > didn'tI > know the password.  Is there a way to login single-user and edit passwde > file?,  5 Probably should ask this in comp.unix.solaris, but...   G The general procedure is to boot into single user mode from the Solaris F install CD's (boot cdrom -s), mount the root filesystem (assuming it'sE UFS), and edit the /etc/shadow file to remove the root password. Then> reboot the system normally.a  B Otherwise, you're probably better off doing a clean install of the> system. At this point you have a system in an 'unknown' state.   -- . Ed Wensell IIIE NetBSD/Alpha at home - Solaris/SPARC at work - OpenVMS in a past life A E-mail address is valid if you know the appropriate bits to drop.i   wibble?o   ------------------------------    Date: 14 Mar 2002 13:02:17 -0600+ From: young_r@encompasserve.org (Rob Young) Y Subject: Re: R.I.P. OpenVMS - ISS Recommends That H-P Holders Vote in Favor of Compaq Acqf3 Message-ID: <I6PfWSBqCubG@eisner.encompasserve.org>   k In article <3C8CE9B0.3000503@sun.com>, Andrew Harrison <andrew_nospam.harrison_remove_this@sun.com> writes:- >  >  > Bill Todd wrote: > ; >> "Rob Young" <young_r@encompasserve.org> wrote in message60 >> news:7BzFBC32iDpd@eisner.encompasserve.org...& >>>Just like good old Andrew Harrison. >>>m >> nA >> That's it:  if you can't debate competently, try slinging mud." >> s >  > 6 > Take it as a compliment Bill, Robs attempts to argue9 > with me in a reasoned way went the same way as they aren > going with you, badly :):) >   @ 	No... that wasn't my point at all... the point I was attempting= 	to make then (and now again)... was your very good method ofi? 	peeling out a few lines from a large reply and/or ignoring theIG 	main thrust and responding to whatever you care to and within a singler? 	response we are suddenly debating something totally unrelated.a  @ 	Your creative trimming skill was displayed at its finest while 5 	debating Zinc Whiskers and static-free Bunnies, ala:    ====  b http://groups.google.com/groups?selm=Wy9%2B2cwjCh38%40eisner.decus.org&oe=ISO-8859-1&output=gplain    7 	IQ4Hire tells us the Sun FEs are still clueless as do	sA 	the articles.  Just environmentals?  Here , trim this out again:   N http://www.computerworld.com/cwi/story/0,1199,NAV47-68-86-101_STO49356,00.html  O "It's embarrassing enough for Sun to have to admit that after a year or more ofIJ trying, it still can't fix a problem plaguing its top-selling product lineI [Page One, Aug. 28]. Even worse, the company's statements downplaying theoL impact of the problem were contradicted by analysts and angry users, who sayM the issue has affected a lot more sites for a lot longer than Sun claims. ButtF getting caught gagging customers in return for speedy service and full3 disclosure is the real public relations nightmare."i     ====  @ 	And many other creative trimming examples in that large thread.  @ 	You seem to think things go well for you... but I have had manyB 	come up to me at various conferences and give me a wink and a nodE 	and having a few chuckles rehashing the back and forths since 1995, dE 	concensus seems to be in the other direction... but perhaps I'm [we]  	are a bit biased.   				Robe   ------------------------------  % Date: Thu, 14 Mar 2002 15:24:31 -0800t From: James.F.Duff@health.nete Subject: Resource block chainsD Message-ID: <OFA81613C2.68A95DE6-ON88256B7C.007B0B19@foundation.com>   Internals gurus ,i  G I am looking at some old internals code on an alpha running 7.3, and ama havingI some trouble with an executive cell called LCK$GQ_RRSFL.  This puportedlymG points to the beginning of a chain that links resource blocks together.e  K Attempting to get the rsb that this is pointing at, the code does something 	 along then	 lines of:a   #include <rsbdef.h>    extern void *LCK$GQ_RRSFL;   static long int offset;  static struct _rsb *rsb;  :     offset = (long int)&rsb->rsb$q_rrsfl - (long int)&rsb;      rsb = LCK$GQ_RRSFL - offset;    G Referencing a member of the rsb structure produces an access violation.o  C I know there must be something obvious I am missing here.  Pointersg+ (pardon the pun) would be most appreciated.    Jime -- james.f.duff@health.net     I This message, together with any attachments, is intended only for the useiE of the individual or entity to which it is addressed.  It may containyK information that is confidential and prohibited from disclosure. If you are J not the intended recipient, you are hereby notified that any disseminationH or copying of this message or any attachment is strictly prohibited.  IfJ you have received this message in error, please notify the original senderJ immediately by telephone or by return e-mail and delete this message along5 with any attachments, from your computer.  Thank you.    ------------------------------  # Date: Thu, 14 Mar 2002 21:58:14 GMTh4 From: "Matt Muggeridge" <Matt.Muggeridge@compaq.com>6 Subject: Re: sending all data as out-of-band in TCP/IP= Message-ID: <W19k8.15888$mp.72275@news-server.bigpond.net.au>o  F > he has experienced message lost when sending data from OpenVMS to NT > clients without using OOB.  K Given TCP provides a reliable datagram service, there must be something odd-J going on with the application.  Tracing the connection should satisfy your9 curiosity... e.g. was the data not sent, or not received.n  % >Somehow, he seems to have solved the/% > problem by sending all data in OOB.D  H So the data consists of only 1-byte messages?  This is not a solution toL lost messages.  I suggest there may be some side-effect they are seeing, but it's not a solution.   Matt.p   --= -------------------------------------------------------------  OpenVMS TCP/IP Engineering Enterprise Computing Group Compaq Computer Corporationo Gold Coast, AUSTRALIAa= -------------------------------------------------------------l    9 "Tony Cheung" <tony.cheung@asiayeah.com> wrote in message 7 news:f9dc0a5a.0203132234.7719c3fa@posting.google.com...e
 > Hi John, >p? > It is due to the client's request. We are helping a client todG > re-architect an OpenVMS application. In the client's past experience,hF > he has experienced message lost when sending data from OpenVMS to NTA > clients without using OOB. Somehow, he seems to have solved thee% > problem by sending all data in OOB.t >eA > I also agree we should avoid OOB and only use it for compelling H > reasons. At the same time, I am interested in understanding more aboutE > OOB and if it really could have any impact if one sends all data in2 > OOB. >2? > Anyway, meanwhile, we have persuaded the client to avoid OOB.. >( > Thank you very much. >o
 > Tony CheungD >26 > john@ossc.net (John Gemignani, Jr.) wrote in message9 news:<35b06b78.0203121828.23582cc5@posting.google.com>...j/ > > Why would you want to send ALL data as OOB?n > >3	 > > -John6 > >vC > > "Matt Muggeridge" <Matt.Muggeridge@compaq.com> wrote in messageh8 news:<wvij8.9420$mp.41309@news-server.bigpond.net.au>...K > > > > Rather than sending all data normally, if one transmits all data asaJ > > > > out-of-band, will there be any performance or behavior difference? > > >y: > > > Yes.  It won't work... at least as you might expect. > > > 	 > > > > Il? > > > > won't be sending any normal data, but out-of-band data.i > > > < > > > Defining normal and OOB data is a good place to start. > > >eG > > > OOB data is a single character that can be queued at the receivers ahead ofL > > > other 'normal' data.  By setting the OOBINLINE flag, it will be queued with > > > the 'normal' data. > > >tJ > > > The OOB data byte can and is overwritten by subsequent OOB data.  So your1 > > > receiver has to keep up with it or lose it.l > > >fJ > > > OOB seemed like a good idea back when it was being standardised, but in6 > > > practice it suffers from a lot of tricky detail. > > > K > > > My advice is... try to avoid it.  If you absolutely cannot, then take  the1L > > > time to learn all of its limitations.  I've seen normally well behavedL > > > programs fall apart when their receiver could not keep up with the OOB data. > > > when their system became heavily loaded. > > >m > > > Matt.[ > > >U > > > --C > > > -------------------------------------------------------------s  > > > OpenVMS TCP/IP Engineering  > > > Enterprise Computing Group! > > > Compaq Computer Corporationa > > > Gold Coast, AUSTRALIAIC > > > -------------------------------------------------------------  > > >p > > >t? > > > "Tony Cheung" <tony.cheung@asiayeah.com> wrote in message = > > > news:f9dc0a5a.0203112030.7364a382@posting.google.com...d > > > > Hi All,- > > > >-C > > > > I have looked into the TCP/IP's out-of-band implementation.< > > > >rK > > > > Rather than sending all data normally, if one transmits all data asDL > > > > out-of-band, will there be any performance or behavior difference? I? > > > > won't be sending any normal data, but out-of-band data.- > > > >oK > > > > Are out-of-band data subject to the same flow control mechanisms ina > > > > TCP/IP?g > > > >i > > > > Thank you very much. > > > >  > > > > Tony Cheung    ------------------------------   Date: 14 Mar 2002 20:35:44 GMT1 From: JONESD@er6.eng.ohio-state.edu (David Jones) M Subject: Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)s: Message-ID: <a6r1j0$33p$1@charm.magnus.acs.ohio-state.edu>  = In message <35b06b78.0203140940.72bcb6e9@posting.google.com>,q-   john@ossc.net (John Gemignani, Jr.) writes:nA >...  I spent some time recently looking at the maximum number of0B >BG devices and found that VMS actually allows device units in theE >range 0-32767.  The cloned units are designed for 0-9999.  Customers@3 >have asked for a way to go above the 0-9999 limit.   O If VMS systems with thousands of short-lived devices is expected to be a common E situation, they really need to redo the device database.  To assign a F channel or create a cloned deviced, the kernel must do a linear searchG of the UCB chain for the target device controller.  Maybe a flag in the E DDT would indicate whether the UCB's were to be managed traditionallyrK as a linked list or an via alternate index optimized for search and update.h    < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet:hL 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  1 Disclaimer: I'm looking for marbles all day long.p   ------------------------------  % Date: Thu, 14 Mar 2002 14:33:37 -0800 $ From: Shane Smith <ssmith@icius.com>M Subject: Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)p0 Message-ID: <01C1CB65.60765DF0@sulfer.icius.com>   >Hi! >iJ >Just to contribute a word: same Problem under tru64. Guess that doesn't = help1 >to locate the problem, as the stack is the same.r >u >Ren=E9f  D Actually, Rene, I think that does help. It adds weight to the theory< it's something in the network stack rather than Mark's code.  D It was rather ugly tracking mine down. I ended up with flushed debugE statements all over the code, slowly binary-chopping down towards theqC statement that was hanging. Hardly brain surgery, just slow tediousH slogging, but it worked.   Shaner   ------------------------------  % Date: Fri, 15 Mar 2002 10:48:14 +10302/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>aM Subject: Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)5. Message-ID: <3C913DC6.3040102@wasd.vsm.com.au>   Shane Smith wrote: >>Hi!d >>N >>Just to contribute a word: same Problem under tru64. Guess that doesn't help2 >>to locate the problem, as the stack is the same. >> >>Ren >  > F > Actually, Rene, I think that does help. It adds weight to the theory> > it's something in the network stack rather than Mark's code. > F > It was rather ugly tracking mine down. I ended up with flushed debugG > statements all over the code, slowly binary-chopping down towards therE > statement that was hanging. Hardly brain surgery, just slow tediouse > slogging, but it worked.   Thanks Ren, Shane, Rick.l  F If this *is* the case then there's hardly any point in me pursuing my E code any further without involvement from Compaq Engineering.  All I eG need now is confirmation from Someone (capitalized) willing to confirm aA they know about the problem.  If the Apache development team are aI struggling with it too then there's probably better places I could spend aF my time.  I had this persistent feeling it shouldn't have been *this* F obscure (though having made less-than-perfect code implementations in G the past - now that's optimistic - I tend to try and nut it out myself u1 before exposing myself to a global "hey stupid").h   ------------------------------    Date: 14 Mar 2002 19:54:04 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)cM Subject: Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)M3 Message-ID: <trYGIvTcv4Ek@eisner.encompasserve.org>e  ` In article <3C915CC8.1020906@wasd.vsm.com.au>, Mark Daniel <Mark.Daniel@wasd.vsm.com.au> writes:  H > My understanding is AST will always preempt non-AST execution (whilst J > enabled anyway).  With a large number of concurrent requests all firing G > ASTs constantly I could imagine this would make the non-AST mainline  K > $QIOW accept() rather slow to respond even with a $SETAST(0) immediately t3 > following the $QIOW.  Am I being too pessimistic?e  C Not at all too pessimistic.  Programs that perform significant workmC at AST level should reserve mainline processing for things that are > prohibited at AST level, such as certain system service calls.   ------------------------------  % Date: Fri, 15 Mar 2002 13:00:32 +1030W/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>sM Subject: Re: TCPIP, sharing sockets via $QIO (programming, long and detailed) . Message-ID: <3C915CC8.1020906@wasd.vsm.com.au>   John Gemignani, Jr. wrote:
 8< snip 8<G > If the issue appears to be some form of problem around the acceptanceDD > of the connection, why not create a mainline in non-AST state thatD > does the accept, then fires off a new thread?  I've written serverE > code that way as well.  Be sure to protect the thread creation witheG > $SETAST(DISABLE/ENABLE).  This would replace the traditional mainline0 > consisting of: >  >     while (!shutdown_flag) >         $hiber();o >   F My understanding is AST will always preempt non-AST execution (whilst H enabled anyway).  With a large number of concurrent requests all firing E ASTs constantly I could imagine this would make the non-AST mainline tI $QIOW accept() rather slow to respond even with a $SETAST(0) immediately A> following the $QIOW.  Am I being too pessimistic?  (I haven't F experimented.)  This might introduce significant latency into request  acceptance processing.  E > Oh, something else to think about that is fairly important.  If you F > are passing around the name of the BG device using a value block, beH > sure that you allow enough space for the name.  Don't just pass a unitF > number.  I spent some time recently looking at the maximum number ofC > BG devices and found that VMS actually allows device units in theeF > range 0-32767.  The cloned units are designed for 0-9999.  CustomersF > have asked for a way to go above the 0-9999 limit.  This may involveC > some trickery in the device name and, if you are copying the unitMG > number, this may pose a problem.  I believe that I put a release note A > in the V5.3 documentation recommending that any code using unit E > numbers be modified now before an enhancement appears in the futureX > which could break the logic.  E Thanks.  I use use the full 16 bytes (15+null as a "string") for the gH device.  Though, as already mentioned by Dave Jones in this thread, the F 9999 limit on unit numbers becomes significant for drivers associated C with high volume low duration activities as found in TCP/IP server iG environments.  Whilst 32766 is three times better it may not be enough  G if VMS turns out to have greater longevity than some of the doomsayers o of c.o.v. would prognosticate.  H > If you want to talk more about this or the server issues, feel free toD > email me directly.  If you think there's really a bug here, if youC > submit a problem report to Compaq with code that demonstrates they$ > problem I'm sure we'll look at it.  H Thankyou.  I'll probably let it simmer for a few more days before going F to the effort of distilling the code down into something suitable for F standalone testing.  I'm currently negotiating with non Compaq TCP/IP 4 Services site(s) for a chance to compare behaviours.   ------------------------------    Date: 14 Mar 2002 21:40:02 -0800) From: P.Young@unsw.EDU.AU (Patrick Young)eM Subject: Re: TCPIP, sharing sockets via $QIO (programming, long and detailed)n= Message-ID: <55f85d77.0203142140.4a3712e9@posting.google.com>S  e "Rick Barry" <barry@star.zko.dec.com> wrote in message news:<6S1k8.956$fL6.22159@news.cpqcorp.net>...- > H > Patrick, just curious - are you running TCP/IP Services or an alterate > TCP/IP stack?R >    TCPIP/IP Services...  ?   Compaq TCP/IP Services for OpenVMS Alpha Version V5.1 - ECO 3a=   on a COMPAQ Professional Workstation P running OpenVMS V7.3   D The problem was also present with TCPIP V5.0-11 (TCPIP_ECO V5.0-112)A under OpenVMS 7.2-1. The upgrade of TCPIP Services and VMS - both 4 done at the same time - did not make any difference.  C This is certainly load related. On the machine I run 6 instances ofe@ Apache - 29 different web sites. The one with our main web site,C which gets the most traffic, is the one to suffer from this problema? (around 260,000 requests a day). The box as a whole does around A 535,000 because now is a busy time for us. I've needed to restart ; about 3 times this week. Two of which were on the same day.e   ------------------------------  # Date: Fri, 15 Mar 2002 05:55:36 GMTp$ From: "Tim Peer" <peert@envysys.com>7 Subject: There is nothing like performing a REALM walk?wC Message-ID: <s1gk8.11569$r86.2978538612@newssvr14.news.prodigy.com>e   Alan,m  L It is understandable why your query is so fast. On PRTREC, the PRTNO segmentK is hashed using the CALC SET-PRTHSHSET. Perhaps the SQL driver is using the=J optimized CODASYL SET (PRTHSHSET) when performing the query. In this case, performance would be excellent.I   > $ NAVSQL MANDB5 > SELECT PRTDESC FROM PRTREC WHERE PRTNO = 'DP-XXX' ;t  L Do you realize the same performance when you issue the query syntax:AssumingI the description field contains the string," Little Red Cables Attach thisg6 Part to an Assembly" or a comparable part description?   > $ NAVSQL MANDB@ > SELECT PRTDESC FROM PRTREC WHERE PRTDESC  LIKE ' Red Cables' ;   -- Timothy E. Peer, eNVy Systems Inc.e 4960 Almaden Exp. #330 San Jose, CA 95118 Voice: (408) 363-8896a Fax:    (408) 363-8897   http://envysys.com  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:76v29ugcomv442ctf6vpksta6eh10cvsvb@4ax.com...B > On Thu, 14 Mar 2002 18:24:43 GMT, "Tim Peer" <peert@envysys.com> > wrote: >r > >Alan, > > L > >I should balance my explanation by stating that Interpreted Direct AccessI > >technologies work for many sites. In fact, I know of a few sites where  RdbuK > >and SQL databases are used with Direct Access technologies as a completeiH > >solution.  Direct Access technologies have the advantage of real-time accessJ > >to Codasyl data. Real-time data access is not available in the SQL onlyI > >environment. Best case for real-time data is usually every 1-2 minutesu from" > >the time of the Codasyl update. >sH > Not sure what you mean here? If I execute a transaction in MANMAN thenB > that will be immediately seen by an Attunity/Navigator SQL query2 > directly from the VMS $ prompt.  Soemthing like: >n > $ NAVSQL MANDB5 > SELECT PRTDESC FROM PRTREC WHERE PRTNO = 'DP-XXX' ;i >n- > If I've got the field names right off hand.rK > >Given the power of SQL database technologies, Direct Access queries needhK > >only execute against data where a Codasyl Set exists,  all other queriesR> > >usually execute against the Rdb or companion  SQL database. >f   ------------------------------  # Date: Fri, 15 Mar 2002 01:36:08 GMTS1 From: "David J. Dachtera" <djesys.nospam@fsi.net>t Subject: Re: VFC File Problema' Message-ID: <3C915210.688A23F0@fsi.net>o  ! norm.raphael@jamesbury.com wrote:  > 9 > > A couple of discoveries which arose from this thread.. > >f6 > > 1. DSNlink articles appear to be alive and well at > >,& > > http://askq.compaq.com/askopenvms/ > >d$ > > No username / password required. > > I > > For example, typing the following into the dialogue box brings up ther > > article Norman quoted: > >r? > > Converting VFC-formatted Files To Sequential Variable Filesi > >  > - > Thank you for finding and sharing the link.e > F > (It's odd that searching www.openvms.compaq.com does not find this.)  E ...but based on on-going experience with the Q's website, it's not ata all unexpected.y   -- m David J. Dachterap dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/M   ------------------------------  # Date: Fri, 15 Mar 2002 01:30:15 GMTi1 From: "David J. Dachtera" <djesys.nospam@fsi.net>rA Subject: Re: Viability of a Commercial ISO-9960 formatter for VMSi' Message-ID: <3C9150AE.46E3F3A6@fsi.net>h   Tim Llewellyn wrote: > [snip]R > You mean you can run IP services now without an appropriate NAS/EIP/UCX licence?! > Things are changing if correct.o  E I'd heard via this ng that such was to be the case. Whether or not itdH actually ever happened, I really cannot say with any certainty. I'm just$ going by what I recall reading here.   -- b David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/.   ------------------------------  # Date: Fri, 15 Mar 2002 01:32:36 GMT-1 From: "David J. Dachtera" <djesys.nospam@fsi.net>uA Subject: Re: Viability of a Commercial ISO-9960 formatter for VMS-' Message-ID: <3C91513C.9C231CD6@fsi.net>-   John Santos wrote: > / > On Thu, 14 Mar 2002, David J. Dachtera wrote:e >  > > John Santos wrote: > > >1 > > > Much snippage... > > > 3 > > > On Wed, 13 Mar 2002, David J. Dachtera wrote:  > > > > Carl Perkins wrote:e	 > > > > >a > > > [...]lN > > > > > Normally you also get a package of other licenses too, NAS or EIS or > > > > > whatever.O > > > > ? > > > > Yes - if you buy them, you get them. If not, you don't.  > > > >r7 > > > > > }Want networking? Sorry, that's extra (or was  > > > > > }up until recently).	 > > > > >lN > > > > > This is only the case if by "recently" you mean "for the last decade/ > > > > > or more". And that's only talking IP,n > > > >lN > > > > I don't recall UCX being included in the OVMS base license much before& > > > > about 1998 or so, maybe later. > > > >C% > > > > > DECnet has been there a lotn > > > > > longer.m > > > >eO > > > > I don't recall either DECnet end-node or Routing-IV ever being includedtL > > > > in the base OVMS license. You always had to buy them separately, andM > > > > choose one or the other. Of course, DECnet-IV for OVMS-Alpha does not.K > > > > provide the routing functionality. DVNETEND is the best you can do.n > > > >  > > >aK > > > When we got our first Alpha, a 3000-300 in late 1993, it came bundled  > > > with NAS-250,t > >t > > NAS-250 is not OVMS-BASE.e > > > I didn't say it was.  I said it was *BUNDLED* with VMS.  Who< > cares if it is a separate PAK if there is no extra charge?  F I wasn't aware that such was the case. When did NAS start to come free with OVMS-BASE?q   -- t David J. Dachteraa dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Fri, 15 Mar 2002 04:29:09 GMT.4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>A Subject: Re: Viability of a Commercial ISO-9960 formatter for VMSs0 Message-ID: <3C91775B.B7FAE072@blueyonder.co.uk>   "David J. Dachtera" wrote: >  > John Santos wrote: > > > > M > > > > When we got our first Alpha, a 3000-300 in late 1993, it came bundledr > > > > with NAS-250,s > > >  > > > NAS-250 is not OVMS-BASE.  > >a@ > > I didn't say it was.  I said it was *BUNDLED* with VMS.  Who> > > cares if it is a separate PAK if there is no extra charge? > H > I wasn't aware that such was the case. When did NAS start to come free > with OVMS-BASE?s  = As John points out, even the first Alphas came with NAS. Thiso% also concurs with my recollections.     ? OK, I will admit it was optional but recommeded on one reseller-> acquired project, and as I mentioned before cheaper than a UCX licence.   Regardsy  .   -- o tim.llewellyn@blueyonder.co.uk 5  F * tim.llewellyn@cableinet.co.uk address will cease to work June 2002 *   ------------------------------  # Date: Fri, 15 Mar 2002 01:27:39 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>,@ Subject: Re: Viability of the VMS Market for third party vendors' Message-ID: <3C915010.8A6FD956@fsi.net>I   Larry Kilgallen wrote: > ( > With well over 40 replies to the topic > > >         Viability of a Commercial ISO-9960 formatter for VMS > A > to date, precisely 1 individual has expressed any interest in a. > commercial product.y >  > ================== > A > But there has been significant discussion of why such a featuregB > ought to be built into VMS, including by someone I _know_ has inD > the past bemoaned the lack of third party vendors of VMS software. > E > So why should any vendor think there is revenue in the VMS market ?9  C You might ask Two Guys and a Vax, the people who founded Raxco, and 	 others...n  ! <timetravel destination=the_past>aH Why would anyone want TCP/IP for VAX/VMS? Doesn't Digital have their ownH network stack? Isn't there already a freeware IP stack making the rounds	 from CMU?h  H Why would anyone want an on-line defragmenting tool for VAX/VMS? Doesn'tF BACKUP/IMAGE save and restore do that just fine? Isn't that the *ONLY* method supported by Digital?  $ <timetravel destination=the_present>: Why would anyone buy ISO-9660 support for OpenVMS? Doesn't. MOUNT/MEDIA_FORMAT=CDROM already support that?  H Just because we would prefer it to come from OpenVMS Engr., doesn't meanH a third-party product would be universally dismissed out of hand (though7 perhaps there are many here who might do exactly that).   > Have we forgotten what the word "entrepreneur" *REALLY* means?  E Perhaps we have - in which case, to paraphrase Luke Skywalker, "Then,s OpenVMS is truly dead!"u   -- H David J. Dachtera  dba DJE Systems+ http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  % Date: Thu, 14 Mar 2002 20:40:55 -0500 2 From: rdeininger@mindspring.com (Robert Deininger)@ Subject: Re: Viability of the VMS Market for third party vendorsK Message-ID: <rdeininger-1403022040560001@1cust203.tnt2.nashua.nh.da.uu.net>   ; In article <3C915010.8A6FD956@fsi.net>, "David J. Dachtera"k <djesys.nospam@fsi.net> wrote:    I >Why would anyone want an on-line defragmenting tool for VAX/VMS? Doesn'ttG >BACKUP/IMAGE save and restore do that just fine? Isn't that the *ONLY*t >method supported by Digital?i  3 I don't think Digital supports anything these days.b  G Compaq supports an on-line defragmenting tool for VMS, namely Disk FilesG Optimizer.   Though stealth marketing skills seem to have been honed to-, razor sharpness for this particular product.  G And last I checked, it was significantly less expensive than one of itsc" competitors, Diskeeper.  Shocking!   ------------------------------  % Date: Fri, 15 Mar 2002 06:16:24 +0000m& From: Alan  Greig <a.greig@virgin.net>> Subject: Walter Hewlett says HP board is really against merger8 Message-ID: <68439u0vkg44gkhfjkqo9fit67hfmu521k@4ax.com>  F In a webcast available at http://www.pressnews.net/hp/index_live.htm ,F Walter Hewlett suggests the rest of the board back him and are againstF Carly but cannot say so publicly because of legal concerns. Well worth	 a listen.h   ------------------------------  + Date: Thu, 14 Mar 2002 20:43:31 +0100 (CET)d: From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>Y Subject: Re: Why no DEFINE /GROUP=nnnn? (was re: define "group-logicals" at system startu*J Message-ID: <Pine.LNX.4.21.0203142037370.12921-100000@irys.stanpol.com.pl>  & On Sun, 10 Mar 2002, Paul Sture wrote:  " >+Gotfryd Smolik, VMS lists wrote: [...]o= >+> Hm... Personally will not name a use of documented systemr >+> routines a "hacking"... !n [...]a/ >+But a lot of systems don't have compilers ...y   ..except MACRO...d8  Must agree ! But have say not about "may be hard", only< about use ("little overusage") of the term "hacking" here :)   >+Paul Sture
 >+Switzerland     Regards - Gotfryd   -- iE ===================================================================== F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEr. $!                        GS@stanpol.zabrze.plE =====================================================================l   ------------------------------  % Date: Fri, 15 Mar 2002 04:45:36 +0000C& From: Alan  Greig <a.greig@virgin.net>H Subject: Re: Why not ODBC Direct Access? Codasyl DBMS Data on Oracle Rdb8 Message-ID: <c7u29ukr053h3riej12kpbd42osfba37u6@4ax.com>  @ On Thu, 14 Mar 2002 17:12:05 GMT, "Tim Peer" <peert@envysys.com> wrote:  J >as defined in the Codasyl DBMS storage schema.  Defining new access pathsL >require a storage schema change and reorganization of the database. ImagineM >performing a pattern-match query on a CHARACTER type data element, perhaps ahA >description field, in a storage area with say 1,000,000 records.p  E Imagine it - we do it!. We have a Navigator SQL query interface whichsE searches through 6 million MANMAN MATREC records for descriptions. If E we ran the whole thing from memory I reckon it could do it in under auE minute on an ES40. But I guess  if you really need very fast searches C through large amounts of data and don't want to start modifying themA underlying DBMS database then I can see why you might use the RDBoC approach.  But don't forget that you can arrange things so that roweB caching and or DBMS local/global buffering and/or VIOC/XFC cachingC means that after the first search the MATREC records are all cachedsC and you don't have to walk through the entire storage realm but are C you sure your DBMS database is not heavily into extents and this is ? why you are seeing a linear walk through the storage area? DBMStD performance can really tank if this is the case, You can easily slowE things down by a factor of ten to one if the database is heavily intocF auto extents and this *will* be the case with MANMAN unless you preset4 things correctly or load/unload the database to fix.  G >Unfortunately, you would probably not find a Codasyl Set for this data'J >element. Using traditional data access, the query will probably perform aD >storage area realm walk and the IT department will probably have an- >opportunity to meet their transaction users.d >eH >The net-change approach used by the Rdb Warehouse works well as the RdbM >database stays synchronized with Codasyl without the overhead defined above.c >lE >Beyond ad-hoc SQL queries, the real benefit is seen in a developmentuK >environment. Developing web and SQL-based applications is rather simple togH >do and besides there is a rich selection of tools available with nativeD >interfaces (such as Oracle Developer 2000) to relational databases.  A You can use Developer 2000 to talk to a DBMS database via variousv methods.   >r >>But AttunityA >> works fine and lets us do whatever we need with ODBC accessing F >> underlying MANMAN databases. However I'm not sure if that  would be2 >> the case if we allowed updates via this method, >f3 >Why one would use Rdb in place of Interpreted SQL:e >TK >The I/O, CPU and memory overhead incurred in executing queries is isolated  >to an off-line system.iK >Ability to use relational database functions and objects without having tooC >modify the Codasyl schema or Codasyl application, examples: storedtL >procedures, functions, triggers, views, hashed and sorted indexes, synonyms >to name a few.eI >Ability to open the data to user/analysts for use with OLAP (data cubes)i >tools.s >e4 >Why wouldn't someone implement Codasyl data in Rdb?   ------------------------------  # Date: Thu, 14 Mar 2002 18:27:07 GMTa* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Win one - Lose one - more pfunds seigh in on the dealC Message-ID: <%X5k8.379518$Aw2.31303224@bin7.nnrp.aus1.giganews.com>   @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:W05k8.967$fL6.22208@news.cpqcorp.net...! > Engaging in abstract math Dave?a  K I suspect he was just trying to make the explanation more concrete for that-H portion of the readership which thinks better with examples.  Otherwise,D it's really difficult to see how what you say below differs from his
 presentation.1  K The major point is that while Putnam, given that it holds considerably more I Compaq stock than HP stock, may have a good reason to support the merger,jK that reason has absolutely no relevance to HP shareholders who do *not* ownRL Compaq stock:  if indeed Putnam believes it will win only because its CompaqL holdings will rise more than its HP holdings will fall, then HP shareholdersL without Compaq holdings would be well-advised to scotch the deal rather thanF look at Putnam's support as an endorsement of its intrinsic viability.  J For that matter, even Compaq-only shareholders have only a very short-termK incentive to see the deal go through:  if it does, their best bet is likelyTG to unload immediately, whereas if it doesn't and Compaq leadership as aoJ result is radically changed (for the better - it would be rather difficultG to do otherwise) their stock has at least a fair chance of recovering at/ significant portion of what it's lost recently.    - bill   >eI > There is no way of estimating some "real" value of the stocks, it's all L > imaginary.  Putnam is betting that on the whole, that there will be a riseK > in the value of their Compaq stock value that is larger than any decreases inL > the value of their HP holdings.  That is, there is currently a gap betweenK > the share prices and the merger stock swap amount.  Either HP has to comeQH > down, or Compaq has to go up, or both move to converge - the odds that theyH > will both *fall* to convergence isn't very likely since the market hasJ > already depressed the stocks waiting for the merger results.  Since theyJ > hold a larger stake in Compaq, I imagine a little simple math can figure out L > how much Compaq has to move up to offset any HP movement.  The combinationE > does *not* have to result in a combined share value higher than theOH > independent values for each - for someone with a large Compaq stake to makeF > out.  You have more risk if you do not have a large stake in Compaq. >a >a > Welcome to the big casino. >v >s >mB > David Mathog wrote in message <3C90CCD8.BAB5DBA9@caltech.edu>... > >John Smith wrote: > >@I > >> On Wednesday, Putnam Investments, one of the largest shareholders ino the  > two K > >> companies, threw its support behind the deal. Boston-based Putnam, ther > No. 4cK > >> U.S. fund group, held about 46.2 million HP shares in its mutual funds  > and K > >> institutional accounts, and 68.9 million Compaq shares, as of Dec. 31.l > > G > >As has been pointed out before, the merger is a much better deal for 
 > Compaq'sJ > >stock holders than for HP's.  (It stinks for both sets of customers but > >customersH > >don't get a vote unless they're also stockholders.)  Anyway, the math goes > >somethingI > >like this (using arbitrary normalized units to demonstrate the conceptA > along K > >with the simplification that the total stock after the merger is the sumf of > the  > >two( > >company's shares before the merger.): > >E; > >HP premerger share value      1.00   (real value $38.02)v; > >Compaq premerger share value  0.50   (real value $10.85) J > >Postmerger share value        0.75   (real value $??.?? That's what all thea > >debate is about!) > >tG > >Q and HP management want us to believe the last value is >1.00 but IS don'tb
 > >believe it-J > >and neither do most independent analysts.  If they did the merger would be > >sailing through.. > >mL > >Should Putnam vote yes or no?  It depends upon the ratio of HP and Compaq > stock # > >owned.  Crunch Putnam's numbers:  > > " > >Before:  46.2 + .5*68.9 = 80.65" > >After:   (46.2+68.9)*.75= 86.33 > >aK > >So if the merger goes through Putnam would boost the cumulative value ofp > the J > >stock they own by 7%.  However, if instead they held the 68.9 of HP and	 > 46.2 of 	 > >Compaqa > >the numbers work out to:  > >l  > >Before:  46.2*.5 + 68.9  = 92# > >After:   (same as before)= 86.33l > >a* > >and they'd do better by voting against. > > F > >Of course, they'd probably do much better than that by selling both+ > >the HP and Compaq shares and buying IBM!g > >e > >Regards,h > >Q > >David	 > >Mathoga > >mathog@caltech.edu  >m >a   ------------------------------  % Date: Thu, 14 Mar 2002 19:06:55 -0500f1 From: "Island (hpaq.net)" <dbturner@islandco.com>m# Subject: XP1000 (EV6) Going Cheap !-/ Message-ID: <u92eo0tnmqli55@news.supernews.com>m  5 We have only a few of these left in stock this month.R   XP1000 6/500
 1GB Memory 18GB 10KRPM Disk 10/100 Ethernetg	 32x CDROM5 3DLabs Oxygen 32MB PCI Video Keyboard Mouse    Price each is $2299u  & Also have 1 x 667Mhz version for $5350     -- Island Computers US Corp.s 2700 Gregory Streete Savannah GA 31404i Toll Free: 1-877 636 4332b International: 001 912 447 6622c  Facsimile:      001 912 201 0096 dbturner@hpaq.netr www.hpaq.net   ------------------------------  # Date: Thu, 14 Mar 2002 20:59:51 GMT % From: jlsue <jlsuexxxz@insightbb.com> I Subject: Re: [OT] US/Europe living costs, was: Re: VMS sys admin salaries 8 Message-ID: <rl329u8u82dpim7m7j29tb67158qu5ketr@4ax.com>  F On Wed, 13 Mar 2002 03:50:45 GMT, "John Smith" <a@nonymous.com> wrote:  	 >flame oniK >In the US it seems that the country as a whole would rather spend hundreds6K >of thousands, if not millions of dollars, on one heroic effort to save theaL >life of some damn fool wasn't wearing a setbelt who was ejected through theH >windshield of his gas-guzzling, pollution-generating unstable SUV as itK >rolls over, in a collision that killed a family of four in a Honda Accord, L >simply because the SUV driver has private insurance and not publicly-funded >insurance.b   Flame on indeed.D Are you implying that we should decide NOT to even attempt to save a' life we deem less valuable in some way?   C I have worked with people in Canada who have had direct issues with"A the availability of health care, so that is not a myth.  But this < attitude you expressed of allowing some bureaucrat to decide# life-and-death is a bigger problem.o  1 Not speaking for anyone, certainly not DEC/Compaq - (get rid of the xxxz in my address to e-mail)    ------------------------------   End of INFO-VAX 2002.145 ************************ng includedtL > > > > in the base OVMS license. You always had to buy them separately, andM > > > > choose one or the other. Of course, DECnet-IV for OVMS-Alpha does not.K > > > > provide the routing functionality. DVNETEND is the best you can do.n > > > >  > > >aK > > > When we got our first Alpha, a 3000-300 in late 1993, it came bundled  > > > wi