1 INFO-VAX	Sun, 15 Jun 2003	Volume 2003 : Issue 330       Contents:; Re: BLASTed directory locks, timing windows & endless loops ( Do's and don'ts about cleaning keyboards, Re: Do's and don'ts about cleaning keyboards, Re: Do's and don'ts about cleaning keyboards, Re: Do's and don'ts about cleaning keyboards Re: FC Tape on OpenVMS& Free gifts give away, limited quantity- Re: How to configure Batch Queues for cluster P Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome tP Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome tP Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome tP Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome t  Re: New release of MySQL for VMS7 RE: problem after upgrading to compaq (DEC) fortran 7.5  Re: Problems with SYS$GETRMI@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)  F ----------------------------------------------------------------------    Date: 15 Jun 2003 05:21:05 -0700) From: jbrankin@ntlworld.com (Jim Brankin) D Subject: Re: BLASTed directory locks, timing windows & endless loops= Message-ID: <863f19d6.0306150421.119a9d7a@posting.google.com>   \ David Froble <davef@tsoft-inc.com> wrote in message news:<3EE93F07.2050903@tsoft-inc.com>... > Keith Parris wrote:   O > Can I get you guys to back up a bit and explain what you're trying to do?  I  0 > may, or may not, have something to contribute. >   D The problem is to send an event to a process when a file is closed.   E One way is to queue for a the arbitration lock on the file. The lock   name is make up of    0      "F11B$a" + <label of the disk> + <lock id>   , It is a top level lock and is system owned.   < You can see these locks in SDA with show lock /name="F11B$a"  J One major problem is that these locks are only used on clustered systems. F On standalone systems the file system uses flags in the FCB and this a approach will not work.   H This may be more trouble than it is worth. You could have another threadH or another process poll the file trying to open it and when it succeeded@ close the file again and fire an AST in the main process/thread.  $ Returning to issues raised earlier:   # The rule for locks going away are:    C    1. If you want it to go away at image rundown, make it user mode      F    2. If you want it to go away at process rundown, make it kernel or        exec mode.    C    3. If you want it to outlive the process, make it system owned.    H System owned locks are a pain. They hang around forever making debuggingJ and testing difficult. You are forever rebooting to get rid of old locks.   G The paging issue has been covered. You can page in kernel mode so long  G as you keep IPL below 2. So unless you take a spinlock or similar there " is no need to lock the code down.    - Jim    ------------------------------   Date: 15 Jun 03 11:09:07 +0200) From: p_sture@elias.decus.ch (Paul Sture) 1 Subject: Do's and don'ts about cleaning keyboards ) Message-ID: <LfyiEFWpVfrp@elias.decus.ch>   G My heartful thanks to the person who recommended putting my LK keyboard  through the dishwasher.    It is beatifully clean now.   ' But a pity it doesn't work any more...       --  
 Paul Sture   ------------------------------  % Date: Sun, 15 Jun 2003 09:45:20 -0500 ( From: brandon@dalsemi.com (John Brandon)5 Subject: Re: Do's and don'ts about cleaning keyboards 1 Message-ID: <03061509452023@dscis6-0.dalsemi.com>   I > My heartful thanks to the person who recommended putting my LK keyboard  > through the dishwasher.  >  > It is beatifully clean now.  > ) > But a pity it doesn't work any more...   >  > --   > Paul Sture  9 You should have disconnected from your server first... ;)      J*o*h*n B*r*a*n*d*o*n  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------   Date: 15 Jun 2003 13:51:33 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann) 5 Subject: Re: Do's and don'ts about cleaning keyboards 0 Message-ID: <bchtl5$kjo$1@n.ruf.uni-freiburg.de>  U In article <LfyiEFWpVfrp@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes: H >My heartful thanks to the person who recommended putting my LK keyboard >through the dishwasher. >  >It is beatifully clean now.  K There is still hope. I know of cases where people put the whole keyboard in O Alcohol (to dissolve the remaining water) and then let it dry. Alternatively if H you have the chance to put it into some vacuum, this might help as well.  	 Good luck     Christoph Gartmann   J P.S.: all this assumed you didn't run your dishwasher at high temperature.H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, Germany                                           |H +------------- http://www.immunbio.mpg.de/home/menue.html -------------+   ------------------------------  % Date: Sun, 15 Jun 2003 11:58:31 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>5 Subject: Re: Do's and don'ts about cleaning keyboards ) Message-ID: <3EEC97A7.73ED77A5@istop.com>    Paul Sture wrote:  > I > My heartful thanks to the person who recommended putting my LK keyboard  > through the dishwasher.   ( > But a pity it doesn't work any more...  J Ah ! and I though I had lost a lot of keyboards by just gently washing theL rubbery surface with windex. (remove all keys, wash keys separately).  SeemsG that the minute some water seeps in, the keyboard is rendered unusable. F However, if you wait a few months, perhaps it would come back to life.   ------------------------------  % Date: Sun, 15 Jun 2003 14:38:22 +0200 / From: "Marc Van Dyck" <marc.vandyck@brutele.be>  Subject: Re: FC Tape on OpenVMS * Message-ID: <bchpbq$6tm$1@news.brutele.be>  H Company : Banksys (credit/debit cards transaction processing in Belgium)  
 Server side : 3 Various Alphaserver models (GS160, ES40, 4000/4100)  OpenVMS V7.2-1 or V7.2-1H1 SCSI interface : KZPBAJ Backup software : OpenVMS Backup + SLS + DCSC + the ex DECscheduler + lots of DCL code    SCSI-FC bridge :@ OmniServe IV from TD Systems, resold and supported by StorageTEK   Drive side : StorageTEK 9840 & 9940 4 powderhorn silos ACSLS   L The whole config is being migrated to OpenVMS V 7.3-1, which supports native	 FC tapes. * We will then eliminate all SCSI equipment.    No particular problem to report.   Marc.   < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3EEA92B1.E8A49410@fsi.net... : > I need to ask this question again with a narrower focus: > J > Is anyone out there using FC tape drives (preferably SDLT of any flavor,J > but preferably SDLT-320) with any flavor of CrossRoads FC-SCSI "bridge":7 > Hp/Compaq NSR, STK FC-SCSI bridge, etc. with OpenVMS?  > $ > If so, could you please post your: > B > o Hardware make/models (Alpha, NSR, tape drive, HBA, SAN switch) > H > o Soft/firmware versions? (OpenVMS, HBA, NSR, tape drive, SAN Switch)? > 8 > o Problems you are (or aren't) having with this setup? > D > Feel free to obfuscate your e-mail address, or whatever to protectC > whatever confidences you may fear breaching by posting such info.  > G > ...or just e-mail me privately (how to de-mung the reply-to should be G > obvious, but I'd recommend using earthlink instead of fsi) and I will  > respect your privacy.  > I > I just need to know if I'm fighting a losing battle with my VAR or just 6 > what the story is, and this would help tremendously. > D > Also, any horror stories you may have - on-going problems, problem  > fixed, etc. - would help also. > I > As you may have gathered if you saw my earlier posts on this topic, I'm J > having major problems and would appreciate any insights anyone may have. >  > -- > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sat, 14 Jun 2003 20:14:11 -0500 . From: "Freegift Roger" <zqmkxlwu@xpljwkvs.com>/ Subject: Free gifts give away, limited quantity / Message-ID: <bcgpq2$gch$1030@news.chatlink.com>   + This is a multi-part message in MIME format   $ --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain+ Content-Transfer-Encoding: quoted-printable   0 Free laser pointer and free harmonica give away,7 limited time offer, limited quantity, while supply last ) http://www.zeroboss.com       for details         7 ******************************************************* 7 *      http://www.zeroboss.com                        * 7 ******************************************************* 1  -- Homebase business opportunities, FREE to join 4  -- Quality Jewelry, watches, cookware, toys on Sale/     at low wholesale price, several wharehouses   7 *******************************************************           $ --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html + Content-Transfer-Encoding: quoted-printable   0 Free laser pointer and free harmonica give away,7 limited time offer, limited quantity, while supply last % see detail at http://www.zeroboss.com                 & --=_NextPart_2rfkindysadvnqw3nerasdf--   ------------------------------  # Date: Sun, 15 Jun 2003 17:23:53 GMT 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)6 Subject: Re: How to configure Batch Queues for cluster5 Message-ID: <JY1Ha.229240$lL2.2278485@news.chello.at>   T In article <rJ2W$Gs4prJ+@eisner.encompasserve.org>, briggs@encompasserve.org writes:X >In article <vejq09e4ahbke4@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:a >> "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:3EE92CA4.E1B439A3@fsi.net... L >>> You could do this in your SYSTARTUP_VMS.COM procedure in the SYS$MANAGER	 >>> path:  >>> H >>> $ INIT/QUE/BATCH SYS$BATCH/GENERIC=(SYS$BATCH_node1,SYS$BATCH_node2)! >>> $ NODE = F$GETSYI("NODENAME") 1 >>> $ INIT/QUE/BATCH SYS$BATCH_'NODE'/JOB_LIMIT=4  >>  N >> You don't have to put INIT/QUE commands in SYSSTARTUP_VMS.COM.  INIT/QUE isL >> a one time command (unless you want to make changes).  The only thing youG >> have to do at startup is start the queue or enable autostart queues.  >  >Absolutely true.    Yup.  D >But if your queue mangler database has a habit of blowing itself to@ >smithereens or if you restore the queue database from an onlineG >backup (/IGNORE=INTERLOCK) and thus blow it away yourself, it is handy F >to be able to recreate your queues and handier still if they recreate >themselves.  > Then a separate command procedure _not_ invoked during startup is the way to go.   ) >At least that was my reasoning for using  > % >$ INIT /QUEUE blah blah blah /START   >instead of  >$ START /QUEUE blah blah blah >or  >$ ENABLE AUTOSTART /QUEUES  >  >in my startup procedures.  K And my motivation was quite the opposite. I had over 500 queues and I never H lost one by some corruption. I was even able to recreate my queues (on aM test machine) from the BACK/IGN=INTER system disk backup without any problem.   I But reducing the startup time from my AS2100 from over 20min to 2min (!!) I was the reason to never ever use a INIT/QUEUE command in startup anymore. G Only an ENABLE AUTOSTART is in (and one START command for the one batch 7 queue <node$STARTUP> which I use during the startup)...    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  + Date: Sun, 15 Jun 2003 07:29:13 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>Y Subject: Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome t @ Message-ID: <20030615142913.71022.qmail@web20205.mail.yahoo.com>   Everhart  < There are a lot of things this buy-out would be good for IBM  * a) IBM will acquire the Sun's marketshare;A b) IBM will become the owner of JAVA (they can defeat Microsoft); M c) IBM will consolidate Solaris + AIX (maybe just porting Smit to Solaris) :) < d) There are IBM and Sun partneships with Fujitsu/Hitachi... e) Just to begin...   F By the way, I think IBM should stop developing/selling Intel hardware.A They should concentrate in notebooks like Toshiba. IBM would make B an agreement with Dell to sell PCs and Servers, and Dell migrating! all the Services Area to IBM !!!     Regards    FC  --- Everhart <ge@gce.com> wrote:E > Ayup. Also if they bought Sun, they would own various unix licenses D > that Sun has, which would let them make SCO go away. That might be4 > attractive enough for them to be even thinking it. >  >  > Fabio Cardoso wrote: >  > > Guys > > = > > With the Sun share valuing US$ 5,00 ... IBM acquiring Sun < > > would be much more profitable to them than buying VMS !  > >  > >  > > Regards  > >  > > FC   >      =====  ========================== Fbio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.br ==========================  " __________________________________ Do you Yahoo!?+ SBC Yahoo! DSL - Now only $29.95 per month!  http://sbc.yahoo.com   ------------------------------  % Date: Sun, 15 Jun 2003 11:33:30 -0400 * From: "Bill Todd" <billtodd@metrocast.net>Y Subject: Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome t 2 Message-ID: <1NGcnbc4nLSdD3GjXTWcog@metrocast.net>  ; "Fabio Cardoso" <fabiopenvms@yahoo.com.br> wrote in message : news:20030615142913.71022.qmail@web20205.mail.yahoo.com...
 > Everhart > > > There are a lot of things this buy-out would be good for IBM > , > a) IBM will acquire the Sun's marketshare;C > b) IBM will become the owner of JAVA (they can defeat Microsoft); L > c) IBM will consolidate Solaris + AIX (maybe just porting Smit to Solaris) :)> > d) There are IBM and Sun partneships with Fujitsu/Hitachi... > e) Just to begin...   K If IBM felt that way, why didn't they buy Sun when its stock price was only  a bit over half what it is now?    - bill   ------------------------------  % Date: Sun, 15 Jun 2003 12:15:49 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>Y Subject: Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome t ) Message-ID: <3EEC9BB4.721FEE96@istop.com>    Bill Todd wrote:M > If IBM felt that way, why didn't they buy Sun when its stock price was only ! > a bit over half what it is now?   N IBM has had its shares of antitrust issues. It knows that IBM buying Sun would bring those back.   E However, IBM buying VMS wouldn't be such an antitrust issue. Since HP J essentially denies owning VMS and doesn't market or attempt to sell to newI customers, if someone else were to take it and start to sell it, it would D increase competition since a "new" product would come to the market.  H HP has done more to reduce competition than IBM. First, it is a slave toF Microsoft. Second, it has killed off many product lines, including oneK competing Unix, hidden VMS, killed its own PDA line (some of which were not  windows-ce), killed MPE etc.   ------------------------------  + Date: Sun, 15 Jun 2003 10:05:14 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>Y Subject: Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome t ? Message-ID: <20030615170514.6796.qmail@web20209.mail.yahoo.com>   4 There is only one thing to do with OVMS outside HP :  7 Becoming an independent company !!!  www.openvms.com !    @ I doubt IBM wants VMS ! It will fade like AS-400 platform or IBMC will port all the OVMS products and technology to the OS 390/Linux   architecture !     Regards    FC  / --- JF Mezei <jfmezei.spamnot@istop.com> wrote:  > Bill Todd wrote:O > > If IBM felt that way, why didn't they buy Sun when its stock price was only # > > a bit over half what it is now?  > J > IBM has had its shares of antitrust issues. It knows that IBM buying Sun > would  > bring those back.  > G > However, IBM buying VMS wouldn't be such an antitrust issue. Since HP L > essentially denies owning VMS and doesn't market or attempt to sell to newK > customers, if someone else were to take it and start to sell it, it would F > increase competition since a "new" product would come to the market. > J > HP has done more to reduce competition than IBM. First, it is a slave toH > Microsoft. Second, it has killed off many product lines, including oneM > competing Unix, hidden VMS, killed its own PDA line (some of which were not  > windows-ce), killed MPE etc.     =====  ========================== Fbio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.br ==========================  " __________________________________ Do you Yahoo!?+ SBC Yahoo! DSL - Now only $29.95 per month!  http://sbc.yahoo.com   ------------------------------  % Date: Sun, 15 Jun 2003 18:55:05 +0930 / From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au> ) Subject: Re: New release of MySQL for VMS , Message-ID: <3eec3b85_1@news.chariot.net.au>  I Thanks but no thanks Jean-Franois.  According to a lot of the volume of  H this forum what is required for VMS specifically, and IT in general, is F is more a return to home-spun, right-of-centre, non-commie-ideologue, G closed-source software, and definitely less compliance (lest unsavoury  D foreign ideas take root).  Being able to exchange data with non-VMS E systems cannot be good (what about all that nasty contagion?).  Nice  G try, but what the VMS jobs market requires is less industry compliance  8 and more niche projects.  That's the wave of the future.   Jean-Franois Pironne wrote: P > I have just put online a new kit of MySQL, this is version 4.0.13 which is the > latest stable version. >   > More information about change:. > http://www.mysql.com/doc/en/News-4.0.13.html > K > Now, the VMS version of MySQL server run under a dedicated non privileged 
 > account. > N > I have also build a PCSI kit which contain pre-build version for VMS 7.3 andI > higher (anyway I don't expect MySQL to run under older version of VMS).  > M > Source kit can be download from http://www.pi-net.dyndns.org/anonymous/jfp/  > < > PCSI kit from http://www.pi-net.dyndns.org/anonymous/kits/ > . > There is also a faster North America Mirror. >  > M > I also expect to release a pre-build Python PCSI kit soon, more information / > can be found on http://vmspython.dyndns.org/.  >  >  >  >  > Jean-Franois Pironne   ------------------------------  % Date: Sun, 15 Jun 2003 08:51:07 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> @ Subject: RE: problem after upgrading to compaq (DEC) fortran 7.5R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB05898D@tayexc19.americas.cpqcorp.net>   >=20 > -----Original Message-----. > From: Sam Hoblit [mailto:hoblit@liii.com]=20 > Sent: June 14, 2003 1:54 PM  > To: Info-VAX@Mvb.Saic.Com  >=20 > Hi - >=20> > I recently got the new SPL for alpha VMS. We're currently=207 > running VMS 7.2-2 and we had fortran 7.4-1 installed. A > I'm planning on soon upgrading to VMS 7.3-1, but can't right=20 = > now. However, the SPD for fortran 7.5 said it only needs=20 < > version 7.1 or higher so I decided to go ahead with the=20A > upgrade of the runtime libraries, fortran, and the cxml now.=20 A > I do the upgrade and everything goes fine, post-installation=20 ? > test goes fine, and I replace the installed images for the=20 ( > rtl as mentioned in the release notes.@ > Now, I try to compile some routines and except for the most=20= > trivial routines ("hello world" test programs, etc), the=20 . > compiler crashes with the following message: >=20< >  F90-F-FATAL, **Internal compiler error: specification =20> > exception signal raised** Please report this error along =20? > with the circumstances in which it occurred in a Software =20  > Problem Report.  >=20A > No line number given, and most of our production code raises=20 ? > this exception. I also added the ECO1 for both the rtl and=20 6 > fortran but it didn't help. I've been through the=20: > installation manual, SPD, & release notes looking for=20? > something. Has anyone else seen this with fortran 7.5-1 or=20 ? > 7.5-3 on VMS 7.2-2? For now I just reverted back to 7.4-1,=20 / > which works. Our 7.2-2 is fully patched, btw.  >=20 > Sam  > hoblit@liii.com  >=20   Sam,  E I noticed a similar error in an internal notes file being reported as G having been fixed recently. While I do not know if it is the same error F or not, as mentioned in a previous reply, the best suggestion would beA to report the problem via the standard processes in your country.    Regards   
 Kerry Main Senior Consultant  Hewlett-Packard (Canada) Co.! Consulting & Integration Services  Voice: 613-592-4660  Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)  OpenVMS DCL - the original .COM    ------------------------------  + Date: Sun, 15 Jun 2003 17:25:23 +0000 (UTC) 1 From: "Bagbourne" <the_bagbournes@btinternet.com> % Subject: Re: Problems with SYS$GETRMI 2 Message-ID: <bcia62$sib$1@hercules.btinternet.com>  H  You need to wait for it to write the values into the addresses that you* passed - that's an asynchronous operation.  L Look at SYS$GETRMIW, and read up about event flags - you need to pass it oneE to wait on.... Unless, IIRC you are on a late V7 version - that has a K special event flag 128 I think. I sadly exited the VMS world about the time  this feature arrived :-(   Nige0 <fernando.vallarino@oca.com.uy> wrote in message7 news:5da5a1ff.0306131409.1e3162a7@posting.google.com... A > I'm trying to obtain the cpu usage of an AlphaServer using this G > system service (SYS$GETRMI), but all the counters are 0 in all modes. 8 > The value returned is 1 (also in the IO status block). > Any idea?  > Here is the code:  >  > main() > {  >         float Espera = 10;G >         unsigned int CPUInterrupt,CPUKernel,CPUExec,CPUSuper,CPUUser, , >                         CPUCompat,CPUIdle; >         IL Sol[] = {8 >                 {4, RMI$_INTERRUPT, &CPUInterrupt, 0},2 >                 {4, RMI$_KERNEL, &CPUKernel, 0},. >                 {4, RMI$_EXEC, &CPUExec, 0},0 >                 {4, RMI$_SUPER, &CPUSuper, 0},/ >                 {4, RMI$_USER,  &CPUUser, 0}, 2 >                 {4, RMI$_COMPAT, &CPUCompat, 0},. >                 {4, RMI$_IDLE, &CPUIdle, 0},. >                 {0, 0,          0,        0} >         }; >         int Ret; >         IOSB Iosb; > 7 >         Ret = sys$getrmi(0, 0, 0, &Sol, &Iosb, 0, 0); 7 >         printf("GETRMI = %d %d\n", Ret, Iosb.status); 6 >         printf("CPUInterrupt = %d\n", CPUInterrupt);0 >         printf("CPUKernel = %d\n", CPUKernel);, >         printf("CPUExec = %d\n", CPUExec);. >         printf("CPUSuper = %d\n", CPUSuper);, >         printf("CPUUser = %d\n", CPUUser);0 >         printf("CPUCompat = %d\n", CPUCompat);, >         printf("CPUIdle = %d\n", CPUIdle); > }    ------------------------------  % Date: Sun, 15 Jun 2003 18:28:28 +0930 / From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au> I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long) . Message-ID: <3EEC3534.9060500@wasd.vsm.com.au>  G Well, it's been a fortnight (or whatever the metric equivalent of that  A is these days) and this issue has generated only the *slightest*  # interest from the c.o.v. community.   H The only conclusion I can draw from this is what is such a *significant*D problem for our environment is unique to us (I'm tempted to add - in> contrast to so many, seemingly off-topic threads, that do get = considerable discussion in this forum). No one else needs to  G interoperate in heterogenous X environments?  It would seem then, that  G DEC/Cpq/HP have made the correct call on where their resources need to  . be deployed (and who can blame them for that).  G I'll (one more time) need to go, cap-in-hand, to those that administer  G our environment and explain that VMS, yes - once again, cannot be made  D to integrate into that.  Oh well, perhaps RLM made the correct call G after-all.  Shame.  Never thought I'd be resigned to it, but you can't  # swim against the tide indefinitely.   F +--------------------------------------------------------------------+E   Mark Daniel                         http://wasd.vsm.com.au/adelaide F   mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au)F +--------------------------------------------------------------------+   Mark Daniel wrote:D > I am not really wishing to start a "this is typical of DEC/CPQ/HP K > OpenVMS Management ..." thread.  Please restrain the impulse to do so if  J > this post just reinforces your experience over the years.  If there are J > others out there in this same situation it just might be an opportunity H > to inform those OpenVMS Engineering Project Managers who frequent and F > now are often active in these newgroups, of what (I feel is) a very  > basic requirement. > A > This relates to my day-job (DSTO), not the proprietory company  D > represented by my email address (VSM).  That really dosn't change G > anything of course. Small organizations as well as large are equally  7 > dependent the ubiquitous X Window System environment.  > I > We are in the process of replacing a large number of older X-terminals  H > that provide only 8 bit colour with those supporting 24 bits (amongst G > other reasons).  In so doing we discovered that a candidate solution  F > (which best goes unspecified in this forum) requires the support of G > MIT-MAGIC-COOKIE-1.  Now, I don't want to debate the efficacy of the  K > this method of "authentication" or privacy insurance.  Suffice to say it  ? > *is* a requirement.  It is also a "policy" that such such an  K > authentication scheme be used with X-terminals to reduce the possibility  E > of unauthorized clients accessing sensitive information, including  H > displays, entered passwords, etc.  In other words, all the stuff that I > the standard X Window System so promiscuously allows.  Up until now we  J > have not been able to implement the "policy" on our VMS systems because G > we use TCP/IP extensively as a transport and DECwindows 1.0->1.2 has  > > only supported user-based authentication for DECnet, or the G > XDM-AUTHENTICATION-1 which is cumbersome and was not practicable (at   > least in our environment). > F > Motif 1.3 has changed this.  It supports MIT magic and works well.  K > (Many thanks to the specialist handling the call at our national CSC for  J > chasing this down and obtaining a copy for us well before we would have D > received it on the Q2 distribution.)  OK, all is well.  Hmmm, not H > quite.  After time and effort was expended getting the XDM to support J > the MIT_MAGIC-COOKIE-1 authentication it still didn't.  And won't!  You D > see, apparently all of OpenVMS' X Display System (DECwindows) has E > received a major overhaul EXCEPT THE XDMCP tool!  Yes, the XDM was  H > "overlooked" (?) and does not provide what the rest of the suite does. > F > When I pressed my contact at the CSC he relayed his impression from K > OpenVMS Engineering over this issue.  I quote (with permission) my reply  D > here (with only some private detail removed) so as not to have to C > recompose the same sentiments.  He understood the remarks and is  B > forwarding them to the "whomever". Thanks for your reading time. > : >> From: Daniel, Mark Sent: Monday, June 02, 2003 11:17 AM >> Subject: RE: magic cookies  >>
 >> Hi [name],  >>F >>> Sigh... I thought we were well past "yes/no", you can't do it with9 >>> XDM. We've been trying to raise this as a "please fix  >> >>J >> My mistake.  I thought we were still in the "get the folks back home to >> tell us how" stage :^)  >>J >>> this ASAP", but getting lots of "yeah, sure, after Itanium ships" type >>> noises. :-(  >> >>C >> Never thought I'd be so exasperated.  I know I'm not telling you I >> anything new [name], just expressing myself out loud.  Perhaps you can , >> return this reply verbatim to "whomever". >>K >> Not wishing to again express any opinion over the essential value of MIT D >> magic cookie style authentication, it is so fundamental a part ofJ >> heterogenous environments (which we all live in these days) that for itI >> to be absent is tantamount to illuminating a neon sign over VMS saying G >> "DOES NOT FIT IN".  VMS does not need to draw attention to itself in I >> *this* way.  Now, MIT magic in Motif 1.3 is an *excellent* move.  BUT, K >> it's only half done if the XDMCP tool does not support it!!  Thin-client K >> environments just cannot be supported without an effective XDM.  I would B >> have thought this would have been obvious to blind-Freddy.  I'mI >> surprised that someone in the DECwindows Motif 1.3 enhancement project I >> did not notice this, or did not state long and loud that the XDM is an K >> essential component of the VMS X Display System environment.  Perhaps it F >> should be wrested from the TCP/IP team, or some better coordinationJ >> between them and DECwindows project management.  Perhaps it is just Too >> Hard. >>J >>> Can you give me a rough dollar value on what we could sell you guys ifJ >>> we delivered this capability? If not dollars, then some number of DS??& >>> systems? As they say, money talks. >> >>K >> Ignoring the issue of future Itanium sales :^)  Perhaps you might remind I >> the bean counters that new systems aside, my Division retains hardware H >> and software maintenance on the existing systems.  I just enquired ofC >> our IT Manager and for this Division alone it's in the order of   >> [considerable number]G >> Australian beans per annum, the majority of which is for VMS systems @ >> (perhaps not major customer status, but significant, I'd say,K >> "money-for-jam").  Considering the reported disparity in margins between J >> sales of new iron and that for "services", I would suggest that OpenVMSH >> first strive to retain this income stream before asking how much moreG >> we'll spend next year.  In fact it is probably from this source that F >> ports to Itanium are being funded.  Nobody is debating that now the6 >> Alpha platform has been declared obsolescent that aK >> Itanium/Opteron/whatever port is necessary and inevitable but not to the , >> exclusion of much else that is necessary. >>J >>> Or would we be giving sales to [platform]? XP workstations give heaps  >>> moreF >>> than 8 bit colour depth. DS10 or DS15 instead maybe? Wouldn't need >>> magic cookies at all...  >> >>D >> Still would.  It has now come to the attention (after the need toL >> explain why we can't support VMS sessions on [platform] - at least beforeE >> Motif 1.3) of our IT Security Officer that those using VMS have no : >> connection authentication enabled on their X-Terminals.1 >> Needless-to-say, "this needs to be addressed".  >> >>> [signature]  >> >> >> Hope this is of some value. >> >> Regards,  >> >> Mark Daniel.    ------------------------------  % Date: Sun, 15 Jun 2003 15:25:30 +0200  From: Dirk Munk <munk@home.nl>I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long) 2 Message-ID: <bchses$1eh$1@news2.tilbu1.nb.home.nl>  H To start with, you may have noticed that there are not that many people Q participating in this newsgroup. It seems there are still something like 450,000  P VMS systems around, and if only 1% of those systems would be represented by one Q person here, we would see 4,500 name popping up in this newsgroup. There are far   less contributors I'm afraid.   Q So it may well be that others have the same problems as you, but don't read this  
 newsgroup.  P On the other hand that is not really the issue. The problem you are facing is a K problem that we can see more often, and not just with HP. In your case the  N problem is that no one seems to be reponsible for the Motif architecture as a Q whole, that is including for instance the TCP/IP changes that have to be made to  O   bring the Motif environment up to today's standard. Someone should have told  Q the TCP/IP engineers to make the necesarry changes, and he should have made sure  I the work was done. Somehow this did not happen, and that is poor product  O management in my view, and that is the real problem. Now you are stuck with an  N unfinished product, and you as a customer really don't care who is reponsible 6 for that, the Motif engineers or the TCP/IP engineers.  H I'm facing a similar problem that HP isn't going to solve on short term.  N TCP/IP services for VMS can also be used as a BIND server, and it can be used L with dynamic DNS updates. So in that respect TCP/IP services are up to date.  N As we all know we can cluster VMS sytems for high availability, and so we can L also make a clustered BIND server. This is great, most likely the only such  product around.o  J However you can NOT use dynamic updates with such a clustered BIND server.  J Now if you want to build a VMS TCP/IP production cluster, it will use the 3 Loadbroker, and that relies on dynamic DNS updates.   O So there we have a high availability clustered VMS BIND server that can not be  Q used with high availability production clusters, because the BIND server can not  I be used with the dynamic DNS updates that the production cluster needs !!e  Q This is just as silly as your problem. If this wasn't the case I could recommend -O using VMS BIND servers to our network group. They don't have a sollution for a -O failing master BIND server, except by manually 'promoting' a slave BIND server l to master BIND server.  I These inconsistencies are very irritating and harm the reputation of the  4 products, specialy when HP doesn't want to fix them.             Mark Daniel wrote:I > Well, it's been a fortnight (or whatever the metric equivalent of that nC > is these days) and this issue has generated only the *slightest* e% > interest from the c.o.v. community.  > J > The only conclusion I can draw from this is what is such a *significant*F > problem for our environment is unique to us (I'm tempted to add - in@ > contrast to so many, seemingly off-topic threads, that do get ? > considerable discussion in this forum). No one else needs to SI > interoperate in heterogenous X environments?  It would seem then, that rI > DEC/Cpq/HP have made the correct call on where their resources need to s0 > be deployed (and who can blame them for that). > I > I'll (one more time) need to go, cap-in-hand, to those that administer eI > our environment and explain that VMS, yes - once again, cannot be made dF > to integrate into that.  Oh well, perhaps RLM made the correct call I > after-all.  Shame.  Never thought I'd be resigned to it, but you can't  % > swim against the tide indefinitely.a > H > +--------------------------------------------------------------------+F >  Mark Daniel                         http://wasd.vsm.com.au/adelaideG >  mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au)aH > +--------------------------------------------------------------------+   ------------------------------  % Date: Sun, 15 Jun 2003 11:56:59 -0400h* From: JF Mezei <jfmezei.spamnot@istop.com>I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)a) Message-ID: <3EEC974B.D39B1DED@istop.com>    Mark Daniel wrote:J > The only conclusion I can draw from this is what is such a *significant*- > problem for our environment is unique to us'  F No, it is not unique to you. But otehsr have given up on hope. The VMSN engineers are way too busy with the unwanted port to IA64 to make the sofwtareJ changes necessary to meet customers's need. We'll have to wait a few years before they can get to it.  H What the TCPIP folks should do is simply publish the source to their XDM) server so that we could fix it ourselves.J   ------------------------------  % Date: Sun, 15 Jun 2003 12:07:24 -0400g* From: JF Mezei <jfmezei.spamnot@istop.com>I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)r) Message-ID: <3EEC99BB.9F3D1E47@istop.com>    Dirk Munk wrote:R > participating in this newsgroup. It seems there are still something like 450,000 > VMS systems around,   M This figure is good to publish to help kill the image that VMS is dead, but IaB personally do not find it credible in terms of "active" VMS sites.  O > problem is that no one seems to be reponsible for the Motif architecture as ahR > whole, that is including for instance the TCP/IP changes that have to be made to8 >   bring the Motif environment up to today's standard.   I 1- Motif is progressing nicely. It is up to version 2.1 I think (or is it M 2.0). Ironically, it is available on HP-UX. But VMS has a very old version oftN Motif. Someone took a decision that VMS wouldn't be scalable anymore and would" only run on wildfireclass systems.  M 2-XDM has very little to do with Motif.  It is just a "who is willing to giverI me a login screen" ? protocol. It is only after XDM has done its job thatlK X-windows comes into play with the X-client popping a login screen onto theuI X-server. And this is done at the TCPIP level. While X can use DECNET for-K transport, XDM is a TCPIP stack protocol, so it is logical to put in in the  TCPIP software.6   ------------------------------   End of INFO-VAX 2003.330 ************************