1 INFO-VAX	Sun, 20 Mar 2005	Volume 2005 : Issue 157       Contents:: (",) Do You Want To Know For Sure You Are Going To Heaven?> Re: (",) Do You Want To Know For Sure You Are Going To Heaven?, Re: Are RZ29B and RZ28D supposed to be LOUD?) DECnet, LAT, Cterm over IP/GRE - Timeout? - Re: DECnet, LAT, Cterm over IP/GRE - Timeout?  Memory for PWS500a Re: Memory for PWS500a Re: Memory for PWS500a Re: VMS 8.2 for VAX  Re: VMS 8.2 for VAX  Re: VMS 8.2 for VAX  Re: [Announce] FreeVMS 0.1.3  F ----------------------------------------------------------------------    Date: 19 Mar 2005 15:23:29 -0800 From: Ron038547@yahoo.com C Subject: (",) Do You Want To Know For Sure You Are Going To Heaven? C Message-ID: <1111274609.938878.192510@z14g2000cwz.googlegroups.com>   8 http://www.want-to-be-sure.blogspot.com << Click On Link   ------------------------------   Date: 19 Mar 2005 23:48:17 GMT$ From: "Doc." <doc@openvms-rocks.com>G Subject: Re: (",) Do You Want To Know For Sure You Are Going To Heaven? 6 Message-ID: <Xns961F841B5CFEdcovmsrox@212.100.160.126>  7 %NEWS-I-NEWMSG,  wrote in news:1111274609.938878.192510  @z14g2000cwz.googlegroups.com   : > http://www.want-to-be-sure.blogspot.com << Click On Link  H Heaven?  Nah, you're going to the nearest spam reporting site.  I don't  even care if it is in the sky.     Doc. --  G OpenVMS:     Eight out of ten hackers prefer *other* operating systems. G http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.    ------------------------------  % Date: Sat, 19 Mar 2005 19:14:07 -0500  From: "DavidT" <david@hpaq.net> 5 Subject: Re: Are RZ29B and RZ28D supposed to be LOUD? 0 Message-ID: <113pffs4uiq8fdb@news.supernews.com>  / we're giving away... yes, giving away 4gb disks - you shoould take some - they are pretty quiet    --     david  Island Computers US Corp 2700 Gregory St Suite 180  Savannah GA 31404  Tel: 912 4476622 Fax: 912 201 0402  Email: dbturner@icusc.com     ; "Ralph Aichinger" <ralph@dolphy.pangea.at> wrote in message ( news:1078771184.415794@news.liwest.at...0 > I know, this is not a strict VMS question, but3 > I think there might be knowledgeable people here:  > 1 > I just got an AlphaStation 255 with 2 disks and 3 > a CD-Rom. It is unbelievably loud. It sounds like 0 > a dentist's drill as soon as the disks spin up5 > (or I suppose it is the disks giving these noises).  > 2 > When I switch it of, I hear a slow spinning down0 > (so I think it can't be a fan, that would stop > almost instantly IMHO).  > 1 > Is this normal for RZ29B and RZ28D disks (there 2 > is Linux on this machine and these are the names1 > i get in "dmesg")? Or are they possibly broken?  > 2 > These disks are 2GB SCSI or something like this. > 3 > As loud as it is now, this machine may be used as 1 > a server in some rack, but for use on a desk it 3 > is simply unbearably loud (unless you play *very*   > loud music all day I suppose). > 3 > Any comments appreciated! Nice machine otherwise, $ > maybe a bit large for a "desktop". >  > /ralph   ------------------------------  # Date: Sun, 20 Mar 2005 05:19:29 GMT - From: Scott Fisher <scott.fisher@remmele.com> 2 Subject: DECnet, LAT, Cterm over IP/GRE - Timeout?7 Message-ID: <BJ7%d.11507$gx3.657@tornado.rdc-kc.rr.com>    All,  C (Warning, this may be a bit long, but we did lots of testing and I   wanted to present some facts).  	 Question: F Could we be timing out a DECserver (DS100, DS200) or Cterm across WAN E (T1) and if so, what timers might I check?  Or, do you have a better   idea on my problem?   
 Situation:G We have a WAN (T1) with Alphas, DECservers (DS100, DS200), and windows  H boxes.  Everything is fine.  We run IP, DECnet, MOP, etc across the wan G without problems.  The DS100 downloads across the wan without problem.  F We want to move to MPLS which requires that all packets are IP  thus E the problem with the DS100 and DECnet.  We have an older application  F that requires VTs and attached printers and it will not be going away I for a few years.  Also, we rely on VMS Copy, Cterm, and submit/remote on  H the remote alphas.  I know we can do things with ftp, telnet, dcl, etc, 3 but it would be nice not to have to mess with that.    Testbed:H We can, in principle, do the IP thing (yes, with LAT too), by using GRE 7 on our routers.  We have created the following testbed:   5 Alpha-A, DS100, DS200, Router -cable- Router, Alpha-B   @ Running the routers back to back in our lab.  It is running and   basically functions (see below).   Facts:C 1.  We can boot the DS100 and it will download from Alpha-B (i.e.,  , across the network). Works 100% of the time.  E 2.    From VT on DS100, we can connect to Alpha-A just fine.  We can  ? leave it logged in all day just sitting there and it will stay   connected.  No problems at all. H 3.    We can connect from same VT to Alpha-B (across the MPLS with GRE) H and it will connect just fine.  PROBLEM:  After about 20-30 minutes, it H will disconnect from the service  the VT will talk to the DS100, but D we are logged out of alpha-B.  This problem happens at varying time  intervals but 100% of the time. G 4.    From VT on DS100, connect to Alpha-A, then $set host alpha-A (to  & itself).  Works fine, stays connected.B 5.    From VT on DS100, connect to Alpha-A, the $set host alpha-B G (across the network), connects fine, but times out after 5-30 minutes.  / Again, times vary but happens 100% of the time. G 6.    Copy large from Alpha-A to Alpha-B, it ran for 3 hours (big file  1 for testing), and no problem at all.  No timeout. I 7.    From VT on DS100, connect to Alpha-A, then $telnet to Alpha-B.  No  ' problem, no timeout  ran for 1.5 days. F 8.    Take all of this and do it in reverse to prove that it is on an / alpha-a or alpha-b question.  Results the same.   G So, it seems like we have some kind of a timeout going on, but I cant  D think of where to go next.  I apologize for the long message, but I  think the data is important.   TIA  Scott    ------------------------------  % Date: Sun, 20 Mar 2005 00:38:04 -0500 - From: "John E. Malmberg" <wb8tyw@qsl.network> 6 Subject: Re: DECnet, LAT, Cterm over IP/GRE - Timeout?1 Message-ID: <nZOdnTJ4Y_aikaDfRVn-pA@adelphia.com>    Scott Fisher wrote:  > All, > E > (Warning, this may be a bit long, but we did lots of testing and I    > wanted to present some facts). >  > Question: H > Could we be timing out a DECserver (DS100, DS200) or Cterm across WAN G > (T1) and if so, what timers might I check?  Or, do you have a better   > idea on my problem?  >  > Situation:I > We have a WAN (T1) with Alphas, DECservers (DS100, DS200), and windows  J > boxes.  Everything is fine.  We run IP, DECnet, MOP, etc across the wan I > without problems.  The DS100 downloads across the wan without problem.  H > We want to move to MPLS which requires that all packets are IP  thus G > the problem with the DS100 and DECnet.  We have an older application  H > that requires VTs and attached printers and it will not be going away K > for a few years.  Also, we rely on VMS Copy, Cterm, and submit/remote on  J > the remote alphas.  I know we can do things with ftp, telnet, dcl, etc, 5 > but it would be nice not to have to mess with that.  > 
 > Testbed:J > We can, in principle, do the IP thing (yes, with LAT too), by using GRE 9 > on our routers.  We have created the following testbed:  > 7 > Alpha-A, DS100, DS200, Router -cable- Router, Alpha-B  > B > Running the routers back to back in our lab.  It is running and " > basically functions (see below). >  > Facts:E > 1.  We can boot the DS100 and it will download from Alpha-B (i.e.,  . > across the network). Works 100% of the time. Brief use of MOP protocol.    G > 2.    From VT on DS100, we can connect to Alpha-A just fine.  We can  A > leave it logged in all day just sitting there and it will stay  ! > connected.  No problems at all.    Exclusively LAT protocol.   J > 3.    We can connect from same VT to Alpha-B (across the MPLS with GRE) J > and it will connect just fine.  PROBLEM:  After about 20-30 minutes, it J > will disconnect from the service  the VT will talk to the DS100, but F > we are logged out of alpha-B.  This problem happens at varying time ! > intervals but 100% of the time.   F Apparently the LAT protocol is having a problem from DS100 to Alpha B.  I > 4.    From VT on DS100, connect to Alpha-A, then $set host alpha-A (to  ( > itself).  Works fine, stays connected.D > 5.    From VT on DS100, connect to Alpha-A, the $set host alpha-B I > (across the network), connects fine, but times out after 5-30 minutes.  1 > Again, times vary but happens 100% of the time.   K Apparently the DECNET protocol is having a problem from Alpha-A to Alpha B.   I > 6.    Copy large from Alpha-A to Alpha-B, it ran for 3 hours (big file  3 > for testing), and no problem at all.  No timeout.   L Was a CTERM(DECNET) connection like described in #5 set up at the same time?  K > 7.    From VT on DS100, connect to Alpha-A, then $telnet to Alpha-B.  No  ) > problem, no timeout  ran for 1.5 days.   G TCP/IP is more tolerant of some types of network disturbances than LAT  
 or DECNET.  H > 8.    Take all of this and do it in reverse to prove that it is on an 1 > alpha-a or alpha-b question.  Results the same.  > I > So, it seems like we have some kind of a timeout going on, but I cant  F > think of where to go next.  I apologize for the long message, but I  > think the data is important.  H It may take a ethernet monitor to sort things out, with it specifically F monitoring the LAT or CTERM(Decnet) connections that you are having a 
 problem with.   F It looks like there is definitely something different about Alpha B's & settings or connection to the network.  H LAT is a non-routable protocol, and is sensitive to network disruptions.  F DECNET is routable if the routers understand it.  It can also be more F sensitive to network problems than TCP/IP.  That might be adjustable, 6 but not an area that I have any current experience in.   -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------    Date: 19 Mar 2005 17:04:31 -0800 From: mcbill20@yahoo.com Subject: Memory for PWS500a C Message-ID: <1111280670.950280.248130@f14g2000cwb.googlegroups.com>   D Hello all. I did a search of C.O.V. for info on memory for a PWS500aG and only found one thread. It said that the machine needs PC100 ECC and  CL222.  A I've looked around Ebay and found a few different PC100 ECC items G listed, but they either don't list any "CL" parameter or the one listed G is different. To be honest, I don't know what that spec is. Does anyone 8 know for sure what type of memory is OK in this machine?   Thanks.  Bill   ------------------------------  % Date: Sat, 19 Mar 2005 17:47:09 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: Memory for PWS500a ( Message-ID: <opsnwxwvx5zgicya@hyrrokkin>  : On 19 Mar 2005 17:04:31 -0800, <mcbill20@yahoo.com> wrote:  F > Hello all. I did a search of C.O.V. for info on memory for a PWS500aI > and only found one thread. It said that the machine needs PC100 ECC and  > CL222. > C > I've looked around Ebay and found a few different PC100 ECC items I > listed, but they either don't list any "CL" parameter or the one listed I > is different. To be honest, I don't know what that spec is. Does anyone : > know for sure what type of memory is OK in this machine? > 	 > Thanks.  > Bill > J ECC is not necessary, it can be disabled, but I think that is not a good   idea. I there are three banks of two slots, which connect directly to the Pyxis    chip setJ the two DIMMs in each bank must be identical and unbuffered (provided by   Pyxis)I and if the DIMMs are not the same in the three banks Pyxis will tune to   
 the lowestI performing bank.  CAS latency may be 2 or 3.  DIMMs may be up to 256MB,    for a total L of 1.5GB.  IIRC, last time I added memory I just bought two DIMMs 128M 100   ns CAS 2J ECC.  Hope that helps.  Drop me a not offline if you need more, but just   one:-)   ------------------------------    Date: 19 Mar 2005 20:53:32 -0800; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com>  Subject: Re: Memory for PWS500a C Message-ID: <1111294412.510317.258780@f14g2000cwb.googlegroups.com>    Bill,   C I have 1GB in my PWS500. 512MB of it is 2 256MB MT18LSDT3272AG-10xx G sticks I got on Ebay.  It's a Micron ECC, non-Reg, double-sided 18-chip F PC100 CL2 stick.  I've bought a few and they work great in the PWS and the AS1200.   @ Funny thing is I used to have 4x256MB Infinion memory but it wasB registered (which I tried because I thought a thread here had saidD registered DIMMs were needed).  They worked great under SRM and VMS,F but when I went to boot ARC to run the DAC960 raid utilities it alwaysC hung.  I switched to the non-registered and now it works fine under  both SRM and ARC.   B Sorry to wander, the point is if you search for MT18LSDT3272AG-10*G memory on Ebay they will work.  The "-10xx" means they are PC100 speed. G  If they are "-13xx" that is PC133.  I think those should work but I've E not tried them.  Currently expect to pay somwhere in the neighborhood F of $40 a stick for the 256MB.  The last batch of 5 I bought I paid $46 each (shipping included)  G If you can't find that particular memory, then any "low-density" PC100, G ECC, non-registered should work also.  If you get the 256MB sticks look E for ones with 18 chips. I don't know if the PWS memory controller can D handle the higher density 9-chip versions.  If you can't find the CLA rating in the description look for it on a picture of the memory. G Usually it will be a string of 3 numbers, either "222" for CL2 or "322" A for CL3.  Tom maybe right about CL3 working but I don't know from : experience and I have not found the specs online anywhere.    Hope this helps.       John H. Reinhardt   ------------------------------    Date: 19 Mar 2005 14:49:20 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: VMS 8.2 for VAX3 Message-ID: <GGb94wA4JAPE@eisner.encompasserve.org>   e In article <423c5525$1@NEWS.LANGSTOEGER.AT>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:   I > Last I heard was that they 'are considering' and 'fieldtest this year'. G > Thats a change. But noone seems to notice, care or protest or pay ;-) M > I think, with the HP changes (like CEO), VMS future is still not that rosy.   9 But they accellerated the schedule for SuperDome support.   4 When you change the schedule, something has to give.   ------------------------------    Date: 19 Mar 2005 22:39:09 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: VMS 8.2 for VAX, Message-ID: <423caa0d$1@NEWS.LANGSTOEGER.AT>  c In article <GGb94wA4JAPE@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: f >In article <423c5525$1@NEWS.LANGSTOEGER.AT>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:J >> Last I heard was that they 'are considering' and 'fieldtest this year'.H >> Thats a change. But noone seems to notice, care or protest or pay ;-)N >> I think, with the HP changes (like CEO), VMS future is still not that rosy. > : >But they accellerated the schedule for SuperDome support. > 5 >When you change the schedule, something has to give.   @ 2004 roadmap told OpenVMS V8.3 supports Superdome in H2 of 2005.B So, having V8.2-1 (Itanic only) supporting Superdome in H2 of 20059 (while V8.3 is now H1 of 2006) is really "accellerated" ?   K And no, I don't want to offend VMS engineering, only the 'head of the fish'    --   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: Sat, 19 Mar 2005 18:16:55 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca> Subject: Re: VMS 8.2 for VAX- Message-ID: <423CB2DD.5509DBAC@vaxination.ca>   < > >But they accellerated the schedule for SuperDome support. > > 7 > >When you change the schedule, something has to give.     F The REAL question is whether VMS engineering will grow , stay the sameA or shrink now that the Intel subsidized port to IA64 is complete.   C The ever shrinking roadmap leads me to believe that VMS engineering 4 resources are not growing and are perhaps shrinking.  @ There is still a large gap with teh TCPIP services for instance,< especially with regards to the applicatiosn such as SMTP. IfD Digital/Compaq/HP/whatever isn't willing to put in the money to keep; those products up to date, then they should open source the D applications, and keep the TCPIP kermel inside VMS engineering to be part of VMS.  H Same with Motif. If they aren't going to upgrade to fcurrent versions ofG motif, they should open source the VMS specific portions so that we can  port the open source Motif 2.*.   D The reality is that the focus seems to be on providing features thatH serve a small number of customers (such as fancy clustering interconnectC between planets), while features that coudl benefit a large marklet G place don't have priority, probably because VMS management has lost any  hopes of capturing that market.   F When you consider the potential for Charon VAX to introduce VMS to theG masses, you'd think that VAX VMS would have some strategic advantage to  regrow VMS.    ------------------------------    Date: 19 Mar 2005 14:46:58 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) % Subject: Re: [Announce] FreeVMS 0.1.3 3 Message-ID: <+Hg17epEXG1S@eisner.encompasserve.org>   W In article <3a2qvhF64cbu8U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:   B > Personally, if we are going to talk about older languages with aA > long history, I would have to agree with Tom that PL/I would be C > the best for doing systems programming.  It has proven it's worth A > many time over.  I often wonder why C was created to write Unix C > instead of just using PL/I.  But I would guiess it had more to do 9 > with politics or copyright issues than technical merit.   A I believe the first C compiler was considerably simpler that PL/I  compilers of the time.  " C was developed for research work.   ------------------------------   End of INFO-VAX 2005.157 ************************