1 INFO-VAX	Sun, 21 May 2006	Volume 2006 : Issue 280       Contents:' ANN: HTNotes - a web interface to NOTES " Re: Fixing a Corrupt PCSI Database" Re: Fixing a Corrupt PCSI DatabaseP Re: OT: Woodcrest (X86-64) will ouperform all other cpus on the market  says InqP Re: OT: Woodcrest (X86-64) will ouperform all other cpus on the market says Inqu Re: Performance and Disk Size  Re: VPM_SERVER strangeness Re: VPM_SERVER strangeness/ Re: what should Bad-Clients: in SMTP.CONFIG do?   F ----------------------------------------------------------------------    Date: 20 May 2006 18:56:47 -0500? From: burley.not-this@encompasserve-or-this.org (Graham Burley) 0 Subject: ANN: HTNotes - a web interface to NOTES3 Message-ID: <wUNhvj+qn8NI@eisner.encompasserve.org>   H HTNotes provides a web interface to Notes, it provides a full Notes userI context and many of the features of the standard Notes client. A user can K switch between HTNotes and standard Notes clients and maintain a consistent H Notebook and identity. HTNotes can also be configured to allow anonymous read & write access to Notes.   I HTNotes is available as a *beta* for use with WASD or OSU web servers at:   & 	http://www.encompasserve.org/~burley/    . %HOBBYIST-?-CODE, coded by an OpenVMS hobbyist   ------------------------------  # Date: Sat, 20 May 2006 20:34:37 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>+ Subject: Re: Fixing a Corrupt PCSI Database 0 Message-ID: <x3Lbg.861$Qn3.747@news.cpqcorp.net>   Steve Matzura wrote:0 > On Fri, 19 May 2006 18:27:11 GMT, Hoff Hoffman" > <hoff-remove-this@hp.com> wrote: > G >>   I wish you luck with your recommendation, but what those HP folks  G >> told you was very likely correct, and likely the safest course.   I  D >> would tend to expect to have to perform a roll forward to regain C >> consistency, an approach the folks you talked with at HP likely   >> commented on. > F > No, they did not.  I'll ask about it.  Any info before I get to them > would be greatly appreciated.   D    Again, please contact the support center folks -- they'll have a G better view into the particular system involved, and to the particular  I corruption that has arisen.  Me discussing this with you discussing this  E with the end-user system manager is a little too, um, "disconnected"  F from the error for my personal preference here, and a little too open * for the unintended introduction of errors.  A    The sequence is moderately involved, as well -- assuming it's  F applicable for this particular PCSI corruption.  Assuming there's not B something nasty, the classic sequence is listed in Ask The Wizard E (2434); at the URL <http://h71000.www7.hp.com/wizard/wiz_2434.html>.  E The support center folks will be able to troubleshoot the error here  7 rather better, given the more direct contact available.   E    Another factor central in the recovery is the installation of the  I current PCSI ECO kit for the OpenVMS version in use, and at the earliest   available opportunity.   ------------------------------  % Date: Sat, 20 May 2006 17:42:58 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> + Subject: Re: Fixing a Corrupt PCSI Database , Message-ID: <446F8D57.29F0410B@teksavvy.com>  H re: having to re-install a whole suite of products just because one PCSI file is "corrupt".  E If this were Windows, nobody would balk at such a suggestion. It is a  standard practice.  G But for VMS, such an answer isn't really acceptable in my opinion.  The G PCSI architecture should allow manual fixing when necessary, even if it T means adding a flag to records to indicate that the record was added "artificially".  D If you have a system that works, with software that works, having toE destabilise everything just because the PCSI thing isn't perfect is a D big ask, especially when you consider the amount of work required toG fetch all the kits and ensure they are installed in the right order and D that none of those PCSI installations xap any customisations you may
 have done.  F If the database is OK, but warns of a missing product specific file, IE would fetch the product's original .PCSI file , extract all the files > from it in a temporary directory and find the product specificF .pcsi<mumble>  and put them where they belong.  This way, you are sure) that nothing will mess with your system.    ? And if it is the actual database that is corrupt, then edit the E installation script for the product, cut all the stuff out except the G part that updates the PCSI database. You can then repackage the kit and @ install it, knowing all it will do is update the pcsi databases.   ------------------------------  % Date: Sat, 20 May 2006 19:24:26 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Y Subject: Re: OT: Woodcrest (X86-64) will ouperform all other cpus on the market  says Inq ) Message-ID: <446FA51A.4C17F@teksavvy.com>    Neil Rieck wrote: K > Engineering. When HP stops manufacturing Alpha Servers at the end of 2006 : > the peanut gallery will see OpenVMS as a one-trick pony.  C The real issue as that as the 8086 scales up quickly, there will be K fewer and fewer types of systems where that IA64 thing will be competitive.   E The correct direction to take for VMS is to follow SUN's lead: VMS on C 8086 for low end (desktop + small+mid servers) and VMS on that IA64 - thing for superdomes and other large servers.   H The more overlap between 8086 and Alpha/IA64, the more time ISVs have toC make their software abailable on the 8086. And the more software is A available, the less traumatic the port will be. And remember that D starting this october, there won't be many sales of new hardware forB VMS, most customers will see Alphas on the used markets.  Making aH commitment to the 8086 would then unleash new energy into VMS and people9 would start buying hardware and VMS based software again.   E If, at the time IA64 is officially killed, VMS is already running (or D close to it) on the 8086, then there wouldn't be a question of VMS'sG survival. But if VMS management have not actively ported/porting VMS to A the 8086, then it becomes much easier for folsk liek Stallard and A Winkler-clones to convince Hurd it isn't worth porting VMS again.    ------------------------------  % Date: Sat, 20 May 2006 17:42:30 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> Y Subject: Re: OT: Woodcrest (X86-64) will ouperform all other cpus on the market says Inqu : Message-ID: <%1Mbg.10648$aa4.443902@news20.bellglobal.com>   > ' <bob@instantwhip.com> wrote in message  = news:1148136720.617884.260990@y43g2000cwc.googlegroups.com... % > so when does the vms port start? :)  >   M Hopefully this has already started as a "skunk works" project inside OpenVMS  J Engineering. When HP stops manufacturing Alpha Servers at the end of 2006 8 the peanut gallery will see OpenVMS as a one-trick pony.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html: http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------  # Date: Sat, 20 May 2006 20:13:08 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>& Subject: Re: Performance and Disk Size0 Message-ID: <oLKbg.859$Ys3.322@news.cpqcorp.net>   prep@prep.synonet.com wrote:  E    [discussion of moving to 16, 32, 64, or larger powers of 2, block   cluster factors expurgated.]   > Is this a recent change?  @    The disks with the larger sector sizes are in the design and I engineering and committee pipelines, with product releases estimated for  E this year or next.  Much like using a larger page size, using larger  ? block sizes can assist in various ways -- but at least for the  E foreseeable future.  These devices are currently targeting 4096 byte   sector sizes, native.   I    (I personally expect at least some of these disk drives will continue  G to present 512-byte sections (by default), and that host device driver  D work would be required to switch into operations with larger sector C sizes.  Legacy operations, if you want to use the L-word.  This is  E personal opinion, BTW, and this may or may not prove correct, and is  H entirely up to the various vendors.  At the disk level, it's "just" new F firmware.  Up the I/O stack and through the operating system and into H the application code, however, it's rather more work to bring these new > disks on-line if they do not also offer some form of 512-byte I operations.  Within OpenVMS, we already de-block the native sector sizes  I with CD and DVD media, as these devices use 2048-byte operations, and --  H other than SETBOOT, COPY/RECORDABLE_MEDIA and similar low-level giblets H -- nothing really knows about or has to know about the 2048-byte native @ sectors.  These disks look to be 512-byte devices, based on the H operations provided by the drivers.  Again, there is extensive personal  opinion embedded here.)   @    Various of the storage controllers that benefit from natural C alignment and moderately-sized cluster factors have been out for a  E couple of years now, and the benefits of natural alignment have been  D noticed during performance testing.  (If you have disk partitioning F within an operating system, things get rather more interesting, as it G isn't (just) the cluster factor within the partition that enhances (or  E degrades, depending on ow you look at it) performance, it's both the  3 alignment of the partition AND the cluster factor.)   A    http://www.idema.org (International Disk Drive, Equipment and  H Materials Association) is the association, and there are discussions at D that web site.  This hits a number of parts of an operating system, G obviously, and the discussion has been brewing for a few years.  There  , are discussions on-going elsewhere, as well.   ------------------------------  # Date: Sat, 20 May 2006 20:15:47 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com># Subject: Re: VPM_SERVER strangeness 0 Message-ID: <TNKbg.860$Ys3.830@news.cpqcorp.net>  / Phillip Helbig---remove CLOTHES to reply wrote: ? > In article <Crkbg.808$7u2.460@news.cpqcorp.net>, Hoff Hoffman $ > <hoff-remove-this@hp.com> writes:  > 2 >> Phillip Helbig---remove CLOTHES to reply wrote:+ >>> ...VPM server was showing a few hundred + >>> thousand page faults and 0 CPU usage...  ... G > They are both 7.3-2, fully patched (except for the latest FIBRE_SCSI  	 > patch).  >  >>    VPM via DECnet or IP?  >  > IP.   9    IP version and ECO?  Something "odd" in the IP set-up?    ------------------------------  # Date: Sun, 21 May 2006 04:59:42 GMT   From: John Santos <john@egh.com># Subject: Re: VPM_SERVER strangeness ) Message-ID: <2tSbg.1000$oA6.571@trnddc06>   / Phillip Helbig---remove CLOTHES to reply wrote: ? > In article <Crkbg.808$7u2.460@news.cpqcorp.net>, Hoff Hoffman $ > <hoff-remove-this@hp.com> writes:  >  > 1 >>Phillip Helbig---remove CLOTHES to reply wrote:  >>* >>>...VPM server was showing a few hundred* >>>thousand page faults and 0 CPU usage...G >>>Another cluster, same VMS and patch level, shows no problems at all. J >>>I restarted the VPM server on the system with problems.  No change: it + >>>immediately starts throwing page faults.  >>J >>   That two OpenVMS systems are at the same revision level is certainly H >>interesting and useful, but knowing that both are at the most current H >>level is arguably more interesting.  (The former implies a difference J >>between the box that doesn't involve ECO kits, while the latter implies H >>the potential for a new and as-yet unresolved problem within OpenVMS.) >  > G > They are both 7.3-2, fully patched (except for the latest FIBRE_SCSI  	 > patch).  >  >  >>   VPM via DECnet or IP? >  >  > IP.  >  >  >>   OpenVMS version   >  >  > See above.   >  >  >>and architecture?  >  > G > The system with the problem is COMPAQ Professional Workstation XP1000 B > while the one in the same cluster without the problem is DigitalI > AlphaStation 500/500.  (In my cluster, I have a DEC 3000/600 and a 5305 E > (ALPHAserver 1200)---both at 7.3-2 and fully patched (the 5305 is a > > satellite of the DEC 3000)---and have not seen the problem.) >  >  >>   How was VPM started?  >  > - > Via the startup database feature in SYSMAN.  >  > I >>   Different system default quotas?  (That case shouldn't hit VPM, but  J >>I've seen that trip various applications over the years -- depending on D >>the system default quotas can lead to odd application differences 9 >>between two otherwise identical systems, for instance.)  >  >  > There is a common SYSUAF.  >   @ Are the sysgen PQL parameters the same?  Maybe on one system theB UAF WSEXT or WSQUOTA is getting overridden by a PQL MIN parameter,> but it is allowed to stand on the other one, resulting in less? memory available to the process and zillions of (probably soft)  page faults.         > D >>   There are ECOs available for VPM-related problems for specific  >>OpenVMS releases.  >  > I > The problem is still there.  A restart of the VPM_SERVER didn't change  F > anything.  Here are some outputs from SHOW SYSTEM taken a couple of - > seconds apart.  Note the lack of CPU usage.  > O > 2120014E VPM_SERVER      HIB     15       18   0 00:00:00.02   9201890    107  > O > 2120014E VPM_SERVER      HIB     15       18   0 00:00:00.02   9203060    107  > O > 2120014E VPM_SERVER      HIB     15       18   0 00:00:00.02   9204464    107  > O > 2120014E VPM_SERVER      HIB     15       18   0 00:00:00.02   9205400    107     E What does this look like on the systems that are okay?  Is it getting  more pages (last column?)        > I > SHOW PROC/CONT shows only the page faults changing, everything else is  	 > static.  > I > (This isn't my system but I do have access to a priviledged account on  ) > it, so could try out some diagnostics.)  > + > SHOW ERROR doesn't show anything of note.  > N > Physical Memory Usage (pages):     Total        Free      In Use    ModifiedN >   Main Memory (256.00MB)           32768       21441        9526        1801 >      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 20 May 2006 15:17:43 -0400 - From: JF Mezei <jfmeze.spamnoti@teksavvy.com> 8 Subject: Re: what should Bad-Clients: in SMTP.CONFIG do?, Message-ID: <446F6B57.6DC431E4@teksavvy.com>  / Phillip Helbig---remove CLOTHES to reply wrote: G > No.  I can understand people who ALWAYS have spam-blocks in the From: J > address, and I don't want to drop those.  Of course, the place to put itG > is in the domain, not in the username, so that the domain doesn't get  > mail for a non-existent user.   F For NNTP, esepcially moderation robots, you want to have a real domainH in your From:, this is why most transformations of valid email addresses happen at the username level.   + > Mail from unbacktranslatable is accepted.   E You might wish to disable this. (reject unbacktranslatable to True).  G > No, relaying is switched off.  This was an example of a mail from the J > same IP address to a domain I DO accept mail for.  Since the user was a) > non-existent    D OK, if this is a bounce message then one cannot draw any conclusionsA from it. Bounces don't show who they were originally intended for ' (unless you look inside their content).     G Remember that the SMTP server on VMS does not act on the "From:" in the H RFC headers. It delivers to destinations specified in an RCPT TO: in the SMTP dialogue.   ------------------------------   End of INFO-VAX 2006.280 ************************                                                                                                                                                                                                                                                                6@K%f
iMf!ξqOUYN0s`<Q=K ?
DKOp\5NTSjP4F %ǐ%`'b[U-tMjr *t9V¸q~jͥdY5ɟ;;g`wgŅ]%d,۩$_弝j|gtf?m~XC}۟}caan
X.>VR2E8FOꊾs`WL [[qlTVي;,Rsv[{Q\31ūq߉|x}qlJ*F"r;j~_/t|[!x̱kxM6A|GAt4
ޑr2&[AјtZ0(e5N([s&AqT*.tg4U]KO[%q5l^Omurwq:Ϧ⾡Ժ5.j-J.