1 INFO-VAX	Thu, 08 Jun 2006	Volume 2006 : Issue 317       Contents:. CMS question - notification of changed element Re: Intel selling Itanium? Re: Intel selling Itanium? Re: Intel selling Itanium? Re: Intel selling Itanium? Re: Intel selling Itanium? learning vms long distance data replication9 More than 2,000 Best Software in internet, 100% guarantee & RE: Problem with "New mail" broadcasts& Re: Problem with "New mail" broadcasts- Re: Replacing common dump file - sanity check - Re: Replacing common dump file - sanity check / Re: SA 5300A, changing system disk breaks ACUXE 3 Re: SimH 3.6-0 (problems compiling VAX using MinGW) 3 Re: SimH 3.6-0 (problems compiling VAX using MinGW) & Re: Two VAXBI Node number plugs needed& Re: Two VAXBI Node number plugs needed& Re: Two VAXBI Node number plugs needed( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definitionC Re: What wide SCSI constrollers will be recognized by SRM of PWS600   F ----------------------------------------------------------------------  % Date: Thu, 08 Jun 2006 11:24:55 -0400 # From: sol gongola <sol@adldata.com> 7 Subject: CMS question - notification of changed element 0 Message-ID: <1149780326.584388@nntp.acecape.com>  C I am looking for a way to notify others that a cms element has been E updated. We compile the source on multiple platforms and need to know C when the compiles need to be performed elsewhere. Something like an G automated email notification would make things easier than periodically  running a dir/since.  " CMS Version V3.8-2, OpenVMS V7.2-1    	 Thank you  sol    ------------------------------  % Date: Thu, 08 Jun 2006 08:15:57 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de># Subject: Re: Intel selling Itanium? / Message-ID: <e68fa7$gte$01$2@news.t-online.com>    Tom Linden schrieb: ' > PA-RISC is even more dead than Alpha.   1 So their last order date is before October 2006 ?    ------------------------------  % Date: Thu, 08 Jun 2006 08:17:59 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de># Subject: Re: Intel selling Itanium? / Message-ID: <e68fe1$gte$01$4@news.t-online.com>    JF Mezei schrieb: I > Right now, HP expects to lose about 30% of its BCS customers because of H > the unwanted migration to that IA64 thing.  If HP revitalises PA-Risc,H > it may end up keeping a greater number of customers and hence profits.  = PA-RISC is or would be profitable in case of revitalization ? 9 Wasn't the reason to drop it in favour of itanic the lack  of profitability ?   ------------------------------  % Date: Thu, 08 Jun 2006 03:32:13 -0400 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: Intel selling Itanium? G Message-ID: <1dydnb5sb__gTxrZnZ2dnUVZ_vGdnZ2d@metrocastcablevision.com>    Michael Kraemer wrote: > JF Mezei schrieb: J >> Right now, HP expects to lose about 30% of its BCS customers because ofI >> the unwanted migration to that IA64 thing.  If HP revitalises PA-Risc, I >> it may end up keeping a greater number of customers and hence profits.  > ? > PA-RISC is or would be profitable in case of revitalization ? ; > Wasn't the reason to drop it in favour of itanic the lack  > of profitability ?  G Not at all - in fact, Itanic began life as PA-RISC III.  After several  I years of work (starting in late 1988), HP decided that having Intel as a  D partner was a great idea:  Intel could contribute the manufacturing G expertise and economies of scale, while HP could reap the benefit of a  B chip tailored to its needs without having to build it itself, and D together they would preside over a monopoly on the high-performance 8 commercial market once their wunderchip hit the streets.  G Great in theory, considerably less so in the execution - probably more  = HP's fault than Intel's, since most of the problems involved  C difficulties in realizing the (alleged) potential of the VLIW/EPIC  I architecture that HP had promoted to Intel (and later to the rest of the  I world - far in advance of any evidence that it could actually deliver on  G the hype).  True, Intel's Merced team came up far short in performance  G and 'way long on schedule, but HP's McKinley team didn't come anywhere  G near creating the hyped RISC-annihilating juggernaut either (let alone  G deliver their product any more quickly), just barely managed to create  I something sufficiently competitive to keep the wallowing ship afloat and  D at least the majority of their PA-RISC customers on board (and only H after they gave them a couple more generations of PA-RISC than they had 3 originally planned to offer to fill the major gap).   C Rumor has it that shortly after Carly took the helm at HP (perhaps  C around 1999) some of the engineers there voiced significant second  > thoughts about the viability of Itanic and urged that PA-RISC H development be restarted for real, but got over-ruled (funny:  'burning F the boats' seems to have been something of a Carly trademark).  Given F how much money HP has since shoveled down the Itanic rat-hole and how H little it has gotten in return (e.g., it seems unlikely that 1/3 of its I HP-UX base would be up for grabs if serious PA-RISC development had been  @ restarted back then), it seems reasonable to suggest that those D engineers were right - though it's certainly reasonable to question G whether restarting PA-RISC development *now* (7 years later) could get  F HP out of the hole it dug for itself (and yes, resurrecting Alpha now I would probably be at least an equally questionable strategy:  some boats   once burned never float again).    - bill   ------------------------------   Date: 8 Jun 2006 06:27:20 -0700  From: bob@instantwhip.com # Subject: Re: Intel selling Itanium? C Message-ID: <1149773240.345439.234570@g10g2000cwb.googlegroups.com>    Michael Kraemer wrote: > JF Mezei schrieb: K > > Right now, HP expects to lose about 30% of its BCS customers because of J > > the unwanted migration to that IA64 thing.  If HP revitalises PA-Risc,J > > it may end up keeping a greater number of customers and hence profits. > ? > PA-RISC is or would be profitable in case of revitalization ? ; > Wasn't the reason to drop it in favour of itanic the lack  > of profitability ?  A pa risc only runs hp unix which most would eventually end up with 
 x86 linux ...   > OpenVMS is a different story, and bringing back alpha may be a= good and inexpensive strategy unless the port to x86 would be  easy ...   ------------------------------   Date: 8 Jun 2006 07:11:19 -0700  From: etmsreec@yahoo.co.uk# Subject: Re: Intel selling Itanium? C Message-ID: <1149775879.782840.172510@h76g2000cwa.googlegroups.com>   E With/by whom?  The Alpha developers were let go to Intel.  I wouldn't C bet on them being happy to return to the company (or its successor) G that transferred them out the door when they decided to kill off Alpha.    Steve    bob@instantwhip.com wrote: > Michael Kraemer wrote: > > JF Mezei schrieb: M > > > Right now, HP expects to lose about 30% of its BCS customers because of L > > > the unwanted migration to that IA64 thing.  If HP revitalises PA-Risc,L > > > it may end up keeping a greater number of customers and hence profits. > > A > > PA-RISC is or would be profitable in case of revitalization ? = > > Wasn't the reason to drop it in favour of itanic the lack  > > of profitability ? > C > pa risc only runs hp unix which most would eventually end up with  > x86 linux ...  > @ > OpenVMS is a different story, and bringing back alpha may be a? > good and inexpensive strategy unless the port to x86 would be 
 > easy ...   ------------------------------   Date: 8 Jun 2006 09:54:19 -0700 ( From: "geletine" <adaviscg1@hotmail.com> Subject: learning vms C Message-ID: <1149785658.913726.109360@u72g2000cwu.googlegroups.com>    Ive seen a few book on amazon ,  http://www.amazon.co.uk/exec/obidos/search-handle-url/202-7270782-5070231?%5Fencoding=UTF8&search-type=ss&index=blended&field-keywords=vms) which books are recommended to learn vms? D I have seen http://deathrow.vistech.net/ , which is very encouraging	 project..   / I feel that openvms lacks publicity, apart from C http://h71000.www7.hp.com/success-stories.html , are they any other F published institutions that use openvms? , i am aware it was used on a space shuttle.  G Many will disagree, i feel that if openvms was to become open source, a F lot more would use it, i could imagine countless ports being made, oneF of the reasons i believe that it has a smaller popularity, and perhapsE the reason why its secure? (Security by oscurity)If vms was to become F open source, nobody can deny security vunerbilities would happen, evenD with openbsd , vunerbilities occur (not by default in over 8 years).  E To support the open source view, i recommend Bruce Schneier excellent 5 article on why open source security is a good option. C http://www.schneier.com/crypto-gram-9909.html#OpenSourceandSecurity   F As my post started, i am interested in learning vms than comparing....   thanks in advance    ------------------------------   Date: 8 Jun 2006 00:38:47 -0700 - From: "mb301@hotmail.com" <mb301@hotmail.com> ' Subject: long distance data replication A Message-ID: <1149752327.403643.97780@f6g2000cwb.googlegroups.com>   E It's good to see IBM supporting HP OpenVMS with their lateste release  of SVC.   F IBM makes long distance call with storage software.. SVC will now work with HP's OpenVMS   9 http://www.channelregister.co.uk/2006/05/25/ibm_svc_four/    ------------------------------   Date: 8 Jun 2006 09:31:20 -0700  From: myoceandream@gmail.comB Subject: More than 2,000 Best Software in internet, 100% guaranteeB Message-ID: <1149784280.723685.29740@c74g2000cwc.googlegroups.com>   http://www.3wgift.com   ? More than 2,200 Best industry software and business software in   internet, discount, from 15~35$.  G This is not a Spam, I absolutely did not want to cheat anybody's money. F Just to make a chance for us, I REALLY think our products is worth you take a look!9 We promise, you can 100% refund if you 1% not satisfied .    ------------------------------  * Date: Thu, 8 Jun 2006 07:55:48 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)/ Subject: RE: Problem with "New mail" broadcasts $ Message-ID: <e68l64$bnl$1@online.de>  
 In articleA <085BCCCF596B684092B66310B1D3BA7D02A61A25@NJ103EX1.EAST.VIS.COM>, 4 "Farrell, Michael" <MFarrell@Voltdelta.com> writes:   G > " You could, additionally, use a chunk of code to interrogate the new ' > mail count every once in a while ..."  >  > How does one do that?    Submit this:   $BEGIN:  $  MAIL  SHOW NEW Q  $  WAIT 'p1' $GOTO BEGIN   F You can then do TYPE/TAIL/CONTINUOUS on the log file, or just execute ; the code above without the loop aspect at your convenience.    ------------------------------  % Date: Thu, 08 Jun 2006 17:35:17 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> / Subject: Re: Problem with "New mail" broadcasts , Message-ID: <4er0asF1ffql6U1@individual.net>  ) On 2006-06-07 21:58, "sol gongola" wrote:   B > If the characters were part of the message itself, they would beA > 'mimed' into alphanumeric and wouldn't cause this problem.  The * > same thing be done in the email headers?   It *should* be done of course.  A Having looked into some spam mails some time ago it seems to be a H problem of ISO-2022-xx character sets without MIME encoding the "escape"* character used to switch character tables.   Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  % Date: Thu, 08 Jun 2006 01:42:35 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 6 Subject: Re: Replacing common dump file - sanity check9 Message-ID: <UridnesOS7YuKhrZnZ2dnUVZ_o2dnZ2d@libcom.com>    norm.raphael@metso.com wrote: A > I have downsized the memory on this VAX and want to replace the = > common dump file.  I have created a new one and entered it. - > After I reboot, the new one will be in use. : > What are the proper steps to delete the old one cleanly?G > Must I SET FILE/REMOVE all the specific roots (this disk has several) < > before I purge the common file, or is there an easier way? >  > 4 > $DIRE/SIZ=ALL/FILE/WID=FILE=40 SYSDUMP*.DMP/NOHEAD9 > SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;2         (2349,2705,0)  > 262153/262156 7 > SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;1         (211,354,0)  > 786441/786444  > + > Total of 2 files, 1048594/1048600 blocks. 9 > SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP;2   (2349,2705,0)  > 262153/262156 7 > SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP;1   (211,354,0)  > 786441/786444  > + > Total of 2 files, 1048594/1048600 blocks.  > @ > Grand total of 2 directories, 4 files, 2097188/2097200 blocks. >   G I could be wrong here, but I don't think the file should have an entry  F in SYS$COMMON:.  The dump file is for a specific system, even if in a H cluster.  The page, swap, and dump files should all be in, and only in,  SYS$SPECIFIC:.  I Regardless, I think Richard is correct, a purge or a delete will get the  G job done.  If not, an ANA/DISK/REPAIR should get rid of the extra file   header.    --  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: Thu, 8 Jun 2006 11:34:06 +0000 (UTC) From: david20@alpha2.mdx.ac.uk6 Subject: Re: Replacing common dump file - sanity check) Message-ID: <e691ve$cv5$1@news.mdx.ac.uk>   c In article <UridnesOS7YuKhrZnZ2dnUVZ_o2dnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:  >norm.raphael@metso.com wrote:B >> I have downsized the memory on this VAX and want to replace the> >> common dump file.  I have created a new one and entered it.. >> After I reboot, the new one will be in use.; >> What are the proper steps to delete the old one cleanly? H >> Must I SET FILE/REMOVE all the specific roots (this disk has several)= >> before I purge the common file, or is there an easier way?  >>   >>  5 >> $DIRE/SIZ=ALL/FILE/WID=FILE=40 SYSDUMP*.DMP/NOHEAD : >> SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;2         (2349,2705,0) >> 262153/2621568 >> SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;1         (211,354,0) >> 786441/786444 >>  , >> Total of 2 files, 1048594/1048600 blocks.: >> SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP;2   (2349,2705,0) >> 262153/2621568 >> SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP;1   (211,354,0) >> 786441/786444 >>  , >> Total of 2 files, 1048594/1048600 blocks. >>  A >> Grand total of 2 directories, 4 files, 2097188/2097200 blocks.  >>   > H >I could be wrong here, but I don't think the file should have an entry G >in SYS$COMMON:.  The dump file is for a specific system, even if in a  I >cluster.  The page, swap, and dump files should all be in, and only in,   >SYS$SPECIFIC:.  >   O Creating a common dump file and using set file/enter to create entries in each  K system's sys$specific area pointing at that common dump file was a standard M documented technique to save disk space on the system disk before you had the J ability to move the dumpfile off the system disk (and some of us are still
 using it).   eg  9 ALPHA1 System: dir sys$specific:[sysexe]sysdump*.dmp/full    Directory SYS$SPECIFIC:[SYSEXE]   3 SYSDUMP.DMP;1                 File ID:  (158,827,0) 0 Size:      2621516/2621520    Owner:    [SYSTEM]      1 Alpha2:dir sys$specific:[sysexe]sysdump*.dmp/full    Directory SYS$SPECIFIC:[SYSEXE]   3 SYSDUMP.DMP;1                 File ID:  (158,827,0) 0 Size:      2621516/2621520    Owner:    [SYSTEM]    / Alpha2:dir sys$common:[sysexe]sysdump*.dmp/full    Directory SYS$COMMON:[SYSEXE]   ? SYSDUMP-COMMON.DMP;1                      File ID:  (158,827,0) 0 Size:      2621516/2621520    Owner:    [SYSTEM]    
 David Webb Security team leader CCSS Middlesex University        J >Regardless, I think Richard is correct, a purge or a delete will get the H >job done.  If not, an ANA/DISK/REPAIR should get rid of the extra file  >header. >  >-- 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: Thu, 8 Jun 2006 11:55:40 -0400  From: "DBT" <dbturner@icusc.com>8 Subject: Re: SA 5300A, changing system disk breaks ACUXE0 Message-ID: <128gi5iqbtq3j48@news.supernews.com>  & From whom did you buy the system Rich?   DT   --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   3 "Rich Jordan" <jordan@ccs4vms.com> wrote in message = news:1149721002.154692.315270@y43g2000cwc.googlegroups.com...  > And another followup.  > I > Changed the allocation class as required, updating the SSL root logical E > as required.  ACUXE broke again, same symptoms; an access violation  > when I start it. > F > Removed and reinstalled ACUXE, no go.  Removed and reinstalled ACUXEH > and the management agents.  No go.  Removed both plus completely wipedH > and rebuilt the TCPIP configuration, no go.  Full power cycles between > attempts, no change. > F > The raid setup created by booting from the local drive (which cannotE > remain) still works fine, and ACU-XE on that local drive also still F > works fine.  I can't find any differences other than the SSL logical > and the contents of the  > F > I still can't find anything relevant to the failure via google or on > itrc.  >  > > Rich >    ------------------------------  # Date: Thu, 08 Jun 2006 10:35:34 GMT ( From: Alan Greig <greigaln@netscape.net>< Subject: Re: SimH 3.6-0 (problems compiling VAX using MinGW)= Message-ID: <W3Thg.309554$tc.14605@fe2.news.blueyonder.co.uk>    Wilm wrote: I > I have a problem compiling VAX and VAX780 under Windows, using the SIMH " > supplied build_mingw.bat script. > H > The VAXen will not build *unless* I copy vax_defs.h, vaxmod_defs.h andF > vax780_defs.h from the VAX folder into the PDP11 folder. If not, theF > first PDP11 module to be compiled with either VAX fails with a "file! > not found" error on vax_defs.h.   = I had that problem as well. Also you should turn on full gcc  5 optimization. That almost doubles the emulator speed.   / > The gcc command generated by mingw32-make is:  > E > gcc -std=c99 -U__STRICT_ANSI__ -O0 -I. VAX/vax_cpu.c VAX/vax_cpu1.c 9 > VAX/vax_fpa.c VAX/vax_io.c VAX/vax_cis.c VAX/vax_octa.c A > VAX/vax_cmode.c VAX/vax_mmu.c VAX/vax_stddev.c VAX/vax_sysdev.c C > VAX/vax_sys.c  VAX/vax_syscm.c VAX/vax_syslist.c PDP11/pdp11_rl.c D > PDP11/pdp11_rq.cPDP11/pdp11_ts.c PDP11/pdp11_dz.c PDP11/pdp11_lp.cE > PDP11/pdp11_tq.c PDP11/pdp11_xq.c PDP11/pdp11_ry.c PDP11/pdp11_vh.c G > PDP11/pdp11_cr.c scp.c sim_console.c sim_fio.c sim_timer.c sim_sock.c H > sim_tmxr.c sim_ether.c sim_tape.c -DVM_VAX -DUSE_INT64 -DUSE_ADDR64 -I. > VAX/ -I PDP11/  -o bin/vax.exe -lm -lwsock32 > I > (note the -I switches to specify the #include directories, they seem to 
 > be correct)  >  > What am I missing? >  > /Wilm  >    --  
 Alan Greig   ------------------------------  % Date: Thu, 08 Jun 2006 19:14:03 +0200 3 From: Wilm Boerhout <w5OLD.boerhout@PAINTplanet.nl> < Subject: Re: SimH 3.6-0 (problems compiling VAX using MinGW)- Message-ID: <44885ADB.3010104@PAINTplanet.nl>   % Alan Greig wrote on 8-6-2006 12:35...   ? > I had that problem as well. Also you should turn on full gcc  7 > optimization. That almost doubles the emulator speed.   H Sounds good. How do I turn it on (I have installed MinGW 5.0.2, with it  comes gcc 3.42)    /Wilm    ------------------------------   Date: 8 Jun 2006 06:22:42 -0700 $ From: "Bob Armstrong" <bob@jfcl.com>/ Subject: Re: Two VAXBI Node number plugs needed C Message-ID: <1149772962.594397.238580@h76g2000cwa.googlegroups.com>    Bob Armstrong wrote: > ...   F   Alternatively, does anybody know the part number for these plugs, so& I can see if any are still available ?   Thanks,  Bob    ------------------------------  % Date: Thu, 08 Jun 2006 10:47:58 -0400  From: Pete <None@nospam..com> / Subject: Re: Two VAXBI Node number plugs needed 8 Message-ID: <k2eg82to32a164tv9rbcvultckk5g1351s@4ax.com>  C On 8 Jun 2006 06:22:42 -0700, "Bob Armstrong" <bob@jfcl.com> wrote:    >  >Bob Armstrong wrote:  >> ... > G >  Alternatively, does anybody know the part number for these plugs, so ' >I can see if any are still available ?  >  >Thanks, >Bob  &  12-23701-17 ID's 0 thru 9. Good luck.   Pete   ------------------------------   Date: 8 Jun 2006 09:48:05 -0700 $ From: "Bob Armstrong" <bob@jfcl.com>/ Subject: Re: Two VAXBI Node number plugs needed B Message-ID: <1149785285.892418.62750@j55g2000cwa.googlegroups.com>   Pete wrote:   
 >  Good luck.   @   Tell me about it :-)  Do you know what's actually inside theseC things?  You'd think they'd be just simple jumpers, but they've got C seven pins (which is way too many for four bits) and they're pretty : big.  I'd try to crack one open, but I'm already short :-)   Thanks,  Bob    ------------------------------  * Date: Thu, 8 Jun 2006 08:00:19 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)1 Subject: Re: Wanted:MAIL.MAI structure definition $ Message-ID: <e68lej$bnl$2@online.de>  E In article <Uzphg.9661$3i3.8801@trnddc08>, John Santos <john@egh.com>  writes:   I > (I use VMS Pine as a mail program.  It uses the standard mail.mai files F > and callable mail, but it attempts to impose some structure, such asE > threading the messages and selectively displaying RFC-style headers G > and manufacturing them from the DEC mail headers if they aren't there E > (i.e. for local mail or mail received over DECnet.)  It is far from J > ideal, and very slow, even though its searching abilities, address book,E > and so forth are much better than standard VMS mail.  There is huge I > room for improvement here.  For example, I simulate a multilevel folder G > structure by naming my folders "cat1-subcat1", "cat1-subcat2", "cat2- I > subcat1", "cat2-subcat1-subsubcat1", etc. which makes them sort nicely, H > but there is no way, for example to display a subtree or to search it.H > If I know I got mail in about something that is probably in one of theJ > "Cat3-..." folders sometime between 1999 and 2003, I need to iterativelyF > select each or the cat3* folders in turn, specify a date range (PineI > will do this), and then search.  Repeat until fingers fall off.  Or the F > easier way, just use DCL search [.mail]*.mai "something to look for"2 > with a big window and hope it isn't too common.)  A The MLSEARCH utility (written in FORTRAN, IIRC) can do much more  H flexible searching than the MAIL> SEARCH command.  A while back, Hunter : Goatley modified it so that it would run on ALPHA as well.   ------------------------------  * Date: Thu, 8 Jun 2006 11:04:51 +0000 (UTC) From: david20@alpha2.mdx.ac.uk1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <e6908j$cd8$1@news.mdx.ac.uk>   a In article <6CChg.1608$Ot2.1333@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes:   >david20@alpha2.mdx.ac.uk wrote: > O >> Relational databaes aren't a particularly good fit for storing and searching  >> Mime encoded mail messages. > D >   Relational databases would work just fine for this purpose -- I D >regularly store vastly more information in databases, and far more & >volatile and more active information. > J >   I can't say that MySQL would or would not work for this task nor that I >the solution would scale arbitrarily, but Oracle Rdb is blazingly fast,  H >and it's likely more than capable of handling the email traffic on the ) >local engineering cluster, for instance.  > K Relational databases are very good for structure which naturally can be put N into a tabular format. They aren't particularly good for handling objects likeN mail messages which are of an arbitrary size and arbitrarily complex structureI (eg messages containing nested multipart/mixed, multipart/alternative etc H parts containing images, video, audio, text and other document formats).O Many of which will certainly be base-64 or uuencoded and others of which may be M stored in an encrypted format. Also the exact format of the message body may  H need to be maintained in order to not invalidate signing of the message.B The exact order of message body parts also needs to be maintained.O This means that the message body would need to be stored as an opaque object in L the database (or as with exchange stored as a flat file on disk with just a , pointer to the file stored in the database).  J Headers are slightly better in that the complexity is reduced. However theF order of header-lines need to be maintained, header-line types such asK received-lines appear multiple times and there is no complete list of valid M header lines. The exact formats of header lines vary between implementations  C (even where they are defined in the appropriate RFCs there are many 2 implementations which are not strictly compliant).N Headers (as well as message bodies) may also contain encoded text to deal with( different charactersets as per RFC 2047.  L Hence once again the majority of headers are best stored as an opaque object. along with the message body or in a flat file.  H There are only a very limited number of headers which it makes sense to M search on eg Subject, From address, To address (and possibly CC address) and   date.   K The only advantage a centralised relational database has for storing these  O limited items  as against individual indexed files in each users home directory N is the possibility of just storing a single copy of a mail message rather thanM separate copies for each user. However this only really applies when the mail L message has entered the mail system as one single mail message which says itM needs to be delivered to all those users. The mail message-id is supposed to  N uniquely identify a mail message which if true would allow mail messages whichN had been split up during delivery but which were really still the same messageN to be stored just once. However unfortunately this is not possible since thereI are a number of systems which do not produce unique message-ids for every  message.  O One problem with the mail.mai indexed file approach as currently implemented is K that all the folders referenced in the mail.mai file are stored in the same L directory. A better approach would be to create separate sub-directories forG each folder. This would improve the performance when a user has tens to I hundreds of thousands or millions of mail messages without requiring the  H creation of separate (and more difficult to access) mail.mai files (and K should allow for reasonable searching across all the folders referenced in   the mail.mai file).   N Also given the size of mail messages in todays world it doesn't make sense forM the mail.mai file to store small mail messages directly in itself much better B just to store a pointer to the mail message in a flatfile on disk.  O Obviously there are a lot of things which need to be done to VMS Mail to better M support standard internet mail headers etc but I think the basic indexed-file C structure is a better approach than a relational database approach.     
 David Webb Security team leader CCSS Middlesex University    >    ------------------------------  # Date: Thu, 08 Jun 2006 12:53:48 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: Wanted:MAIL.MAI structure definition 2 Message-ID: <w5Vhg.1656$vY2.1023@news.cpqcorp.net>   Dave Froble wrote: > JF Mezei wrote:  >> Hoff Hoffman wrote:H >>>    More efficient, and less flexible -- it's a trade-off.  There areF >>> serious limits within the current design, such as the inability toK >>> generally search the mail file, or to have a message in two folders, or = >>> to handle the information in a transactional format, etc.  >>H >> Funny, ALLIN1 does all of this and it uses ISAM files for in indexes. > G > Yeah, through the years we did lots of things.  We also learned some  4 > lessons.  New ideas and products grew out of such. > I > Bottom line, a relational database is more flexible in the retrival of  K > data.  Note that I'm not a big fan of relational databases as a cure-all  J > for all purposes.  But for retrieval and searching, they're pretty good.    H    I have to assume that there is a lack of familiarity with relational G databases here.  Relational databases are very powerful, and very easy  H to add new data and new tables, and allow the programmer to provide the C end user great flexibility -- in terms of data organization, cross  8 linkages, action routines, transactional integrity, etc.  H    Could you do this with RMS?  Ayup.  But by the time you're done, you C are maintaining your own semi-relational database -- and there are  I features of database products that your upgraded RMS would still lack --  H and then you get to maintain your database, support and upgrade it, and  all the effort that entails?    D >> The problem with mail these days is that RFC822 headers are quiteJ >> variable and new fields are added and not always consistently used. AndE >> one really needs to keep that header "intact" because it is like a G >> postmark on a letter. So even if you were to parse the RFC822 header I >> into some fancy XML structure, you'd still need to retain the original K >> RFC822 header because your XML parser wouldn't be able to understand new   >> fields being added to RFC822. >  > Wanna bet?    F    I have to assume that there is a lack of familiarity with XML here.  I    Looking past the hype (not an easy task :-), XML is very powerful and  B very portable, and it gets the application out of the business of H parsing the data.  (There are trade-offs here too, as the XML libraries ? have substantial overhead.  It doesn't scale as well as a more   traditional database.)  @    In OpenVMS terms, XML is a portable text-based itemlist-like F construct -- and one that can be nested, provided with attributes and B tags, structurally verified, displayed, embedded, transfered, and I extended as required.  I'm using XML within OpenVMS V8.3, and for all of   these reasons.  I    I would also propose storing the data in a database, and allowing the  H external software to access the data via XML; to allow data imports and H exports using XML.  This gets the other software out of the business of I processing RFC-compliant headers.  (And, going full circle, if SMTP mail  D were to be (re)implemented today, it is exceedingly likely that XML 3 would have been used as the basis of the wrappers.)    ------------------------------  * Date: Thu, 8 Jun 2006 14:30:21 +0000 (UTC) From: david20@alpha2.mdx.ac.uk1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <e69c9t$gff$1@news.mdx.ac.uk>   ` In article <z9Vhg.1657$vY2.103@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes:  >david20@alpha2.mdx.ac.uk wrote: > N >> Relational databases are very good for structure which naturally can be putQ >> into a tabular format. They aren't particularly good for handling objects like Q >> mail messages which are of an arbitrary size and arbitrarily complex structure L >> (eg messages containing nested multipart/mixed, multipart/alternative etcK >> parts containing images, video, audio, text and other document formats). R >> Many of which will certainly be base-64 or uuencoded and others of which may beP >> stored in an encrypted format. Also the exact format of the message body may K >> need to be maintained in order to not invalidate signing of the message. E >> The exact order of message body parts also needs to be maintained. R >> This means that the message body would need to be stored as an opaque object inO >> the database (or as with exchange stored as a flat file on disk with just a  / >> pointer to the file stored in the database).  > D >   I maintain the OpenVMS source code control system.  Storing and " >retrieving MAIL messages is easy. >   N In recent years pure relational databases such as Oracle have changed to allowN the storage and retrieval of opaque data such as images so yes you could storeL and retrieve opaque mail message objects but I don't see what advantage that
 gives you.  = In a previous message you also mentioned XML with the comment    " H    I would also propose storing the data in a database, and allowing theG external software to access the data via XML; to allow data imports and G exports using XML.  This gets the other software out of the business of H processing RFC-compliant headers.  (And, going full circle, if SMTP mailC were to be (re)implemented today, it is exceedingly likely that XML 3 would have been used as the basis of the wrappers.)  "   N SMTP mail and all the software out there which processes RFC-compliant headers8 is not going to be reimplemented using XML anytime soon.N If you store mail messages you must be able to present them with all their RFC2 headers, Mime structure, PGP signatures etc intactJ This isn't a static environment new headers are being created constantly -D sometimes pretty much standardised such as the new header lines for N "anti-forging" techniques such as DomainKeys and SPF - sometimes just locally J introduced headers (which should be X-???? header lines but often aren't).  J Oracle's XML appears to support two types of storage CLOB (which maintainsJ document fidelity and appears just to be an opaque object) and O-R storageK which maintains document object model fidelity by decomposing the XML into   the underlying O-R structures.G I would maintain that to store mail messages you would need to use CLOB  storage.      P Converting SMTP mail to other formats (as for instance Exchange does) is one of J the main ways of producing software which has problems interoperating withM other SMTP compliant systems. I think that breaking up mail messages using an L XML schema to store them in O-R structures and then reconstructing them for F output to SMTP based tools or for forwarding would be prone to errors.      
 David Webb Security team leader CCSS Middlesex University     >  >  >    ------------------------------  % Date: Thu, 08 Jun 2006 18:37:32 +0400 N From: "Ruslan R. Laishev" <zzLaishev@zzDeltaTelecom.RU-remove.all-zz-to-reply>1 Subject: Re: Wanted:MAIL.MAI structure definition ? Message-ID: <75E8A9692FB23CBF6C2B8BFDA8FD890F@NNTP.DeltaTel.RU>    Hoff Hoffman wrote:   ! > david20@alpha2.mdx.ac.uk wrote:  > H >> Relational databases are very good for structure which naturally can 	 >> be put E >> into a tabular format. They aren't particularly good for handling   >> objects like H >> mail messages which are of an arbitrary size and arbitrarily complex  >> structureL >> (eg messages containing nested multipart/mixed, multipart/alternative etcK >> parts containing images, video, audio, text and other document formats). F >> Many of which will certainly be base-64 or uuencoded and others of  >> which may be G >> stored in an encrypted format. Also the exact format of the message  H >> body may need to be maintained in order to not invalidate signing of  >> the message. E >> The exact order of message body parts also needs to be maintained. I >> This means that the message body would need to be stored as an opaque   >> object inH >> the database (or as with exchange stored as a flat file on disk with 6 >> just a pointer to the file stored in the database). >  > D >   I maintain the OpenVMS source code control system.  Storing and # > retrieving MAIL messages is easy. 6 	Cool! But ! OracleRDB is not free-of-charge software.       --  F + WBR, OpenVMS [Sys|Net] HardWorker ............. Skype: SysMan-One  +9 Delta Telecom JSC, IMT-MC-450(CDMA2000) cellular operator E Russia,191119,St.Petersburg,Transportny per. 3 Cel: +7 (812) 716-3222 F +http://starlet.deltatelecom.ru ............. Frying on OpenVMS only +   ------------------------------  % Date: Thu, 08 Jun 2006 18:59:57 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> 1 Subject: Re: Wanted:MAIL.MAI structure definition ; Message-ID: <40310$4488578e$50db5015$20883@news.hispeed.ch>    Ruslan R. Laishev wrote:   > ; >     Cool! But ! OracleRDB is not free-of-charge software.  >   I It is indeed a shame that since the sell-off to Oracle, the Rdb run time  % license no longer comes with VMS. :-(    ------------------------------  $ Date: Thu, 8 Jun 2006 10:36:41 -0400  From: "DBT" <dbturner@icusc.com>L Subject: Re: What wide SCSI constrollers will be recognized by SRM of PWS6000 Message-ID: <128gdhfd415ng8f@news.supernews.com>   Why can't you order a DEC part?    FYI    KZPBA-CA UW SCSI PCI $60 each D This is the QLA1041 Qlogic "standard" controller for the PWS Systems   DT   --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   ; "vesko" <member816@nomx.sysadminforum.com> wrote in message 8 news:139$1425012$5153388$1149420636@sysadminforum.com... > E > I have a PWS600a (Miata MX5 with SRM 7.2-1) and now I use it with a G > 50pin NCR 53C810 (ASUS PCI-SC200). But I want to use 68pin HDDs and I J > need a wide SCSI controller. Which controllers will be recognized by theH > SRM (and of course OpenVMS)? Maybe KZPAC/KZPSC (Mylex DAC960) , QlogicI > 1020/1040? I need to find something generic (not DEC/Compaq/HP branded) G > from some old x86 server, because I'm from Bulgaria and can not order  > any DEC part. < > What controllers do you use on your Personal Workstations? >  > Vesselin Kenashkov >  > --   >    ------------------------------   End of INFO-VAX 2006.317 ************************