1 INFO-VAX	Sat, 30 Dec 2006	Volume 2006 : Issue 718       Contents:/ %MAIL-F-CODERR reading a big wastebasket folder 3 Re: %MAIL-F-CODERR reading a big wastebasket folder 3 Re: %MAIL-F-CODERR reading a big wastebasket folder & Re: DECterm special escape sequences ? PWR SWitch om XP1000 Re: PWR SWitch om XP1000 Re: PWR SWitch om XP1000 Re: PWR SWitch om XP1000 Re: PWR SWitch om XP1000 Re: PWR SWitch om XP1000+ Re: Renaming a root from [SYS0] to [SYS1] ? # Re: Whatever happened to Christmas? > Re: Who's crazier, HP C V7.1-015 on OpenVMS Alpha V7.3-2 or I?> Re: Who's crazier, HP C V7.1-015 on OpenVMS Alpha V7.3-2 or I?  F ----------------------------------------------------------------------    Date: 29 Dec 2006 14:21:47 -0800( From: "Rich Jordan" <jordan@ccs4vms.com>8 Subject: %MAIL-F-CODERR reading a big wastebasket folderC Message-ID: <1167430906.946856.204060@k21g2000cwa.googlegroups.com>   D Very large mail file (70,000+ blocks) due to purges not happening onF the monster spam receiver account of all time.  We don't know how many- messages are in the wastebasket but its huge.   @ I set file to that mail file from a priv'd account with sizeable quotas.   D "Select wastebasket" just ran for 2 hours (on an unloaded DS15), andE appeared to be spinning in a tight loop.  We control-y'd out, and got 9 the following messages when we EXITted at the DCL prompt:   # %LIB-E-BADBLOADR, bad block address # %LIB-E-BADBLOADR, bad block address B %MAIL-F-CODERR, internal coding error; please contact your Digital support representative.   E We will probably do that since this system is under software support, D but I want to try verifying the mail file first.  I've made a backupB copy to be safe.  ANALYZE/RMS on the file is clean, the disk isn'tG throwing errors, and an ANALYZE/DISK also reports no unexpected issues.   7 Any thoughts?  Thanks!  And have a happy new year, all.    Rich   ------------------------------    Date: 29 Dec 2006 14:39:50 -0800( From: "Rich Jordan" <jordan@ccs4vms.com>< Subject: Re: %MAIL-F-CODERR reading a big wastebasket folderA Message-ID: <1167431990.112097.77790@a3g2000cwd.googlegroups.com>    Rich Jordan wrote:F > Very large mail file (70,000+ blocks) due to purges not happening onH > the monster spam receiver account of all time.  We don't know how many/ > messages are in the wastebasket but its huge.  > B > I set file to that mail file from a priv'd account with sizeable	 > quotas.  > F > "Select wastebasket" just ran for 2 hours (on an unloaded DS15), andG > appeared to be spinning in a tight loop.  We control-y'd out, and got ; > the following messages when we EXITted at the DCL prompt:  > % > %LIB-E-BADBLOADR, bad block address % > %LIB-E-BADBLOADR, bad block address D > %MAIL-F-CODERR, internal coding error; please contact your Digital > support representative.  > G > We will probably do that since this system is under software support, F > but I want to try verifying the mail file first.  I've made a backupD > copy to be safe.  ANALYZE/RMS on the file is clean, the disk isn'tI > throwing errors, and an ANALYZE/DISK also reports no unexpected issues.  > 9 > Any thoughts?  Thanks!  And have a happy new year, all.  >  > Rich  D Bit more.  Ran mail against the copy (in  another directory) and gotG the same results, and the same error when I control-y'd out.  BTW while . in the tight loop no I/Os are being generated.  D Ran a CONVERT on the copy, no errors generated.  But when I tried toG select wastebasket in the converted copy I got a different behavior; it G still went into a tight cpu loop (per sho proc/cont) but was generating E a very high direct I/O rate (tens of thousands per second, presumably D to cache given the rate).  I allowed it to run for almost 20 minutesF before control-ying out; no errors showed up when I EXIT'ed at the DCL prompt.   G I guess its just a damaged mail file at this point, and likely the best D solution will be to delete it and start a new one (its used for POP,8 anything in it has already been downloaded to a peecee).   Thanks for any info    Rich   ------------------------------  % Date: Fri, 29 Dec 2006 20:12:37 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>< Subject: Re: %MAIL-F-CODERR reading a big wastebasket folder8 Message-ID: <675ce$4595bd28$cef8887a$19386@TEKSAVVY.COM>   Rich Jordan wrote:G >> "Select wastebasket" just ran for 2 hours (on an unloaded DS15), and H >> appeared to be spinning in a tight loop.  We control-y'd out, and got< >> the following messages when we EXITted at the DCL prompt:  D If the messages are already in the wastebasket, why not set mail to J automatically delete messages from the wastebasket when you exit and then  exit ?  I If you are actually refiling messages from read to wastebasket, it would  K require a lot of index work to delete entries from the "READ" index key to  ? the "WASTEASKET" index key with many many many many duplicates.     E Another thing to try would be DECW$MAIL . It seems to have different   handling of the mail files.    ------------------------------  + Date: Fri, 29 Dec 2006 21:36:06 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) / Subject: Re: DECterm special escape sequences ? ( Message-ID: <en41o6$l71$1@pcls4.std.com>  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:     K >> VT100 and the associated ANSI standard are very well documented and easy  >> to find in public locations.  >>  J >> What you seek isn't VT100 stuff.  DECterm is based on the VT300 series,J >> IIRC.  But DECterm has its own extensions, which may not be part of any >> general standard.  J >Exactly my point.  Digital should have made those extensions more formal H >and published them so that anyone using the so called "VT100" standard K >would not conflict with DEC's own extensions, which render the VT100 less  J >"standard". The fact that even within Digital, there were conflicts with ' >the <ESC>[xx t  is such an indication.   M >You know very well that the VT100 "standard" is really much more than VT100  H >and includes far more modern features such as advanced video, and even 	 >colours.   K What you call the 'VT100 "standard"' already _is_ a published, non Digital  # standard. It's ANSI standard X3.64.    ------------------------------  % Date: Fri, 29 Dec 2006 11:22:17 -0800 * From: "Tom Linden" <tom@kednos-remove.com> Subject: PWR SWitch om XP1000 ) Message-ID: <op.tlb5ffa5tte90l@hyrrokkin>   B Just got back from Palm Desert.  While away I had left 3 XP1000's,E a VAX and a DS10L running in the cluster.  Owing to our annual winter B storms we had a several power outages here in Pebble Beach.  AfterE the first outage the systems rebooted.  There were apparently several G other outages and when I returned I noticed that all the power switches G on the XP1000's were dark.  Not so on the VAX or DS10L.  Depressing the G switches restored things to normal.  Anybody expreience this with these ? machines?  Is this a known bug?  AUTO_ACTION is set to RESTART.    ------------------------------  + Date: Fri, 29 Dec 2006 13:48:53 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)! Subject: Re: PWR SWitch om XP1000 2 Message-ID: <06122913485367_2020028F@antinode.org>  * From: "Tom Linden" <tom@kednos-remove.com>  D > Just got back from Palm Desert.  While away I had left 3 XP1000's,G > a VAX and a DS10L running in the cluster.  Owing to our annual winter D > storms we had a several power outages here in Pebble Beach.  AfterG > the first outage the systems rebooted.  There were apparently several I > other outages and when I returned I noticed that all the power switches I > on the XP1000's were dark.  Not so on the VAX or DS10L.  Depressing the I > switches restored things to normal.  Anybody expreience this with these A > machines?  Is this a known bug?  AUTO_ACTION is set to RESTART.   G    My XP1000 systems seem to remember the power switch setting properly D (unlike my early edition PWS 500a[u], which did not).  Sounds like aA mystery (unless your batteries are dead, or an NVRAM is fried, or  something like that).   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Fri, 29 Dec 2006 12:05:46 -0800 * From: "Tom Linden" <tom@kednos-remove.com>! Subject: Re: PWR SWitch om XP1000 ) Message-ID: <op.tlb7fwsitte90l@hyrrokkin>   J On Fri, 29 Dec 2006 11:48:53 -0800, Steven M. Schweda <sms@antinode.org>   wrote:  , > From: "Tom Linden" <tom@kednos-remove.com> > E >> Just got back from Palm Desert.  While away I had left 3 XP1000's, H >> a VAX and a DS10L running in the cluster.  Owing to our annual winterE >> storms we had a several power outages here in Pebble Beach.  After H >> the first outage the systems rebooted.  There were apparently severalJ >> other outages and when I returned I noticed that all the power switchesJ >> on the XP1000's were dark.  Not so on the VAX or DS10L.  Depressing theJ >> switches restored things to normal.  Anybody expreience this with theseB >> machines?  Is this a known bug?  AUTO_ACTION is set to RESTART. > I >    My XP1000 systems seem to remember the power switch setting properly F > (unlike my early edition PWS 500a[u], which did not).  Sounds like aC > mystery (unless your batteries are dead, or an NVRAM is fried, or  > something like that).  > F Batteries are OK and NVRAM is fine and they have successfully rebootedH after a number of power outages.  I think we can also rule out neutrinosJ on probabilistic arguments.  My guess is that power irregularities somehow: put it into a funny state and it shut down, maybe a surge.J > ------------------------------------------------------------------------ > 5 >    Steven M. Schweda               sms@antinode-org 6 >    382 South Warwick Street        (+1) 651-699-9818 >    Saint Paul  MN  55105-2547        --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Fri, 29 Dec 2006 15:26:23 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ! Subject: Re: PWR SWitch om XP1000 8 Message-ID: <459579d7$0$21886$c3e8da3@news.astraweb.com>   Tom Linden wrote: L > on probabilistic arguments.  My guess is that power irregularities somehow< > put it into a funny state and it shut down, maybe a surge.  K Although done with totally different hardware, I had similar problems with  I my Vaxstation 3100-30. If the power cycled too quickly, the power supply  I would "jam" and the machine would stay off , despite the hardware switch  J being in the ON position.  Had to power cycle it again with a long enough K pause before setting the switch back "ON" at which point the machine would   start up properly.  J If one of the power glitch caused the power supply to jam, then the logic 9 on the CPU wouldn't be told that power had been restored.    ------------------------------  % Date: Fri, 29 Dec 2006 20:25:45 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>! Subject: Re: PWR SWitch om XP1000 8 Message-ID: <1bac9$4595c03d$cef8887a$20861@TEKSAVVY.COM>   H Vlems wrote:M > JF, I guess that the behaviour you're describing has nothing to do with the H > problems of the XP1000. The VAX/VAXstation 3100 series (as well as theD > VAXstation 4000 models) have a power supply that has some built in > intelligence.   H I would have to assume that alphas also have some intelligence in their C power supply. (in fact more so since the "on-off" switch is not as  * "hardware" as that of the older machines).  M > button that operates circuitry that connects to the mains. My XP1000 failed . > to power up when I pressed the mains switch.  K On the DS10L, the actual little switch is actually a switch even though it  H feels like a momentary push-button.  If the XP1000 is the same way, the J first time you pressed it, you may have actually turned it "OFF" and then + the second time, you may have turned it on.   I And boeyond that switch (On the DS10L at least) is the remote mamagement  I console which has its own processor that is powered up when the hardware  F switch is "ON". It controls whether the computer is powered on or not J (POWER ON and POWER OFF commands, as well as the logic that automatically @ shuts off teh coputer when the temperature exceeds a threshold).  K If there is an RMC on the X1000, knowing if it was functional or not would  J provide a hint on whether it was the power supply that remained "OFF", or A whether it was the RMC that decided to not power the CPU back up.    ------------------------------    Date: 29 Dec 2006 17:48:06 -0800; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> ! Subject: Re: PWR SWitch om XP1000 C Message-ID: <1167443285.984662.134250@h40g2000cwb.googlegroups.com>    JF Mezei wrote:  > H Vlems wrote:O > > JF, I guess that the behaviour you're describing has nothing to do with the J > > problems of the XP1000. The VAX/VAXstation 3100 series (as well as theF > > VAXstation 4000 models) have a power supply that has some built in > > intelligence.  > I > I would have to assume that alphas also have some intelligence in their D > power supply. (in fact more so since the "on-off" switch is not as, > "hardware" as that of the older machines). > O > > button that operates circuitry that connects to the mains. My XP1000 failed 0 > > to power up when I pressed the mains switch. > L > On the DS10L, the actual little switch is actually a switch even though itI > feels like a momentary push-button.  If the XP1000 is the same way, the K > first time you pressed it, you may have actually turned it "OFF" and then - > the second time, you may have turned it on.  > J > And boeyond that switch (On the DS10L at least) is the remote mamagementJ > console which has its own processor that is powered up when the hardwareG > switch is "ON". It controls whether the computer is powered on or not K > (POWER ON and POWER OFF commands, as well as the logic that automatically B > shuts off teh coputer when the temperature exceeds a threshold). > L > If there is an RMC on the X1000, knowing if it was functional or not wouldK > provide a hint on whether it was the power supply that remained "OFF", or C > whether it was the RMC that decided to not power the CPU back up.   F If it works anything like an ATX power supply then the "smarts" are onF the mainboard.  The power supply has a trickle feed which is always on@ whenever the p/s is plugged in.  The mainboard has a small logicA section which is constantly monitoring the power switch. When the F switch is closed it triggers the logic to raise a signal to the p/s toC turn fully on. The logic section also usually senses if the various G voltages coming from the p/s are within expected values and then either F allows the system to start booting or tells the p/s to shutdown again.  F Depending on the design it is possible that repeated voltage spikes orF outages could easily confuse this circuit and cause the system to hang in the power off stage.   C What I'm wondering is if these systems are not on some sort of UPS? C The protection factor against surges and multiple power drops alone @ would be worth the cost against risking the damage that could be- caused. Even if the storms are just seasonal.      John H. Reinhardt    ------------------------------  + Date: Fri, 29 Dec 2006 21:25:21 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) 4 Subject: Re: Renaming a root from [SYS0] to [SYS1] ?( Message-ID: <en4141$ld4$1@pcls6.std.com>  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   G >And obviously, when I do attempt the rename, i will quiesce my system.   . >I am hoping to get around to it this weekend.   Well, OK, it's your system.    ------------------------------  # Date: Sat, 30 Dec 2006 00:38:03 GMT + From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= , Subject: Re: Whatever happened to Christmas?3 Message-ID: <Lxilh.27739$E02.11399@newsb.telia.net>    bob@instantwhip.com skrev: > Alan Greig wrote: I >> Jesus is one of the most important figures in Islam believe it or not.  > 9 > Jesus preached love and the ten commandments, one being  > "thou shalt not kill" ...  > A > Jesus did not force Himself on anybody threatening to kill them  > if they did not convert ...  > 1 > Jesus said and proved He was the Son of God ...  > ( > do they follow any of these teachings? >      And exactly *who* does ???   ------------------------------  + Date: Fri, 29 Dec 2006 15:21:48 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)G Subject: Re: Who's crazier, HP C V7.1-015 on OpenVMS Alpha V7.3-2 or I? 2 Message-ID: <06122915214808_2020028F@antinode.org>      As you may recall:   @ > ALP $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) -' >        /OBJ=ubz2err.AXP_obj ubz2err.c  > L > ALP $ pipe anal /obje ubz2err.AXP_obj | search sys$input bz_internal_error- >                 symbol: "BZ_INTERNAL_ERROR"  > @ > ALP $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) -5 >        /OBJ=ubz2err.AXP_obj ubz2err.c /show = brief 5 >                                       =============  > L > ALP $ pipe anal /obje ubz2err.AXP_obj | search sys$input bz_internal_error- >                 symbol: "bz_internal_error"         For those keeping score:   @ td183 $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) -'          /OBJ=ubz2err.I64_obj ubz2err.c   : td183 $ pipe anal /obje /sect = symtab ubz2err.I64_obj | -+          search sys$input bz_internal_error E 00000638 00000138  Symbol 13. (0000000D)          "BZ_INTERNAL_ERROR"   @ td183 $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) -5          /OBJ=ubz2err.I64_obj ubz2err.c /show = brief   : td183 $ pipe anal /obje /sect = symtab ubz2err.I64_obj | -+          search sys$input bz_internal_error E 00000638 00000138  Symbol 13. (0000000D)          "bz_internal_error"     ( td183 $ show symb cc   !!! So don't ask.= %DCL-W-UNDSYM, undefined symbol - check validity and spelling    td183 $ cc /vers" HP C V7.2-022 on OpenVMS IA64 V8.3    D    Apparently, it's a trend.  On the bright side, it appears to be a relatively recent trend:  ? GIMP $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) - &         /OBJ=ubz2err.VAX_obj ubz2err.c  K GIMP $ pipe anal /obje ubz2err.AXP_obj | search sys$input bz_internal_error '             symbol: "bz_internal_error"   ? GIMP $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) - 4         /OBJ=ubz2err.VAX_obj ubz2err.c /show = brief  K GIMP $ pipe anal /obje ubz2err.AXP_obj | search sys$input bz_internal_error '             symbol: "bz_internal_error"   ' GIMP $ show symb cc   !!! So don't ask. = %DCL-W-UNDSYM, undefined symbol - check validity and spelling    GIMP $ cc /vers % Compaq C V6.4-005 on OpenVMS VAX V7.3   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  + Date: Fri, 29 Dec 2006 19:46:35 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)G Subject: Re: Who's crazier, HP C V7.1-015 on OpenVMS Alpha V7.3-2 or I? 2 Message-ID: <06122919463561_2020028F@antinode.org>  A > GIMP $ cc /include = ([], [.vms]) /define=(MODERN, USE_BZIP2) - ( >         /OBJ=ubz2err.VAX_obj ubz2err.c > M > GIMP $ pipe anal /obje ubz2err.AXP_obj | search sys$input bz_internal_error ) >             symbol: "bz_internal_error"  > [...]   .    Apparently I wasn't paying attention there.  B    In fact, on the VAX, "BZ_INTERNAL_ERROR" was always upper-case,F irregardful of the compiler listing options I tried, which is actually( rather comforting, as things turned out.  H    While reviewing the compiler release notes, I found the actual sourceB of the problem, namely a function prototype in a header file whichF lacked the magic "#pragma names" directives.  As it says in the notes:                    [...] TheD                  NAMES setting in effect at the first declaration ofD                  an external name is the one that takes effect, thusC                  the setting specified in a header file will not be G                  overridden by a subsequent redeclaration in the user's I                  program (which might specify a different NAMES setting).   H    This explains the always-"BZ_INTERNAL_ERROR" behavior on the VAX, butF it doesn't explain the /SHOW=BRIEF-dependent behavior on the Alpha andE IA64.  However, I can make things LINK properly now without the goofy 7 compiler listing work-around, so things could be worse.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------   End of INFO-VAX 2006.718 ************************