1 INFO-VAX	Sun, 18 Jul 2004	Volume 2004 : Issue 394       Contents: 68 pin SCSI on 50 pin SCSI bus" Re: 68 pin SCSI on 50 pin SCSI bus" Re: Audit Trail of Interactive DCL Re: DECnet question  Re: DECnet question 1 Re: HSx ECB (cache battery) troubleshooting/specs 1 Re: HSx ECB (cache battery) troubleshooting/specs 1 Re: HSx ECB (cache battery) troubleshooting/specs 1 Re: HSx ECB (cache battery) troubleshooting/specs ) Itanium Licensing and Hobbyist on Itanium   Re: LOGIN.COM comparison utility Re: OpenVMS security?  Re: OpenVMS security?  Re: What could have been ... Re: What could of been ...  F ----------------------------------------------------------------------    Date: 17 Jul 2004 14:52:53 -0700/ From: stuie_norris@yahoo.com.au (Stuart Norris) ' Subject: 68 pin SCSI on 50 pin SCSI bus = Message-ID: <51262235.0407171352.4a97d539@posting.google.com>   
 Hello All,  % I have an Alpha station 200i 4/100.     O I am finding it very hard to get 50 pin SCSI disks that are good enough to use.   6 I have several RZ29 drives with a 68 pin interfaces.    T If I buy a female 50 pin to female 68 pin SCSI adapter can I connect this adapter toQ the mother board and run the 68 pin drives.  The 68 pin SCSI cable I have states  < that all the drives including the last must be unterminated.  , From a gender point of view this will work.   ) Will this work from a SCSI point of view?    Stuart   ------------------------------  + Date: Sat, 17 Jul 2004 23:33:00 +0000 (UTC) 1 From: Jefferson Humber <matrix01@globalnet.co.uk> + Subject: Re: 68 pin SCSI on 50 pin SCSI bus / Message-ID: <cdccvc$lgb$1@titan.btinternet.com>   / BlackBox sell internal SCSI adapters for HDD's.   I We have bought 80pin -> 50pin & 68pin -> 50pin adapters that simply plug   onto the back of the drive.   $ Haven't used them on Alpha's though.   Jeff     Stuart Norris wrote: > Hello All, > ' > I have an Alpha station 200i 4/100.    > Q > I am finding it very hard to get 50 pin SCSI disks that are good enough to use.  > 8 > I have several RZ29 drives with a 68 pin interfaces.   > V > If I buy a female 50 pin to female 68 pin SCSI adapter can I connect this adapter toS > the mother board and run the 68 pin drives.  The 68 pin SCSI cable I have states  > > that all the drives including the last must be unterminated. > . > From a gender point of view this will work.  > + > Will this work from a SCSI point of view?  >  > Stuart   ------------------------------    Date: 17 Jul 2004 17:03:49 -05004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)+ Subject: Re: Audit Trail of Interactive DCL 3 Message-ID: <+kQ1rMEjWrYu@eisner.encompasserve.org>   _ In article <926edf3b.0407141758.643c0457@posting.google.com>, lsk55@hotmail.com (Scott) writes: H > I have a command procedure that simulates the DCL command line prompt,H > logging everything that the user types.  It works great, except that IG > lose up-arrow and RECALL.  I don't want to use ACCOUNTING because the I > information I want to track is really pretty minor and I don't want the I > the overhead.  I don't want to use a pseudo-terminal because it creates I > another process (I've got over 2,000 users on a single Alpha.)  But I'd , > sure like to get up-arrow and RECALL back! > H > So does anyone have any ideas about how I can track just what is typedG > in at the DCL prompt in interactive mode?  (Is there a hook I can use  > in the CLI or something?)   / What about capturing the command recall buffer?   1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  O  Save Model Rocketry from the HSA!   http://www.space-rockets.com/congress.html    ------------------------------  % Date: Sat, 17 Jul 2004 13:52:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: DECnet question, Message-ID: <40F9673B.D6B4B256@teksavvy.com>   Jay Olson wrote:I > Perhaps you misunderstood my qustion. I am asking about what parameters G > control when a $QIOW write to a DECnet channel will succeed/complete.    I am not 100% certain of this.  5 If I compare this to mailboxes, this is how it works:   L When you create a mailbox, you define its maximum size. This size is limitedK by the BUFQUO  limit in your UAF (account) definition. If nobody reads from M the mailbox, you can write up to its mailbox buffer size, after which a $QIOW L will go into LEF until someone reads from the mailbox. (a $QIO without the W would go into RWMBX state).   K With DECNET, it is slightly different since there are more buffers involved R (outbound and inbound). But I suspect that BUFQUO would also be a limiting factor.  J Try to do a SHOW PROC/ALL/ID=xxxxxxx for the sending process and receivingM processes as the buffers fill up and you should be able to see which resource  (likely BUFQUO) is depleted.   ------------------------------  # Date: Sun, 18 Jul 2004 00:55:35 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu> Subject: Re: DECnet question. Message-ID: <bUjKc.106626$IQ4.86742@attbi_s02>   Jay Olson wrote:J > Perhaps you misunderstood my qustion. I am asking about what parameters H > control when a $QIOW write to a DECnet channel will succeed/complete. I > TCP/IP has nothing to do with the problem. I can reproduce the problem  K > by suspending the process on the other end or by sitting in the debugger.    Maybe, or maybe not.  > If it is a TCP property then it might be that the intermediate< program puts data into TCP's buffers but isn't notified thatF it isn't going anywhere.  If such information isn't passed from TCP to? the TCP/DECnet program, it can't be passed back through DECnet.     That is all I was trying to say.   -- glen    ------------------------------  # Date: Sat, 17 Jul 2004 18:38:39 GMT / From: "Richard L. Dyson" <rick-dyson@uiowa.edu> : Subject: Re: HSx ECB (cache battery) troubleshooting/specs( Message-ID: <40F97234.5090100@uiowa.edu>  D I refurbished an RA450 that used those kind of batteries.  I found aD UK company that would sell me 2 brand new batteries for about 21 GBPB plus 20 GBP shipping.  It came to ~63 GBP which was USD$107 to me.C Compared to every place I found them listed in the US, they were as C much as $300.  Apparently they were the original makers of them for  Digital in the first place.   > It was MDS Battery.  http://www.mdsbattery.co.uk/defaultuk.asp  E NOTE: Be careful about the circuit board.  I replaced one battery and G accidentally plugged in the connector backwards and apparently blew the G board.  I had to buy an entire BA350 shelf with a PS and battery module H on EBAy for an additional $25 + S/H to get a replacement board (and dead, batteries, but I also got the BA350 and PS!)   Rick   Duncan Brown wrote: H > (Self-reply...)  I dissected one of the battery packs more thoroughly H > and did some more googling based on what I found, and I now know that ; > indeed those batteries are below-spec and need replacing.  > > > Each "battery" is really two Hawker Cyclon 2V 5.0AH X Cells E > shrinkwrapped together and wired in series to produce a nominal 4V  G > stick.  The part number is 0800-0004, and the cheapest place I could   > find them online is  > A > http://www.gotbatteries.com/ProductPage.asp?ProductNum=37L142S1  > H > The manufacturer's website is hard to track down but here is the page  > for these batteries: > . > http://www.enersysreservepower.com/cyc_b.asp > F > Note the application manual .pdf link at the bottom, that gives the K > specs that show that 4.15V is simply not enough for a 2-cell stick to be  K > called well-charged.  It also mentions the life characteristics on these  I > things and even if DEC designed their charging circuit perfectly these  K > things would only be good for a few hundred discharge/recharge cycles. I  J > guess it becomes clear why they don't last more than a few years in use. > F > I went ahead and ordered 6 batteries to get the price break - in an H > unused state they have a long shelf life, so I'll be all set the next J > time they die.  Now I just get to have the fun of trying to rebuild the K > stick of two batteries, keeping the shrink tubing thin and smooth enough  ? > to be able to fit the stick back in the frame.  Wish me luck!  >  > Duncan     --  J Richard L. Dyson                                      rick-dyson@uiowa.eduK   _   _  _____                      http://www-pi.physics.uiowa.edu/~dyson/ J | | | ||_   _|  Senior Systems Analyst   --   INFORMM-Cerner Systems Group< | | | |  | |    The University of Iowa Hospitals and ClinicsJ | \_/ | _| |_   Information Systems Dept. BT1000 GH   Office: 319/384-7016K   \___/ |_____|  Iowa City, IA 52242-1052                 FAX: 319/384-7020 E                  (Consulting to the Physics and Astronomy Department)    ------------------------------  % Date: Sat, 17 Jul 2004 14:52:02 -0700 / From: Duncan Brown <brown_du@encompasserve.org> : Subject: Re: HSx ECB (cache battery) troubleshooting/specs2 Message-ID: <EfqdnZiTKL7aHmTd4p2dnA@speakeasy.net>   David J Dachtera wrote: J > Good luck. Rumor has it that cache batteries turn to mush if they're not3 > kept charged, ragardless of the voltage readings.   @ Yes, part of the spec says not to let them dip below 1V, or bad D unrecoverable chemical things happen inside.  I assume when they're I first made they either have no charge whatsoever, or they keep it a long  G time with no load on them, because the unused, as-purchased shelf life  H is actually pretty long.  Clearly, though, buying used HSX battery unitsG is a near guarantee of receiving mushy batteries, if they haven't been  F shut down properly.  Not a very user-friendly design, that's for sure.   Duncan   ------------------------------  % Date: Sat, 17 Jul 2004 14:57:40 -0700 / From: Duncan Brown <brown_du@encompasserve.org> : Subject: Re: HSx ECB (cache battery) troubleshooting/specs2 Message-ID: <T9udnermKbgEGWTd4p2dnA@speakeasy.net>   Richard L. Dyson wrote:   F > I refurbished an RA450 that used those kind of batteries.  I found aF > UK company that would sell me 2 brand new batteries for about 21 GBPD > plus 20 GBP shipping.  It came to ~63 GBP which was USD$107 to me.E > Compared to every place I found them listed in the US, they were as E > much as $300.  Apparently they were the original makers of them for  > Digital in the first place.  > @ > It was MDS Battery.  http://www.mdsbattery.co.uk/defaultuk.asp  H They carry the separate cells for a little over $12 US, while the place F I linked to is under $8 US.  I don't see a part number for the 2-cell E assembly on their site, so that must have been a custom construction   they quoted you.  I Since I have the old dead battery, I'm simply going to use the wires and  I connectors and construction technique from the old one to make a new one  G with new cells, for about $16 each.  The only stumbling block I see at  C all is the fact that they used really thin plasticy shrink tubing,  F whereas the stuff I usually get is thicker and rubberier, and may not $ fit as well inside the little frame.   Duncan   ------------------------------    Date: 17 Jul 2004 17:10:42 -05004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow): Subject: Re: HSx ECB (cache battery) troubleshooting/specs3 Message-ID: <Njf1QqgCT32D@eisner.encompasserve.org>   ` In article <40F89A49.79DE2D76@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes:J > Good luck. Rumor has it that cache batteries turn to mush if they're not3 > kept charged, ragardless of the voltage readings.   K That's been my experience. They have an in-use life of about 2 years, and a I sit on the shelf life of at most a few months. Lead Acid needs to be kept  fully charged or it's trash.  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  O  Save Model Rocketry from the HSA!   http://www.space-rockets.com/congress.html    ------------------------------  % Date: Sat, 17 Jul 2004 23:55:59 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>2 Subject: Itanium Licensing and Hobbyist on Itanium5 Message-ID: <40f9ae73$0$7801$db0fefd9@news.zen.co.uk>   G With some of the talk about what will (and will not) be included in the L different licensing options with Itanium and the comments about it not beingF definitively decided yet, I had a look around on an pre 8.2 base level machine.  F The products in the different categories were no shock and as previousG stated by hp, but looks like hobbyists won't have to load quite so many H licences any more, and more importantly shows that they are committed to6 catering for hobbyist's from the start. Well done hp..   From the early 8.2 box...       FOE     Foundation 1    OPENVMS-I64,OPENVMS-USER,DVNETEND,DW-MOTIF,UCX :    TDC,DCOM-MIDL,X500-ADMIN-FACILITY,X500-DIRECTORY-SERVER      EOE     Enterprise     DECRAM,RMSJNL,VOLSHAD,SYSMGT       MCOE    Mission Critical '    RTR-SVR,VMSCLUSTER,VMSCLUSTER-CLIENT       HOE     Hobbyist     OPENVMS-HOE  L It has been documented prior that each category will also include everything from the preceding categories.   Alex   ------------------------------  % Date: Sat, 17 Jul 2004 13:02:00 -0500 ( From: brandon@dalsemi.com (John Brandon)) Subject: Re: LOGIN.COM comparison utility 1 Message-ID: <04071713020067@dscis6-0.dalsemi.com>    D.J.D. writes:C > I did that in DCL about eight or nine years ago. I may be able to I > resurrect the code from the many archives I've kept, if you REALLY want  > it.   M It may be useful to look at for point of reference.  My thought process is to F develop a process by which I read each login.com and create a database/ consisting of symbols and associated usernames.   Q > > I have a legacy system that some dev/admin had the great idea to add the same * > > symbols (etc) to each users LOGIN.COM. > $ > Typical "cut and paste" mentality.  M Got that right - and the "You can consolidate, really?" or "You can do that?"   mentalitty (or ignorance).   Q > > My mission is to go out and consolidate these symbols (etc) into the SYLOGIN.  >  > PLEASE!!! NOT SYLOGIN!!! > I > If you must consolidate, put them in a separate .COM file and invoke it H > in LOGIN, perhaps conditionally based on whatever criteria make sense. > F > Best not to clog up SYLOGIN with application specific stuff (not all > users will need it).  I Whoa - I am not a person who likes to clutter - sometimes babble, but not  clutter!  E I was thinking of creating a login process that will check for rights L identifiers and execute a specific code for that user.  When I say SYLOGIN ID my meaning is the system login process not SYLOGIN.COM specifically.       J*o*h*n B*r*a*n*d*o*n  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Sat, 17 Jul 2004 14:02:12 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: OpenVMS security?, Message-ID: <40F9699C.D4F4D030@teksavvy.com>   Bob Ceculski wrote: N > VMS is/was written in a variety of languages including fortran, pascal, pl1,G > bliss, etc.  I believe very little "c" garbage is part of the kernel.   J I believe that with the port to Alpha, PL1 code was removed. (As I recall,J Monitor had to be rewritten when ported to Alpha due to lack of PL1 in the early days).  H Anmd in terms of "c garbage", this is not an appropriate statement. LikeI Bliss, Cobol, Fortran, Macro, C can use descriptors, and in fact, for any L privileged code, it must not make use of the C run time library and must useK the "secure/trusted" system routines to perform IO or other functions. As a H result, for privileged code, C would be just as secure as Bliss or otherK languages simply because it would end up using the same structures and same $ system services to get the job done.  K You should also know that which VAX-C had many detractors, DEC-C has a very N pedantic compiler that can force a lot of discipline in the programmer (unlessB he uses switches to specifically reduce/remove the pedantic mode).    L The language isn't really the issue. It is the discipline of the programmersN as well as operating system standards that make a huge difference. VMS has hadF established standards for calling subroutines from any language in anyM language, and well documented rules on how to write privileged programs, user 0 written system services etc etc for a long time.    K The problem with Windows is that its programmers were educated in a mindset M that you had to bypass the OS and do stuff yourself, and its documentation is N incomplete, lacks proper standards, and has a lot of lazy programmers who justN prefer to require a program to be installed with all mighty provileges insteadK of spending time to design an application architecture that doesn't require  all those privs all the time.   G On VMS, because customers have had serious system managers, application M writers have had to justify the use of privileges to make sure that their app K doesn't interfere with other apps. On Windows, because system managers were H inexperienced with real systems, they just pointed and clicked during anJ install wizard, not knowing what what being done in the background and notK realising that an application was granting itself whatever privs it wanted.   @ Attitude is far more important than programming language itself.   ------------------------------  # Date: Sat, 17 Jul 2004 22:13:38 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger)  Subject: Re: OpenVMS security?L Message-ID: <rdeininger-1707041819370001@user-105n8t3.dialup.mindspring.com>  J In article <Hoadnc3EK9GZ3mTdRVn-hg@igs.net>, "John Smith" <a@nonymous.com> wrote:   >Robert Deininger wrote:? >> In article <AMWdnWKtYYEgnWTdRVn-ig@comcast.com>, Undisclosed + >> <nomail@dontbeaweaselspammer.com> wrote:  >>	 ><<snip>>  >   F >> I think a lot can be done to help VMS, quicker, cheaper, and easier >> than porting to Opteron.  >  > E >Like taking the money an Opeteron port would cost and devoting it to  >VMS-exclusive advertising?   H I think some advertising would be helpful, yes.  But maybe not THAT much advertising.    ? >>> I'd love to see more competition in the OS marketplace, and F >>> aggressively pricing OpenVMS as a solid server while putting it on< >>> real commodity hardware might win OVMS a lot more users. >>I >> Well, if I was in charge I'd try to make VMS dirt cheap on entry-level E >> systems.  This is a business decision that's pretty independent of G >> what hardware VMS runs on.  Alpha, Itanium, or Opteron, the decision 	 >> on VMS " >> price points would be the same. >  > > >I like your thinking. Maybe we should put you in-charge?  :-)   Don't hold your breath. :-)    ------------------------------  % Date: Sat, 17 Jul 2004 14:03:44 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: What could have been ... , Message-ID: <40F969F7.50AA6AEA@teksavvy.com>   Bob Ceculski wrote:  >  > if I owned OpenVMS ...    K You'd stop using the really silly "open" word from day one. And market your K product to make sure you maximised the return on your investment to buy VMS  from its previous owners.    ------------------------------  % Date: Sat, 17 Jul 2004 12:51:13 -0700  From: Z <z@no.spam> # Subject: Re: What could of been ... 0 Message-ID: <10fj0p9f5i68k9f@corp.supernews.com>   Bob Ceculski wrote:   >Re: What could of been ...   What could HAVE been.    ------------------------------   End of INFO-VAX 2004.394 ************************