1 INFO-VAX	Tue, 11 Jun 2002	Volume 2002 : Issue 321       Contents: Re: "Tru64 and OpenVMS Times" 0 Re: ? VMS 7.3.1 release date and a SAN question.4 Re: A dvdwrite(r)-Program: save 4.3 GB on a DVD-R(W)& Re: Alpha to ia64: where is the issue?& Re: Alpha to ia64: where is the issue?3 Re: Another analyst says VMS port won't be finished $ Re: AS-1000A Firmware upgrade manual# Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday # Re: Carly was here in ZKO yesterday  Re: Could linux become VMS?  Re: Fibre Disk vs. SCSI Disk) Re: For all you hobbyists: IDE on SCSI !!  Re: hobbyist (mini)merge/ Re: how to increase vms virtualpagecnt value ??  INITIALIZE and PCs Re: INITIALIZE and PCs Re: INITIALIZE and PCs2 Re: Is Polycenter for VMS a good security product? Re: Memo:  A pleasant surprise0 Re: Mounting shadowset system disks across a SAN8 Re: MRU and TZ875 (was:HP Alphaservers and Lan Consoles)8 RE: MRU and TZ875 (was:HP Alphaservers and Lan Consoles)8 Re: MRU and TZ875 (was:HP Alphaservers and Lan Consoles) Re: No new Alpha sales Re: Open Letter to HP  Re: Open Letter to HP  RE: Open Letter to HP  Re: Open Letter to HP  RE: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP   Re: OpenVMS FAQ due next week...G Re: OpenVMS, Volume Desktop OS (Re: Mark Gorham's Beer Bash in Reading) G Re: OpenVMS, Volume Desktop OS (Re: Mark Gorham's Beer Bash in Reading) G Re: OpenVMS, Volume Desktop OS (Re: Mark Gorham's Beer Bash in Reading) 	 rcp setup 
 Re: rcp setup  Re: Shadow sets efficiency# strange double comparison behaviour ' Re: strange double comparison behaviour  SYSMAN default parameters # SYSMAN default parameters - REVISED ' Re: SYSMAN default parameters - REVISED $ Re: TCP socket communication queries Re: VMS Monitoring a User  Re: VMS Monitoring a User  Re: VMS Monitoring a User  Re: VMS Monitoring a User  Re: VMS Monitoring a User < Re: Why porting apps to VMS isn't very helpful in most cases Re: xtoolkit error  F ----------------------------------------------------------------------  # Date: Tue, 11 Jun 2002 02:38:01 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> & Subject: Re: "Tru64 and OpenVMS Times"- Message-ID: <dodN8.149278$352.7367@sccrnsc02>   2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4023D9138@kaoexc01.americas.cpqcorp.net. ..	 Phillip -   G Re: HPS name change ..there are likely a number of reasons for changing B this name - not the least of which is HP Services is HPS .. Compaq, Global Services used to be shortened to CGS.  G That is a very good reason. I initially planned to call SKC SKHPS as in E Shannon Knows High Performance Systems. I was advised by a senior HPQ I executive to go with another name  because HPS does in fact equal Hewlett  Packard Services.    ------------------------------   Date: 10 Jun 2002 21:08:52 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)9 Subject: Re: ? VMS 7.3.1 release date and a SAN question. * Message-ID: <ae34h4$7iu$4@web1.cup.hp.com>  \ In article <1023352245.923506@ftp.adept.co.za>, "Zoldric Caff" <zoldric@hotmail.com> writes:2 :Does anyone know when VMS 7.3.1 will be released.  E   OpenVMS V7.3-1 is expected to ship from Engineering within a month  F   or so, and should arrive at most contract customer sites circa July B   or August 2002, assuming that the usual media and documentation A   replication and product shipping schedules hold to their norms.   . :Will a field test version be made available ?     You missed it, sorry.   6 :At present, I am doing some research on SANS and VMS.E :Does anyone know where I can find more informaction on this subject.   G   The OpenVMS Frequently Asked Questions (FAQ) document is probably as  F   reasonable a starting point as any other.  The OpenVMS FAQ contains I   the section "Where can I get Fibre Channel Storage (SAN) information?". E   The FAQ also has a pointer to the OpenVMS roadmaps, documents which C   provide expected release schedules and release contents and such.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Mon, 10 Jun 2002 19:43:03 GMT + From: Jeff Campbell <jcampbell@ins-msi.com> = Subject: Re: A dvdwrite(r)-Program: save 4.3 GB on a DVD-R(W) + Message-ID: <3D04F6DE.90CC0C61@ins-msi.com>    Larry Kilgallen wrote: > e > In article <3D04D57B.E8AEAC31@mindspring.com>, Atlant Schmidt <atlantnospam@mindspring.com> writes:  > > Larry Kilgallen wrote: > > $ > >> How about a 4.7GB ISO9660 DVD ? > >>O > >> Would VMS still expect a 2048 byte Logical Sector Size (an ISO9660 term) ?  > >>M > >> Does the rest of the industry think that 2048 is the Logical Sector Size & > >> to be used on ISO9660 DVD discs ? > > @ > > I don't know enough about ISO9660 to answer authoritatively,: > > but I know I tested DQDRIVER with ISO9660 CD-ROM discs@ > > and I'm pretty sure not all of these discs originated on VMS= > > systems, so I *THINK* whatever we do with regard to block * > > sizes is industry-standard conformant. > G > Yes, while the ISO9660 specification allows for a Logical Sector Size F > of 2048 bytes or any larger power of 2, every CDROM I have tries hasC > has a Logical Sector Size of 2048 bytes.  I had presumed that the D > nature of the CDROM hardware was such that something was "natural" > about 2048 bytes.  > C > For DVD-ROM, I thought maybe some other Logical Sector Size might # > be "natural", but I did not know.  > A > The smallest allocation unit under ISO9660 is the Logical Block B > (as distinguished from Logical Sector) and it can be as small asD > 512 bytes, although on CDROMs I have never noticed one to be otherE > than 2048.  To read ISO9660 from a given device, software must know E > the Logical Sector Size, which gives enough information to find the / > place where the Logical Block Size is stored.   < I think the 'natural' 2048 bias is the result of the ISO9660G specification of the "system area". The "system area" is defined as the @ first 16 logical sectors. The Primary Volume Descriptor (PVD) is2 defined to start with byte 1 of logical sector 16.  B ISO9660 defines a minimum logical sector size but does not provideC storage of the actual logical sector size in the PVD. It does store A the *active* logical block size in the PVD. Thus if a larger than D minimum *active* logical sector size were stored in the PVD, a givenC driver interface would have no way of finding where the PVD starts,  as you point out.   
 Jeff Campbell  n8wxs@arrl.net   ------------------------------  # Date: Tue, 11 Jun 2002 04:43:52 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> / Subject: Re: Alpha to ia64: where is the issue? & Message-ID: <3D0583B5.2E2E577@fsi.net>   "Main, Kerry" wrote: >  > Arne,  > F > >>>   2) even if it is just a re-compile, then there are still costs< >      (hardware and software purchase, testing etc.etc.)<<< > H > While you are correct, something to keep in mind from a developers andF > support point of view - assuming a SAN is in place, the same system G > IPF HW will be able to be used in the future to test and support not  G > only multiple versions of OpenVMS, but also W64 (whenever it becomes  G > available), HP-UX, or Linux. Simply point the boot device to another   > part of the SAN.  B Of course, the problem there is WhineBloze's nasty little habit ofG assuming it can write a "harmless" signature to (i.e., trash the zeroth G block of) every disk it sees, unless this is finally corrected by then.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 10 Jun 2002 23:57:25 -0600+ From: young_r@encompasserve.org (Rob Young) / Subject: Re: Alpha to ia64: where is the issue? 3 Message-ID: <bxlaY3q3RXuO@eisner.encompasserve.org>   Z In article <3D0583B5.2E2E577@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: > "Main, Kerry" wrote: >>   >> Arne, >>  G >> >>>   2) even if it is just a re-compile, then there are still costs = >>      (hardware and software purchase, testing etc.etc.)<<<  >>  I >> While you are correct, something to keep in mind from a developers and G >> support point of view - assuming a SAN is in place, the same system  H >> IPF HW will be able to be used in the future to test and support not H >> only multiple versions of OpenVMS, but also W64 (whenever it becomes H >> available), HP-UX, or Linux. Simply point the boot device to another  >> part of the SAN.  > D > Of course, the problem there is WhineBloze's nasty little habit ofI > assuming it can write a "harmless" signature to (i.e., trash the zeroth I > block of) every disk it sees, unless this is finally corrected by then.  >   , 	Yes, it is corrected.  It is called zoning.   			Rob   ------------------------------  # Date: Tue, 11 Jun 2002 02:40:44 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> < Subject: Re: Another analyst says VMS port won't be finished+ Message-ID: <MqdN8.34755$pw3.813@sccrnsc03>   : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:quRckBKYxp9v@eisner.encompasserve.org... = > In article <3D023C63.620C8F61@fsi.net>, "David J. Dachtera"  <djesys.nospam@fsi.net> writes:  > L > > Might there be room for HP to sue Gartner? (I realize you're not a legal' > > expert - speculation will suffice.)  > 9 > Please, comp.os.vms needs _less_ speculation, not more.  > G > But this item needs no speculation.  The nature of US law is that one I > can always sue.  There is no certainty regarding the success of a suit.   0 Quite true, and my son the lawyer confirms same.  I Filing a lawsuit seems a waste of time. An alternate approach might be to C take all the positive commentary from the likes of Giga, Meta, IDC, H Illuminata, DHBA, the Standish Group, et al, and stack it up against theG negative commentary from one analyst firm. In other words, who ya gonna 	 trust....    ------------------------------  # Date: Tue, 11 Jun 2002 00:11:48 GMT ( From: Alder <PGDEHMKOKIMD@spammotel.com>- Subject: Re: AS-1000A Firmware upgrade manual * Message-ID: <3D054043.20103@spammotel.com>   Main, Kerry wrote: > Alder, >  > G >>>>The HP/Compaq site seems to have a dead link to the firmware manual  >>> H > I want to read before I try upgrading the firmware in my AS-1000A. <<< > 7 > The links will apparently be fixed by noon EST today.  > E > In the meantime, if you would like the release notes sooner, please ; > email me offline and I will fwd the pdf file in question.  > 	 > Regards  >  > Kerry Main > Senior Consultant  > Hewlett-Packard Canada# > Consulting & Integration Services  > Voice: 613-592-4660  > Fax   : 613-591-4477 > Email: Kerry.Main@hp.com >  >  > -----Original Message-----2 > From: Alder [mailto:PGDEHMKOKIMD@spammotel.com]  > Sent: June 9, 2002 5:59 PM > To: Info-VAX@Mvb.Saic.Com + > Subject: AS-1000A Firmware upgrade manual  >  > H > The HP/Compaq site seems to have a dead link to the firmware manual I I > want to read before I try upgrading the firmware in my AS-1000A.  I've  J > no idea if I NEED to read this doc, but as a complete newbie I'd better  > be safer than sorrier. > J > Does anyone have a copy of this manual they'd like to share?  It's name  > on the HPQ site is:  > ! > alpha800_1000a_v57_fw_rnote.pdf  >  > Many thanks, > Alder  >   F The links are working again, Kerry, and I've now got the PDF.  Thanks  for the update.    Alder    ------------------------------  % Date: Mon, 10 Jun 2002 16:36:35 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> , Subject: Re: Carly was here in ZKO yesterday, Message-ID: <3D050DD2.4FF18529@videotron.ca>   Dave Gudewicz wrote: > 8 > I am 5 for 5 with messages to and from Scott Stallard.  K Since Scott Stallard seems to be the culprit in this case, would it be more B effective to reach both the guy under him and the guy above him ?   M If he is the one who wants VMS customers to move to Unix, then he can respond F anything to please you and yet continue to state that he will help VMS customers go to HP-UX.  M There are two possibilities: Stallard acts on his own and the policies stated M by Stallard don't represent official HP policy. Or Stallard is just a soldier & pushing policies set by his superiors.  K Only by seing the response from his superiors can one even attempt to judge I where the "we expect VMS customers to move to UNIX over time" comes from.    ------------------------------  # Date: Tue, 11 Jun 2002 02:45:08 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> , Subject: Re: Carly was here in ZKO yesterday, Message-ID: <UudN8.34769$pw3.1398@sccrnsc03>  7 "Tony Scandora" <Scandora@cmt.anl.gov> wrote in message % news:ae2h7a$thb$1@milo.mcs.anl.gov...  .  > F > HP's prime software is Windows, HP-UX, with some of Tru64 eventually foldedJ > in, and Linux.  VMS and NSK will be funded, but don't expect them to get the J > corporate visibility of Windows, HP-UX, or Linux.  I'd like to know some ofJ > what she couldn't repeat in public, but a corporation has good reason toL > keep some of its numbers and plans private.  I think what Sue posted about' > Carly's visit to ZKO is a Good Thing.   B No doubt. At least the lady now knows what VMS and Tru64 UNIX are.  H It seems to me that HPQ is stronger in Unix (and Linux) than in Windows.8 Perhaps some decent halo effect from CPQ in that regard.    I Hypothetically speaking, if HPQ were able to take HP-UX and endow it with K ALL the goodness of VMS (clustering, DLM, security, stability, reliability, L enhanced management, dynamic partitioning, Galaxy, etc, etc) would it really) make any difference if VMS still existed?    Just wondering.    ------------------------------  # Date: Tue, 11 Jun 2002 02:53:09 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> , Subject: Re: Carly was here in ZKO yesterday, Message-ID: <zBdN8.34791$pw3.1334@sccrnsc03>  7 "Tony Scandora" <Scandora@cmt.anl.gov> wrote in message % news:ae2h7a$thb$1@milo.mcs.anl.gov... 0 > "John Smith" <a@nonymous.com> wrote in messageE > news:KHQL8.238874$t8_.35896@news01.bloor.is.net.cable.rogers.com...  > > Sue, > > L > > Here's an idea for you. Scavenge this newsgroup for all the names of the > VMS L > > users who post in comp.os.vms. In most cases these will be people in the! > > trenches, not the executives.  > > @ > > Pick 10 people at pseudo-random from this group of newsgroup
 contributors,  > J > Not quite.  I read this newsgroup because my living used to be dependent onK > VMS, I still think VMS is interesting, and I want to be current should an L > opportunity to use VMS present itself to me some day.  I sitll do a littleI > VAX VMS 5.5-2 and 6.2 work, but I haven't spent any money on VMS except  for K > a few spare VAX parts since Digital was in business, and I'm not the only L > legacy reader of this newsgroup.  Based on posting vilume, Andrew HarrisonI > is likely to get called in a pseudo-random sampling.  This newsgroup is H > interesting, fun, and can be useful, but there must be a better way to > identify paying customers. > F > HP's prime software is Windows, HP-UX, with some of Tru64 eventually foldedJ > in, and Linux.  VMS and NSK will be funded, but don't expect them to get the J > corporate visibility of Windows, HP-UX, or Linux.  I'd like to know some ofJ > what she couldn't repeat in public, but a corporation has good reason toL > keep some of its numbers and plans private.  I think what Sue posted about' > Carly's visit to ZKO is a Good Thing.  > 3 > Tony Scandora, Argonne National Lab, 630-252-7541  > scandora@cmt.anl.gov >e >1   ------------------------------  # Date: Tue, 11 Jun 2002 03:15:05 GMTSL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"), Subject: Re: Carly was here in ZKO yesterday8 Message-ID: <00A0F443.F96440F6@SSRL04.SLAC.STANFORD.EDU>  ` In article <UudN8.34769$pw3.1398@sccrnsc03>, "Terry C. Shannon" <terryshannon@attbi.com> writes: > 8 >"Tony Scandora" <Scandora@cmt.anl.gov> wrote in message& >news:ae2h7a$thb$1@milo.mcs.anl.gov... >. >>G >> HP's prime software is Windows, HP-UX, with some of Tru64 eventuallye >folded K >> in, and Linux.  VMS and NSK will be funded, but don't expect them to gete >theK >> corporate visibility of Windows, HP-UX, or Linux.  I'd like to know some  >ofeK >> what she couldn't repeat in public, but a corporation has good reason toeM >> keep some of its numbers and plans private.  I think what Sue posted aboutI( >> Carly's visit to ZKO is a Good Thing. >cC >No doubt. At least the lady now knows what VMS and Tru64 UNIX are.E >dI >It seems to me that HPQ is stronger in Unix (and Linux) than in Windows.d9 >Perhaps some decent halo effect from CPQ in that regard.t >s > J >Hypothetically speaking, if HPQ were able to take HP-UX and endow it withL >ALL the goodness of VMS (clustering, DLM, security, stability, reliability,M >enhanced management, dynamic partitioning, Galaxy, etc, etc) would it really * >make any difference if VMS still existed?  J Does that etc, etc, include compatibility for VMS binaries, VMS-compatibleK compilers, VMS system services, and support for mixed-architecture clusters I with real VMS systems?   Does this imaginary HP/UX run on VAX and Alpha? m  K I'm not being arbitrary with these additional requirements.  The market forkA VMS is primarily in the existing (eroding) installed base. If HPQmK discontinued VMS in favor of HP/UX without providing the things I mentionedeJ in the last paragraph, then HPQ would be screwing the installed base (likeD that's never happened).  Even with very agreeable deals for forkliftF upgrades, you still have to port your applications, and if it isn't atH least as easy as VAX->Alpha, you might as well go to some platform whoseE vendor you can trust not to try pushing you off the new platform ontoaG Windows.  A super-enhanced HP/UX with a whole VMS checklist of featuresyG might be an atractive option ab initio, but a customer with a homegrown-H applications portfolio would probably sleep better on an adequate systemF with either a committed vendor - IBM, Sun - or whose fate isn't in the+ hands of any one vendor (eg, xBSD, Linux).)d   -- Alan5  O ===============================================================================C0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056mM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================g   ------------------------------  # Date: Tue, 11 Jun 2002 04:26:54 GMTi( From: "C.W.Holeman II" <cwhii5@ACM5.org>, Subject: Re: Carly was here in ZKO yesterday? Message-ID: <i_eN8.177$hm1.55@newsread2.prod.itd.earthlink.net>    Terry C. Shannon wrote:-  K > Hypothetically speaking, if HPQ were able to take HP-UX and endow it with @ > ALL the goodness of VMS (clustering, DLM, security, stability,K > reliability, enhanced management, dynamic partitioning, Galaxy, etc, etc)0; > would it really make any difference if VMS still existed?e  E Does any Unix or anything else have logical names with search lists? 1 Just wondering.h   --   C.W.Holeman II cwhii5@ACM5.orgr remove the fives http://also.as/cwhii   ------------------------------  # Date: Tue, 11 Jun 2002 04:58:18 GMTi1 From: "David J. Dachtera" <djesys.nospam@fsi.net>p, Subject: Re: Carly was here in ZKO yesterday' Message-ID: <3D05871B.C10901FC@fsi.net>    Rob Young wrote: > g > In article <ae2a9q$ck1$1@fizban.pprd.abbott.com>, "Dave Gudewicz" <david.gudewicz@abbott.com> writes:o: > > I am 5 for 5 with messages to and from Scott Stallard. > >t > G >         That's because you are a professional.  My initial impressionh >         Oct.  1998.n  D ...and the rest of us are Swiss Cheese? (...or chopped liver, if you prefer.)   --   David J. Dachterat dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/-   ------------------------------  % Date: Tue, 11 Jun 2002 01:33:40 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>F, Subject: Re: Carly was here in ZKO yesterday, Message-ID: <3D058BB3.9C75D4FC@videotron.ca>   "Terry C. Shannon" wrote: K > Hypothetically speaking, if HPQ were able to take HP-UX and endow it with-M > ALL the goodness of VMS (clustering, DLM, security, stability, reliability,mN > enhanced management, dynamic partitioning, Galaxy, etc, etc) would it really+ > make any difference if VMS still existed?1  N Depends if they add stuff to HP-UX just to say it has it, or if they add stuffI to really give it all the functionality and reliability that is expected.rN Everyone claims to have clustering, so it won't be hard to add enough to HP-UX& to allow HP-UX to also claim the same.  J I find your use of "hypothetically speaking" interesting. Seems to me thatK this is what HP intends to do anyways. They have admitted that they will be?N initially transfering clustering from tru64 to HP-UX and I think they left the door opened to do more.R   ------------------------------  % Date: Tue, 11 Jun 2002 01:37:58 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>t, Subject: Re: Carly was here in ZKO yesterday, Message-ID: <3D058CB4.B450A37D@videotron.ca>   "C.W.Holeman II" wrote:nF > Does any Unix or anything else have logical names with search lists? > Just wondering.   F MVS has had the equivalent of logical names in JCL since last century.   ------------------------------  % Date: Tue, 11 Jun 2002 01:42:23 -0400u- From: JF Mezei <jfmezei.spamnot@videotron.ca>I, Subject: Re: Carly was here in ZKO yesterday, Message-ID: <3D058DBD.F80D02C7@videotron.ca>   re: VMS parts ported to HP-UXt  M The *smart* thing to do would be to continue to make VMS more Unix compatibled/ and then get HP-UX  applications ported to VMS.C  I It is always easier to upgrade to a better system than to downgrade to anm inferior system.   ------------------------------  % Date: Tue, 11 Jun 2002 01:38:36 -0400o  From: John Santos <JOHN@egh.com>, Subject: Re: Carly was here in ZKO yesterday4 Message-ID: <1020611012515.385A-100000@Ives.egh.com>  , On Tue, 11 Jun 2002, Terry C. Shannon wrote:   > 9 > "Tony Scandora" <Scandora@cmt.anl.gov> wrote in messagee' > news:ae2h7a$thb$1@milo.mcs.anl.gov...t > .e > > H > > HP's prime software is Windows, HP-UX, with some of Tru64 eventually > foldedL > > in, and Linux.  VMS and NSK will be funded, but don't expect them to get > thevL > > corporate visibility of Windows, HP-UX, or Linux.  I'd like to know some > ofL > > what she couldn't repeat in public, but a corporation has good reason toN > > keep some of its numbers and plans private.  I think what Sue posted about) > > Carly's visit to ZKO is a Good Thing.  > D > No doubt. At least the lady now knows what VMS and Tru64 UNIX are. > J > It seems to me that HPQ is stronger in Unix (and Linux) than in Windows.: > Perhaps some decent halo effect from CPQ in that regard. >  > K > Hypothetically speaking, if HPQ were able to take HP-UX and endow it with M > ALL the goodness of VMS (clustering, DLM, security, stability, reliability,oN > enhanced management, dynamic partitioning, Galaxy, etc, etc) would it really+ > make any difference if VMS still existed?  >  > Just wondering. L Necessary but not sufficient.  It would also need DCL, RMS, most of the API,  source-compatible compilers, ...  & Without all that, here's what happens:  M Since you are forced to rewrite in another language (C/C++/Java/scripts/etc.)eH in order to port, you probably won't want to lock yourself into a singleH platform, which means writing to least-common-denominator Unix.  (HavingG bit the bullet of rewriting, there's a good chance you wouldn't want tocF lock yourself into HP-UX, no matter how many nice VMS-derived features were under the hood.)t  B For example, if your app depends on locks, you could 1) stick withI VMS (use DLM), or 2) rewrite in C/etc. targeted for HP-UX and use HP-UX's E VMS-derived DLM, or 3) rewrite in C/etc. and write a minimal portableqD locking package that does only what you need and nothing more, might? require manual restarting if something dies, etc. (ugly, but it,B does the job.)  Since it wouldn't be cluster-aware, you don't have% to worry about lock remastering, etc.t  B It's all a matter of trade-offs, and for many apps, the rewards ofE option 3 are much greater than the costs.  The reward is portability,rF and the ability to run on generic (cheap) systems. The costs of 2) andC 3) both include a large cost to rewrite in a different language and D option 3 also includes a much smaller incremental cost to write yourC "poor-man's locking" package.  Plus the loss of clusters, security,o- etc., but for MANY apps, those are secondary.   H Of course, if HP did all the things I listed above, then you would have I option 4) recompile for HP-UX, which would be almost as easy as option 1.c   -- v John Santose Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 10 Jun 2002 23:53:22 -0600+ From: young_r@encompasserve.org (Rob Young)2, Subject: Re: Carly was here in ZKO yesterday3 Message-ID: <piTNOcRRvMLN@eisner.encompasserve.org>y  ` In article <UudN8.34769$pw3.1398@sccrnsc03>, "Terry C. Shannon" <terryshannon@attbi.com> writes: > 9 > "Tony Scandora" <Scandora@cmt.anl.gov> wrote in messagee' > news:ae2h7a$thb$1@milo.mcs.anl.gov...C > .0 >>G >> HP's prime software is Windows, HP-UX, with some of Tru64 eventually  > foldedK >> in, and Linux.  VMS and NSK will be funded, but don't expect them to get- > theaK >> corporate visibility of Windows, HP-UX, or Linux.  I'd like to know some  > ofK >> what she couldn't repeat in public, but a corporation has good reason to M >> keep some of its numbers and plans private.  I think what Sue posted about ( >> Carly's visit to ZKO is a Good Thing. > D > No doubt. At least the lady now knows what VMS and Tru64 UNIX are. > J > It seems to me that HPQ is stronger in Unix (and Linux) than in Windows.: > Perhaps some decent halo effect from CPQ in that regard. >  > K > Hypothetically speaking, if HPQ were able to take HP-UX and endow it withnM > ALL the goodness of VMS (clustering, DLM, security, stability, reliability,1N > enhanced management, dynamic partitioning, Galaxy, etc, etc) would it really+ > make any difference if VMS still existed?0 >  > Just wondering.n >   A 	Make a difference if VMS existed?  From a management standpoint?d; 	Probably not.  From a former customer standpoint?  Surely.r  6 	But a quick perusal of MC discussion board... picking 	a topic at random:n  < http://forums.itrc.hp.com/cm/CategoryHome/1,,210!1!2,00.html  L I have two K580 class servers in a MCSG configuration, running MCSG 11.12. IK have two packages configured in this cluster: (pkga on Node A) and (pkgb ontM Node B). Each time the cluster is rebooted, both packages start on the Node A6N thus package pkgb has to manually switched over to Node B. Question (2 parts):8 A) Will editing the High Availability Configuration FileL (/etc/cmcluster/pkgb/pkgb.conf), in section defining the order of the nodes,O will correct this problem so that pkgb starts on NODE B and pkga starts on NODEt& A each time the servers are rebooted? 0 ... (pkgb.conf file ..near the FAILOVER_POLICY)  NODE_NAME NODE A 0 NODE_NAME NODE B e  N B)Can this change be made on online? (cmcheckconf -v -P pkgb.conf, cmapplyconf -v -P pkgb.conf) o    F 	Shows it has a large dose of what Unix/NT folks embrace as a cluster.C 	In a number of discussions, you don't run apps concurrently (shorty@ 	of OPS, others?  If so, trot them out.  I do want to learn moreD 	about this sort of thing.  FUD is one thing.  If more apps do exist: 	that are concurrent, sure would like to know about them).  = 	I certainly don't have all night.  Not tonight anyhow... but:B 	looking for signs of true clusters (shared vg, maybe this is it!) 	alas led back to OPS:  Y http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x62547bb04b5cd611abdb0090277a778c,00.htmla   Hello Ischae,   O Each node in an OPS cluster must have it's own package in order to activate the G Volume Groups in "shared" mode and start their own instance of Oracle. oG This means two different packages with unique package names and control 	 scripts. aH Each package should be configured to run on only one node and no other.   L See the manual: "Configuring OPS Clusters with ServiceGuard OPS Edition " atU http://docs.hp.com/hpux/ha/index.html#ServiceGuard%20OPS%20Edition%20(MC/LockManager)r for more information.     1 	Ischae isn't doing OPS and discovers the answer:g  	 jschae        8  May 03, 2002 00:37 AM GMT   [ N/A: Question Author ]     P -------------------------------------------------------------------------------- Thank you.. L At first, I have made one package two node cluster. But the both node cannot access at the same time. 37 So, I make a one package owned by one node each other. >0 Now, the both node can access the volume group.  Thank you..      : 	i.e. Node A , Node B ,  package failover thingy.  Another 	confirmation of failover:  
 Aaron Sheard S    "  February 26, 2002 22:00 PM GMT     P --------------------------------------------------------------------------------L I have a question, when a fail-over occurs, it disables package switching onL the primary node. I would like to know how, when you fail a package from oneK node to another, you can re-enable package switching from the command line,dN instead of going into sam, under package admin, modify failover options. I was@ hoping i can script it with cmmodpkg or something like that,,,     ----  > 	So okay.  Let's pretend they get a DLM.  That's a good start.B 	Maybe we check back in 2 or 3 years?  Also, if they get somethingF 	that resembles a real cluster, won't it scramble these folks' brains?  @ 	I mean you get used to fallover "clusters" and then have to do : 	a real cluster, wouldn't that be very hard on the psyche?  = 	Galaxy?  That is very hard.  Maybe we check back in 5 years?m   				Rob    ------------------------------  # Date: Tue, 11 Jun 2002 04:51:49 GMTs1 From: "David J. Dachtera" <djesys.nospam@fsi.net>>$ Subject: Re: Could linux become VMS?' Message-ID: <3D058592.1AF7C0BC@fsi.net>@   Aristotle SnowNasis wrote: > J > In article <adoch4$jga$1@milo.mcs.anl.gov>, Scandora@cmt.anl.gov says... > >i7 > >"Brass Christof" <welcome@spam.not> wrote in message % > >news:3CFF3B6D.ED24C47D@spam.not...o' > >> "Scandora, Anthony (35048)" wrote:  > >> ...A > >> > > Did I mention that UNIX is shit/crap and C fits well in?h > >> >N > >> > There is a lot not to like about it, but once properly configured, UNIX > >canN > >> > run reliably and do a lot of work, and most of what's wrong with C alsoO > >> > applies to BLISS and to Macro.  A lot can be said about .ascid v. .ascizu8 > >> > strings, but that's a lanugage independent issue. > >>A > >> The point is how much time you need to get it in that state. @ > >> Having BLISS and Macro similar flaws doesn't make C better. > >i > >iM > >It's annoying, but not too difficult to learn where those config files are.L > >and what goes in them.  I suspect someone who doesn't know VMS would moanO > >about having to learn AUTOGEN and MODPARAMS.  Once you know your stuff, it'sb; > >pretty easy to configure either a Linux or a VMS system.. > + > I'd agree. VMS can be so obtuse at times,t  @ Examples, please? Hard to understand the reference without them.  & > whereas MOST Unix have configurationL > files in centrally located areas. Also, help on VMS is quite brief and notJ > always very helpful. On the other hand, man pages, while sometimes beingO > tautological are full of information, especially that parts that describe thea( > files used in such-and-such a program.  D That's what documentation is for. However, since none comes with theH average UN*X variant, the man pages are about all there is - ANYWHERE! -G other than things like the on-line FreeBSD doc.'s and such. Even today,o7 there is still a great preference for hard-copy doc.'s.n  K > By the way, I'm an administrator on several unix and vms platforms (vax &a	 > alpha).N > Q > Overall, VMS has stood still for years while Unix has marched on (especially to"P > the degree of products provided by the likes of HP, Sun, Compaq to enhance the > "unix experience"...)H  F Compared to VMS, IMO, it *NEEDS* a whole hell of a lot of enhancement!   > [snip]   -- n David J. Dachteral dba DJE Systemsd http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/w   ------------------------------  % Date: Tue, 11 Jun 2002 02:04:39 +0200g) From: "Steven Thompson" <steven@omga.biz> % Subject: Re: Fibre Disk vs. SCSI DisksB Message-ID: <ae3enk$t4s$1@nsnmrro2-gest.nuria.telefonica-data.net>   Hi PeterJ The arguments are good. So where do do put your money? Just how many disks are you going to buy?nJ Put it another way, just how many I/O's does your application need anyway?F or does the DB server with 4 CPUs show a measly 30% CPU usage all day?J (Thats 30 out of a possible 400%... understood since were in the VMS group :-)i  J I've had a  HSZ80 ("old" DEC/Compaq technology, SCSI disks, SCSI bus) giveI impressive io rates, FAR better than a more modern XP512 (fiber disks andaI fiber bus) under "similar" circumstances. But there were reasons why thatr	 happened.eK The HSZ80 was "full" with it's 24 disks and the XP with supposedly superiorm; everthing, only had 7 disks hidden behind the closed doors. L The HSZ was dedicated to my VMS application and the XP was used by my VMS asD well a Unix box. The results I measured from from VMS point of view.8 Clients typically buy a new toy and expect more from it!H (The XP has been added to , and reconfigured since then, and the figures  have improved, without a doubt!)  L So it's important to DESIGN a disk sub-system to your requirements (and your8 pocket), not just worry about whether its SCSI or FIBER.I The newer (Compaq's) MA8000 is a newer SCSI/ fiber version of the HSZ andtK gives excellent results with just about any operating system you have! Samea3 goes for (Compaq's) EVA, the latest 2GB  fiber SAN.iL If you're looking at EMC, SYMMETRIX etc then you must consider the XP's MA's and EVA!   Steven Thompsonl Omega-Peripheralsn Madrid  A "Peter LANGSTOEGER" <peter@langstoeger.at> escribi en el mensajes/ news:0CQM8.181983$305.2428695@news.chello.at...nF > As I watched a discussion between two people with different opinionsF > and I have no information yet, to know who has the better arguments, > I'd like to ask you: >eE > What do you think on the advantages of Fibre Disks vs. SCSI Disks ?  >l > Arguments I heard there: >X > Pro SCSI:RJ > *) SCSI has (at least with the latest technology) better throughput than Fibre., > *) SCSI disks are cheaper than fibre disks >- > Pro Fibre:L > *) Fibre has (via better commands on the wire) better throughput than SCSII > *) One bad SCSI disk can quiesce the whole SCSI bus => fibre has betterd > fault tolerancekK > *) Fibre will keep the better throughput vs. SCSI in the very near futurea# > via upgrade to 2GB and 10GB links 0 > *) SCSI disks are NOT cheaper than fibre disksI > *) Some companies (eg. Q until recently) had no Fibre offerings and dida# > therefor badmouth Fibre solutionsa >aD > At the last DECUS Symposium in Germany I saw that eg. EMC has both	 solutionsaK > but the bigger ones (SYMMETRIX vs. CLARION) have been the SCSI-only ones.5J > Is this a correct or only a very limited view of the current situation ? >- >-J > NOTE: I mean the connection from the disk to the storage controller in a SANmC > The connection from SAN to the host systems are FibreChan without  discussions. >C > TIAt >  > -- > Peter "EPLAN" LANGSTOEGERe' > Network and OpenVMS system specialistD > E-mail  peter@langstoeger.atK > A-1030 VIENNA  AUSTRIA              I'm looking for (a) Network _and_ VMS. Job(s)   ------------------------------    Date: 10 Jun 2002 20:25:31 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)f2 Subject: Re: For all you hobbyists: IDE on SCSI !!= Message-ID: <cf15391e.0206101925.53a48255@posting.google.com>w  L Dirk Munk <munk@home.nl> wrote in message news:<3D0126A7.9040702@home.nl>...E > Characteristics: 1C4D4408 dir,qsvbl,fod,shr,avl,mnt,elg,idv,odv,rnd26 >                   25010201 clu,nnm,nlt,scsi,nofe,dtn2                                               ^^^^I > So it seems it does not support Forced Error operations.  Now I have toe2 > check how serious that is for shadow operations.  @ Disks will sometimes report an Uncorrectable ECC error, when theD number of data symbols corrupted within a sector is greater than theA disks' Error Detection and Correction scheme is able to correct. eF What's left of the data will then be revectored to a good sector (thisD is called Bad Block Replacement).  Because VMS users hate undetectedC data corruption, VMS will write a Forced-Error flag on that sector, ? which will cause an error message to be generated each time youHE re-read the now-bogus data, until the sector gets overwritten and thek( Forced-Error flag on it is thus cleared.  D If VMS needs to write a Forced-Error flag on a disk with "nofe" set,@ it cannot do that, and it will remove the entire member from the: shadowset instead, because it can no longer guarantee data consistency.: ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------    Date: 10 Jun 2002 20:01:57 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)e! Subject: Re: hobbyist (mini)merget= Message-ID: <cf15391e.0206101901.30119f13@posting.google.com>   | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KINQCE35W496WQWC@sysdev.deutsche-boerse.com>...F > After having successfully shadowed some disks (including the system J > disk) in my hobbyist system, I now plan to distribute the members acrossC > nodes so that I am guarded against not only disk/controller/mediarG > failure but also node failure.  (Of course, relevant applications aretH > cluster-aware, so even a system failure shouldn't bother me too much.) > G > I'm thus reading up on host-based volume shadowing.  Am I correct in 0G > assuming that (mini)merge is not relevant unless there is a non-MSCP hK > path to more than one machine?  (Not that I NEED a non-MSCP path to more  J > than one machine; I just want to make sure that I don't have to read up  > on this.)o  D The need for a merge really has nothing to do with what type of pathC one uses to reach the disks.  The requirements are the same whethernE you are accessing the disk directly (as in a SCSI cluster) or via theo VMS MSCP Server over a LAN.v   A merge will be required if:D 1) A node which leaves the cluster had the shadowset mounted when it	 left, andtE 2) There are at least 2 shadowset members left in the shadowset afternA the node leaves (such that a write operation in progress from the'C departed node might have reached one or more of the members but noto all of the members)T  < A Mini-merge can be done instead of a Full Merge if the diskE controller supports the MSCP Volume Shadowing Assists (in particular,CC Write History Logging).  HSJ and HSD controller models tend to havelA this feature.  If you have the VMS MSCP Server serving local SCSIt0 disks, the write-logging capability isn't there.  E If the node leaving the cluster unexpectedly also takes a member awaylD with it, that member will need to be the subject of a Full Copy when it returns. : ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------  # Date: Mon, 10 Jun 2002 19:22:05 GMTu( From: Don Sykes <annonymous@pacbell.net>8 Subject: Re: how to increase vms virtualpagecnt value ??+ Message-ID: <3D04FCB2.2A8E3440@pacbell.net>c  
 harris wrote:  > D > in my VAX6500 system ,it reset (reboot) by itself when login users > about 150 it reset by itself! > i add 320 MB memory and two cpuM > but it's performance is badt > and loading heavy.G > i want to modify stsgen parameter "virtualpagecnt" value about 200000,1 > when i increase it about 250000(current vqalue)  > it can't boot .e) > i must decrease it's value about 200000m4 > can i use autogen to modify system parameter value > how can i do??* > my vax 6500 system reboot once 20 days .4 > i can't read any error messages in ana/err/sin=xxx >  > or > ana/system > sda> > i can't read any messages. > or dump files...., > please help me.a  O There are many in this group who could answer you better, but I hate to see you N hanging, so i'll offer this. It could be you've run out of disk space and that value (250000) seems low.o1 In any event to do what you ask via AUTOGEN, add n 	VIRTUALPAGECNT=250000 to SYS$SYSTEM:MODPARAMS.DATm Then enter:n, 	@SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK  
 Good luck. --     Have VMS. Will Travel. Wire Paladin @alphase.com 
 San Franciscos   ------------------------------  + Date: Mon, 10 Jun 2002 20:37:27 +0100 (MET)h9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>a Subject: INITIALIZE and PCs ; Message-ID: <01KIS1HFLYRI96WQWC@sysdev.deutsche-boerse.com>5  H I took a SCSI disk which had been connected to a PC and connected it to F a VMS box.  Could see it at the console, could see it from VMS, could I INITIALIZE it.  What about the reverse direction---take a SCSI disk from n@ a VMS box and connect it up to a PC.  Obviously, if it has been I INITIALIZED by VMS, the PC can't use it as it is.  Is it possible to get wI it into a PC-usable state from the PC itself, or does one need to format '1 (in some sense of the word) somewhere else first?u   ------------------------------  % Date: Mon, 10 Jun 2002 19:05:07 +0000t2 From: John Eisenschmidt <jweisen@eisenschmidt.org> Subject: Re: INITIALIZE and PCsu3 Message-ID: <20020610190507.C8339@eisenschmidt.org>t   --O3RTKUHj+75w1tg5* Content-Type: text/plain; charset=us-ascii Content-Disposition: inline + Content-Transfer-Encoding: quoted-printableC  L If I'm understanding your questions correctly, you need to use fdisk to par=L tition the disk and then use format to ... well ... format the disk. You ca=L n pass a /? parameter to both for the syntax under DOS and Win 9x. For NT/2=: k/XP you would use some derrivative of disk administrator.  L Unless the Voices are Mistaken, Phillip Helbig (HELBPHI@sysdev.deutsche-boe= rse.com) Wrote:tJ > I took a SCSI disk which had been connected to a PC and connected it to= =20 J > a VMS box.  Could see it at the console, could see it from VMS, could=20K > INITIALIZE it.  What about the reverse direction---take a SCSI disk from=t =20iD > a VMS box and connect it up to a PC.  Obviously, if it has been=20K > INITIALIZED by VMS, the PC can't use it as it is.  Is it possible to get=  =20pK > it into a PC-usable state from the PC itself, or does one need to format=l =20e3 > (in some sense of the word) somewhere else first?    --=20p/ John W. Eisenschmidt <jweisen@eisenschmidt.org> 6  Homepage URL    | http://www.eisenschmidt.org/jweisenL  PGP Public Key  | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.a= scD  PGP Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2  L FOO MANE PADME HUM: "Our first obligation is to keep the FOO counters turni= ng."   --O3RTKUHj+75w1tg5' Content-Type: application/pgp-signaturet Content-Disposition: inlinen   -----BEGIN PGP SIGNATURE-----r Version: GnuPG v1.0.6 (OpenBSD) * Comment: For info see http://www.gnupg.org  @ iD8DBQE9BPhjH5fmozfjvvIRAnIvAKCAoUcn7qy0axewa5dRxcjgzt+DUwCg3VwB 0Z7dRVPhre2csvW3kSBFDic= =Ty0Hy -----END PGP SIGNATURE-----    --O3RTKUHj+75w1tg5--   ------------------------------  # Date: Mon, 10 Jun 2002 22:52:59 GMTn( From: "Tom Simpson" <simpsont@attbi.com> Subject: Re: INITIALIZE and PCsh; Message-ID: <f5aN8.55950$2m.17588166@typhoon1.se.ipsvc.net>   L Reformat it from the PC - fdisk and reformat, that is...  I'm sure I've done
 it before, but it's been awhile.y   Regards, Tomi  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KIS1HFLYRI96WQWC@sysdev.deutsche-boerse.com...tI > I took a SCSI disk which had been connected to a PC and connected it to7G > a VMS box.  Could see it at the console, could see it from VMS, couldtJ > INITIALIZE it.  What about the reverse direction---take a SCSI disk fromA > a VMS box and connect it up to a PC.  Obviously, if it has beencJ > INITIALIZED by VMS, the PC can't use it as it is.  Is it possible to getJ > it into a PC-usable state from the PC itself, or does one need to format3 > (in some sense of the word) somewhere else first?    ------------------------------  # Date: Tue, 11 Jun 2002 04:53:40 GMT21 From: "David J. Dachtera" <djesys.nospam@fsi.net>c; Subject: Re: Is Polycenter for VMS a good security product? ' Message-ID: <3D058604.253E34E5@fsi.net>u   dittman@dittman.net wrote: > ( > Main, Kerry <Kerry.Main@hp.com> wrote: > : Rainer,- > - > :>>> Dealing with CA was a heavy matter.<<<n > K > : While I will certainly not argue this point, I do know CA is apparently H > : trying to rectify their image and pricing issues that many Customers > : have had in the past.o > K > : As an example, I was told a couple of weeks ago that CA has drasticallyhI > : dropped the prices for many of the OpenVMS related products e.g. like:L > : what was formerly called DECps (now Unicenter Performance Management for
 > : OpenVMS).- > ? > What is a pain is the products no longer use LMF.  The new CAw, > license manager can be a pain in the butt.  F ...and as has been discussed recently, some corporate policies preventE the implementation of non-LMF-compliant software, partly for securityaF but mostly to control the costs associated with license adminstration.   -- w David J. Dachterae dba DJE Systems, http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Mon, 10 Jun 2002 23:10:00 GMTr4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>' Subject: Re: Memo:  A pleasant surprisen0 Message-ID: <3D05306B.2E19BE16@blueyonder.co.uk>   paul.beaudoin@hsbc.com wrote:? > J > In an otherwise frustrating and serviceless world I am please to offer aM > ray of sunshine. A year ago I purchased a 500Mz Alpha from Island ComputersaJ > (who at the time did not have the specified 7.2K spin disk so supplied aK > 10K spin disk so as not to delay the order) and got it from USA to LondonaM > in 2 days. In the UK you are lucky to get a return call in that time frame." > M > I subsequently had a problem with the power supply and despite it being outmM > of the warranty period and entirely possible that this was a self inflictednM > wound, David very kindly supplied a replacement part without quibble and as B > I gathered later handled this from home as he was sick with flu! > J > It doesn't get better than this. My thanks for a fine service and if youK > want good Alphas from a good company who will provide excellent service -u > these are the guys.h > H > Disclaimer: This is unsolicited and I have no relationship with Island) > beyond being a very satisfied customer.  >  > Paul   K How about DS10l ordered from the same vendor Fri 17:00 GMT delivered to UK oL monday. Not me, sadly, but an ex-colleague now has a nice home box. Me, I'm 2 messing with Mandrake 8.2. The price is right :-).   regards,   -- l tim.llewellyn@blueyonder.co.uk    F * tim.llewellyn@cableinet.co.uk address will cease to work June 2002 *   ------------------------------    Date: 10 Jun 2002 19:48:38 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)t9 Subject: Re: Mounting shadowset system disks across a SANe= Message-ID: <cf15391e.0206101848.67362322@posting.google.com>a  g norm.raphael@jamesbury.com wrote in message news:<OFD8FC3770.B1DF3E2E-ON85256BD1.00517611@metso.com>... C > In the April 2001 white paper "Fibre Channel in Disaster-Tolerantd= > OpenVMS Cluster System" it say in footnote 2 on page 5 thatr@ > "mounting system disk shadow sets in DT configurations on both > sites is not recommended."  ; At this point in the white paper, they are still discussing'E traditional disaster-tolerant cluster theory (they won't get to Fibrep Channel until Page 7).  A Prior to Fibre Channel, it was not feasible in practice to have a A shared, common system disk for the entire cluster and try to boota> systems from it at both sites.  This was because all access toC shadowset members at the opposite site was via the VMS MSCP Server,.C and so you didn't have any access to remote disks until there was acD VMS system booted (or at least far enough along in its boot sequence9 for the VMS MSCP Server to be active) at the remote site.g  F Let's say you did have a shared system disk between sites.  You boot aF system at one site first, and since it cannot yet see any disks at theF opposite site, it must form a single-member shadowset of the member atE its own site.  Next, you boot a system at the other site, and it musttE boot from the local member of the system disk at its site, since from C the boot prompt it cannot see the disks at the opposite site.  WhenlD VMS on that system gets far enough along in the boot to try to mountE the system disk as a shadowset, it discovers that the local member itsF has booted from had been removed from the shadowset, and is now out ofA date, and the node crashes with a Shadowing Detected Inconsistentt State bugcheck.o  A > In a meeting yesterday, I was told that enhancements to OpenVMSs, > made since this was published negate this. > 3 > What is correct and why (feel free to elaborate)?   C With Fibre Channel, it now becomes theoretically possible to have asE shared, common system disk between sites, because (with an inter-siteuD FC link) you don't need the VMS MSCP server to be in place to accessD the remote site's member of a system disk shadowset.  Although it isD now possible, I still have some serious doubts as to whether, from aB high-availability standpoint, this is really a good thing to do orF not, and I haven't had the chance to play with it and discover all the! ramifications in actual practice.I  D I do know that a cluster-common system disk, despite being shadowed,D can still be a single point of failure for an entire cluster, in theD event someone accidentally does a DELETE *.*;* or something.  HavingE multiple system disks is more work to manage, but can allow a cluster'  to survive this type of failure.: ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------  # Date: Mon, 10 Jun 2002 18:31:08 GMTe" From: Alfred Falk <falk@arc.ab.ca>A Subject: Re: MRU and TZ875 (was:HP Alphaservers and Lan Consoles) 9 Message-ID: <Xns92297F5933EF4falkarcabca@205.233.108.180>a  & dooleys@snowy.net.au (dooley) wrote in6 news:1ca82fc6.0206081948.30333d97@posting.google.com:    <snip>+ > While on the subject of remote managementh/ > does anyone use the Media Robot Utility (MRU)n. > to access a tz875 mini-library from vms 7.2? > Phil  , I use it on VMS 7.3.  Is that close enough?    --  @ ----------------------------------------------------------------A   A L B E R T A         Alfred Falk               falk@arc.ab.ca p@ R E S E A R C H         Information Systems Dept   (780)450-5185+   C O U N C I L         250 Karl Clark Roadn1                         Edmonton, Alberta, Canadan http://www.arc.ab.ca/   T6N 1E4i  http://www.arc.ab.ca/staff/falk/   ------------------------------  % Date: Mon, 10 Jun 2002 15:46:05 -0400 * From: WILLIAM WEBB <WWEBB1@email.usps.gov>A Subject: RE: MRU and TZ875 (was:HP Alphaservers and Lan Consoles)r- Message-ID: <0033000067471683000002L032*@MHS>s   =0AVMS 7.2-1  4 Not having the bar code readers like on the TL891/2s is kind of a drag, though.   WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNET # Sent: Monday, June 10, 2002 2:45 PMGB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNETA Subject: RE: MRU and TZ875 (was:HP Alphaservers and Lan Consoles)o    & dooleys@snowy.net.au (dooley) wrote in5 news:1ca82fc6.0206081948.30333d97@posting.google.com:7   <snip>+ > While on the subject of remote management / > does anyone use the Media Robot Utility (MRU)!. > to access a tz875 mini-library from vms 7.2? > Phil  + I use it on VMS 7.3.  Is that close enough?e   --@ ----------------------------------------------------------------@   A L B E R T A         Alfred Falk               falk@arc.ab.ca@ R E S E A R C H         Information Systems Dept   (780)450-5185+   C O U N C I L         250 Karl Clark Roadu1                         Edmonton, Alberta, Canadah http://www.arc.ab.ca/   T6N 1E4w! http://www.arc.ab.ca/staff/falk/=s   ------------------------------    Date: 10 Jun 2002 16:22:23 -0700- From: tony_mcgrath@toll.com.au (Tony McGrath)iA Subject: Re: MRU and TZ875 (was:HP Alphaservers and Lan Consoles)h= Message-ID: <ba84734f.0206101522.556dac27@posting.google.com>(  c Alfred Falk <falk@arc.ab.ca> wrote in message news:<Xns92297F5933EF4falkarcabca@205.233.108.180>...r( > dooleys@snowy.net.au (dooley) wrote in8 > news:1ca82fc6.0206081948.30333d97@posting.google.com:  >  > <snip>- > > While on the subject of remote managementr1 > > does anyone use the Media Robot Utility (MRU)l0 > > to access a tz875 mini-library from vms 7.2? > > Phil > - > I use it on VMS 7.3.  Is that close enough?r  A We use it too, on our 4100 servers, although we have the TZ885's.o' Initially while on 7.2-1H1, now on 7.3.-" Works just fine, for our purposes.   Cheers from Melbourne,    Tonyp --- ) OpenVMS Support, IT Dept., Toll Transport-$ Laverton North, VIC, Australia, 3026   ------------------------------    Date: 10 Jun 2002 16:42:18 -0700( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: No new Alpha sales1= Message-ID: <d7791aa1.0206101542.42082781@posting.google.com>v   Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<ae2cmb$kl3$1@new-usenet.uk.sun.com>...i > Bob Ceculski wrote:  >  > > Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<adqg4m$73h$1@new-usenet.uk.sun.com>...  > > H > >>I agree entirely, hence why I used the SAP results to illustrate whyC > >>Robs claims that you will need more SPARC CPU's than Alphas are  > >>BS.i > >> > >>O > >>>When we did the SAP BM that was the latest version, adjust it by 70% and arQ > >>>per CPU measure comes out just about the same, 50 users per cpu on GS, 53 on P > >>>F15k. Then we could have a discussion about the shape of the tail-off curveN > >>>and the effect of the GS with 1001MHz CPUs with bigger caches which couldL > >>>well put the GS back up there on a per CPU basis. I don,t, can't, claimL > >>>parity with the F15k at its top end. What I wanted to show, and I stillI > >>>believe that I did, was that the GS series are not the total failureiP > >>>technically that Andrew claims. The only competitor I really worry about isH > >>>IBM with their p690 - anything else can be beaten - even with a GS. > >>>o > >>>e > >>  B > >>But sadly none of the none SPECint/SPECfp results show this as? > >>I have illustrated. There are no performance numbers of thesF > >>type you seem to prefer which show the GS320/160 to be competitiveD > >>against, Sun, HP or IBM, you should be afraid of all of them and > >>not just IBM.) > >>? > >>And this is not just a criticism that can be applied to thea; > >>GS series, the Turbolasers suffered in exactly the samel: > >>way. Great SPECint and SPECfp numbers below average on: > >>the kind of apps benchmarks that you appear to prefer. > >>; > >>In both the Turbolaser and WildFires there were obvious 8 > >>inadeqacies in the system design. The TurboLaser had8 > >>a relatively slow and long latency interconnect when= > >>compared with other competing systems and having to trade29 > >>CPU's/Memory and I/O in configs ment that most of theu< > >>claims made by Digital for the boxes would have required= > >>two 8400 backplanes to be bolted together to be realised.  > >>8 > >>The WildFire problems have been discussed at length. > >>= > >>Of course on the plus side being bought by HP removes oneM > >>of the competitors to fear.  > >> > >>L > >>>As to TPC-H - TPC counsel against comparing differing database sizes. IJ > >>>can't remember the date of the GS 300GB benchmark, and I think it gotM > >>>withdrawn. It's yet another benchmark where it would be nice to have thetO > >>>same benchmark on the same day and from current price lists - but it ain't  > >>>going to happen.r > >>>e > >>>a8 > >>They do, but there is in practice a good correlation; > >>between say 300 GB and 1 TB results for the same system ; > >>and this makes it a fairly safe bet to compare 300 with  > >>1000 GB results. > >> > >>Regardsr > >>Andrew Harrisonu > >> > > F > > of course all of this means nothing when EV7 is in the picture ...@ > > then Andrew, you and IBM and all the rest get blown away ... > >  >  > 9 > So you don't dispute the claim that neither the 8400 orD9 > the WildFire can deliver on the performance claims madel > for them by Compaq/Digital.c > 8 > You and Rob seem to be birds of a feather, don't worry9 > about the current boxes not being competitive just waitv7 > for the next box. This has been Rob's refrain since Is7 > started posting to this group, it appears to be yours 
 > as well. > 	 > Regardsh > Andrew Harrisono  C we didn't say that ... current boxes are very competitve and futureu one will have no competition!T   ------------------------------  # Date: Mon, 10 Jun 2002 18:32:47 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Open Letter to HPB Message-ID: <jh6N8.175829$%y.17283803@bin4.nnrp.aus1.giganews.com>  # "Andrew Harrison SUNUK Consultancy"f> <andrew_nospam.harrison_remove_this@sun#.com> wrote in message* news:ae2gbt$lp8$1@new-usenet.uk.sun.com... >- >- > Rob Young wrote:   ...1  E > > Let's see... We know or gather McKinley is about 1300 Specfp2000,cF > > leaving IA64 and Power architectures to fight it out in HPC space.  L Not so clear, given the popularity of large clusters of ES45s in that space.J To the degree that HPC is embarrassingly parallel, Hammer may well provideB considerably more bang for the buck than Itanic (and possibly evenI comparable FP bang per processor, especially considering that each of its.G 8-processor sub-components will have significant internal advantages in9; memory latency/throughput and MP coordination over Itanic).i   > >o >  >n; > How interesting, now remind me how big is the HPC market.d >s7 > The market IA-64 needs to suceed in isn't HPC its thed9 > commecial server market which is dominated by apps that  > are integer based. > 7 > Even at 1.5x the performance of the Itanium would put.: > Itanium 2 at the back of the pack on integer performance > if measured by SPECint.n  I The recent Intel numbers divulged at tecchannel (?) suggest closer to 2x.CH Then again, Merced never lived up to the numbers Intel claimed for it asI recently as this year (0.5 SPECint2K/MHz).  Sounds as if we'll know in ate most a month now.   K MP coordination in medium-sized configurations may be at least as importantgJ to commercial server performance as SPECint2K (after all, HP, Sun, and SGII have held their own in delivered server performance using processors witheL trailing SPECint but building boxes that made better use of what performanceH was available than, e.g., the GS series made of Alpha's).  So it will beL interesting to see how Itanic (and USIII) boxes stack up against the on-chip' MP support in POWER, Hammer, and Alpha.r   ...o  K > > We would be naive to believe Intel with Alpha engineering to supplementQI > > their design staffs won't make IA64 very competitive in the integer /33 > > commercial space.  It is only a matter of time.3  J LOL.  It was 'only a matter of time' that changed Merced from the platformJ that was going to take over the world to being a complete and embarrassingD dud.  And 'only a matter of time' that caused Alpha to fall from itsC performance pinnacle to just being a leader - and then into demise.    > >v >o > 6 > Why ? IA-64 represents an approach to delivering CPU6 > performance that not everyone agrees is a good idea. > = > If the fundamentals of ILP are flawed for real applications.6 > then there will be nothing that Alpha engineers will > be able to do to help.  K More importantly, there is nothing significant that the Alpha engineers canAI do before 2005, when EV7-style on-chip memory and MP glue could appear in K Chivano.  By 2006-7 they could produce a completely new Itanic core free ofVL all constraints (e.g., EPIC could go into the trashcan) except the inheritedI instruction set (and while this might be a bit constraining, what Intel's J engineers have been able to do with the x86 ISA should be an inspiration).  I But there's some real question (largely due to the 'memory wall') whethernI per-processor performance will be as important in the second half of this-H decade as it is today (where it can still significantly reduce the totalK number of processors required for a given load and hence the complexity andwI cost of the server handling it).  If Itanic can survive *until* then, its,H performance may not be enough of an issue in 2006 to justify the cost ofL developing a replacement:  its inferiority over the next 3 - 4 years will be its biggest problem.   >e; > And thats before you realise that the engineers you referm9 > to have not been very sucessfull at doing what you hopes) > they will do for IA-64 on Alpha itself.r  K The engineers Rob is referring to have an exemplary record of doing exactlyoK that.  It's the server group (not the chip group) that has come up short in.' larger-than-4-processor configurations.    >r8 > Its probably unfair to place the blame at the doors of5 > the Alpha engineers themselves, nice processor sameo2 > about the system but the fact is that Alpha does5 > not deliver on the claims made for it in this spacew > and hasn't for a long time.r  F Actually, it has delivered quite respectably in the 4-processor server space.   - bill   ------------------------------    Date: 10 Jun 2002 13:48:00 -0600+ From: young_r@encompasserve.org (Rob Young)  Subject: Re: Open Letter to HP3 Message-ID: <wFQ0ikfKJHQK@eisner.encompasserve.org>i  o In article <jh6N8.175829$%y.17283803@bin4.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes:n   >>< >> And thats before you realise that the engineers you refer: >> to have not been very sucessfull at doing what you hope* >> they will do for IA-64 on Alpha itself. > M > The engineers Rob is referring to have an exemplary record of doing exactlytM > that.  It's the server group (not the chip group) that has come up short int) > larger-than-4-processor configurations.m >  >>9 >> Its probably unfair to place the blame at the doors ofl6 >> the Alpha engineers themselves, nice processor same3 >> about the system but the fact is that Alpha doest6 >> not deliver on the claims made for it in this space >> and hasn't for a long time. > H > Actually, it has delivered quite respectably in the 4-processor server > space. >   4 	And if slide 31 is any indication of things to come 	(linear scaling of STREAM),  < http://www.eecs.umich.edu/vlsi_seminar/f01/slides/bannon.pdf  B 	Alpha and IA64 follow-ons will scale quite well beyond 8, 16, 32  	processors.   	It comes down to 3 things:K  
 		1)  Latencye 		2)  Bandwidthx' 		3)  Keeping the functional units busy'  B 	In 2-4 years, maybe the only question mark will be 3) and at that@ 	there are probably more than a few tricks the folks will use to? 	make up for a poor ISA (VLIW) in IA64.  With on-chip switches,-) 	leadership in 1 and 2 should be a given.8   				Robm   ------------------------------  % Date: Mon, 10 Jun 2002 15:40:18 -0400w' From: "Main, Kerry" <Kerry.Main@hp.com>D Subject: RE: Open Letter to HPT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF402660760@kaoexc01.americas.cpqcorp.net>   Andrew, Andrew ...=201  8 >>> So where will you be if IA-64 doesn't deliver ???<<<   Lets turn the question around -M  H "Where will Sun be if the volumes and performance for future SPARC based# Solaris solutions doesn't deliver?"o  7 Come on now, you can deliver better fud than that ..=20e   :-)p  F >>> We are talking about a long term future, in case you hadn't worked it out yet. :):):):)<<<i  H Mmm... I guess you have different Customers than I do - most of mine areG not looking beyond 8-10 years right now. Course, in 8-10 years, most of F them feel that is enough time to move their OpenVMS based applicationsE to another HW platform (IA64-3 or IA64-4) since OpenVMS is OpenVMS ..e, And mixed clusters are supported ... Right ?    F >>> As ever its a pleasure to converse with someone of your analytical
 abilities.<<<   9 Now, now .. Lets keep the sarcasm to a minimum shall we ?    :-)    Regards,  
 Kerry Main Senior Consultant  Hewlett-Packard Canada! Consulting & Integration Servicesi Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancy 7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20a Sent: June 10, 2002 12:43 PM To: Info-VAX@Mvb.Saic.Com  Subject: Re: Open Letter to HP         Main, Kerry wrote:  	 > Andrew,t >=20 >=20B >>>>Any problems in the IA-64 and the whole program catches a cold >>>> > leaving printing.<<< >=200 > ROTFL .. Talk about "those in glass houses .." >=20H > Lets re-type that sentence and see how the same statement works for=20 > Sun .t >=20H > "Any problems in SPARC futures and the whole Solaris program catches a  " > freezing cold leaving ..nothing" >=20    1 So where will you be if IA-64 doesn't deliver ???h  3 All you need is MS to drag their feet and the dreamn is over.  = No HP-PA, no Alpha. No platform for HP-UX, Tandem or OpenVMS.t  C Just lots of 32 bit 1-2 CPU boxes and possibly a very hasty jump toM Hammer.r  ; As you said glass houses, you never seem able to detect thet one you are in..       >=20G >>>>Its called the IA-64 one trick pony, running Win2000 at the low enda >>>> > and HP-UX at the high end.<<<  >=20G > Actually, your statement is incorrect - imho, the actual statement=20  > should read: >=20 >=20H >>>>HP will be offering IA-64 platforms running Win2000 and Linux at the >>>>H > low-med range and OpenVMS, NSK and HP-UX at the medium-high end. It=20J > will also offer OpenVMS, Tru64 and Linux on newer Alpha EV7 platforms=20# > that are soon to be released. <<<m >=20    E We are talking about a long term future, in case you hadn't worked it- out yet. :):):):)-    7 As ever its a pleasure to converse with someone of youra   analytical abilities.<   Regards  Andrew Harrison-   =20-   ------------------------------  % Date: Mon, 10 Jun 2002 16:42:42 -0400b- From: JF Mezei <jfmezei.spamnot@videotron.ca>e Subject: Re: Open Letter to HP, Message-ID: <3D050F41.E9CFB581@videotron.ca>   "Main, Kerry" wrote:H > "Any problems in SPARC futures and the whole Solaris program catches a" > freezing cold leaving ..nothing"  M There is a difference. Sparc is a known entity with a proven track record. ItoL has never been seen as the fastest chip in the world nor does it make claims to that effect.h  N Intel made arrangements to have Alpha killed because it wants its IA64 to takeL its place. In the past, there was significant performance difference betweenM Alpha and Sparc (at the chip level at least). But replace Alpha with IA64 and $ Sparc doesn't seem that much slower.  K And replace Alpha with IA64 and HP no longer has the chip that gives it thecK performance edge. If HP really wanted to go commodity, it should have asked2N Intel to develop a 64 bit 8086 with features such as lockstep that would allow< it to run serious operating systems as well as windows toys.   ------------------------------  % Date: Mon, 10 Jun 2002 17:27:55 -0400d' From: "Main, Kerry" <Kerry.Main@hp.com>f Subject: RE: Open Letter to HPT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF402660763@kaoexc01.americas.cpqcorp.net>   JF -  F >>> There is a difference. Sparc is a known entity with a proven track
 record.<<<  A In the past - absolutely.  What about the future? Can it meet the H volumes required to keep SPARC competitive? What about Linux futures and its impact on Solaris/SPARC?  F Anyway, I do not doubt Solaris/SPARC will be a player at some level inE the future, but the point is that you can not base future predictions./ based soley on what has gone on in the past.=20   D And whether you like or hate Intel, you have to give them credit for/ being pretty good at marketing - as an example: 5 http://news.com.com/2100-1001-934033.html?tag=3Dcd_mhm, "Dell picks Intel over IBM in server design"  H >>> And replace Alpha with IA64 and HP no longer has the chip that gives it the performance edge.<<<.  > Imho - You are basing this statement on current IA64-1 systemsD performance. The OpenVMS initial release will be on IA64-3 or IA64-4H systems (or whatever the official naming standard is going to be ..). AnE analogy to Alpha would be that OpenVMS on IPF is being developed on aoA EV4 class system with the expectation that its initial production , shipment will be on an EV68 class system.=20  H In the meantime, current Customers will be able to continue to use AlphaG EV7 or EV79 based systems as alternatives if they feel the IA64 serversoD available at the time when OpenVMS is initially released do not meet their expectations.z  > At the same time, mixed clusters are going to be supported andF translator utilities are being made available, so Customers transition' will be easier and at their own pace...      Regards,  
 Kerry Main Senior Consultanto Hewlett-Packard Canada! Consulting & Integration Servicesn Voice: 613-592-4660, Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20n Sent: June 10, 2002 4:43 PM  To: Info-VAX@Mvb.Saic.Coma Subject: Re: Open Letter to HP     "Main, Kerry" wrote:H > "Any problems in SPARC futures and the whole Solaris program catches a  " > freezing cold leaving ..nothing"  B There is a difference. Sparc is a known entity with a proven trackH record. It has never been seen as the fastest chip in the world nor does it make claims to that effect.  F Intel made arrangements to have Alpha killed because it wants its IA64A to take its place. In the past, there was significant performance D difference between Alpha and Sparc (at the chip level at least). But@ replace Alpha with IA64 and Sparc doesn't seem that much slower.  G And replace Alpha with IA64 and HP no longer has the chip that gives it0D the performance edge. If HP really wanted to go commodity, it shouldH have asked Intel to develop a 64 bit 8086 with features such as lockstepG that would allow it to run serious operating systems as well as windows  toys.e   ------------------------------  % Date: Mon, 10 Jun 2002 18:29:24 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Open Letter to HP, Message-ID: <3D05283A.1026AF57@videotron.ca>   "Main, Kerry" wrote:C > In the past - absolutely.  What about the future? Can it meet thehJ > volumes required to keep SPARC competitive? What about Linux futures and > its impact on Solaris/SPARC?  N If Sun maintains higher volumes than HP, then Sun will be in a better positionM to keep Sparc alive than HP will. As long as HP is the only big user of IA64,tM it gives HP no advantage since that chip will be de-facto just as proprietaryh as Alpha, Sparc etc.  M The error Carly and Curly made is in betting IA64 would be industry standard.>  H > Anyway, I do not doubt Solaris/SPARC will be a player at some level inG > the future, but the point is that you can not base future predictions . > based soley on what has gone on in the past.  N But having a track record and established market is a better indication of the> future than some unknown entity with an unproved track record.  N This is why both Alpha and Sparc had a less cloudy future than IA64. Alpha hadK about 8 years of track record and a certain degree of certainty of what they& engineers would be able to do with it.  I IA64 is an unknown entity, unquantifiable future because there is no past>N track record, and worse, it has a different EPIC philosophy so there is no wayL to really know if that gamble will work or not and iof it works, how it willH work and if HP/INTEL will be able to make EPIC move as fast as the 8086,
 Sparc, Power.   N If IA64's advances are slower than that of the 8086, Sparc and Power, then theL performance gap will widen and IA64 won't catch up. It is one thing to claimN that IA64 will move ahead a lot, but once has to remember that the other chipsJ will too, and the important thing to look at is how fast each chip will be( able to progress compared to the others.    @ > Imho - You are basing this statement on current IA64-1 systemsF > performance. The OpenVMS initial release will be on IA64-3 or IA64-4
 > systems   J Since IA64 and EPIC have no previous track records, then how should one beM able to predict whether Intel will be able to achieve the promised results or. not ?     J > In the meantime, current Customers will be able to continue to use AlphaI > EV7 or EV79 based systems as alternatives if they feel the IA64 serverstF > available at the time when OpenVMS is initially released do not meet > their expectations.o  L In the same vein, current alpha customers will start right away to implementK longer term plans to move away from alpha, and right now, such plans cannot.3 include IA64 because IA64 is still slow vapourware.   K So when/if IA64 does become attractive, customers may have already begun toiG move to a different platform.  Combine with HP's apparent policy of not4? marketing VMS and not trying to grow it, prefering to just keepOJ maintaining/supporting it for exsiting customers and the message is prettyK clear that VMS is not a platform whose portfolio of applications will grow,o2 hence not a good platform to continue to build on.  L IA-64 for HP-UX is a different proposition because there are no doubts aboutF HP's commitment to HP-UX so it is just a single whammy of moving to an4 uncertain chip. But for VMS, it is a tripple whammy: 	-the bad past of VMSe 	-the uncertain future of IA64' 	-the uncertain future of VMS within HP    ------------------------------  % Date: Tue, 11 Jun 2002 00:52:04 +0200m From: Dirk Munk <munk@home.nl> Subject: Re: Open Letter to HP& Message-ID: <3D052D94.6010603@home.nl>   > @ > Imho - You are basing this statement on current IA64-1 systemsF > performance. The OpenVMS initial release will be on IA64-3 or IA64-4H > systems (or whatever the official naming standard is going to be ..).   7 IA64-2 isn't very convincing either as we've just read.d  J > An analogy to Alpha would be that OpenVMS on IPF is being developed on aC > EV4 class system with the expectation that its initial production , > shipment will be on an EV68 class system.   J With the exception that IA64 development has taken many years now without P producing anything that gives us hope for a fast high class processor. That EV4 P class system should have been a EV68 by now, and the IA64-3 should be a kind of P EV8. If the Alpha team is going to give Intel the possibilities to produce such P a good IA64 processor (if (!) that is possible), then why didn't Intel stick to Q the Alpha in the first place? It is a superior design according to many experts, dP there is a superior Unix for it (Tru64), there is Windooz for it (Windooz 2000, P not for sale but it's is there), and there is even a real operating system  for @ it (guess what that is :-) ). It is proven technology and so on.   > J > In the meantime, current Customers will be able to continue to use AlphaI > EV7 or EV79 based systems as alternatives if they feel the IA64 serversiF > available at the time when OpenVMS is initially released do not meet > their expectations.   J And then what ? Does the NewHP have a plan-B scenario ? If so what is it ?G The problem is we see a IA64 processor that does not live up by far to tM expectations after years of development. And the NewHP tells us we must have aL faith in the abilities of the Alpha team to make something good out of this Q piece of overexpensive and slow silicon (or should we call it a sillycon chip ?).a  P You really can't blame us for being sceptical and VERY WORRIED !! The Alpha has P always been on time more or less, except for the last couple of years. When the P first 150 Mhz Alpha was announced, they told us there would be a 1 GHz Alpha in Q the year 2000. That was in the days 60 MHz Pentiums exploded. And we had a 1 GHz  Q   Alpha in 2000. Not for sale, but it was there. Some people have even uttered a yM conspiracy theory that Alpha development was slowed down to minimize the gap IP between Alpha and Intel. The IA64 on the other hand has never been on schedule, 5 (far from it) and has not shown us anything hopefull.   M Every now and then you read about sects that believe the end of the world is oL coming, or that creatures from another solar system will come for them. The O people from such a sect will gather and wait for the event to happen. It never  M does of course. Somehow I feel the same, now I'm waiting for a good IA64 ....e   ------------------------------  % Date: Mon, 10 Jun 2002 20:54:36 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>, Subject: Re: Open Letter to HP, Message-ID: <3D054A4B.E5476CF4@videotron.ca>   Dirk Munk wrote:L > And then what ? Does the NewHP have a plan-B scenario ? If so what is it ?  L Windows will eviscerate Unix. Remember ? So if IA64 flops, folks like Carly,M Curly and Winkler will simply roll out even more Wintel solutions on the 8086h4 while HP-UX and Tandem languish , stuck in IA64-mud.  K Tandem has never been a big sucker for high performance. It doesn't do manypL transactions per second, but it does them well. So as long as IA64 is faster8 than MIPS, then Tandem customers won't have to complain.  I Now, will IA64 be faster than PA-RISC could have been ? If so, then HP-UXtK customers won't have to complain. The ones who will complain are those thatn) were Alpha based for performance reasons.r  H > The problem is we see a IA64 processor that does not live up by far to* > expectations after years of development.  K No, the problem is that every VMS sale that is delayed by years due to IA64bL being delayed, is going to make VMS look bad on the books due to poor sales.K Such news will make ISVs rethink their VMS products and that will also sloweJ down sales of VMS. A tailspin is a real danger, especially with folks like) Stallrd spewing out Palmeresque rethoric.f  J Now, if HP were to come out and admit that the Alpha murder, combined withN lack of marketing, uncertainty about IA64 would cause of few years of very badG numbers for VMS but that HP was committed to it because as soon as IA64 K becomes marketable, HP commit to rebuild VMS and market it big time, then Io would be far more confortable.  P But for as long as HP puts VMS on auto-pilot and ignores it, the danger is real.   ------------------------------  # Date: Tue, 11 Jun 2002 01:58:01 GMTt* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Open Letter to HPB Message-ID: <JOcN8.177102$%y.17590926@bin4.nnrp.aus1.giganews.com>  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF402660763@kaoexc01.americas.cpqcorp.net. ..   .../  D And whether you like or hate Intel, you have to give them credit for/ being pretty good at marketing - as an example: 3 http://news.com.com/2100-1001-934033.html?tag=cd_mh , "Dell picks Intel over IBM in server design"   *** G I'm afraid that article cuts against Itanic, though:  Dell got Intel toeE extend one of its Itanic-2 support chip-sets to support Xeon as well,fI because the servers Dell wants to sell are Xeon servers, not Itanic-2s...d ***o  H >>> And replace Alpha with IA64 and HP no longer has the chip that gives it the performance edge.<<<   > Imho - You are basing this statement on current IA64-1 systemsD performance. The OpenVMS initial release will be on IA64-3 or IA64-4H systems (or whatever the official naming standard is going to be ..). AnE analogy to Alpha would be that OpenVMS on IPF is being developed on a A EV4 class system with the expectation that its initial productionC) shipment will be on an EV68 class system.o   ***eK Not even EV67-class.  McKinley will likely be a bit less than twice as fastlI as Merced, and Montecito at introduction is unlikely to be much more than)J twice as fast as McKinley, for a total performance increase over Merced ofJ about 4x in 3 years (*including* clock-rate advances).  While I don't haveI the numbers at hand, that sounds more like the difference between EV4 ands EV56.o   - bill   ------------------------------    Date: 10 Jun 2002 20:56:02 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)  Subject: Re: Open Letter to HP< Message-ID: <cf15391e.0206101956.bcd41cf@posting.google.com>  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3D05283A.1026AF57@videotron.ca>...- > "Main, Kerry" wrote:E > > In the past - absolutely.  What about the future? Can it meet the L > > volumes required to keep SPARC competitive? What about Linux futures and  > > its impact on Solaris/SPARC? > P > If Sun maintains higher volumes than HP, then Sun will be in a better position# > to keep Sparc alive than HP will.e  D HP today already has higher Unix marketshare (and thus volumes) than Sun.  D I noticed an editorial in the latest issue of VAR Business Magazine,A entitled "It's Time for You to Get Out of the Sun Market."  A few" samples:  E "For the resellers and integrators of Sun products, filing Chapter 11 F or shuttering operations is becoming a way of life.  Many Sun VARs areB living on the edge of financial ruin or being propped up by one ofC Sun's two distribution partners.  That's Sun's dirty little secret,t say its partners."  F One major Sun VAR's business has dropped to one quarter of what it had been.e  D "If you sell Sun today, you should be looking to make investments in< other technologies or shift to other platforms immediately."  D "The solution is selling something besides the Sun brand -- like IBM8 or HP Unix offerings, or an Intel-server running Linux."  ( Looks to me like Sun's in major trouble.: ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------   Date: 10 Jun 2002 20:06:00 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)) Subject: Re: OpenVMS FAQ due next week...4* Message-ID: <ae30r8$7iu$3@web1.cup.hp.com>  w In article <01KIJBL0W0BM984WQP@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes: E :>  To various questions which arose in this thread, in no particulary
 :>  order... c :aH :Perhaps the FAQ could go onto the VMS documentation CD as well?  There H :ARE folks interested in getting going with VMS who might want to avoid . :relying on another system for IP access etc.   F   The version of the OpenVMS FAQ that is contemporary with the releaseB   is expected to ship as part of the OpenVMS Alpha V7.3-2 release.  D   An older copy of the FAQ presently ships on the Freeware V5.0 kit;<   on disks which are part of all existing OpenVMS shipments.  eB :                                             Also, cut-and-paste F :between DECterms is nice, which would be possible if the FAQ could beC :addressed locally on a system so that it is available for internetf :access is.   H   That capability has been available for many years -- the text version E   of the FAQ was the master copy and was the source of the HTML files E   for all releases prior to the current release of the FAQ, and this cH   text file can be readily downloaded -- and all current and all future >   editions of the FAQ continue to be available in text format.  F   With a copy of the FAQ on the OpenVMS distribution or Freeware, you =   then also won't need to download the FAQ from the Internet.   E   Specifically for ease of downloading, I've provided a zip file withR0   all of the available file formats for the FAQ.  C   It is not feasible for me to get the new FAQ onto the V7.3-1 kit, 6   and I'm not updating the Freeware as part of V7.3-1.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 10 Jun 2002 19:35:19 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)tP Subject: Re: OpenVMS, Volume Desktop OS (Re: Mark Gorham's Beer Bash in Reading), Message-ID: <ae2v1n$14br$1@info.cs.uofs.edu>  + In article <adrcmo0dsr@enews3.newsguy.com>, 5  "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:t |>M |> A few years ago I was playing around with some network monitoring softwareeO |> (publically available software for Linux) on my home network.  I was rather oP |> shocked to find that I could basically point it at one packet, and from then Q |> on I could see anything that was typed/displayed in a specific Telnet session.  |> lJ |> So, yes, it really is that dangerous.  Unfortunatly a lot of people are> |> still forced to use Telnet.  IIRC, another problem is POP3.  E A few years ago everything was done on hubs and coax and thus was allaG broadcast media.  Today, even home systems can not be monitored to thateF leverl.  I once saw a demo of how easy it was to non-intrusively tap a1 fiber optic cable.  But even that was detectable.a  E There is no doubt that monitoring is possible, but I personally don'tnG think the rest of the world even knows I exist, much less that they areeF trying to monitor what I do on the various networks I use.  Paranoia??   bill   -- 3J 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>       ------------------------------   Date: 10 Jun 2002 19:44:22 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)vP Subject: Re: OpenVMS, Volume Desktop OS (Re: Mark Gorham's Beer Bash in Reading), Message-ID: <ae2vim$14br$2@info.cs.uofs.edu>  , In article <3D015A9C.2A89BBAF@videotron.ca>,0  JF Mezei <jfmezei.spamnot@videotron.ca> writes: |> "Zane H. Healy" wrote:tO |> > A few years ago I was playing around with some network monitoring softwareiP |> > (publically available software for Linux) on my home network.  I was ratherQ |> > shocked to find that I could basically point it at one packet, and from thennS |> > on I could see anything that was typed/displayed in a specific Telnet session.  |>  P |> But on a LAN when you can run such traces, you have access to a hell of a lot |> more than telnet data.l |>  L |> My question pertains to the internet itself. What are the odds of someoneM |> monitoring your telnet packets between your LAN and the destination LAN ? e |> pP |> Also, assume you manage the network backbone. You have access to all the dataN |> that transits in the backbone. But when you telnet to the router that feedsO |> one departmental lan, someone with an ethermon on that LAN will not see yourtQ |> telnet session to the router and hence won't be able to capture the management K |> passord for the router. But if you do this from a de]artmental lan, thenhI |> anyone on that lan will be able to ethermon you and see what you type.v  F Not unless they are using old equipment (hubs rather than switches) orE have deliberately engineered the lack of security into their network.i  D I have switches and even lock down the ports to prevent someone fromA plugging in a box that I do not have administrative control over. B Wireless is still a problem, but even it can be secured to a large extent.    |> aJ |> Are ISPs and internet backbine networks really so untrustworthy that an: |> average telnet session is considered such a high risk ?  ? Counting packets going in and out of my departments lan I can'tI? imagine any ISP paying for a box capable of actually extractingeA usable information from its customers traffic.  After all, we all ( know what 98% of that traffic really is.   bill   -- eJ 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>   t   ------------------------------   Date: 10 JUN 2002 22:15:28 GMT2 From: karcher@kort.waisman.wisc.edu (Carl Karcher)P Subject: Re: OpenVMS, Volume Desktop OS (Re: Mark Gorham's Beer Bash in Reading)4 Message-ID: <10JUN02.22152804@kort.waisman.wisc.edu>  I In a previous article, bill@triangle.cs.uofs.edu (Bill Gunshannon) wrote:w  H ->Not unless they are using old equipment (hubs rather than switches) orG ->have deliberately engineered the lack of security into their network.i -> ...  E Having a switched network doesn't mean traffic can't be sniffed. It'sn just not as easy:c  G See: <http://www.sans.org/newlook/resources/IDFAQ/switched_network.htm>    --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madisone; --                      karcher.dontspam@waisman.wisc.edu      ------------------------------  # Date: Tue, 11 Jun 2002 02:59:16 GMTe, From: "R. Srinivasan" <r.srinivasan@cox.net> Subject: rcp setup8 Message-ID: <8IdN8.55864$092.2283048@news1.east.cox.net>   folks,  K Attempting to setup rsh/rcp (the "r" family) to execute on an Alpha VMS 6.2wL UCX 4.1 system from Win NT/Win 2K systems. Cannot even get them working from one VMS box to another.m  3 RSCBCK.Level2-> rcp rscpri:0def.com rscbck:0def.come  < %RSH-E-FAILED, INTERnet ACP AUXS failure Status = %RMS-E-DNF  
 (from remote)M  ( It is not clear what this message means.  E Can someone offer some help -- perhaps a pointer to some step by stepe
 instructions.a      $ Any help would be deeply appreciated       regardss       srini    ------------------------------  % Date: Tue, 11 Jun 2002 07:41:41 +0100d, From: "Rainer Giese" <waste.not@welcome.net> Subject: Re: rcp setup5 Message-ID: <ae42il$3pff9$1@ID-138444.news.dfncis.de>n  = "R. Srinivasan" <r.srinivasan@cox.net> schrieb im Newsbeitrag 2 news:8IdN8.55864$092.2283048@news1.east.cox.net... >e> > %RSH-E-FAILED, INTERnet ACP AUXS failure Status = %RMS-E-DNF >   ) Look at : HELP /MESSAGE /FACILITY=RMS DNF J It explains, that there is a directory-not-found-error. For the r-servicesI you have corresponding TCPIP$-usernames in your UAF. Check, if there homen directories exist correctly.   -- Regards, Rainer Giese   ------------------------------    Date: 10 Jun 2002 19:21:48 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)r# Subject: Re: Shadow sets efficiencyd= Message-ID: <cf15391e.0206101821.235eba4a@posting.google.com>n  | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KINN07NZXA96WQWC@sysdev.deutsche-boerse.com>...K > > Instead, it does a read, a compare, and if the comparison fails, writeshJ > > to the target disk and then loops around and does the read and compare" > > again, until it gets a match.  > ? > Is the loop just for error detection or also to allow for the C > possibility that the source disk got written to there during this . > operation---or is that handled differently?   B It's to allow for the possibility of another simultaneous writer. F It's rare that the second comparison would fail, but it is possible inD practice.  On a shadowed system disk, for example, a failed VMS nodeD could be in the process of writing a crash dump, and forced to do so? without any chance of coordination via the VMS Distributed Lock  Manager.  G > > So on a disk with different data, that implies a read, a compare, aVB > > write, and another read and a compare for each segment of dataH > > (presently Shadowing deals with 127-block segments).  If the data isK > > identical, only the read and compare are needed (with just a few of theaK > > more-complex operations in the few areas where the data might differ). t > K > Using BACKUP/PHYSICAL would imply read and write (during the backup) and sC > a read and compare during the shadow copy.  So the difference is s? > essentially just a compare.  Is this significant?  Or is the oD > BACKUP/PHYSICAL faster with reads and writes than the shadow copy?  C Shadowing is careful not to do double-buffering or other techniques ) which Backup could freely do if it wants.o  = In any case, my empirical data shows that the BACKUP/PHYSICAL @ (followed by clobbering the SCB) and then performing a Full CopyD afterward is faster in elapsed time than just starting the Full Copy with differing data.  I > > an $INITIALIZE, which writes a minimal file system but leaves most ofpD > > the data untouched (but don't do INITIALIZE/ERASE or you'll have3 > > undone all the benefit of the BACKUP/PHYSICAL).  > G > What does INITIALIZE/ERASE actually do?  HELP seems to imply that it oB > sets a flag so that DELETE/ERASE becomes the default instead of J > DELETE/NOERASE: "In effect, each file on the volume is erased when it isG > deleted".  This sounds like nothing is deleted during the INITIALIZE n5 > itself.  Is this correct, or is the HELP confusing?n  F Looks like the writer was indeed a bit confused here (I'm looking at aE 7.2 version).  But looking carefully at the Help, one can deduce that@F with the /ERASE qualifier, VMS does a Data Security Erase operation onE the entire volume as it intializes it.  It also sets the ERASE volumewD attribute so that Erase-on-Delete will be in effect (which you couldC turn off with SET VOLUME/NOERASE_ON_DELETE, of course).  But it wasiA writing the DSE pattern to all blocks which I was referring to as 5 undoing the beneficial effect of the BACKUP/PHYSICAL. : ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------    Date: 10 Jun 2002 21:33:39 -0700 From: wingwong@witty.com (wing)l, Subject: strange double comparison behaviour= Message-ID: <873e96d6.0206102033.762d29e5@posting.google.com>s   Hi,l  F The following program fails to compare double values 1.9.  All doublesD a, b, c, are expected to be 1.9.  With printf, a, b, d are 1.9 but dC give 0.  Moreover, (a==b) gives false result, (fails to check 1.9 =t 1.9).r  8 Moreover, the output in openvms and pc are not the same.  ( --- output of the program in openvms ---
 a:    1.90000 
 b:    1.90000w
 c:    1.90000s
 d:    0.00000V ooops, 1.9 != 1.9  ooops, 1.9 != 1.9  ooops, 1.9 != 1.9   # --- output of the program in pc ---t
 a:    1.90000t
 b:    1.90000u
 c:    1.90000e
 d:    0.00000, a == b returns trueu ooops, 1.9 != 1.9e ooops, 1.9 != 1.9i   --- the source code ---, #include <stdlib.h>6 #include <stdio.h> #include <string.h>u #include <iostream.h>H #include <math.h>i  ' int my_atoi(const char* src, int len) {b*   // Make a null-terminated version of src!   char* buf=(char*)malloc(len+1);    strncpy(buf,src,len);s      buf[len] = NULL; u  p   int i=atoi(buf);
   delete buf;r   return i;- }-  < double my_atof(const char* src, int len, int decimalPoint) {   if (decimalPoint<=0)%     return (double)my_atoi(src, len);t  -   int intPart=my_atoi(src, len-decimalPoint);i:   int decPart=my_atoi(src+len-decimalPoint, decimalPoint);      double value=decPart;5$   for (int i=0;i<decimalPoint;i++) {     value=value/10;c   }e   return (double)intPart+value;  }e   int main(){   "    char* src          = "0000190";    int   len          = 7;    int   decimalPoint = 2;      char* src2         = "1.9";  .    double a = my_atof(src, len, decimalPoint);    double b = atof(src2);a1    double c = atof(src) * pow(10, -decimalPoint);t    double d = 0;D    sscanf(   src, "%*.*lf", (len - decimalPoint), decimalPoint, &d);      printf("a: %10.5lf\n", a);e    printf("b: %10.5lf\n", b);d    printf("c: %10.5lf\n", c);     printf("d: %10.5lf\n", d);t      if ( a == b)     {$       cout << "a == b returns true "            << endl;e    }else    {"       cout << "ooops, 1.9 != 1.9 "            << endl;l    }    if ( b == c)4    {$       cout << "b == c returns true "            << endl;e    }else    {"       cout << "ooops, 1.9 != 1.9 "            << endl;d    }    if ( b == d)m    {$       cout << "b == d returns true "            << endl;     }else    {"       cout << "ooops, 1.9 != 1.9 "            << endl;     } }     Thanks in advance for any ideas.   Wing   ------------------------------  % Date: Tue, 11 Jun 2002 00:31:48 -0500sC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com> 0 Subject: Re: strange double comparison behaviourH Message-ID: <craig.berry-D643A7.00314711062002@news.directvinternet.com>  = In article <873e96d6.0206102033.762d29e5@posting.google.com>,-!  wingwong@witty.com (wing) wrote:2  H > The following program fails to compare double values 1.9.  All doublesF > a, b, c, are expected to be 1.9.  With printf, a, b, d are 1.9 but d
 > give 0.   G I'm no expert in conversion specs, but yours seems to expect a decimal 75 point even though your src variable doesn't have one.p  < > Moreover, (a==b) gives false result, (fails to check 1.9 = > 1.9).e  G You do enough manipulations in my_atof that you could easily be losing aF the last digit of precision.  For your own curiosity, you may want to E print out everything, not just 6 significant digits, in order to see eE where a and b are different.  However, comparing the contents of two nC unrounded floating point variables that have undergone a differing MF number and type of floating point operations and expecting them to be A identical is an unreasonable expectation.  Is there a particular s! problem caused by the difference?   = If you post again, it would be helpful to know the following:o   OpenVMS versionc architecture (VAX, Alpha)p: double precision format in use (D_FLOAT, G_FLOAT, T_FLOAT) C++ versione   ------------------------------    Date: 10 Jun 2002 15:06:39 -0700- From: zroundtree@oasys.com (Zoltan Roundtree)o" Subject: SYSMAN default parameters= Message-ID: <bf1b7500.0206101406.62d56cc9@posting.google.com>r  B Is it possible to modify the sysman/sysgen parameters? ie> ijoblim   ------------------------------    Date: 10 Jun 2002 15:09:04 -0700- From: zroundtree@oasys.com (Zoltan Roundtree)o, Subject: SYSMAN default parameters - REVISED= Message-ID: <bf1b7500.0206101409.218d4bc6@posting.google.com><  : Is it possible to modify the DEFAULT sysman/sysgen params?   ------------------------------   Date: 10 Jun 2002 21:49 CDTH' From: carl@gerg.tamu.edu (Carl Perkins)e0 Subject: Re: SYSMAN default parameters - REVISED- Message-ID: <10JUN200221490421@gerg.tamu.edu>e  1 zroundtree@oasys.com (Zoltan Roundtree) writes...v; }Is it possible to modify the DEFAULT sysman/sysgen params?h   Why would you want to?  ? Just put modifications in modparams.dat where they belong. Theyt% will be used instead of the defaults.    --- Carl   ------------------------------  # Date: Tue, 11 Jun 2002 01:23:52 GMTo0 From: "Matt Muggeridge" <Matt.Muggeridge@hp.com>- Subject: Re: TCP socket communication queriesh@ Message-ID: <IicN8.286016$o66.737056@news-server.bigpond.net.au>  
 64K per read.    --= -------------------------------------------------------------  OpenVMS TCP/IP Engineering Enterprise Computing Group Hewlett-Packard Company  Gold Coast, AUSTRALIA = -------------------------------------------------------------u    , "wing" <wingwong@witty.com> wrote in message7 news:873e96d6.0206061641.7f070a32@posting.google.com...a	 > Thanks.  > G > Is there any maximum limit of the bytes read in the read(int d, void* 5 > buf, int bytes) in the the socket read call in VMS?e >M > Wing > = > "Matt Muggeridge" <Matt.Muggeridge@hp.com> wrote in messageh< news:<eLBL8.264180$o66.679005@news-server.bigpond.net.au>...F > > > Is there any chance of data loss in socket communication between) > > > processes within a openvms machine?  > >MC > > Depends on the socket type.  Stream (TCP) sockets are reliable,t
 sequenced,F > > and will not duplicate packets.  However record boundaries are notG > > preserved, so at most you will be guaranteed to receive 1-byte at at time, soJ > > you need to reassemble and parse the stream for packets in user-space. OnF > > the other hand, datagram (UDP) sockets will only guarantee messageK > > boundaries are preserved.  Otherwise datagrams may and do get discardedt andeL > > replicated and arrive out of order silently.  Your application must take > > care of that.- > >-F > > Within this context, it makes no difference whether your socket is blocking > > or non-blocking. > >-D > > > Is there any tool to trace the data thro' socket with the same > > > machine? > >u > > $ HELP TCPTRACER > >e	 > > Matt.e > >t > > --A > > -------------------------------------------------------------i > > OpenVMS TCP/IP Engineering > > Enterprise Computing Group > > Hewlett-Packard Companyh > > Gold Coast, AUSTRALIA A > > -------------------------------------------------------------o > >s > >r0 > > "wing" <wingwong@witty.com> wrote in message; > > news:873e96d6.0206051800.67bcda89@posting.google.com... 	 > > > Hi,a > > >n1 > > > I am new in socket programming and openvms.e > > >iK > > > I have written a server process and client process which communicates " > > > with socket with each other. > > >aF > > > Is there any chance of data loss in socket communication between? > > > processes within a openvms machine?  The socket option isx > > > non-blocking.r > > > D > > > Is there any tool to trace the data thro' socket with the same > > > machine? > > > 
 > > > Thanks.  > > >i
 > > > Wing   ------------------------------    Date: 10 Jun 2002 11:38:59 -0700; From: jnchambl@texaschildrenshospital.org (Jesse Chambless) " Subject: Re: VMS Monitoring a User= Message-ID: <d92c63cc.0206101038.70ba0f30@posting.google.com>d  = You might also check into PEEK and SPY from Network Dynamics.l  n P.Young@unsw.EDU.AU (Patrick Young) wrote in message news:<55f85d77.0206090004.5a338006@posting.google.com>...j > spammitplease@yahoo.co.in (Ab) wrote in message news:<9f100812.0206070001.9ffd7ac@posting.google.com>...
 > > Hi AllG > >   We have OpenVMS 6.2 .. want to monitor a user for the commands her
 > > executes.l > J > *Many moons ago* we used a product on VAX called watch. A quick internet > search just now uncovered: > 3 > http://www.advsyscon.com/Products/Watch/Watch.aspa > I > I once set this up in many evil ways, to track many evil students, alsocH > I used it to advise staff during "help desk" (I hate that term) calls, > etc. > H > Seriously though - you need to review who has which privs. and why and  > take a look at your audit log.   ------------------------------   Date: 10 Jun 2002 19:32:04 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)" Subject: Re: VMS Monitoring a User* Message-ID: <ae2urk$7iu$1@web1.cup.hp.com>  c In article <9f100812.0206070001.9ffd7ac@posting.google.com>, spammitplease@yahoo.co.in (Ab) writes:>  D :  We have OpenVMS 6.2 .. want to monitor a user for the commands he
 :executes.D : We have a problem with some privileged user logging in and killingF :other logins (other users logged in are automatically logged out). WeB :want to monitor that user and create logs of the commands that heE :executes with time information. Is there any VMS utility that allowse :us to do this.A  D   The mechanism that prevents this is the "Privilege".  There are noC   "Privileges" that prevent misuse of "Privileges".  If you want tooF   prevent users from killing other jobs or other unsocial behaviours, D   remove GROUP or WORLD and all heavy privileges from the untrusted    users.  C   There is no particular command to monitor user input on OpenVMS, eC   though -- as listed in the OpenVMS FAQ -- tools such as Peek and cG   Spy and other related products are available.  That said, monitoring  E   the commands will likely result in huge volumes of data; you'll seeeG   far more data than you really want to look at -- and if the nefarioustH   operations are calls to $delprc or $forcex embedded within some user'sC   own application image(s), you might not ever see the operation.     F   Better here would be use-of-privileges auditing or $delprc auditing.;   Both are documented parts of the OpenVMS auditing system.m  B   Best approach here would be the SOLVE THE PROBLEM and remove allA   ALL-class privileges from all untrusted users, and to move all m"   of the users into unique UICs.    ?   If you have canny nefarious users, even simple removal of thev@   privileges won't necessarily help -- see the OpenVMS Security @   manual for how to clean up after a successful system security @   breach or break-in, as that situation is effectively what you >   have here.  Bluntly, you unfortunately have a busted system B   security implementation -- untrusted privileged users are, well,B   a serious problem -- and you now want to (need to) clean up the    resulting mess.w  >   Please see the OpenVMS FAQ, and particularly please see the @   OpenVMS Security Manual for additional details on how to clean   up this particular mess.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 10 Jun 2002 19:42:07 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)" Subject: Re: VMS Monitoring a User* Message-ID: <ae2vef$7iu$2@web1.cup.hp.com>  c In article <9f100812.0206070001.9ffd7ac@posting.google.com>, spammitplease@yahoo.co.in (Ab) writes:o  D :  We have OpenVMS 6.2 .. want to monitor a user for the commands he
 :executes.D : We have a problem with some privileged user logging in and killingF :other logins (other users logged in are automatically logged out). WeB :want to monitor that user and create logs of the commands that heE :executes with time information. Is there any VMS utility that allowsn :us to do this.e  C   Unfortunately, you have received various literal answers to your -A   question as replies, and none are particularly reliable -- you iB   will get exactly what you asked for with these replies, the userB   command input (and lots of it) -- but this is probably NOT what A   you really want, and (while it can work) can (will?) result in 8F   your expending a whole lot of effort sifting through the user input.  C   This harks back to the danger of asking a literal question -- it tD   is often best to provide a general problem description and to ask C   for potential solution(s), lest you get a literal answer to your eC   proposed solution question and thus miss one or more potentially  3   better alternative solution(s) to the problem(s).   ?   As mentioned in my other posting, establish a security policy :   and apply it to the OpenVMS system security, and use the?   use-of-privileges or $delprc or similar auditing to track theH?   specific instances of the STOP/ID.  That said, you do need to9?   address and remove privileges from those users who do not and,A   should not have them -- the privilege mechanisms are the basic  A   mechanisms for controlling system access and system operation, ,5   and there is no control over the use of privileges.r  B   Please see the OpenVMS FAQ and the documentation, as referenced    in the other reply.r  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 10 Jun 2002 18:03:04 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>t" Subject: Re: VMS Monitoring a User, Message-ID: <3D052210.D1EC4717@videotron.ca>   Hoff Hoffman wrote:sF >   The mechanism that prevents this is the "Privilege".  There are noE >   "Privileges" that prevent misuse of "Privileges".  If you want towG >   prevent users from killing other jobs or other unsocial behaviours,eE >   remove GROUP or WORLD and all heavy privileges from the untrustedd
 >   users.  N If an employee "was" trusted and granted privileges and you SUSPECT abuse, youK then need to present sufficient proof when you confront the user and removeo? his privileges (either just the VMS ones, or the paycheck one).c    H What if the user is using some utility written by programmers that has aN trojan "joke" in it that scans for process names that match an employee's nameJ and then deletes that process, and that portion is only effective when the% utility runs from a privileged user ?   L In such a case, the action would appear to come from the "trusted user", butL said user would be unaware of what he is actually doing, thinking he is just= running that utility that everyone is running at the company.   I This is why it would be important to find out more about what the user isE doing before accusing him.   ------------------------------    Date: 10 Jun 2002 22:21:59 -0700$ From: spammitplease@yahoo.co.in (Ab)" Subject: Re: VMS Monitoring a User= Message-ID: <9f100812.0206102121.5e652f1e@posting.google.com>s   Thanks to all who responded...D    I didnt try monitoring this user yet... want to be a bit cautiousC on that. Problem here is that we know who the fellow is but cant dooF anything unless we have a proof against him, this organisation is likeD that even the highest authority cant do anything. And the machine is& an operational system ....no downtime.
  Thanks againv  Abw      a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3D052210.D1EC4717@videotron.ca>...O > Hoff Hoffman wrote:BH > >   The mechanism that prevents this is the "Privilege".  There are noG > >   "Privileges" that prevent misuse of "Privileges".  If you want to-I > >   prevent users from killing other jobs or other unsocial behaviours,DG > >   remove GROUP or WORLD and all heavy privileges from the untrusted  > >   users. > P > If an employee "was" trusted and granted privileges and you SUSPECT abuse, youM > then need to present sufficient proof when you confront the user and remove A > his privileges (either just the VMS ones, or the paycheck one).u >  > J > What if the user is using some utility written by programmers that has aP > trojan "joke" in it that scans for process names that match an employee's nameL > and then deletes that process, and that portion is only effective when the' > utility runs from a privileged user ?0 > N > In such a case, the action would appear to come from the "trusted user", butN > said user would be unaware of what he is actually doing, thinking he is just? > running that utility that everyone is running at the company.1 > K > This is why it would be important to find out more about what the user is  > doing before accusing him.   ------------------------------  % Date: Mon, 10 Jun 2002 15:35:06 -0500 , From: "Tony Scandora" <Scandora@cmt.anl.gov>E Subject: Re: Why porting apps to VMS isn't very helpful in most cases,+ Message-ID: <ae32id$vp8$1@milo.mcs.anl.gov>n  J Right.  The ancient, scorned DECshell product for VAX had the only VMS tarG that ever worked reliably for me.  Of course, it was VAX only and neveroI heard of ODS-5.  Other than DECshell's tar.exe, which runs just fine as a I DCL foreign command without the rest of the DECshell environment, I foundlH the simplest and most reliable way to unpack tarballs on VMS is to go toL UNIX, unpack there, zip up with Info-ZIP on UNIX, and unzip with Info-ZIP on VMS.  H That is a great example of a problem DII-COE might be able to solve.  IfI DII-COE actually works, it will be able to run UNIX software correctly on;L VMS.  One might ask for VMS-only software or real VMS ports of software, butL good software written for UNIX exists, and could be useful if it ran well onL VMS without the prohibitive professional time necessary for a real VMS port.  1 Tony Scandora, Argonne National Lab, 630-252-7541l scandora@cmt.anl.gov  + <david20@alpha1.mdx.ac.uk> wrote in messager% news:ae2h65$qqn$1@aquila.mdx.ac.uk... K > In article <ADYMY2hEkG+r@eisner.encompasserve.org>, Kilgallen@SpamCop.net  (Larry Kilgallen) writes: G > >In article <ae27dr$nmv$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk< writes:  > >=K > >> Come off it. 90+% of public domain software ported to VMS doesn't meet=' > >> your criteria for a "Decent port". L > >> They still work and I am grateful for them. I think most VMS users wantK > >> to see the apps - they don't really care that much about niceties such-) > >> as using the CDL, PCSI or VMSINSTAL.0 > >r7 > >For some reason, I cannot figure out what CDL means.o > >m > + > From the context of Brass Christof's posto > 0 > " A decent port would make use of specific VMS4 > features where appropriate like CDL with carefully7 > chosen parameter types (and qualifier names) that fitw4 > in and like using RMS instead of flat/stream files6 > and with standard installation procedures like PCSI. > "o > I > I'd assumed he meant "Command definition language" - though that shouldn reallyK > be the Command definition utility (CDU) ie having the program support VMSa stylesH > qualifiers and parameters rather than having to define it as a foreign command., > with Unix style qualifiers and parameters. >a >oC > >I would prefer PCSI, with VMSINSTAL as a second choice.  I wouldn1 > >prefer not having to link the software myself.  > L > Although using PCSI or VMSINSTAL would be nice. Just having a command file toL > run or being able to use MMS/MMK is good enough. Indeed it is often betterH > since VMSINSTAL kits and PCSI kits can sometimes rather restrict where > software is installed. >n > >But what I wouldb, > >_really_ prefer is _Software_That_Works_! > >a >d > Of course. >e >  > David Webb > VMS and Unix team leader > CCSS > MIddlesex University >e >oH > >I had occasion to use VMSTAR recently to package up some files.  FromK > >what I can see, the latest-and-greatest (which I used) is VMSTAR V3.4-1.JG > >Looking at the credits, some real VMS experts have contributed to itu > >_on_a_part_time_basis_. > > J > >I ended up having to redo the transfer (which involves two other peopleE > >to receive it) because the program totally botched handling sticky-	 filespecs-H > >originating in a rooted directory.  It not only missed files but alsoJ > >regressed into not understanding ODS-5.  Certainly Backup, Copy and anyJ > >other VMS utility capable of accepting a list of input files do not get& > >this basic sort of operation wrong. > >-G > >I realize that if I had the time I could fix this myself, but I have.G > >had occasion to use this program once this year and once a year ago.DC > >It is obvious to me that the Freeware model does not have enoughcF > >serious regular users to find the bugs, or someone would have fixedG > >this one by now.  Gaining the trust of sporadic users (like me) doessF > >require some body of regular users to whip the software into shape.   ------------------------------    Date: 10 Jun 2002 22:23:33 -0700/ From: chris@applied-synergy.com (Chris Scheers)e Subject: Re: xtoolkit erroru= Message-ID: <754a27c1.0206102123.729bd32a@posting.google.com>8  r merritt.robert@spsd.sk.ca (rob merritt) wrote in message news:<b6bf97d5.0206080601.108deb68@posting.google.com>...7 > Thanks guys I tried them both and here is what I got:C >  > from create/term/detach  >  n > $ create/term/detach- > %DECW-E-CANT_OPEN_DISPL, Can't open display- >  - > from  r decw$examples:ico.exeg > $ r decw$examples:ico.exe  > $8M > (i get nothing???? so then I turned on SET WATCH FILE ?CLASS=MAJOR and get)a >  > $ r decw$examples:ico.exed3 > %XQP, Thread #0, Lookup  (0,0,0) Status: 00000910t? > %XQP, Thread #0, Access ICO.EXE;1 (8576,2,0) Status: 00000001 L > %XQP, Thread #0, Deaccess (8576,2,0) Reads: 9, Writes: 0, Status: 00000001 > $e >  > what do you think?  + Check to see what transports are supported:m  C     $ Show Logical /Table=DECW$Server0_Table DECW$Server_Transports    ------------------------------   End of INFO-VAX 2002.321 ************************