1 INFO-VAX	Sat, 22 Jul 2006	Volume 2006 : Issue 405       Contents:6 Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix6 Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unixP How to create a VMS PDF file from a VMS text file and an image (signature) on VM Re: http://h71000.www7.hp.com/? # Re: InfoServer 100 trouble - update ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain  Re: update SCSI to IDE bridge  VaxStation vs. Infoserver  Re: VaxStation vs. Infoserver   F ----------------------------------------------------------------------  # Date: Sat, 22 Jul 2006 11:01:08 GMT . From: Jack Patteeuw <jack.patteeuw@nospam.net>? Subject: Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix > Message-ID: <Uznwg.71270$fb2.65071@newssvr27.news.prodigy.net>    VAXman- @SendSpamHere.ORG wrote:I > I can forward mail to YOU if account ME exists using the .forward file.  > J > How can I create and "alias" name such as ME without creating an account > and forward it to you? >   $ Well here is "the rest of the story"  G First there is a file (/etc/svc.conf for Tru64, /etc/nsswitch.conf for  E Solaris) which tell you which mail alias "db" is used on you system.  H The format of this files differs a bit between flavors of Unix so check 
 the man page.   I The mail aliases "db" could be a file (typically /etc/aliases, but could  H be different on your flavor), nis (aka yellow pages, this works well in I a "cluster" of Unix systems) or (gag, I hope no one is still using) nis+.   = If you are using nis, the mapnae is mail.aliases, not aliases    ------------------------------  + Date: Sat, 22 Jul 2006 14:40:02 +0000 (UTC) , From: Mikko Putkonen <miputkon@paju.oulu.fi>? Subject: Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix ' Message-ID: <e9tdc2$scp$1@news.oulu.fi>    VAXman- wrote:  J > FWIW, an internet radio station web site is now being hosted on a serverJ > in my VAXcave.  It's running on Linux at the moment but my plan, once it: > is all moved in and cozy, is to move and host it on VMS.  K Does VMS have anything similar to the Spacial Audio software?  It would be  ; great to see the whole station hosted on the OS some day...      -Mikko aka Methem    ------------------------------  % Date: Sat, 22 Jul 2006 11:02:12 -0400  From: circepb@optonline.net Y Subject: How to create a VMS PDF file from a VMS text file and an image (signature) on VM 8 Message-ID: <m5f4c2pdp2oeldsa84ov87unakn2378c4a@4ax.com>  D I was searching on the NET about this. Does anyone know that the GPL< (From GNU project) can do this. Any comments is appreciated.     David    ------------------------------    Date: 22 Jul 2006 08:49:35 -0700 From: "w_tom" <w_tom1@usa.net>( Subject: Re: http://h71000.www7.hp.com/?A Message-ID: <1153583375.102012.71800@75g2000cwc.googlegroups.com>   E   Bud follows me around 'cutting and pasting' same half truth post to @ represent plug-in protectors.  His paper describes how a plug-in@ protector might work BUT also how a kid with an Xbox can totallyF compromise that protection.  Paper ends by declaring the 'whole house'" protectors as a superior solution:3 >  High-current surges ... are best diverted at the # > service entrance of the premises.   :   Bud says otherwise and hopes you ignore that conclusion.  F   Bud must ignore these pictures that demonstrate another problem with plug-in protectors: B   http://www.westwhitelandfire.com/Articles/Surge%20Protectors.pdf0   http://www.hanford.gov/rl/?page=556&parent=554)   http://www.zerosurge.com/HTML/movs.html E   http://www.nmsu.edu/~safety/programs/gen_saf/surgeprotectorfire.htm   F   Yes, if you carefully rewire the room AND supervise how ever wire isF connected (no kid with Xbox), then an SRE solution would apply for oneD appliance.  Or we install a single 'whole house' protector, make theE kid with an Xbox irrelevant, and have superior protection for tens of @ times less money.  Instead we protect everything in the house byF installing products from more responsible manufacturers such as SquareE D, Siemens, Leviton, Intermatic, Cutler-Hammer, and GE.  Products are D sold in Lowes, Home Depot, and electrical supply houses.  Instead we; use the solution that is well proven even long before WWII.   E   Shunt mode protectors need an essential connection to earth ground. ? Somehow Bud's carefully installed SRE solution using shunt mode ? protectors will be effective and yet have no dedicated earthing G connection.  Only if you carefully reroute every wire in the room using D an engineering analysis and keep kids with an Xbox out.  Bud ignores0 that essential earthing to promote his products.  G   Bud's even denies the bulkhead increased wire impedance.  Responsible D industry professionals use that bulkhead to supplement protection as> was demonstrated previously by manufacturers who also solve byD earthing.  Bud did not even understand the purpose of that bulkhead.D It works because the bulkhead is part of a system that includes that: all so necessary earth ground.  Representatives of plug-inE manufacturers believe earthing is not important - deny the purpose of = that bulkhead.  Notice no dedicated earthing wires on plug-in D protectors.  Somehow plug-in shunt mode protectors will be effective) and yet not earth destructive transients?    Bud-- wrote:F > Tactic of a looser with no argument. I have no connection with surge > suppressors. > ...  > J > May be useful if you have a 200' lighthing rod - aka antenna tower - and@ > want to attach a signal wire to it and connect it to sensitive- > electronics. Irrelevant for the rest of us.  > ...  > H > The professionals at IEEE and NIST recognize plug-in surge suppressors > as effective.  > ...    ------------------------------  % Date: Sat, 22 Jul 2006 12:25:11 -0400 ' From: Dave Froble <davef@tsoft-inc.com> , Subject: Re: InfoServer 100 trouble - update9 Message-ID: <l_SdnWkt0NZq0l_ZnZ2dnUVZ_oydnZ2d@libcom.com>    gl@decadence.it wrote: > Hello everybody :) > - > My trouble with InfoServer 100, once again. D > I finally managed to get the binary kits for the InfoServer 100 by# > downloading them from a FTP site.  > L > I've tried to restore them to the RZ23 disk from InfoServer, but I failed.K > Sorry for asking so silly questions to you, I have the hardware but still & > not the knowledge to be indipendent. > < > This is what I did, on another VAX system running VMS 7.3. > ! > $ INITIALIZE DKA100: INFOSERVER E > $ BACKUP SYS$SYSROOT:[INFOSERVER.KIT]ESS031.A /SAVE DKA100:[000000] G > $ BACKUP SYS$SYSROOT:[INFOSERVER.KIT]F11CD055.A /SAVE DKA100:[000000] H > $ BACKUP SYS$SYSROOT:[INFOSERVER.KIT]INFOMO013.A /SAVE DKA100:[000000]  D I've never run an Infoserver.  Regardless, the above is most likely 8 invalid restoration commands.  Instead use (line wraps):  L $ BACKUP SYS$SYSROOT:[INFOSERVER.KIT]ESS031.A /SAVE DKA100:[*...]/owner=orig  D There may also be an issue with booting.  If you would have done an E image backup, AND the save set included the disk initialization data.   @ A different issue is where you choose to place the [INFOSERVER] F directory.  This is opinion, strong opinion, keep non-VMS data out of 2 the VMS directory structure, namely, SYS$SYSROOT:.  D > I put back the RZ23 DKA100: into Infoserver, and tried to boot it.< > It simply gets into a loop trying to boot from the DKA100: > 
 >>>> B DKA100  > .  > 	 > -DKA100 	 > -DKA100 	 > -DKA100 	 > -DKA100 	 > -DKA100  >  > and so on until forever. > I > I also tried to "INITIALIZE /SYSTEM DKA100:" but I had the same result. G > There should be something wrong in the procedure I used, but I really  > don't know what. >  > Any idea?  > Thanks a lot!  >  > Bye  > gl     --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 22 Jul 2006 11:21:05 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> 2 Subject: Re: New itaniums out at 2.5x perform gain: Message-ID: <16cbc$44c1ee03$50db5015$4172@news.hispeed.ch>   Neil Rieck wrote: K > "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message  / > news:+VsvlB6+v25f@eisner.encompasserve.org... M >> In article <44bf5a0e$0$18489$9a6e19ea@news.newshosting.com>, "Neil Rieck"  ! >> <n.rieck@sympatico.ca> writes: L >>> Yes but on this side of Y2K, corporate execs have "rock star" egos. They? >>> almost never admit they make mistakes (even when in court). @ >>   This side of Y2K corporate managers should wake up to AOL'sG >>   problem with the 2038 "bug".  I just read in the Risks Digest that  >>   it hit them already.  >>O > Most companies became aware of the "2038 bug" when they were doing their Y2K  O > testing. If this bug was left in place, it happened because somebody thought  L > they could make some more money sometime in the future (provided they are  > still alive). B > http://www3.sympatico.ca/n.rieck/docs/calendar_time_y2k_etc.html >   ) Here's the relevant Risks Digest article:    --- start quote ---     Subject: Y2038 bug strikes early  I Starting on May 12, 2006, many installations of the AOLServer web server  D failed. Not all versions or all configurations failed, but the ones H that did became unusable. On start, the server would eat virtual memory E and then terminate with a memory allocation error. Discussion on the  H mailing list revealed the starting date of the problem, indicating that F some part of the software had a clock issue. On careful inspection it G was discovered that database threads were a common factor. It was then  F noted by a perceptive person that the servers all failed on or before F exactly one billion seconds before the end of the Unix epoch in 2038. E Many installations had very long database timeouts, which caused the  G software to look ahead and see the End of Time. Adjusting the timeouts   stopped the crashes.  G The risk of the known clock bug striking 32 years early indicates there F may be other "pre-problems" lurking in software that will show up long8 before the date we have comfortably set as the deadline.  = The thread discussing the problem and its resolution is here:   D http://www.mail-archive.com/aolserver@listserv.aol.com/msg09812.html   --- end quote ---    --  
 Paul Sture   ------------------------------  % Date: Sat, 22 Jul 2006 08:03:56 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 2 Subject: Re: New itaniums out at 2.5x perform gain; Message-ID: <44c2134b$0$5183$9a6e19ea@news.newshosting.com>   3 "Dan Foster" <usenet@evilphb.org> wrote in message  / news:slrnec1k9p.rt3.usenet@zappy.catbert.org... I > In article <44c0b117$0$4147$9a6e19ea@news.newshosting.com>, Neil Rieck   > <n.rieck@sympatico.ca> wrote: C >>> and now 64 bit machine. In the process, it has gained many more K >>> features. So while the 8086 circa 1990 was definitely ill suited to run ? >>> VMS, the CPUs made today for that architecture have gained   >>> respectability.  >>H >> Despite what Intel + AMD marketing folks would have us believe, theseI >> product lines you are referring to are not 64-bit. It may seem so, to   >> some,K >> because CPU and "memory management" functions have been integrated (read 1 >> blurred) but these CPUs are only 32 bits wide.  > I > Er... no, the latest 64-bit processors in that family _are_ true 64 bit J > processors. I'll explain in a moment, if you'll bear with me, please. :) > K >> To understand this better, think about the PDP-11 system which was a 16   >> bitL >> CPU. The memory management system allowed the CPU to address memory usingI >> 18-bit, 22-bit, and 24-bit access. This worked by having the CPU first I >> initialize MMU registers which were later combined (added) with 16-bit F >> addresses coming from the CPU to generate a wider address going to 
 >> memory.K >> But there was "no way" any single process could "see" more than 16-bits   >> of L >> memory at a time without first asking the OS to manipulate the associated >> memory management registers.  > F > Right: the PDP-11 had a 16-bit data bus and 16 to 22 bit address bus8 > depending on what memory access scheme was being used. > C > The data bus width is why the PDP-11 is considered to be a 16 bit  > processor. > E > Same deal with the 65816 which was used in the Apple IIGS and Super I > Nintendo systems: 16-bit data bus, 24-bit address bus, considered to be  > a 16-bit processor.  > G > However, the EM64T and AMD64 processors *are* full 64 bit internally.  > G > They are at least 64 bits wide for the _data_ bus (as well as for the G > various registers including all of the GPRs), which is the big thing.  > G > All pointers are 64-bit. All pushes and pops for the stack is 64-bit. I > (The operands are 32-bit wide, but then again, do they really need more & > than ~4.2 billion defined operands?) > J > Accessing data in the registers and memory is not a matter of internallyH > stringing up two adjacent 32-bit registers or 32-bit memory addresses.G > (First version of this stuff may have done that, but current versions - > don't. It's a full and true 64-bit access.)  > J > The address bus is not quite 64-bit wide in current implementations, butD > likely eventually will either reach 64-bit or come closer to it --I > today's implementations are still much wider than terrible 32-bit hacks 8 > like PAE to squeeze an extra 4 bits out of addressing. > L > On AMD64 64-bit processors, 32-bit is available as a _compatibility mode_.? > I'm not sure if it's considered to be a compat mode on EM64T.  > > > For more detailed information about these two architectures: > $ > http://en.wikipedia.org/wiki/AMD64$ > http://en.wikipedia.org/wiki/EM64T > K > (The EM64T page is rather sparse, admittedly. AMD64 page is pretty good.)  > A > One of the big things distinguishing EM64T and AMD64 from other F > traditional 64-bit implementations such as Alpha, UltraSPARC, POWER3J > (and later), Itanium, etc. is that EM64T/AMD64 has *much* fewer GPRs due7 > to their precedessors originally being a CISC design.  > 	 > Cheers,  >  > -Dan  * I was unaware of this and stand corrected.  
 Neil Rieck   ------------------------------  + Date: Sat, 22 Jul 2006 13:09:11 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk2 Subject: Re: New itaniums out at 2.5x perform gain) Message-ID: <e9t81m$4ai$1@news.mdx.ac.uk>   c In article <3OWdnWCHTZRhfl3ZnZ2dnUVZ_vednZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:  >Bill Gunshannon wrote:  > A >>>>> Alpha sales at this point in time is a very wrong mistake). * >>>> Maybe, but it is a done deal as well.M >>> This is a business decision.  If the decision was changed, continuing to  H >>> manufacture and sell the current Alphas is definitely doable from a  >>> technical perspective. >>  G >> Again, I have to defer to the HP people who are in a better position E >> to know and they have repeatedly stated here that the resources no G >> longer exist at HP to revive the Alpha line.  And, we have been told E >> that there was also some agreement regarding Alpha in the HP-Intel G >> deal.  It is equally possible that the agreement was that they could F >> no longer continue development of the Alpha.  If that turned out toG >> be so, what incentive would Intel have to release HP from it?  No, I D >> think as the HP denizens here have stated, Alpha is a dead issue. > H >Read again what I wrote.  "Current Alphas".  HP could continue to have H >the EV6, EV7, and EV7z CPUs fabbed and build and sell the systems that K >are CURRENTLY being sold.  Wasn't talking about new Alpha CPU development.  > F >Ok, such is a short term (relatively) solution, and in several years E >such systems would be overpriced and far from competitive.  But for  I >several years such would allow customers to run their current VMS based   >applications. > I >Note that there are customers running older hardware.  Why?  Because it  I >just keeps working.  That's what it's all about.  Getting the job done.  J >  If you have a VMS based application, that isn't easily portable, being H >able to continue to run that application is a very BIG issue.  Look at I >the CHARON/VAX product.  What it's about is allowing people to continue  I >to run their applications.  If you believe Stan and others, it's rather  K >successful.  Why?  Because customers need to continue to get the job done.  > I >HP's current line is, "You can continue to get the job done on itanic".  D >  If, note, I write IF, that changes, HP would need to address the F >issue, or just drop VMS.  If they would choose to address the issue, H >continuing to sell Alphas for a while is one possible thing they could ( >do.  Not a solution, a stopgap measure. > P One big problem at the moment is you can't get Oracle classic on VMS on Itanium.J Hence third parties can't certify applications running on Oracle on VMS onE Itanium. Even if Oracle were to release Oracle 10g today the delay in J certifications would mean noone would be able to buy such applications for ages. M On the otherhand 10g-r1 (and earlier versions) of  Oracle on VMS on Alpha are K supported but companies have little time to decide whether to wait for IA64 / support or purchase an Alpha to tide them over.   ' The timing of ending Alpha sales sucks.   
 David Webb Security team leader CCSS Middlesex University              >-- 5 >David Froble                       Tel: 724-529-0450 ? >Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com  >DFE Ultralights, Inc. >170 Grimplin Road >Vanderbilt, PA  15486   ------------------------------    Date: 22 Jul 2006 04:51:18 -07001 From: "nnc@eta.chalmers.se" <nnc@eta.chalmers.se> & Subject: Re: update SCSI to IDE bridgeB Message-ID: <1153569078.882247.205040@75g2000cwc.googlegroups.com>   Dear fellow group-members...  E Excuse me for writing disinformation. I was mistaken by the number of G bytes in each disc/CD-bloc. I was right in that VMS uses 512 bytes, and B that the world has another size, but I was wrong in what this size was...  E Anyhow, my answer, though slightly "off", gave us excellent, correct, # information by other group members!   A I hope you get the bridge working, it is certainly an interesting G project, partly "comersial", but most of all for hobbyist use of PDP:s, 3 as old discs and controllers is an eternal problem!   G (Myself, I operate some PDP-11:s with DEC original SCSI-controller, and B discs in the range of 1-4 GByte. For the moment, I have a stock ofD spare discs to use if/when a disc breakes down, but in the long timeC run, it might be needed to switch to ATA/IDE, if these systems will $ survive the stock of spare discs ;-)    Best Regards, G=F6ran I =C5hling   ------------------------------   Date: 22 Jul 2006 14:55:39 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)" Subject: VaxStation vs. Infoserver+ Message-ID: <4iesjbF3fihaU1@individual.net>   E I know this has probably been asked before, but can a VaxStation 3100 @ be turned into an Infoserver?  I understand the hardware is veryF similar, but will the Infoserver software run on a VS?  I could really9 use an Infoserver but I doubt I will ever get a real one.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Sat, 22 Jul 2006 12:27:07 -0400 ' From: Dave Froble <davef@tsoft-inc.com> & Subject: Re: VaxStation vs. Infoserver9 Message-ID: <l_SdnWgt0Nb0zV_ZnZ2dnUVZ_oydnZ2d@libcom.com>    Bill Gunshannon wrote:G > I know this has probably been asked before, but can a VaxStation 3100 B > be turned into an Infoserver?  I understand the hardware is veryH > similar, but will the Infoserver software run on a VS?  I could really; > use an Infoserver but I doubt I will ever get a real one.  >  > bill >   
 I don't know.   F Others have posted that the Infoserver console code prohibits running F VMS.  I've not read that a VAX's console code prohibits running other 	 than VMS.    Try it.  It might work.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   End of INFO-VAX 2006.405 ************************