INFO-VAX Sat, 01 Nov 2008 Volume 2008 : Issue 590 Contents: Re: Alpha 800 4/500 Re: Fortran, debugger and Alpha/VMS 7.3-2 Re: Fortran, debugger and Alpha/VMS 7.3-2 Re: Fortran, debugger and Alpha/VMS 7.3-2 Most impressive VAX installations Re: Most impressive VAX installations Re: Most impressive VAX installations Re: Most impressive VAX installations Re: Most impressive VAX installations Re: Most impressive VAX installations Re: Most impressive VAX installations SFF (Send From File) Utility ---------------------------------------------------------------------- Date: Fri, 31 Oct 2008 17:54:53 -0000 From: "Richard Brodie" Subject: Re: Alpha 800 4/500 Message-ID: wrote in message news:910ff3a4-594d-401b-85b1-6b1092d05806@d36g2000prf.googlegroups.com... > On my AS800 5/400 it's clearly an EV56: > $ sho cpu/ful > > System: JAMES, AlphaServer 800 5/400 I'm thinking that there was no such thing as a AS 800 4/500. http://h18002.www1.hp.com/alphaserver/archive/comp/index.html ------------------------------ Date: Fri, 31 Oct 2008 13:19:12 -0500 From: Jeff Subject: Re: Fortran, debugger and Alpha/VMS 7.3-2 Message-ID: David Weatherall wrote: >>>>>>> We finally upgraded the Alphas in our cluster from V7.3-1 >>>>>>> to -2 last week. As expected, we never saw any problem >>>>>>> until my colleague needed to use the debugger with her >>>>>>> Fortran (V7.5...) program. >>>>>>> It contains a Structure/record like >>>>>>> structure /asd$record/ >>>>>>> character*36 asd_name >>>>>>> character*36 efile_name >>>>>>> character*12 other_name >>>>>>> ... >>>>>>> end structure >>>>>>> record /asd$record/ asd_record >>>>>>> In the debugger we can >>>>>>> EXA ASD_RECORD >>>>>>> without problem but >>>>>>> EXA ASD_RECORD.ASD_NAME >>>>>>> generates the following error :- >>>>>>> %DEBUG-E-INTERR, debugger error in DBGADDEXP\DETERMINE_TYPE >>>>>>> unknown arg type or session corruption >>>>>>> T'was fine on 7.3-1. Anybody know what's going on? John? >>>>>>> Kristine, my colleague, is less than impressed. This is a bug and it was fixed by me many years ago. Pick up the recent patch kit for DEBUG and you should be fine. As John likes to say, here are the details "for those keeping score at home." The bug is not in the debugger, but in the Bliss compiler used to build DEBUG. The compiler was generating bad code for the routine DETERMINE_TYPE. I worked around the problem by disabling optimization. The workaround was removed for V8.3 because a newer compiler is used that fixes the bug. -Jeff Nelson ------------------------------ Date: Fri, 31 Oct 2008 20:08:40 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Fortran, debugger and Alpha/VMS 7.3-2 Message-ID: <00A81EF3.057BFE0E@SendSpamHere.ORG> In article , Jeff writes: >David Weatherall wrote: >>>>>>>> We finally upgraded the Alphas in our cluster from V7.3-1 >>>>>>>> to -2 last week. As expected, we never saw any problem >>>>>>>> until my colleague needed to use the debugger with her >>>>>>>> Fortran (V7.5...) program. >>>>>>>> It contains a Structure/record like >>>>>>>> structure /asd$record/ >>>>>>>> character*36 asd_name >>>>>>>> character*36 efile_name >>>>>>>> character*12 other_name >>>>>>>> ... >>>>>>>> end structure >>>>>>>> record /asd$record/ asd_record >>>>>>>> In the debugger we can >>>>>>>> EXA ASD_RECORD >>>>>>>> without problem but >>>>>>>> EXA ASD_RECORD.ASD_NAME >>>>>>>> generates the following error :- >>>>>>>> %DEBUG-E-INTERR, debugger error in DBGADDEXP\DETERMINE_TYPE >>>>>>>> unknown arg type or session corruption >>>>>>>> T'was fine on 7.3-1. Anybody know what's going on? John? >>>>>>>> Kristine, my colleague, is less than impressed. > >This is a bug and it was fixed by me many years ago. Pick up the recent >patch kit for DEBUG and you should be fine. > >As John likes to say, here are the details "for those keeping score at >home." The bug is not in the debugger, but in the Bliss compiler used to >build DEBUG. The compiler was generating bad code for the routine >DETERMINE_TYPE. I worked around the problem by disabling optimization. >The workaround was removed for V8.3 because a newer compiler is used >that fixes the bug. > >-Jeff Nelson Thanks Jeff.... Any chance of getting that DELTA issue corrected on IA64 now that this issue has been put to bed? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Fri, 31 Oct 2008 15:20:39 -0500 From: Jeff Subject: Re: Fortran, debugger and Alpha/VMS 7.3-2 Message-ID: VAXman- @SendSpamHere.ORG wrote: > Any chance of getting that DELTA issue corrected on IA64 now that this > issue has been put to bed? I'll see what I can do. -Jeff ------------------------------ Date: Fri, 31 Oct 2008 16:49:37 -0700 (PDT) From: urbancamo Subject: Most impressive VAX installations Message-ID: To anyone listening! I was flicking through the VAX Architecture Reference Manual earlier and it got me wondering about the ratio between physically installed memory in a VAX setup and the maximum theoretical limit of 4 GB. As far as I'm aware for VAXen the physical never to close to the virtual. I remember when 64MB was an astronomic amount of memory, which was around the time of the last VAXes, so I'm asking - how much RAM did you see crammed into the latest or greatest of the VAXen (and what else was interesting about the setups, for example maximum number of users, storage etc) Or just tell me to get a life ;) Mark. ------------------------------ Date: Fri, 31 Oct 2008 21:15:04 -0400 From: "Richard B. Gilbert" Subject: Re: Most impressive VAX installations Message-ID: urbancamo wrote: > To anyone listening! > > I was flicking through the VAX Architecture Reference Manual earlier > and it got me wondering about the ratio between physically installed > memory in a VAX setup and the maximum theoretical limit of 4 GB. As > far as I'm aware for VAXen the physical never to close to the virtual. > > I remember when 64MB was an astronomic amount of memory, which was > around the time of the last VAXes, so I'm asking - how much RAM did > you see crammed into the latest or greatest of the VAXen (and what > else was interesting about the setups, for example maximum number of > users, storage etc) > > Or just tell me to get a life ;) > > Mark. I don't know of ANY VAX that actually supported four GB of memory. I don't recall the largest VAX memory I ever encountered but I doubt if it was more than 128 MB. RISC processors, such as the Alpha need a great deal more memory for the executable code, about four times as much as a VAX. With the Alphas, a GB or more was not only reasonable but also possible! But only if you were very rich! ;-) ------------------------------ Date: Fri, 31 Oct 2008 19:26:33 -0600 From: Dan O'Reilly Subject: Re: Most impressive VAX installations Message-ID: <6.1.2.0.2.20081031192100.0221cae8@raptor.psccos.com> At 07:15 PM 10/31/2008, Richard B. Gilbert wrote: >urbancamo wrote: >>To anyone listening! >>I was flicking through the VAX Architecture Reference Manual earlier >>and it got me wondering about the ratio between physically installed >>memory in a VAX setup and the maximum theoretical limit of 4 GB. As >>far as I'm aware for VAXen the physical never to close to the virtual. >>I remember when 64MB was an astronomic amount of memory, which was >>around the time of the last VAXes, so I'm asking - how much RAM did >>you see crammed into the latest or greatest of the VAXen (and what >>else was interesting about the setups, for example maximum number of >>users, storage etc) >>Or just tell me to get a life ;) >>Mark. > >I don't know of ANY VAX that actually supported four GB of memory. I >don't recall the largest VAX memory I ever encountered but I doubt if it >was more than 128 MB. > >RISC processors, such as the Alpha need a great deal more memory for the >executable code, about four times as much as a VAX. With the Alphas, a GB >or more was not only reasonable but also possible! But only if you were >very rich! ;-) We had a VAXcluster at MCI that I implemented that had 4 VAX 7640's, I think 2gb of memory each, 4 star couplers, 10 HSC95's (all fully-loaded with requestor cards), 10 EZ50 electronic drives and a whole slew of 1gb drives (RA74?). It was for high-speed call statistics processing. We also had VAXen that were really loaded with memory, as we had a database system implemented in non-paged pool, using user-written system services to access them (how cool is THAT???). In addition, we had literally hundreds of VAX systems of various sizes, some desktop but mostly servers. Needless to say, when AXPs came out, it made things a WHOLE lot easier and faster! ..and then came UNIX and Windows...well... ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ ------------------------------ Date: Fri, 31 Oct 2008 21:38:50 -0400 From: "Richard B. Gilbert" Subject: Re: Most impressive VAX installations Message-ID: Dan O'Reilly wrote: > At 07:15 PM 10/31/2008, Richard B. Gilbert wrote: >> urbancamo wrote: >>> To anyone listening! >>> I was flicking through the VAX Architecture Reference Manual earlier >>> and it got me wondering about the ratio between physically installed >>> memory in a VAX setup and the maximum theoretical limit of 4 GB. As >>> far as I'm aware for VAXen the physical never to close to the virtual. >>> I remember when 64MB was an astronomic amount of memory, which was >>> around the time of the last VAXes, so I'm asking - how much RAM did >>> you see crammed into the latest or greatest of the VAXen (and what >>> else was interesting about the setups, for example maximum number of >>> users, storage etc) >>> Or just tell me to get a life ;) >>> Mark. >> >> I don't know of ANY VAX that actually supported four GB of memory. I >> don't recall the largest VAX memory I ever encountered but I doubt if >> it was more than 128 MB. >> >> RISC processors, such as the Alpha need a great deal more memory for >> the executable code, about four times as much as a VAX. With the >> Alphas, a GB or more was not only reasonable but also possible! But >> only if you were very rich! ;-) > > We had a VAXcluster at MCI that I implemented that had 4 VAX 7640's, I > think 2gb of memory each, 4 star couplers, 10 HSC95's (all fully-loaded > with requestor cards), 10 EZ50 electronic drives and a whole slew of 1gb > drives (RA74?). It was for high-speed call statistics processing. We > also had VAXen that were really loaded with memory, as we had a database > system implemented in non-paged pool, using user-written system services > to access them (how cool is THAT???). In addition, we had literally > hundreds of VAX systems of various sizes, some desktop but mostly servers. > > Needless to say, when AXPs came out, it made things a WHOLE lot easier > and faster! > > ..and then came UNIX and Windows...well... > And, obviously, your employers had money to burn! Not only was the hardware expensive, the electric bill must have been out of sight! ------------------------------ Date: Fri, 31 Oct 2008 21:53:59 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Most impressive VAX installations Message-ID: <490bb6b8$0$90275$14726298@news.sunsite.dk> Richard B. Gilbert wrote: > urbancamo wrote: >> To anyone listening! >> >> I was flicking through the VAX Architecture Reference Manual earlier >> and it got me wondering about the ratio between physically installed >> memory in a VAX setup and the maximum theoretical limit of 4 GB. As >> far as I'm aware for VAXen the physical never to close to the virtual. >> >> I remember when 64MB was an astronomic amount of memory, which was >> around the time of the last VAXes, so I'm asking - how much RAM did >> you see crammed into the latest or greatest of the VAXen (and what >> else was interesting about the setups, for example maximum number of >> users, storage etc) >> >> Or just tell me to get a life ;) >> >> Mark. > > I don't know of ANY VAX that actually supported four GB of memory. I > don't recall the largest VAX memory I ever encountered but I doubt if it > was more than 128 MB. > > RISC processors, such as the Alpha need a great deal more memory for the > executable code, about four times as much as a VAX. With the Alphas, a > GB or more was not only reasonable but also possible! But only if you > were very rich! ;-) http://www.compaq.com/alphaserver/vax/archive/vax10000.html says 3.5 GB. Arne ------------------------------ Date: Fri, 31 Oct 2008 21:27:07 -0600 From: Dan O'Reilly Subject: Re: Most impressive VAX installations Message-ID: <6.1.2.0.2.20081031212431.05caf6d8@raptor.psccos.com> At 07:38 PM 10/31/2008, Richard B. Gilbert wrote: >Dan O'Reilly wrote: >>At 07:15 PM 10/31/2008, Richard B. Gilbert wrote: >>>urbancamo wrote: >>>>To anyone listening! >>>>I was flicking through the VAX Architecture Reference Manual earlier >>>>and it got me wondering about the ratio between physically installed >>>>memory in a VAX setup and the maximum theoretical limit of 4 GB. As >>>>far as I'm aware for VAXen the physical never to close to the virtual. >>>>I remember when 64MB was an astronomic amount of memory, which was >>>>around the time of the last VAXes, so I'm asking - how much RAM did >>>>you see crammed into the latest or greatest of the VAXen (and what >>>>else was interesting about the setups, for example maximum number of >>>>users, storage etc) >>>>Or just tell me to get a life ;) >>>>Mark. >>> >>>I don't know of ANY VAX that actually supported four GB of memory. I >>>don't recall the largest VAX memory I ever encountered but I doubt if it >>>was more than 128 MB. >>> >>>RISC processors, such as the Alpha need a great deal more memory for the >>>executable code, about four times as much as a VAX. With the Alphas, a >>>GB or more was not only reasonable but also possible! But only if you >>>were very rich! ;-) >>We had a VAXcluster at MCI that I implemented that had 4 VAX 7640's, I >>think 2gb of memory each, 4 star couplers, 10 HSC95's (all fully-loaded >>with requestor cards), 10 EZ50 electronic drives and a whole slew of 1gb >>drives (RA74?). It was for high-speed call statistics processing. We >>also had VAXen that were really loaded with memory, as we had a database >>system implemented in non-paged pool, using user-written system services >>to access them (how cool is THAT???). In addition, we had literally >>hundreds of VAX systems of various sizes, some desktop but mostly servers. >>Needless to say, when AXPs came out, it made things a WHOLE lot easier >>and faster! >>..and then came UNIX and Windows...well... > >And, obviously, your employers had money to burn! Not only was the >hardware expensive, the electric bill must have been out of sight! We were DEC's largest single customer outside of the gov't. The last year I was there (1997), we let out something like $375m in hardware/software purchases, let alone support contracts. We had a whole sales unit dedicated to MCI. If I remember correctly, the VAX cluster I described ran something in the neighborhood of $17m. It was single most expensive thing I ever specified. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ ------------------------------ Date: Fri, 31 Oct 2008 21:34:53 -0600 From: Dan O'Reilly Subject: Re: Most impressive VAX installations Message-ID: <6.1.2.0.2.20081031213412.01e6a8e8@raptor.psccos.com> At 09:27 PM 10/31/2008, Dan O'Reilly wrote: >At 07:38 PM 10/31/2008, Richard B. Gilbert wrote: >>Dan O'Reilly wrote: >>>At 07:15 PM 10/31/2008, Richard B. Gilbert wrote: >>>>urbancamo wrote: >>>>>To anyone listening! >>>>>I was flicking through the VAX Architecture Reference Manual earlier >>>>>and it got me wondering about the ratio between physically installed >>>>>memory in a VAX setup and the maximum theoretical limit of 4 GB. As >>>>>far as I'm aware for VAXen the physical never to close to the virtual. >>>>>I remember when 64MB was an astronomic amount of memory, which was >>>>>around the time of the last VAXes, so I'm asking - how much RAM did >>>>>you see crammed into the latest or greatest of the VAXen (and what >>>>>else was interesting about the setups, for example maximum number of >>>>>users, storage etc) >>>>>Or just tell me to get a life ;) >>>>>Mark. >>>> >>>>I don't know of ANY VAX that actually supported four GB of memory. I >>>>don't recall the largest VAX memory I ever encountered but I doubt if >>>>it was more than 128 MB. >>>> >>>>RISC processors, such as the Alpha need a great deal more memory for >>>>the executable code, about four times as much as a VAX. With the >>>>Alphas, a GB or more was not only reasonable but also possible! But >>>>only if you were very rich! ;-) >>>We had a VAXcluster at MCI that I implemented that had 4 VAX 7640's, I >>>think 2gb of memory each, 4 star couplers, 10 HSC95's (all fully-loaded >>>with requestor cards), 10 EZ50 electronic drives and a whole slew of 1gb >>>drives (RA74?). It was for high-speed call statistics processing. We >>>also had VAXen that were really loaded with memory, as we had a database >>>system implemented in non-paged pool, using user-written system services >>>to access them (how cool is THAT???). In addition, we had literally >>>hundreds of VAX systems of various sizes, some desktop but mostly servers. >>>Needless to say, when AXPs came out, it made things a WHOLE lot easier >>>and faster! >>>..and then came UNIX and Windows...well... >> >>And, obviously, your employers had money to burn! Not only was the >>hardware expensive, the electric bill must have been out of sight! > >We were DEC's largest single customer outside of the gov't. The last year >I was there (1997), we let out something like $375m in hardware/software >purchases, let alone support contracts. We had a whole sales unit >dedicated to MCI. > >If I remember correctly, the VAX cluster I described ran something in the >neighborhood of $17m. It was single most expensive thing I ever specified. Sorry, a typo: I believe the # was $175m, not $375m. Still, a big number for the mid-90's. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ ------------------------------ Date: Fri, 31 Oct 2008 16:51:55 -0600 From: "Michael D. Ober" Subject: SFF (Send From File) Utility Message-ID: Is there anyway to change the default behavior of the TCPIP v5.6 SFF utility. The change I'm looking for is to have it use a "smart host" for forwarding emails. The default behavior is that if you have an email going to multiple domains, SFF generates an email for each domain. What I'd like to have it do is generate a single email with all the headers so that the "smart host" can split the message to multiple domains. For example: RCPT TO:<> (Outlook Express wouldn't allow single brackets) RCPT TO:<> generates two emails, one to each domain. What I'd like it to do is send a single email and allow the smart host (in this case, an Exchange server with message journaling running) do the split into multiple messages. Splitting into multiple messages causes additional work and storage requirements on the Exchange Server. Thanks, Mike Ober. ------------------------------ End of INFO-VAX 2008.590 ************************