1 INFO-VAX	Tue, 14 Mar 2006	Volume 2006 : Issue 145       Contents:5 Re: ANN: PMDF and PMAS available to OpenVMS Hobbyists # BA46 Expansion Box with Charon-VAX? ' Re: BA46 Expansion Box with Charon-VAX? ' Re: BA46 Expansion Box with Charon-VAX? + Re: Does OpenVMS MIME work with your stack? + Re: Does OpenVMS MIME work with your stack? + Re: Does OpenVMS MIME work with your stack? + Re: Does OpenVMS MIME work with your stack? ) Re: Error installing VMS 82A Update 2 kit  Re: Eve - displaying ESC? 1 Looking For Feedback on Printer Management Issues 5 Re: Looking For Feedback on Printer Management Issues ? Re: Mysterious revision date changes caused by Advanced Server? ? Re: Mysterious revision date changes caused by Advanced Server? ? Re: Mysterious revision date changes caused by Advanced Server? ? Re: Mysterious revision date changes caused by Advanced Server?  Re: need help with Flakey VLC  Re: need help with Flakey VLC  Re: need help with Flakey VLC ! Re: Nodename in Accounting File ?  Re: OPA0 Console connection  Re: OPA0 Console connection  Re: OPA0 Console connection  Re: OPA0 Console connection  Re: OPA0 Console connection  Serial Console connection ! SSL not working in CSWB... Solved ( tcpip 5.5-11 ECO1 SSH server workaroundsO Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features O Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features O Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features O Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features P Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features % Re: [F$GETQUI] Please explain RAD ;-)   F ----------------------------------------------------------------------   Date: 14 Mar 2006 01:15:49 GMT From: healyzh@aracnet.com > Subject: Re: ANN: PMDF and PMAS available to OpenVMS Hobbyists, Message-ID: <dv55g502g54@enews3.newsguy.com>  ( Dave Froble <davef@tsoft-inc.com> wrote:K > An interesting development.  I have to ask about your (Process Software)  ( > perceptions on how such would be used.  D > As for VMS, TCP/IP, languages, and such, I can see their use in a  > hobbyist environment.   K > However, when talking about E-Mail, Spam blocking, and such, I don't see  J > much of non-commercial use for such products.  People will probably not G > be using them strickly on their own systems, limited to mail between  G > their systems.  They're going to set the products up to handle their  H > e-mail coming from outside.  This is something they normally get with : > their commercial ISP services which most are paying for.  L I can sure see a use for this, I run my own Mail and Web servers at home, onK OpenVMS.  This is strictly for Hobbyist usage, and I really want to get the L anti-spam software installed.  Literally the day before this was announced aL co-worker and I were discussing the lack of a antispam solution for HobbyistJ OpenVMS systems, as she wants to setup a mail server running VMS at home. 5 BTW, neither of us work with VMS in our current jobs.    		Zane   ------------------------------  # Date: Mon, 13 Mar 2006 22:26:39 GMT ' From: "Mike D" <mgdonnelly.not@att.net> , Subject: BA46 Expansion Box with Charon-VAX?= Message-ID: <zkmRf.38399$_S7.7832@newssvr14.news.prodigy.com>   M Has anyone had success using the BA46 SCSI expansion box with Charon-VAX?  I  M have an number of TK50 tapes that I'd like to access, but I can't get the PC  5 SCSI card to recognize the devices in the BA chassis.    Thanks,  Mike D     ------------------------------  % Date: Mon, 13 Mar 2006 21:47:46 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>0 Subject: Re: BA46 Expansion Box with Charon-VAX?+ Message-ID: <44163CE2.4B1084EC@comcast.net>   
 Mike D wrote:  > N > Has anyone had success using the BA46 SCSI expansion box with Charon-VAX?  IN > have an number of TK50 tapes that I'd like to access, but I can't get the PC7 > SCSI card to recognize the devices in the BA chassis.   A If you can find a TZ30 (half-height, 5-1/4 inch drive, similar in H operation to the TZ8x drives: insert the cart, slide the handle to load,F push the button to unload the cart, slide the handle to eject it) that? might work, though Windows drivers (if needed) may be an issue.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Mon, 13 Mar 2006 23:43:47 -0500 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>0 Subject: Re: BA46 Expansion Box with Charon-VAX?/ Message-ID: <441603B3.21535.20D2CF47@localhost>   0 On 13 Mar 2006 at 21:47, David J Dachtera wrote:C > If you can find a TZ30 (half-height, 5-1/4 inch drive, similar in D > operation to the TZ8x drives: insert the cart, slide the handle toE > load, push the button to unload the cart, slide the handle to eject C > it) that might work, though Windows drivers (if needed) may be an  > issue.  D CHARON-VAX can address devices without Windows drivers by accessing D the SCSI bus directly using the controller number, SCSI ID, and LUN.  C CHARON-VAX also includes a tool to probe the bus for devices.  And  C the SCSI interface device might also include a similar tool.  It's  F possible that there is a conflict on the bus that is masking the tape  drive.  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA < stan-at-stanq-dot-com   http://www.stanq.com/charon-vax.html) "OpenVMS, when downtime is not an option"    ------------------------------    Date: 13 Mar 2006 10:55:13 -0800 From: n.rieck@sympatico.ca4 Subject: Re: Does OpenVMS MIME work with your stack?C Message-ID: <1142276113.295409.126890@e56g2000cwe.googlegroups.com>    Hunter Goatley wrote:  > Neil Rieck wrote:  > > N > > It would be nice, though,  to see PSC add a logical to TCPware which wouldN > > selectively disable the extra blank line whenever the first line of a mailF > > message contained the phrase MIME. (or a variation on this scheme) > > 4 > I believe we're adding that for the next releases. >  > -- >  > Hunter > ------; > Hunter Goatley, Process Software, http://www.process.com/ D > PreciseMail Anti-Spam Gateway for OpenVMS, Tru64, Solaris, & Linux; > goathunter@goatley.com     http://www.goatley.com/hunter/   G Oops. I've already logged a support call with your company (PSC124003).   
 Neil Rieck   ------------------------------  % Date: Mon, 13 Mar 2006 13:27:01 -0600 - From: Hunter Goatley <goathunter@goatley.com> 4 Subject: Re: Does OpenVMS MIME work with your stack?8 Message-ID: <dDjRf.6278$HV2.1879@bignews1.bellsouth.net>   n.rieck@sympatico.ca wrote:  > I > Oops. I've already logged a support call with your company (PSC124003).   > That's fine.  It means you should be notified when it's ready.   Thanks!    --     Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ B PreciseMail Anti-Spam Gateway for OpenVMS, Tru64, Solaris, & Linux9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------  + Date: Mon, 13 Mar 2006 21:21:48 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)4 Subject: Re: Does OpenVMS MIME work with your stack?$ Message-ID: <dv4npc$6gm$1@online.de>  C In article <Dj%Qf.512$ng.46020@news20.bellglobal.com>, "Neil Rieck"  <n.rieck@sympatico.ca> writes:    K > > Nop, and it isn't MIME's fault, it is the smtp foreign VMSmail protocol G > > image which securely ads a blank line between its's header and your  > > stuff to prevent fraud.   A Several years ago, I remember a hack involving embedding newline  " characters in the Subj: header....   ------------------------------  % Date: Mon, 13 Mar 2006 23:15:01 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 4 Subject: Re: Does OpenVMS MIME work with your stack?9 Message-ID: <UqrRf.1216$fy1.126253@news20.bellglobal.com>   : "Hunter Goatley" <goathunter@goatley.com> wrote in message2 news:dDjRf.6278$HV2.1879@bignews1.bellsouth.net... > n.rieck@sympatico.ca wrote:  >>J >> Oops. I've already logged a support call with your company (PSC124003). > @ > That's fine.  It means you should be notified when it's ready. > 	 > Thanks!  >  > --   >  > Hunter > ------; > Hunter Goatley, Process Software, http://www.process.com/ D > PreciseMail Anti-Spam Gateway for OpenVMS, Tru64, Solaris, & Linux; > goathunter@goatley.com     http://www.goatley.com/hunter/  >   I The good folks at PSC have passed on this interim work-around for my MIME K problem. I tried it out and it works but I haven't (yet) found any official 7 OpenVMS documentation describing "/foreign" or "/type".   3     $MAIL/subj=whatever/foreign/type=2 mime-doc.txt   
 Note that:       send/foreign/type=2    also works from within VMSMAIL.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  + Date: Mon, 13 Mar 2006 21:23:20 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)2 Subject: Re: Error installing VMS 82A Update 2 kit$ Message-ID: <dv4ns8$6gm$2@online.de>  H In article <4414b0f8$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:    K > The VMS732_PCSI V2 has a problem. It forgets to INSTALL REPLACE DCLTABLES O > Could be easily fixed, but is surely bad behaviour (and bad quality control).   ? Is it enough to install it out of the box, then INSTALL REPLACE ' DCLTABLES then log out and log back in?    ------------------------------  % Date: Mon, 13 Mar 2006 21:27:16 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>" Subject: Re: Eve - displaying ESC?+ Message-ID: <44163814.EB551BD6@comcast.net>     Peter 'EPLAN' LANGSTOEGER wrote: > X > In article <47fs3oFfattjU1@individual.net>, Paul Sture <paul.sture@bluewin.ch> writes:K > >In EDIT/TPU, when editing files with records longer than 80 bytes, issue G > ><DO> and then SET RIGHT 1000 (or whatever exceeds the maximum record + > >length) to stop automatic line wrapping.  > J > No. In EDIT/TPU the best way is to generally enable EDT layout/behaviour > (which I did in 1987 or so)  >  > $ TYPE EVE$INIT R > TPU IF GET_INFO (SCREEN, "MOTIF") THEN SET (MOUSE,ON) ELSE SET (MOUSE,OFF) ENDIF! > DEF KEY=CONTROL-B SET WIDTH 132   > DEF KEY=CONTROL-N SET WIDTH 80 > DEF KEY=F8 QUIT  > DEF KEY=GOLD-E EXIT  > DEF KEY=GOLD-Q QUIT 8 > DEF KEY=GOLD-X TPU WRITE_FILE (SELECT_RANGE,"TMP.TMP")# > DEF KEY=GOLD-LEFT  "SHIFT LEFT 8" $ > DEF KEY=GOLD-RIGHT "SHIFT RIGHT 8" > SET CURSOR BOUND > SET NOEXIT ATTRIBUTE CHECK > SET SCROLL MARGIN 7 7  > SET NOWRAP > Q > where SET NOWRAP, SET CURSOR BOUND and SET SCROLL MARGIN (and EVE$KEYPAD "EDT") + > are the main settings to reach this goal.  > I > If all EVE/TPU users would have done such settings decades ago, many of J > the EVE vs EDT flamewars wouldn't had happened (ok, there are still moreL > differences and some flamewars happened because of these, but for joe userK > these settings would have been enough to not miss real EDT and love EVE).   B Dunno 'bout that. The most useful feature - for me - in EDT is theD ability to hit CTRL+K, then build a key definition without having to? actually execute the keystrokes so the editor can "learn" them.   E For example, I might set text fragments into buffers A, B and C, then  type these keystrokes:   CTRL+K CTRL+G( ("$" PASTE=A +EL PASTE=B D+C PASTE=C L).  G ...or something like that, then use GOLD-4 GOLD-5 GOLD-7 SH BUF <ENTER> C to see how many lines are in the buffer, then GOLD (the line count) 1 CTRL+G to execute the "macro" (line count) times.   F To me, that's faster than first "teaching" the sequence to the editor,D then figuring out how many lines remain to be processed in the file,E then convincing the editor to repeat the learned sequence the correct ' number of times to finish out the file.    As always, YMMV.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------    Date: 13 Mar 2006 20:20:45 -0800' From: "Paul Tykodi" <ptykodi@yahoo.com> : Subject: Looking For Feedback on Printer Management IssuesC Message-ID: <1142310045.235016.212720@i39g2000cwa.googlegroups.com>   
 Dear List,  > I am currently interested in receiving information from anyoneA responsible for the management of printers defined in VAX/VMS and G OpenVMS environments, utilizing any of the available TCP/IP stacks, who + might want to contribute thoughts or wishes ? for improvements in the area of printer management, which could > potentially be addressed in a Printer MIB Implementer's Guide.  B I have been asked by the current chairman of the IEEE-ISTO PrinterE Working Group (http://www.pwg.org) to make a presentation at the next G PWG meeting (to be held April 5-6, 2006 in Mt. Laurel, NJ USA) in order : to gauge the potential interest in producing a Printer MIB Implementer's Guide.  ? The printer working group develops industry standards that help G printing devices to work well in today's heterogeneous computer network 
 environments.   F The task of the Printer MIB group is defined as follows on the PWG web site:   @ "A Management Information Base (MIB) defines a framework for the= management of systems using the IETF standard "Simple Network G Management Protocol" (SNMP). MIB objects provide the ability to monitor C and control systems, providing fault, configuration and performance  management.   > PWG MIBs allow network users to utilize SNMP and existing SNMPE infrastructure to manage networked imaging devices. The working group D has completed the development of MIB standards for the management ofC printers, finishing devices, and imaging jobs. For example, the Job G Monitoring MIB provides job related information to end users and system : operators plus accounting information at the end of a job.  F Current work items include the development of a Port Monitor MIB, usedG to facilitate the installation of network printer ports and drivers for A various operating systems. The PWG MIBs working group will remain D active to support any future MIB development efforts and to maintain  the related IANA registrations."   Thanks.   
 Best Regards,    /Paul  -- Paul Tykodi  Principal Consultant$ TCS - Tykodi Consulting Services LLC  / E-mail: ptykodi@tykodi.com or ptykodi@yahoo.com  Tel/Fax: 603.343.1820  WWW: http://www.tykodi.com   ------------------------------    Date: 13 Mar 2006 22:26:18 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) > Subject: Re: Looking For Feedback on Printer Management Issues3 Message-ID: <0T2rZu6OT7Ln@eisner.encompasserve.org>   m In article <1142310045.235016.212720@i39g2000cwa.googlegroups.com>, "Paul Tykodi" <ptykodi@yahoo.com> writes:   @ > I am currently interested in receiving information from anyoneC > responsible for the management of printers defined in VAX/VMS and I > OpenVMS environments, utilizing any of the available TCP/IP stacks, who - > might want to contribute thoughts or wishes A > for improvements in the area of printer management, which could @ > potentially be addressed in a Printer MIB Implementer's Guide.  7 Apple's Printer Access Protocol works best from my VAX.   B If you are required to use IP, there must be a PAP over IP option.   ------------------------------  # Date: Mon, 13 Mar 2006 20:19:39 GMT  From: d_gillbilly@hotmail.com H Subject: Re: Mysterious revision date changes caused by Advanced Server?8 Message-ID: <u0hb125rdp0ppkrn40vdk51nf66ahho1bj@4ax.com>  B On Mon, 13 Mar 2006 19:01:44 GMT, "PEN" <paul.nunez.nosp@m.hp.com> wrote:   >Hi, > M >The Advanced Server will apply ACEs to files to track information pertinent  L >to Windows clients that is not maintained by OVMS (ie. file attributes and M >DOS file size).   The ACE will be updated whenever a client reads the file.  I >Though the client user may not have instructed the client to read these  N >files, Windows Explorer and other apps freely open/read the first x bytes of K >these files (perhaps only those with known file types?) to obtain certain  M >attributes/characteristics.  When AS closes such files, it updates the ACE,  K >which means the ACL is modified, which means the file header is modified,  / >which means the file revision date is updated.  > # >I bet that's what you're seeing...  >  >Paul  >    Hi Paul,  
    Good tip.    >    These header updates do correspond to files with suppressedH PATHWORKS ACE's. If AS wants to set an ACE, I get a header update on theF file. I can understand this. But why only selected files. And how do IG get this behavious to stop. I have entire shares without any suppressed F ACE's, and other shares that I can't seem to make the suppressed ACE'sG go away. Also, if I rename the file, it MAY stop fiddling with the ACE. F I'm still at the consistantly inconsistant stage looking for THE clue.  E    Now to look into suppressed ACE's, site configuration and possible  share/directory issues.   D    It's all fun until the boss finds out that I won't let this go...       Duane    ------------------------------  # Date: Mon, 13 Mar 2006 20:54:04 GMT  From: d_gillbilly@hotmail.com H Subject: Re: Mysterious revision date changes caused by Advanced Server?8 Message-ID: <blmb12d4cnpikniamu7nf97gksl1mj5umv@4ax.com>  F On Mon, 13 Mar 2006 17:56:05 GMT, hoff@hp.nospam (Hoff Hoffman) wrote:  i >In article <ahp412hn756osl3a7tef27gescie2d6rbf@4ax.com>, D Gillbilly <gillbilly@ns.sympatico.ca> writes: @ >:My real problem is that something changes file revision dates. >.. = >:Now that it has happened on my development machine, I have  ? >:debris that I can work with and a pretty good idea on how to  E >:cause the problem. I just need to figure out what security/auditing D >:I need turned on to confirm my suspicions (I prefer books, so this# >:can wait until I return to work).  >.. ? >:In the example below, the only file that should have changed  A >:was the text file, but something also revised the executables.  H >:The text file was put into that directory using "save as" from a PC to0 >:an Advanced Server (PATHworks)  network share. > E >  Are you sure that the Windows boxes involved are not infected with E >  something?  Having something writing into Windows executables is a 5 >  common footprint for electronic vermin, of course.  >   F    Header updates are performed and recently deleted ACE's get readdedF are the only changes that I can see happening. It does seem to pick on; executables, but I have seen the odd header update to other E non-executable files, but I currently can't reproduce that behaviour.   D >  Also, are you sure that whatever application you are using on theD >  Windows system itself isn't also somehow modifying these files or >  the file headers. >   H    The only windows app that I can find that causes this failure (a textF editor), causes the update to the headers when it populates it's "saveH as" window and not when it actually does the save. That explains why theH revision dates predate the creation and revision date of the file that IF actually changed. If it always forced a header update, I would quicklyG blame the app. The app only picks on some files in some shares/folders.     E >  I will assume the contents of the files are NOT changing -- though 2 >  if they are, do see the first paragraph, above. >       Correct.   B >  Given what I've seen of directory operations, it also would notC >  surprise me to see the directory itself rewritten when something E >  was added to or changed within the directory -- directory shuffles C >  are fairly common on OpenVMS and on Windows, and it would not be B >  surprising to learn that some sequences involving Windows filesC >  and directories stored on a remote server can and do lead to the 8 >  host server's associated file headers being modified. >   @    I have seen directory revisions happen also. I can understand and explain that behaviour.   B >  You can see locality within the Windows directories using DUMP,C >  for instance -- the files aren't stored in any particular order, @ >  so they can end up in odd clumps, depending on who wrote what6 >  piece to do what when writing to the directories.   >  >  Not a big help, I know. >    > E    Actually, the "locality within the Windows directories", I think,  G explains the randomness of the files within a directory that get header  updates.  F    As Paul N has pointed out, these header updates are a result of theE system modifying or creating an ACE. I'm hoping that when I find out  * why this is happening, I can make it stop.  /    Again, thanks for your time and suggestions.       Still swimming upstream,        Duane     O > ---------------------------- #include <rtfaq.h> ----------------------------- L >    For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqO > --------------------------- pure personal opinion --------------------------- H >       Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com   ------------------------------  # Date: Mon, 13 Mar 2006 22:01:33 GMT # From: hoff@hp.nospam (Hoff Hoffman) H Subject: Re: Mysterious revision date changes caused by Advanced Server?2 Message-ID: <1ZlRf.4614$%W4.2073@news.cpqcorp.net>  X In article <blmb12d4cnpikniamu7nf97gksl1mj5umv@4ax.com>, d_gillbilly@hotmail.com writes:  F   I've done a little more digging.  Something on the client is openingF   the files, and Advanced Server is updating the ACE -- it may well beE   that the client is retrieving an icon, or other such bits, from the    file(s) involved.   N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  % Date: Mon, 13 Mar 2006 19:38:43 -0500 ' From: Dave Froble <davef@tsoft-inc.com> H Subject: Re: Mysterious revision date changes caused by Advanced Server?9 Message-ID: <edGdnWfMeK66jYvZnZ2dnUVZ_tednZ2d@libcom.com>    d_gillbilly@hotmail.com wrote:D > On Mon, 13 Mar 2006 19:01:44 GMT, "PEN" <paul.nunez.nosp@m.hp.com> > wrote: >  >  >>Hi,  >>N >>The Advanced Server will apply ACEs to files to track information pertinent M >>to Windows clients that is not maintained by OVMS (ie. file attributes and  N >>DOS file size).   The ACE will be updated whenever a client reads the file. J >>Though the client user may not have instructed the client to read these O >>files, Windows Explorer and other apps freely open/read the first x bytes of  L >>these files (perhaps only those with known file types?) to obtain certain N >>attributes/characteristics.  When AS closes such files, it updates the ACE, L >>which means the ACL is modified, which means the file header is modified, 0 >>which means the file revision date is updated. >>$ >>I bet that's what you're seeing... >> >>Paul   >> >  > 
 > Hi Paul, >  >    Good tip.   > @ >    These header updates do correspond to files with suppressedJ > PATHWORKS ACE's. If AS wants to set an ACE, I get a header update on theH > file. I can understand this. But why only selected files. And how do II > get this behavious to stop. I have entire shares without any suppressed H > ACE's, and other shares that I can't seem to make the suppressed ACE'sI > go away. Also, if I rename the file, it MAY stop fiddling with the ACE. H > I'm still at the consistantly inconsistant stage looking for THE clue. > G >    Now to look into suppressed ACE's, site configuration and possible  > share/directory issues.  > F >    It's all fun until the boss finds out that I won't let this go...
 >       Duane   ? Windows Explorer may be selective on the files it opens to get  J information.  The filename extension may be a key part of such a decision.  @ Windoz likes to think that it knows what it, and you, are doing.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 13 Mar 2006 11:34:40 -0700 " From: GreyCloud <mist@cumulus.com>& Subject: Re: need help with Flakey VLC0 Message-ID: <jIGdnTxZ7YW4IYjZRVn-ig@bresnan.com>   JF Mezei wrote:    > GreyCloud wrote: > G >>My guess is that the battery inside the Time Of Year clock is running 2 >>down and getting on the ragged edge so to speak.J >>I don't know where you can get new ones.  Too bad DEC didn't just have a >>battery socket instead.  >  >  > J > Not sure about that specific model, but whe the ROM detect a bad TOY, itG > resets the "non volatile ram" settings to some defaults.  So when you F > power up the machine, you would always have consistent settings, not > corrupted ones.  > I > Not sure about that model either, but many vaxes used a pack made up of F > 3 AAA ni-cd batteries soldered in series (1.2*3 = 3.6volts).  If youI > suspect your battery to be bad, GOSUB radio-shack, and then use the old > > battery's wire/connector and solder it to the new batteries. > G > I use some stretchy rubber tape to wrap the batteries, especially the = > ends and voila, your VLC will be good for another 10 years.   G I looked in this one and it is a little black box that may be soldered  I to the motherboard.  I was hoping someone had a supplier of these little   black boxes.     --   Where are we going?   And why am I in this handbasket?   ------------------------------  % Date: Mon, 13 Mar 2006 19:42:12 -0500 ' From: Dave Froble <davef@tsoft-inc.com> & Subject: Re: need help with Flakey VLC9 Message-ID: <edGdnWbMeK5rjYvZnZ2dnUVZ_tednZ2d@libcom.com>    GreyCloud wrote: > JF Mezei wrote:  >  >> GreyCloud wrote:  >>I >>> My guess is that the battery inside the Time Of Year clock is running 4 >>> down and getting on the ragged edge so to speak.L >>> I don't know where you can get new ones.  Too bad DEC didn't just have a >>> battery socket instead.  >> >> >> >>K >> Not sure about that specific model, but whe the ROM detect a bad TOY, it H >> resets the "non volatile ram" settings to some defaults.  So when youG >> power up the machine, you would always have consistent settings, not  >> corrupted ones. >>J >> Not sure about that model either, but many vaxes used a pack made up ofG >> 3 AAA ni-cd batteries soldered in series (1.2*3 = 3.6volts).  If you J >> suspect your battery to be bad, GOSUB radio-shack, and then use the old? >> battery's wire/connector and solder it to the new batteries.  >>H >> I use some stretchy rubber tape to wrap the batteries, especially the> >> ends and voila, your VLC will be good for another 10 years. >  > I > I looked in this one and it is a little black box that may be soldered  K > to the motherboard.  I was hoping someone had a supplier of these little   > black boxes. >  >   F Have you tried David Turner?  He recently posted about having similar 3 parts for Alpha, I think.  Might be the same thing.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 13 Mar 2006 20:09:56 -08003 From: "rsponholtz@gmail.com" <rsponholtz@gmail.com> & Subject: Re: need help with Flakey VLCC Message-ID: <1142309396.342216.165580@i39g2000cwa.googlegroups.com>   @ After fiddling around with the machine some more, I noticed someG patterns to the failures.  If I press on the connector for the graphics E card (yes, I have one), the machine will sometimes start up properly, C and run for some period of time.  I finally got another motherboard 5 (off ebay again), and the machine is reliable now....    ------------------------------    Date: 13 Mar 2006 16:32:49 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) * Subject: Re: Nodename in Accounting File ?3 Message-ID: <4j6xXb5bm48t@eisner.encompasserve.org>   w In article <dv4q7u$9q1$2@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:   ( > Can one have them off the system disk?  B Looking at the source listing ACCOUNT.LIS, it certainly looks likeD you could redirect with the logical name ACCOUNTNG, if you could get/ it defined before the Job Controller starts up.    ------------------------------  % Date: Mon, 13 Mar 2006 14:42:10 -0800 # From: "Tom Linden" <tom@kednos.com> $ Subject: Re: OPA0 Console connection( Message-ID: <ops6diokhnzgicya@hyrrokkin>  1 Let me summarize what I have undercovered so far.   @ firstly the COM1 port seems to be named TTA0 and the COM2  OPA0.J Why not just call them COM1 and COM2?  If you need to use the other names,E make them an alias.  Secondly, suggested remedy in the FAQ, in fact    disables loginI  from that port, so that is not the right approach.   So how to leave a    console K cable attached without crashing the system is still not solved.  BTW if I    leave , it attached to a W2K problem does not occur.    F On Mon, 13 Mar 2006 10:26:16 -0800, Tom Linden <tom@kednos.com> wrote:  H > On Mon, 13 Mar 2006 17:42:41 GMT, Hoff Hoffman <hoff@hp.nospam> wrote: > F >>   The OpenVMS Frequently Asked Questions (FAQ) section "How can I  
 >> preventF >>   a serial terminal line from initiating a login?" might be of someF >>   interest, here.  And maybe "Using REPLY/LOG from DCL? Disabling  
 >> ConsoleF >>   OPCOMs?", depending on what's initiating the chatter on the line. > I > Well I removed one end of the cable from the 7.3-1 and attached it to   	 > another J > node running 7.3-2 and don't see this behaviour, from which I conclude  
 > that theF > other node is "chattering" as you put it.  In the FAQ your remedy is > > >                     In SYSTARTUP_VMS.COM, issue the command: > @ >                     $ SET TERMINAL/NOTYPEAHEAD/PERMANENT ddcu: > K > Does imply a reboot is required?  SHOW TERM DDCU: reveals no such device. # > Can OPA0 be used instead of DDCU?  > 8 > BTW,  why is it on some nodes OPA0 and on others TTA0? > J >>  Oh, and a BREAK signal -- a serial line framing error -- or a [CTRL/P]? >>   in the data stream, depending on the box -- can halt the    >> configuration. K >>   See "Why does my system halt when I power-cycle the console terminal?"  >>   for related.  > L > Yes this did indeed happen over night, and required a powerdown, as even  	 > SRM was C > in an odd state, it didn't recognize any commands including init.    ------------------------------  # Date: Tue, 14 Mar 2006 00:10:22 GMT # From: hoff@hp.nospam (Hoff Hoffman) $ Subject: Re: OPA0 Console connection1 Message-ID: <ORnRf.4625$YW4.937@news.cpqcorp.net>   N In article <ops6diokhnzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:2 :Let me summarize what I have undercovered so far. : A :firstly the COM1 port seems to be named TTA0 and the COM2  OPA0. ( :Why not just call them COM1 and COM2?    A   Well, you can call them anything you want, of course.  OpenVMS  D   has always called the console port OPA0:, meaning -- if we changed@   it -- we'd tend to bust stuff.  (And we tend not to like to do   that when we can avoid it.)   @   Even more interesting, COM1 and COM2 don't always map the same?   way, as these can be an OP device or a TT device based on the     system firmware configuration.  : :If you need to use the other names, make them an alias.    '   What's an "alias", in this context?     C   If I wanted other names for a device, then I would tend to define A   site-specific logical names for the constructs -- but to define C   these tends to cause as many problems as it solves, as we learned @   back in MicroVAX days.  (Do see the MICROVAX subroutine withinA   SYLOGICALS.TEMPLATE.)  We still define these old logical names, @   as there is stuff around that still uses them -- but the names?   don't scale particularly well, and users and programmers then ?   eventually tend to use logical names or such to implement the ?   required mapping for the particular application requirements.   ?   Things are really getting interesting with devices and device >   naming and such, but that's fodder for another discussion --    and maybe one at the bootcamp.  1 :Secondly, suggested remedy in the FAQ, in fact   C :disables login from that port, so that is not the right approach.    H   It is the correct approach.  You have to disable the typahead to avoidH   the bouncing logins, and you need to enable it to get the login -- andI   having two ports back-to-back means you have to choose which one is the A   one that will originate, and which will receive the connection.   G So how to leave a console cable attached without crashing the system is I :still not solved.  BTW if I leave it attached to a W2K problem does not   :occur.   C   You just haven't seen the problem yet.  Anything that can or does =   generate a framing error on the line will trigger the halt.   D   My preference here is a terminal server, as it does what you want,A   and you can (relatively) secure it against unauthorized access, B   and you don't need to worry about which end of the connection isB   the initiating and which is the receiving.  (The terminal serverC   always initiates the connection to the console, meaning you don't 0   have to worry about folks connecting into it.)       N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  % Date: Mon, 13 Mar 2006 16:48:33 -0800 # From: "Tom Linden" <tom@kednos.com> $ Subject: Re: OPA0 Console connection( Message-ID: <ops6doi7fxzgicya@hyrrokkin>  F On Tue, 14 Mar 2006 00:10:22 GMT, Hoff Hoffman <hoff@hp.nospam> wrote:  J > In article <ops6diokhnzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com>  	 > writes: 4 > :Let me summarize what I have undercovered so far. > : C > :firstly the COM1 port seems to be named TTA0 and the COM2  OPA0. ( > :Why not just call them COM1 and COM2? > B >   Well, you can call them anything you want, of course.  OpenVMSF >   has always called the console port OPA0:, meaning -- if we changedB >   it -- we'd tend to bust stuff.  (And we tend not to like to do >   that when we can avoid it.)  > B >   Even more interesting, COM1 and COM2 don't always map the sameA >   way, as these can be an OP device or a TT device based on the " >   system firmware configuration.  L Just to make sure I understand,  of the two ports (in this case) one being   TTA0J and the other OPA0,  do I have to be on OPA0 to speak to SRM or can I also do it from TTA0? > : > :If you need to use the other names, make them an alias. > ' >   What's an "alias", in this context?  > E >   If I wanted other names for a device, then I would tend to define C >   site-specific logical names for the constructs -- but to define E >   these tends to cause as many problems as it solves, as we learned B >   back in MicroVAX days.  (Do see the MICROVAX subroutine withinC >   SYLOGICALS.TEMPLATE.)  We still define these old logical names, B >   as there is stuff around that still uses them -- but the namesA >   don't scale particularly well, and users and programmers then A >   eventually tend to use logical names or such to implement the A >   required mapping for the particular application requirements.  > A >   Things are really getting interesting with devices and device @ >   naming and such, but that's fodder for another discussion --" >   and maybe one at the bootcamp.  C Well it would be nice to have names like $9$dvd instead of $9$DQA0:   or $9$floppy instead of $9$DVA0: > 1 > :Secondly, suggested remedy in the FAQ, in fact D > :disables login from that port, so that is not the right approach. > J >   It is the correct approach.  You have to disable the typahead to avoidJ >   the bouncing logins, and you need to enable it to get the login -- andK >   having two ports back-to-back means you have to choose which one is the C >   one that will originate, and which will receive the connection.  > I > So how to leave a console cable attached without crashing the system is J > :still not solved.  BTW if I leave it attached to a W2K problem does not	 > :occur.  > E >   You just haven't seen the problem yet.  Anything that can or does ? >   generate a framing error on the line will trigger the halt. J OK, I understand, you can't leave it attached too long,  and how long is   that?  > F >   My preference here is a terminal server, as it does what you want,C >   and you can (relatively) secure it against unauthorized access, D >   and you don't need to worry about which end of the connection isD >   the initiating and which is the receiving.  (The terminal serverE >   always initiates the connection to the console, meaning you don't 2 >   have to worry about folks connecting into it.)C That would be my preference too, and ebay willing, it may happen:-)  >  > 4 >  ---------------------------- #include <rtfaq.h>   > ----------------------------- 5 >     For additional, please see the OpenVMS FAQ --    > www.hp.com/go/openvms/faq 6 >  --------------------------- pure personal opinion   > --------------------------- I >        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com  >    ------------------------------  + Date: Tue, 14 Mar 2006 00:24:16 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) $ Subject: Re: OPA0 Console connection( Message-ID: <dv52fg$rkk$1@pcls4.std.com>   etmsreec@yahoo.co.uk writes:  D >ddcu is intended to be the device name for the terminal so ddcu: is? >general shortform for OPA0: or TTB0: or TXA1: etc etc etc (I'm H >guessing, but probably wrong, at driver-driver-class-unitnumber so thatG >there are two letters for whichever driver is handling the device, one E >for the class or count - eg A, B, C, D etc - and the final character  >for the unit number.)  F >The console appears on AlphaServers with the console set to serial asG >OPA0: but for systems set up to have graphical consoles the device can F >be TTA0: or TTB0:, depending upon the model of AlphaServer concerned.  I It also depends on other serial ports, if any, in the system. For quite a J while, I had an Alphastation 200 with a PC ISA modem card in it. The modemF card appeared as TTA0:, the builtin COM ports were TTB0: and TTC0:.  I forget which was which.    ------------------------------  # Date: Tue, 14 Mar 2006 02:28:20 GMT # From: hoff@hp.nospam (Hoff Hoffman) $ Subject: Re: OPA0 Console connection2 Message-ID: <8TpRf.4631$M_4.3415@news.cpqcorp.net>  N In article <ops6doi7fxzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:G :On Tue, 14 Mar 2006 00:10:22 GMT, Hoff Hoffman <hoff@hp.nospam> wrote: C :>   Even more interesting, COM1 and COM2 don't always map the same B :>   way, as these can be an OP device or a TT device based on the# :>   system firmware configuration.  : M :Just to make sure I understand,  of the two ports (in this case) one being   K :TTA0 and the other OPA0,  do I have to be on OPA0 to speak to SRM or can I  :also do it from TTA0?  G   The ports are COM1 and COM2, and what the operating system calls them H   and what the firmware calls them and what the documentation calls themF   aren't necessarily tied together.  The settings vary.  I've tried toE   make that clear in the FAQ, and have further tried to make it clear I   what tends to modify the names.  Key factors can be the OpenVMS release G   involved and whether or not the console is set to SERIAL or GRAPHICS.   H   If it were easily solvable, this likely would already have been put to   bed, of course.   D :Well it would be nice to have names like $9$dvd instead of $9$DQA0:! :or $9$floppy instead of $9$DVA0:   *   You have that capability now, of course.  C   As for my preferences, I avoid physical device names where I can, ?   seeking to isolate these into SYLOGICALS.COM or into similar  ?   procedures or data stores.  (This makes my code more portable A   across the various OpenVMS I use boxes -- I already use logical A   names widely.)  I tend to use DISK$vollab volume labels where I @   can, and can and do use application-specific logical names (or6   some other data store) when required.  As mentioned.  H   FWIW, $ is also a character reserved to HP and to registered products,K   so I'd not use that in any site-specific logical names and in any files,  F   objects, logical names, etc., associated with unregistered products.  I   As for your own naming preferences, define your own logical names (sans J   the $ character), and use these to specifically identify your devices --F   what you're asking for here with these function-specific names seemsH   reasonable on its face, but it turns into a massively complex problem.H   You can easily set up KEDNOS_DVD or KEDNOS1_DVD1 or whatever you want,   of course.   	-=-  B   Physical device names are a convenience that is generated by theD   operating system to allow programmers and system managers (humans)E   to identify and to differentiate devices, of course -- and while we F   could certainly (try to) make these names prettier, we are currentlyC   using a device naming solution that is intended to generate both  E   short and unique names.   Names that are "pretty", cluster-unique,  F   reproducibly-generated when relatively small changes are made, *and*?   device-specific is a non-trivial problem to solve, after all.   F   As for why this is interesting, when you have a CD-R blank loaded inG   a DVD drive, for instance, it's going to call itself a CD-R currently G   and a dozen other things will be available as and when needed.   What E   do you want the algorithm to call it?   This further assumes we can G   get to the device to ask it what it is -- SCSI, USB and Fibre Channel H   devices can come and go, after all, and we depend on PACKACK and MOUNTG   to figure out what's out there.  Some devices don't appear until they D   have something to do -- and USB devices are really often just SCSI8   devices that can go "unavailable" at any given moment.  F   We punted this naming and device identification stuff some years agoG   (and particularly when y'all wanted to be able to connect anything to F   anything, without having to upgrade to have OpenVMS support), and weF   now simply ask the devices "what do you call yourself" where we can.F   We don't try to do much with that, other than to display it.  (We'reG   largely left with that MicroVAX subroutine stuff I mentioned earlier; E   with that SYLOGICALS.TEMPLATE stuff.)  Remember the old DT$ and DC$ E   codes?  With the dynamic device and dynamic system recognition, we  4   largely moth-balled those old built-in mechanisms.  C   Newer devices can have unique names, usually a WWID, UUID or GUID D   string -- but you don't want to have to enter these manually.  AndG   not all new devices have these -- or have anything unique -- present, F   and older and commodity devices -- such as those you and other folksG   are likely using -- simply don't have these identifying values widely D   available.  And we don't have -- barring device-local storage or aB   way to map the device serial number -- a construct which doesn'tE   exist for all devices -- back to a "pretty" name using a local data E   store.  (Then there's all the "fun" of initializing all that, too.)   E   And again, this device name is to allow humans to figure out where  F   the I/O goes -- OpenVMS itself doesn't need to have device names forC   correct operation.  (We don't have device names when we configure B   stuff, for instance.  We just need an algorthm that allows us toE   generate the requisite device name, and to ensure it's a relatively ,   consistently and uniquely generated name.)  D   We're doing further work in the general area of devices and deviceE   naming, but I'm not presently in a position to discuss that work -- D   and the results of that work probably won't affect this particular   case, in any event.     F :>   You just haven't seen the problem yet.  Anything that can or does@ :>   generate a framing error on the line will trigger the halt.  K :OK, I understand, you can't leave it attached too long,  and how long is    :that?  C   Just a little less than when that next framing error will arrive,    of course.  C   So long as communications and power and signals are stable, these A   sorts of connections tend to be stable.  When they go weird and B   the Alpha SRM console then sees the arrival of the framing error?   (the BREAK -- when enabled), the Alpha system will then halt.    	--   G   FWIW, Integrity servers largely solve the remote console access with  H   the available management processor (MP) option -- you can perform mostG   of the typical management operations entirely remotely, using the MP. E   The classic serial line connection is still around, particularly if ;   you do not have the MP installed in the Integrity server.    	--   D   Now if y'all will excuse me, I have a little open source code thatD   I'm working with and that I need to sort out, and the behaviour itC   is presently manifesting is just, um, well, something that I have E   yet to fathom.  (And as my build of that code is now finished, it's    off to plumb the depths...)   N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  % Date: Mon, 13 Mar 2006 18:43:47 -0800 # From: "Tom Linden" <tom@kednos.com> " Subject: Serial Console connection( Message-ID: <ops6dtu9g8zgicya@hyrrokkin>  F On Tue, 14 Mar 2006 02:28:20 GMT, Hoff Hoffman <hoff@hp.nospam> wrote:  I > :Just to make sure I understand,  of the two ports (in this case) one    > being I > :TTA0 and the other OPA0,  do I have to be on OPA0 to speak to SRM or    > can I  > :also do it from TTA0?H >  The ports are COM1 and COM2, and what the operating system calls themJ >   and what the firmware calls them and what the documentation calls themH >   aren't necessarily tied together.  The settings vary.  I've tried toG >   make that clear in the FAQ, and have further tried to make it clear K >   what tends to modify the names.  Key factors can be the OpenVMS release I >   involved and whether or not the console is set to SERIAL or GRAPHICS.   I With console set to serial are TTA0 and OPA0 interchangeable in the sense K that either could be used to talk to SRM?  I could check it out nect time    I have2 one down, but it is always better to visit Delphi.   ------------------------------  # Date: Tue, 14 Mar 2006 02:31:15 GMT   From: John Santos <john@egh.com>* Subject: SSL not working in CSWB... Solved* Message-ID: <TVpRf.5630$%e1.1063@trnddc05>  A There was an apparently corrupt file in my [._mozilla.default*.*] @ directory, namely one of the *.db files.  There are 3, CERT8.DB,B KEY3.DB and SECMOD.DB.  I renamed them all, and restarted Mozilla,= and it made new versions of these files and SSL (https://...) @ now works, and I didn't lose all my newsgroups, saved mail, etc.  B I have no idea what was wrong with them.  KEY3.DB was zero-length.; The new SECMOD.DB appears to be identical with the old one.   6 Any, thanks to everyone who put me on the right track.     --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 13 Mar 2006 22:19:45 +0100) From: maulis@ludens.elte.hu (Maulis Adam) 1 Subject: tcpip 5.5-11 ECO1 SSH server workarounds ! Message-ID: <bNQEIEFXveNG@ludens>    Hi!     ; Here is a patch/workaround for sys$welcome/ fta accporname  = functionality weeknesses of HP TCP/IP 5.5-11 ECO1 ssh server.     B If you want to see terminal access port info in the SHOW USER/FULLA listing (or something smilar eg. finger) there is a hack for you.   F If you want a working sys$welcome (motd) solution for that ssh server, also see this package.  2 http://ludens.elte.hu/ftp/vms/beta/sshpatch001.zip     Regards, Adam Maulis    ------------------------------  % Date: Mon, 13 Mar 2006 16:33:16 -0500 . From: "Carl Friedberg" <frida.fried@gmail.com>X Subject: Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required featuresI Message-ID: <890539d90603131333r631483d4o73fefbf90447a411@mail.gmail.com>    Phillip,  J This is a part of the New HP. It's not like the good old days with DSNLink and Digital and CSC.  1 The way HP/VMS engineering is working these days,   F (1) they are releasing a "roll-up" kit every six months (a good thing, IMHO);  < (2) they are making subsequent patches dependent on the mostB recent rollup (UPDATE) kit (a necessary feature, good or not); and  A (3) they've probably put in one or two patches (such as MQ) which A might not be mandatory, but we have to live with the new reality.   ? Will this new method of patching de-stabilize VMS? I can't say. = I am a bit unhappy that some patches, like the most SYS patch ? for VMS732, has a lot of patches rolled into it. Again, whether E this is good, or bad, is a matter of experience; only time will tell.   3 And, no word on the fate of the INSTAL kit, either.   = I'm hoping that the new PCSI kit fixes some of the corruption 9 issues we've had with the PCSI data base, which must have # been terrible if you got hit by it.    Sigh.    Carl Friedberg  4 On 3/11/06, Phillip Helbig---remove CLOTHES to reply( <helbig@astro.multiclothesvax.de> wrote:8 > I just downloaded VMS732_SYS-V0900.PCSI-DCX_AXPEXE and5 > VMS732_PCSI-V0200.PCSI-DCX_AXPEXE and had a look at I > VMS732_UPDATE-V0600.txt.  I came to the conclusion that I don't need to J > install VMS732_UPDATE-V0600 since I have already installed, individuallyH > or as parts of previous update kits, all of the patches I need.  ThereJ > are a couple I don't need, namely VMS732_MQ-V0400 and VMS732_DDTM-V0100.B > However, in the descriptions of these patches, there are certainI > products which are mentioned as REQUIRED features, namely in the former > > case IBM MQseries and in the latter case DECDTM,RDB,ACMS,XA. > J > Either these are not really features which are required for the patch toJ > be installed or these patches should not be part of an update kit, which) > "should be installed by all customers".  > J > I suspect the former is the case, i.e. these features are not "required"B > in order to install the patches, but rather there is no point inJ > installing them if one does not have these features.  Is that really the > case?  >  >    ------------------------------  # Date: Mon, 13 Mar 2006 23:03:15 GMT # From: hoff@hp.nospam (Hoff Hoffman) X Subject: Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features2 Message-ID: <TSmRf.4619$4S4.1618@news.cpqcorp.net>  w In article <duvefs$vm4$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: 7 :I just downloaded VMS732_SYS-V0900.PCSI-DCX_AXPEXE and 4 :VMS732_PCSI-V0200.PCSI-DCX_AXPEXE and had a look atH :VMS732_UPDATE-V0600.txt.  I came to the conclusion that I don't need toI :install VMS732_UPDATE-V0600 since I have already installed, individually G :or as parts of previous update kits, all of the patches I need.  There I :are a couple I don't need, namely VMS732_MQ-V0400 and VMS732_DDTM-V0100. B :However, in the descriptions of these patches, there are certain I :products which are mentioned as REQUIRED features, namely in the former  = :case IBM MQseries and in the latter case DECDTM,RDB,ACMS,XA.  : J :Either these are not really features which are required for the patch to J :be installed or these patches should not be part of an update kit, which ( :"should be installed by all customers". : J :I suspect the former is the case, i.e. these features are not "required" B :in order to install the patches, but rather there is no point in J :installing them if one does not have these features.  Is that really the  :case?  E   There are customer folks that want or that must have the latest and F   most current updates (for local requirements, or due to some problemC   that has been encountered), and there are those that (for any of  E   various and equally valid reasons) need or want to hang back and/or #   to select only specific ECO kits.   I   We've been going back and forth on this matter for some eons, now, too.   
   Put simply:        There is no right answer.        There is no general answer.        There is no best answer.  B   As such, we must look at our own ECO testing and release processC   here in OpenVMS Engineering -- the aggregate bandwidth around the B   creation, testing, packaging and release of ECO kits, as well asC   related work around reducing the numbers of problems entering the B   system, of course -- and then make a determination on how we can,   use this to best serve you, our customers.     The three major approaches:   =     1: We can do more and smaller ECO kits and deal with the  =        interactions and the permutations and the testing (and C        you can deal with these interactions and these dependencies, D        too, if we "miss" one -- we had this situation with the V7.1 E        (V7.1, V7.1-1H1 and V7.1-1H2) series, and the ECOs effectively F        led to the requirement for V7.1-2 and the PCSI work for ECOs),   @     2: we can do fewer and larger ECO kit (though obviously less        often), or   @     3: we can do has we've largely been for the past five or tenA        years now, and can generate small kits for specific fixes  @        and can then periodically generate roll-up kits that can *        serve as the basis for future work.  E   I really liked 1 until I slammed into all of the permutations, and  D   into factors such as the installation-ordering of the kits -- thisE   approach gets really hairy, and the permutations climb monstrously.   F   I don't like 2, as it slows down the release of fixes -- and thus itF   causes fixes to be blocked by other and potentially unrelated fixes.  F   That leaves 3.  New "point" ECO kits that involve some or all of theH   images in VMS732_UPDATE V6.0 and in various of the earlier "point" ECOC   kits will then tend to specify the VMS732_UPDATE V6.0 kit as the  G   prerequisite, rather than the "point" kit.   This approach allows the F   new ECO to be tested in a more contained environment, obviously, andC   it also simplifies the documentation and the prequisities-related D   processing within various tools, and it allows us to speed out theF   smaller kits and to then create, test and release the larger roll-up   kits.   G   The course I usually follow involves the installation of the specific H   and required point fixes (and any requisite local testing), and I thenF   install the roll-up (and again, perform any local testing involved).      N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  + Date: Mon, 13 Mar 2006 22:26:57 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)X Subject: Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features$ Message-ID: <dv4rjh$9q1$3@online.de>  H In article <1142287003.514279.158370@p10g2000cwp.googlegroups.com>, "Ian Miller" <ijm@uk2.net> writes:   ? > why bother faking. If you have all the patches installed then A > installing the UPDATE kit won't change anything except the PCSI  > database.   5 I had the impression that some future patch might say   @ %PCSI-E-UPDRQ, not all required UPDATE patches have been applied  I OK, you're saying the procedure is smart enough to notice that the stuff  B is already there and not re-install it.  OK.  But I still have to 8 download it and go through the trouble of installing it.   ------------------------------  + Date: Mon, 13 Mar 2006 22:36:13 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)X Subject: Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features$ Message-ID: <dv4s4t$9q1$4@online.de>  G In article <TSmRf.4619$4S4.1618@news.cpqcorp.net>, hoff@hp.nospam (Hoff  Hoffman) writes:     >     There is no right answer.  > ! >     There is no general answer.  >  >     There is no best answer.   I agree.  B >     3: we can do has we've largely been for the past five or tenC >        years now, and can generate small kits for specific fixes  B >        and can then periodically generate roll-up kits that can , >        serve as the basis for future work. > G >   I really liked 1 until I slammed into all of the permutations, and  F >   into factors such as the installation-ordering of the kits -- thisG >   approach gets really hairy, and the permutations climb monstrously.  > H >   I don't like 2, as it slows down the release of fixes -- and thus itH >   causes fixes to be blocked by other and potentially unrelated fixes. > H >   That leaves 3.  New "point" ECO kits that involve some or all of theJ >   images in VMS732_UPDATE V6.0 and in various of the earlier "point" ECOE >   kits will then tend to specify the VMS732_UPDATE V6.0 kit as the  I >   prerequisite, rather than the "point" kit.   This approach allows the H >   new ECO to be tested in a more contained environment, obviously, andE >   it also simplifies the documentation and the prequisities-related F >   processing within various tools, and it allows us to speed out theH >   smaller kits and to then create, test and release the larger roll-up	 >   kits.   H I agree that 3. is the best bet.  However, my concern is with something  else:   D > :However, in the descriptions of these patches, there are certain K > :products which are mentioned as REQUIRED features, namely in the former  ? > :case IBM MQseries and in the latter case DECDTM,RDB,ACMS,XA.  > : L > :Either these are not really features which are required for the patch to L > :be installed or these patches should not be part of an update kit, which * > :"should be installed by all customers". > : L > :I suspect the former is the case, i.e. these features are not "required" D > :in order to install the patches, but rather there is no point in L > :installing them if one does not have these features.  Is that really the  > :case?  C In other words, in the individual notes, it says (and English IS my H native language, so I don't think I'm misunderstanding it) in effect "inB order to install this patch, you must have installed the followingF software".  That's pretty much what "required" means.  No problem withG an individual patch---don't install it if you don't have the product it A patches---but these patches are in the UPDATE and could/should be = installed by folks who DON'T have these "required" products.    > If the software products aren't really required to install theF individual patches, but rather it is just that installing them withoutF the product they are supposed to patch will do nothing but clutter theF system but not break anything, then, OK, there is no harm, but I thinkF the wording should be changed, e.g. "you only need to apply this patchF if you have <software> installed; you can, however, install it withoutH having <software> installed, for example as part of an UPDATE patch, andD cause no harm to your system".  I suspect that most customers do not- have Rdb and do not have MQSERIES installed.    I Of course, a workaround would be for every VMS installation to include a   full Rdb installation.  :-)    ------------------------------  # Date: Mon, 13 Mar 2006 23:26:51 GMT   From: John Santos <john@egh.com>Y Subject: Re: VMS732_UPDATE-V0600,VMS732_MQ-V0400,VMS732_DDTM-V0100 and required features  , Message-ID: <%cnRf.39858$CI6.27982@trnddc07>  / Phillip Helbig---remove CLOTHES to reply wrote: I > In article <TSmRf.4619$4S4.1618@news.cpqcorp.net>, hoff@hp.nospam (Hoff  > Hoffman) writes:   >  >  >>    There is no right answer.  >>! >>    There is no general answer.  >> >>    There is no best answer. >  > 
 > I agree. >  > B >>    3: we can do has we've largely been for the past five or tenC >>       years now, and can generate small kits for specific fixes  B >>       and can then periodically generate roll-up kits that can , >>       serve as the basis for future work. >>G >>  I really liked 1 until I slammed into all of the permutations, and  F >>  into factors such as the installation-ordering of the kits -- thisG >>  approach gets really hairy, and the permutations climb monstrously.  >>H >>  I don't like 2, as it slows down the release of fixes -- and thus itH >>  causes fixes to be blocked by other and potentially unrelated fixes. >>H >>  That leaves 3.  New "point" ECO kits that involve some or all of theJ >>  images in VMS732_UPDATE V6.0 and in various of the earlier "point" ECOE >>  kits will then tend to specify the VMS732_UPDATE V6.0 kit as the  I >>  prerequisite, rather than the "point" kit.   This approach allows the H >>  new ECO to be tested in a more contained environment, obviously, andE >>  it also simplifies the documentation and the prequisities-related F >>  processing within various tools, and it allows us to speed out theH >>  smaller kits and to then create, test and release the larger roll-up	 >>  kits.  >  > J > I agree that 3. is the best bet.  However, my concern is with something  > else:  >  > D >>:However, in the descriptions of these patches, there are certain K >>:products which are mentioned as REQUIRED features, namely in the former  ? >>:case IBM MQseries and in the latter case DECDTM,RDB,ACMS,XA.   D Not true.  The MQ patch is required for MQSeries.  MQSeries is *NOT*B required for installing the MQ patch.  Same for the other patches.   >>: L >>:Either these are not really features which are required for the patch to L >>:be installed or these patches should not be part of an update kit, which * >>:"should be installed by all customers". >>:   ! They are not and never have been.       L >>:I suspect the former is the case, i.e. these features are not "required" D >>:in order to install the patches, but rather there is no point in L >>:installing them if one does not have these features.  Is that really the  >>:case? >   ! You are misreading the list under   <       INSTALL_2 : To be installed by all customers using the'                   following feature(s):           -  IBM MQSeries    A This does not say that "IBM MQSeries is to be installed by anyone C installing the patch".  It is saying the "INSTALL 2" rating applies ? to anyone using the listed features (the list consisting of one  element, IBM MQSeries.)   ? "INSTALL Rating 2" applies to patches that are only required if = certain optional features or layered products are being used. B If you are using the optional feature, then the patch is required.+ If you are not, then the patch is optional.   = (Rating 1 patches are required for all customers and rating 3  patches are optional.)       > E > In other words, in the individual notes, it says (and English IS my J > native language, so I don't think I'm misunderstanding it) in effect "inD > order to install this patch, you must have installed the followingH > software".  That's pretty much what "required" means.  No problem withI > an individual patch---don't install it if you don't have the product it C > patches---but these patches are in the UPDATE and could/should be ? > installed by folks who DON'T have these "required" products.   >   B The patch doesn't patch MQSeries.  It fixes a system facility used by MQSeries.  @ > If the software products aren't really required to install theH > individual patches, but rather it is just that installing them withoutH > the product they are supposed to patch will do nothing but clutter theH > system but not break anything, then, OK, there is no harm, but I thinkH > the wording should be changed, e.g. "you only need to apply this patchH > if you have <software> installed; you can, however, install it withoutJ > having <software> installed, for example as part of an UPDATE patch, andF > cause no harm to your system".  I suspect that most customers do not/ > have Rdb and do not have MQSERIES installed.   >   A It shouldn't be changed to say that because it already says that.     K > Of course, a workaround would be for every VMS installation to include a   > full Rdb installation.  :-)  >      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 13 Mar 2006 21:44:19 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>. Subject: Re: [F$GETQUI] Please explain RAD ;-)+ Message-ID: <44163C13.905BBB36@comcast.net>     Peter 'EPLAN' LANGSTOEGER wrote: > O > Please, can someone explain this behaviour I just saw (OpenVMS Alpha V7.3-2):  > F > $ WRITE SYS$OUTPUT F$GETQUI ("DISPLAY_QUEUE", "RAD", "$1_job_batch") > 0 $ > $ SHOW QUEUE/ALL/FULL $1_JOB_BATCH, > Batch queue $1_JOB_BATCH, idle, on NODE3::6 >   /BASE_PRIORITY=4 /JOB_LIMIT=20 /OWNER=[VMS,SYSTEM]! >   /PROTECTION=(S:M,O:D,G:R,W:S)  > $!  > $ SET QUEUE/RAD=0 $1_job_batch$ > $ SHOW QUEUE/ALL/FULL $1_JOB_BATCH, > Batch queue $1_JOB_BATCH, idle, on NODE3::6 >   /BASE_PRIORITY=4 /JOB_LIMIT=20 /OWNER=[VMS,SYSTEM]( >   /PROTECTION=(S:M,O:D,G:R,W:S) /RAD=0F > $ WRITE SYS$OUTPUT F$GETQUI ("DISPLAY_QUEUE", "RAD", "$1_job_batch") > 0   > $ SET QUEUE/NORAD $1_JOB_BATCHE > $ WRITE SYS$OUTPUT F$GETQUI ("DISPLAY_QUEUE","RAD", "$1_job_batch")  > -1 > L > Why did F$GETQUI display "0" first, while SHOW QUEUE did not display /RAD?H > (I assume, /RAD wasn't set - as it is not required, but can't be sure) > I > Or in other words, one can't rely on F$GETQUI RAD??? Don't think so (at M > least I hope one can rely on lexical functions). So, where could be my bug?   H My question would be: What does G$GETQUI return for a queue that's never had a RAD set on it?  G Between that and the -1 response, it seems fairly straight-forward what 6 to expect, even if the doc. is not 100% clear on this.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   End of INFO-VAX 2006.145 ************************