1 INFO-VAX	Wed, 07 Jun 2006	Volume 2006 : Issue 315       Contents:% MOSAIC: little bug (invalid requests) & Re: Problem with "New mail" broadcasts& Re: Problem with "New mail" broadcasts& RE: Problem with "New mail" broadcasts& RE: Problem with "New mail" broadcasts& Re: Problem with "New mail" broadcasts& Re: Problem with "New mail" broadcasts Re: SimH 3.6-03 Re: SimH 3.6-0 (problems compiling VAX using MinGW) 3 Re: SimH 3.6-0 (problems compiling VAX using MinGW)  Re: Unix runs faster, maybe D RE: Unix runs faster, maybe (was: Re: Educating potential VMS users)D RE: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)( 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 definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition  F ----------------------------------------------------------------------  % Date: Wed, 07 Jun 2006 05:46:14 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: MOSAIC: little bug (invalid requests), Message-ID: <4486A02A.8BCF7086@teksavvy.com>  C This has been happing on and off (irregular and not reproducible at G will, but happens enough that you remember it). This was happening both  with 3.8 and now with 4.0   H Essentially, double clicking the middle button will open a link in a newC window. But sometimes, the request sent to the server is invalid. A  reload then works.  
 For instance, f > http://webinfo.parl.gc.ca/MembersOfParliament/MainMPsCompleteList.aspx?TimePeriod=Current&Language=E  G gives a list of elected MPs and when you double middle click on an MP's C name, you get his profile/contact info in a new window. In order to F reproduce the problem, I have to open perhaps 5 or 6 windows before itE happens. And I have seen this happen on many different web sites over D the years. Don't know why it happens and have no information on what, triggers the problem. It truly seems random.    ' With a FAILED request TCPTRACE reveals:   G   0B00000A   B874063C   00409CAC   68000045    0000    E..h..@.<.t..... H    5BD6EB05   019A3B6C   500081C8 | 6B52C5C0    0010    ..Rk...Pl;.....[H    6D654D2F   20544547 | 00008766   00F01850    0020    P...f...GET /MemH    746E656D   61696C72   6150664F   73726562    0030    bersOfParliamentH    3F787073   612E504D   656C6966   6F72502F    0040    /ProfileMP.aspx?H    6175676E   614C2639   31343837   3D79654B    0050    Key=78419&Langua@                          0A0D0A0D   453D6567    0060    ge=E....    D Note that the request has just one line followed by a blank line andF does not contain a Host: line which is pretty well required these days; for the web server to know what web site it needs to serve.     C In the new window, the following is displayed apparently by MOSAIC: 5 -----------------------------------------------------  ERROR    Requested document (URL R http://webinfo.parl.gc.ca/MembersOfParliament/ProfileMP.aspx?Key=78419&Language=E) could not be accessed.  G The information server either is not accessible or is refusing to serve  the document to you. 5 -----------------------------------------------------     F The URL in the URL: field of the new window seems correct. a RELOAD of? the page works and this is what the outbound packet looks like: / (obviously, the request is much more complete).   G   0B00000A   4071063C   0040AFAC   CD030045    0000    E.....@.<.q@.... H    367C31E7   0168036D   500083C8 | 6B52C5C0    0010    ..Rk...Pm.h..1|6H    6D654D2F   20544547 | 0000EBD1   00F01850    0020    P.......GET /MemH    746E656D   61696C72   6150664F   73726562    0030    bersOfParliamentH    3F787073   612E504D   656C6966   6F72502F    0040    /ProfileMP.aspx?H    6175676E   614C2639   31343837   3D79654B    0050    Key=78419&LanguaH    410A0D30   2E312F50   54544820   453D6567    0060    ge=E HTTP/1.0..AH    69746163   696C7070   61203A74   70656363    0070    ccept: applicatiH    74616369   6C707061   202C6C6D   782F6E6F    0080    on/xml, applicatH    61202C6C   6D782B6C   6D746878   2F6E6F69    0090    ion/xhtml+xml, aH    6D74682D   782F6E6F   69746163   696C7070    00A0    pplication/x-htmH    682F6E6F   69746163   696C7070   61202C6C    00B0    l, application/hH    74202C6C   6D782F74   78657420   2C6C6D74    00C0    tml, text/xml, tH    74786574   202C6C6D   74682D78   2F747865    00D0    ext/x-html, textH    6D74682F   74786574   202C6E69   616C702F    00E0    /plain, text/htmG    202C6369   7361622F   6F696475   61202C6C    00F0    l, audio/basic, H    6D69202C   66666961   2D782F6F   69647561    0100    audio/x-aiff, imH    782F6567   616D6920   2C706D62   2F656761    0110    age/bmp, image/xH    736D2D78   2F656761   6D69202C   706D622D    0120    -bmp, image/x-msH    0D666967   2F656761   6D69202C   706D622D    0130    -bmp, image/gif.H    6A2F6567   616D6920   3A747065   6363410A    0140    .Accept: image/jH    6765706A   702F6567   616D6920   2C676570    0150    peg, image/pjpegH    616D6920   2C676E70   2F656761   6D69202C    0160    , image/png, imaH    2F656761   6D69202C   676E702D   782F6567    0170    ge/x-png, image/H    6F702D78   2F656761   6D69202C   66666974    0180    tiff, image/x-poH    69202C70   616D796E   612D656C   62617472    0190    rtable-anymap, iH    2D656C62   6174726F   702D782F   6567616D    01A0    mage/x-portable-H    2D782F65   67616D69   202C7061   6D746962    01B0    bitmap, image/x-H    70616D79   6172672D   656C6261   74726F70    01C0    portable-graymapH    62617472   6F702D78   2F656761   6D69202C    01D0    , image/x-portabH    6567616D   69202C70   616D7869   702D656C    01E0    le-pixmap, imageH    67722F65   67616D69   202C6267   722D782F    01F0    /x-rgb, image/rgH    0A0D6D62   782D782F   6567616D   69202C62    0200    b, image/x-xbm..H    2D782F65   67616D69   203A7470   65636341    0210    Accept: image/x-H    782F6567   616D6920   2C70616D   74696278    0220    xbitmap, image/xH    2F656761   6D69202C   70616D78   6970782D    0230    -xpixmap, image/H    6477782D   782F6567   616D6920   2C647778    0240    xwd, image/x-xwdH    6F646E69   77782D78   2F656761   6D69202C    0250    , image/x-xwindoH    65706D2F   6F656469   76202C70   6D756477    0260    wdump, video/mpeH    69746B63   6975712F   6F656469   76202C67    0270    g, video/quicktiH    2F6E6F69   74616369   6C707061   202C656D    0280    me, application/H    6C707061   202C7470   69726373   74736F70    0290    postscript, applH    70706120   2C666470   2F6E6F69   74616369    02A0    ication/pdf, appG    202C6976   642D782F   6E6F6974   6163696C    02B0    lication/x-dvi, G    202C3232   38636672   2F656761   7373656D    02C0    message/rfc822, H    3A6E6F69   7463656E   6E6F430A   0D2A2F2A    02D0    */*..Connection:H    6573550A   0D657669   6C412D70   65654B20    02E0     Keep-Alive..UseH    736F4D5F   534D5620   3A746E65   67412D72    02F0    r-Agent: VMS_MosH    4F3B6669   746F4D28   20302E34   2F636961    0300    aic/4.0 (Motif;OG    20584156   20322E37   5620534D   566E6570    0310    penVMS V7.2 VAX H    7762696C   20202941   3030362D   30303034    0320    4000-600A)  libwH    0A0D6369   61736F4D   5F32312E   322F7777    0330    ww/2.12_Mosaic..H    61702E6F   666E6962   6577203A   74736F48    0340    Host: webinfo.paH    736E6574   78450A0D   61632E63   672E6C72    0350    rl.gc.ca..ExtensH    616D6F44   2D796669   746F4E20   3A6E6F69    0360    ion: Notify-DomaH    0A0D6E6F   69746369   72747365   522D6E69    0370    in-Restriction..H    6F697372   65562420   3A326569   6B6F6F43    0380    Cookie2: $VersioH    41203A65   696B6F6F   430A0D22   31223D6E    0390    n="1"..Cookie: AH    64496E6F   69737365   535F5445   4E2E5053    03A0    SP.NET_SessionIdH    34636434   75326635   347A6377   626C343D    03B0    =4lbwcz45f2u4dc4E          0A   0D0A0D64   61686834   67707335    03C0    5spg4hhad....    ------------------------------   Date: 7 Jun 2006 03:07:36 -0700  From: etmsreec@yahoo.co.uk/ Subject: Re: Problem with "New mail" broadcasts C Message-ID: <1149674856.285432.305130@g10g2000cwb.googlegroups.com>   @ You could always do the obvious command to reject such messages:   $ SET TERMINAL/NOBROADCAST  C You could, additionally, use a chunk of code to interrogate the new G mail count every once in a while and get it to send out its own message 3 in another window when the message count changes...    Steve    JF Mezei wrote: I > There are many emails messages which are now written in chinese and the H > sender/subjects contain many unprintable characters., including escape. > sequences which freeze a terminal (decterm). > D > MAIL's interactive interface long ago implemented filtering of theA > sender and subject data to exclude escape sequences, preventing = > malicious senders from messing with recipients's terminals.  > I > However, this was not implemented at a lower level during mail delivery * > which generates broadcasts to terminals. >  > J > So I would  suggest that VMS engineering modify the broadcasting systemsH > (reply/terminal and whatever system servuices are used by MAIL to sendF > broadcasts to terminals) to filter out unprintable characters and/or > escape sequences/chartacters.  > H > (I suspect that changing MAIL/TCPIP would require some arm twisting byI > major customers to convince HP to allow some of the applications on VMS  > to be updated).    ------------------------------   Date: 7 Jun 2006 06:19:05 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) / Subject: Re: Problem with "New mail" broadcasts 3 Message-ID: <XvM57ObWFCm8@eisner.encompasserve.org>   ` In article <1149674856.285432.305130@g10g2000cwb.googlegroups.com>, etmsreec@yahoo.co.uk writes:B > You could always do the obvious command to reject such messages: >  > $ SET TERMINAL/NOBROADCAST   Or, for a smaller hammer, try:   	SET BROADCAST=NOMAIL    ------------------------------  $ Date: Wed, 7 Jun 2006 07:41:15 -04001 From: "Farrell, Michael" <MFarrell@Voltdelta.com> / Subject: RE: Problem with "New mail" broadcasts L Message-ID: <085BCCCF596B684092B66310B1D3BA7D02A61A25@NJ103EX1.EAST.VIS.COM>  E " You could, additionally, use a chunk of code to interrogate the new % mail count every once in a while ..."    How does one do that?    TIA    Mike Farrell   -----Original Message-----; From: etmsreec@yahoo.co.uk [mailto:etmsreec@yahoo.co.uk]=20 & Sent: Wednesday, June 07, 2006 6:08 AM To: Info-VAX@Mvb.Saic.Com / Subject: Re: Problem with "New mail" broadcasts   @ You could always do the obvious command to reject such messages:   $ SET TERMINAL/NOBROADCAST  C You could, additionally, use a chunk of code to interrogate the new G mail count every once in a while and get it to send out its own message 3 in another window when the message count changes...    Steve    JF Mezei wrote: E > There are many emails messages which are now written in chinese and  the H > sender/subjects contain many unprintable characters., including escape. > sequences which freeze a terminal (decterm). > D > MAIL's interactive interface long ago implemented filtering of theA > sender and subject data to exclude escape sequences, preventing = > malicious senders from messing with recipients's terminals.  > @ > However, this was not implemented at a lower level during mail delivery* > which generates broadcasts to terminals. >  > B > So I would  suggest that VMS engineering modify the broadcasting systems H > (reply/terminal and whatever system servuices are used by MAIL to sendF > broadcasts to terminals) to filter out unprintable characters and/or > escape sequences/chartacters.  > H > (I suspect that changing MAIL/TCPIP would require some arm twisting byE > major customers to convince HP to allow some of the applications on  VMS  > to be updated).    ------------------------------   Date: 7 Jun 2006 09:49:32 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) / Subject: RE: Problem with "New mail" broadcasts 3 Message-ID: <dwRM0LE4Oj3O@eisner.encompasserve.org>    In article <085BCCCF596B684092B66310B1D3BA7D02A61A25@NJ103EX1.EAST.VIS.COM>, "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?   ? The source listings kit shows that Login uses a private routine A MAIL$GET_NEW_COUNT.  The conditions are sufficiently complex that A you should probably have a source kit to attempt to duplicate it.   D If you don't need your solution to work on VAX, it might be possibleG to call SYS$ACM and parse the output, but that seems even more tenuous.    ------------------------------  # Date: Wed, 07 Jun 2006 15:44:49 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>/ Subject: Re: Problem with "New mail" broadcasts 1 Message-ID: <RvChg.1607$ys2.812@news.cpqcorp.net>   4    A formal report of this was logged earlier today.   ------------------------------  # Date: Wed, 07 Jun 2006 15:53:04 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>/ Subject: Re: Problem with "New mail" broadcasts 1 Message-ID: <ADChg.1609$Ot2.676@news.cpqcorp.net>    Farrell, Michael wrote: 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?   C    Through the MAILCOUNT tool or some such, on a Freeware circa V4.   5    Or using the callable MAIL API from your own code.   H    The MAIL API is documented in the utility routines reference manual, & part of the OpenVMS documentation set.   ------------------------------   Date: 7 Jun 2006 02:49:44 -0700 # From: "Galen" <gltackett@gmail.com>  Subject: Re: SimH 3.6-0 C Message-ID: <1149673784.597018.327570@h76g2000cwa.googlegroups.com>    David B Sneddon wrote: > 3 > I have just downloaded and successfully built the 3 > latest version.  I can access the system via LAT, 1 > DECnet and TCPIP, and can get out via the three  > protocols as well. >  > Dave   Dave,   A I'll have to try simh v3.6 on OS X 10.3.9 since I could never get C networking to work with simh v3.5-anything on this OS X version. (I  have libpcap 0.9.4.)  F I'm somewhat familiar with the ethernet device code in simh and even aG little bit with the bits of libpcap it uses. My present problem appears E to be that OS X won't let libpcap use an en device unless OS X has IP E up and running on that device. Even if that's the case, libpcap never C sees any incoming Ethernet traffic for the emulated en device's MAC C address. For that matter, neither does ethereal running on the OS X  side.   @ (By the way, I'm currently using two network cards on the Mac: aG "dedicated" (sort of) ethernet card for simh, and the built-in ethernet 5 for OS X, both connected to the same network switch.)   B Perhaps we can discuss this via e-mail since it's getting a bit OT here.   C Could you e-mail me at gltm@ilb0x-misc at y@h00 d0t c0m (making the ' obvious substitutions @=>a and 0 => o.)    Thanks,    Galen    ------------------------------   Date: 7 Jun 2006 07:50:58 -0700 $ From: "Wilm" <w5.boerhout@planet.nl>< Subject: Re: SimH 3.6-0 (problems compiling VAX using MinGW)C Message-ID: <1149691857.976064.222730@i39g2000cwa.googlegroups.com>   G I have a problem compiling VAX and VAX780 under Windows, using the SIMH   supplied build_mingw.bat script.  F The VAXen will not build *unless* I copy vax_defs.h, vaxmod_defs.h andD vax780_defs.h from the VAX folder into the PDP11 folder. If not, theD first PDP11 module to be compiled with either VAX fails with a "file not found" error on vax_defs.h.   - The gcc command generated by mingw32-make is:   C gcc -std=c99 -U__STRICT_ANSI__ -O0 -I. VAX/vax_cpu.c VAX/vax_cpu1.c 7 VAX/vax_fpa.c VAX/vax_io.c VAX/vax_cis.c VAX/vax_octa.c ? VAX/vax_cmode.c VAX/vax_mmu.c VAX/vax_stddev.c VAX/vax_sysdev.c A VAX/vax_sys.c  VAX/vax_syscm.c VAX/vax_syslist.c PDP11/pdp11_rl.c B PDP11/pdp11_rq.cPDP11/pdp11_ts.c PDP11/pdp11_dz.c PDP11/pdp11_lp.cC PDP11/pdp11_tq.c PDP11/pdp11_xq.c PDP11/pdp11_ry.c PDP11/pdp11_vh.c E PDP11/pdp11_cr.c scp.c sim_console.c sim_fio.c sim_timer.c sim_sock.c F 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  G (note the -I switches to specify the #include directories, they seem to  be correct)    What am I missing?   /Wilm    ------------------------------   Date: 7 Jun 2006 08:20:51 -0700 ; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> < Subject: Re: SimH 3.6-0 (problems compiling VAX using MinGW)C Message-ID: <1149693651.357144.324900@c74g2000cwc.googlegroups.com>    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.  > / > 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   D For your best response you may want to join the SimH mailing list atG http://mailman.trailing-edge.com/mailman/listinfo/simh   Although a lot C of people are common to both lists, it is maybe a bit more on topic  there.   ------------------------------  % Date: Wed, 07 Jun 2006 01:41:03 -0400 ' From: Dave Froble <davef@tsoft-inc.com> $ Subject: Re: Unix runs faster, maybe9 Message-ID: <h92dnW79m_FK-BvZnZ2dnUVZ_rWdnZ2d@libcom.com>    Villy Madsen wrote:  > OK - more importantly  > ) > How many identified vulnerabilities ???  > 8 > many vulnerabilities - few patches  ==> a BAAAAD thing > 8 > many vulnerabilities - man patches =====> lots of work >  > B > few vulnerabilities & few patches ====> I can sleep at night.... >  > L > It's interesting, one of the few VAX "vulnerabilities" that I can remember > was a SNMP problem.  > < > On *ix the problem resulted in people taking over systems. > J > on VMS the SNMP server crashed (and was automatically restarted by VMS). > L > Similar issues with OS/400 (or whatever it's called these days) - not muchF > in the way of vulnerabilities - and therefore not much in the way of
 > patches. > K > It also seems to me that a significant # of the problems that did develop  > were as a resultE > of things that were ported from *ix. (TCPIP on VMS), Apache on both  > platforms. > G > Having said that - I do believe that part of the problem has been the J > historically high cost of ownership of both of these quite excellent (inJ > their own way) platforms- and I speak from the view point of someone whoM > spent over 20 years supporting VMS and supported OS/400 from just about its   > birth until about 3 years ago. > M > Lifetime cost of ownership may be a lot lower  than people realize (because M > OS maintenance (your people costs) are so much lower for the aforementioned M > platforms, but that doesn't seem to be as important as the one time hit.. - J > and the arguably high cost of the year to year manufacturer maintenance.  B There is always a minimum of two (2) sides to any issue, consider:  G 1) Employees like an environment that provides job security.  The more  F needed, the more security.  (So, just what type of 'security' were we  discussing?)  E 2) Managers might rate their importance by how many people they have   working for them.    --  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: Wed, 7 Jun 2006 06:45:56 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> M Subject: RE: Unix runs faster, maybe (was: Re: Educating potential VMS users) T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840155D969@tayexc19.americas.cpqcorp.net>   > -----Original Message-----4 > From: Bill Todd [mailto:billtodd@metrocast.net]=20 > Sent: June 7, 2006 12:14 AM  > To: Info-VAX@Mvb.Saic.Com = > Subject: Re: Unix runs faster, maybe (was: Re: Educating=20  > potential VMS users) >=20 > Main, Kerry wrote: > >> -----Original Message----- 7 > >> From: Bill Todd [mailto:billtodd@metrocast.net]=20  > >> Sent: June 6, 2006 1:36 AM  > >> To: Info-VAX@Mvb.Saic.Com@ > >> Subject: Re: Unix runs faster, maybe (was: Re: Educating=20 > >> potential VMS users)  > >> > > [snip..] > >=20? > >>> The environments I am talking about in the majority of=20  > Windows/UNIX@ > >>> servers today are not CPU lite, but disk IO heavy. They=20 > are just not9 > >>> utilized that much at all in peak periods - period. E > >> That's what I just suggested, Kerry:  they're limited by disk=20  > >> I/O, not=20A > >> CPU, and hence CPU utilization *will* be low, even if the=20  > disks are=20$ > >> working their little tails off. > >> > >=20. > > Apologies, I did not make myself clear.=20 >=20C > No:  you either misspoke, or are now covering up an attempt to=20  > back-pedal - see below.  >=20 > >=20> > > While there is typically a very small number of servers=20 > that are fairly E > > heavy utilized, the majority of Wintel and UNIX servers today are # > > neither CPU *or* disk IO heavy.  >=20H > That is *not* what you said above:  you said "The environments I am=20@ > talking about in the majority of Windows/UNIX servers today=20 > are not CPU=20A > lite, but disk IO heavy" (*not* "neither CPU *or* [sic] disk=20  > IO heavy",=20 A > as you would now like us to think), and that's the statement=20  > to which I=20  > responded  >=20  H Like my updated note stated, I did not make myself clear in the original note.=20   > ...  >=20 >=20C > >> And any file system optimizations that will reduce the load=20  > >> on the disks=20A > >> (as Unix's do far better by default than VMS does) *will*=20  > be useful. > >> > >=20A > > Most admins on any platform I know would tune their OS's /=20  > file systems? > > etc before releasing to production. The same is true for=20  > OpenVMS. Very A > > few ever release the default config into production, so at=20  > best, this is  > > a theoretical viewpoint. >=20A > I notice that you're continuing to skate around the question=20  > of exactly=20 B > how much experience you have with the administration of other=20 > OSs (Unix=20@ > in particular being central to the current context).  Until=20 > such time as=20 ; > you're ready to claim significant experience with Unix=20  > administration,=20B > let's leave this open for more qualified people to comment upon. >=20  E Skate nothing. While I will certainly not claim to be a UNIX admin, I H have been around DC's enough to understand the provisioning process doesG not simply involve install OS, add applications, test and move to prod.   @ Hey - there are lots of other folks here who have UNIX sys adminF experience - how many would move their newly installed UNIX OS to prod0 with zero tuning to the application in question?   > ...  >=20A > >>> And btw, a server with low cpu utilization, but heavy IO=20 
 > makes for a ( > >>> poor candidate for virtualization.E > >> But since you seem to insist on this digression:  horseshit. =20  > >> A server=20? > >> with very low CPU utilization is a *good* candidate for=20  > >> virtualization,=20 H > >> since it's got lots of horsepower left over for other tasks that=20< > >> (especially in Windows environments) admins might be=20 > >> reluctant to run on=20 > > >> the same OS instance:  just hook up some more disks to=20 > >> service the added=20 $ > >> application(s) and let 'er rip. > >> > >=20= > > While it can be done, keep in mind the impact on total=20  > bandwidth (need B > > to balance), CPU cache thrashing and virtual drivers overhead. >=20B > Waving your hands vigorously won't cut it, Kerry - you really=20
 > ought to=20  > have learned that by now.  >=20 >   A heavy ? > > IO application will likely depend on cpu caching, but if=20  > the other OS@ > > instances are constantly invalidating the CPU cache, then=20
 > most of the / > > heavy IO's will go directly to memory/disk.  >=20J > Let's not confuse CPU cache with file-system cache, shall we?  If the=20> > 'heavy I/O application' is not managing to tax the CPU(s)=20 > much, then it=20J > pretty much by definition is *not* depending much on CPU caching, nor=20A > with DMA mechanisms (which have been common for decades now)=20  > is most of=20 F > the data necessarily even *passing through* the CPU caches on its=20 > journey from input to output.  >=20B > And of course other OS instances 'constantly invalidating the=20 > CPU cache'=20 G > will *never* affect disk accesses, only (at worst) send occasional=20 D > references to RAM which might have otherwise hit in the CPU cache. >=20: > Your horseshit is rapidly turning into bullshit, I fear. >=20  B Bill - this looks like an area that you need to do some additional research on.=20   G Virtualization of a system (OS stacking, sub CPU virtualization) is all G about trade-off's in terms of reducing the overall HW, improving server ? utilization and balancing the stacking of *low* resource demand 7 applications against the demands of the overall system.   D As I know you know, all IO based applications have some level of CPUD loads and as you start to mix additional CPU loads that also have IO= loads (not many applications do CPU only with no IO), it will - potentially impact that heavy IO application.   F In the real world, if you have a very IO intensive application that isB anywhere close to being important, most Cust's would leave it on aH dedicated server as they do not want to take any chances that additionalF stacked applications would in any way impact that applications overall performance.=20    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  $ Date: Wed, 7 Jun 2006 07:01:46 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> M Subject: RE: Unix runs faster, maybe (was: Re: Educating potential VMS users) T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840155D96D@tayexc19.americas.cpqcorp.net>   > -----Original Message----- > From: Main, Kerry=20 > Sent: June 7, 2006 6:46 AM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Unix runs faster, maybe (was: Re: Educating=20  > potential VMS users) >=20 >=20	 [Snip ..]   7 > In the real world, if you have a very IO intensive=20 @ > application that is anywhere close to being important, most=20? > Cust's would leave it on a dedicated server as they do not=20 B > want to take any chances that additional stacked applications=20C > would in any way impact that applications overall performance.=20  >=20  F That should state "In the real Windows world.." and other environmentsE that do OS stacking with virtual OS's beneath them. Windows and Linux B environments typically do OS stacking which is much different than Application stacking.   B OpenVMS and some other enterprise OS's do Application stacking (asH opposed to OS stacking, sub cpu partitioning) with mixed IO/CPU loads asB their overall design and architecture has been designed to be more6 supportive of a multi-application stacked environment.   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------   Date: 7 Jun 2006 08:51:07 -0700 - From: "Doug Phillips" <dphill46@netscape.net> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) C Message-ID: <1149695467.161157.322900@j55g2000cwa.googlegroups.com>    Main, Kerry wrote:  I > Virtualization of a system (OS stacking, sub CPU virtualization) is all I > about trade-off's in terms of reducing the overall HW, improving server A > utilization and balancing the stacking of *low* resource demand 9 > applications against the demands of the overall system.  >   D Are you talking about microkernals? Or, hardware abstraction layers?E Or what? I can't find anything in the VMS doc's that is called simply D "virtualization". Galaxy could be considered framework for a type ofD virtualization, as could clustering and grid computing, but normally$ they aren't called "virtualization".  E You may be so familiar with what you are talking about that you don't E give the word a second thought. If you're talking about "OS stacking, D sub CPU virtualization" you are again talking about a concept ratherE than a method. "Virtualization" can be achieved in more than one way. F Your and Bill's discussion about resource demands is pointless if each/ of you is talking about a different technology.   E Maybe you could point me to a specific document that explains exactly D what _you_ mean by "virtualization", because I'd really like to know more.     Thanks    ------------------------------  % Date: Wed, 07 Jun 2006 13:15:13 +0400 N From: "Ruslan R. Laishev" <zzLaishev@zzDeltaTelecom.RU-remove.all-zz-to-reply>1 Subject: Re: Wanted:MAIL.MAI structure definition ? Message-ID: <FF8F896053475C00A7B46E24C343A6AF@NNTP.DeltaTel.RU>    Hello, Hoff!   Hoff Hoffman wrote:    > Ruslan R. Laishev wrote: > A >>     Under high load and concurrent access with POP3 and other  I >> application to VMS mailbox we have frequent problems when MAIL.MAI is  A >> empty but user home contains MAIL$****.MAI files. I'd like to  J >> embending an additional functionality to POP3 server to checking losen 2 >> MAIL$*.MAI files and deleting it. Just for FUY. >  > K >   Sounds like there's a bug somewhere, and I'm not sure I'd want to have  2 > a POP3 tool deleting files from underneath MAIL.Q 	Agreed. But, we have ~40 k VMS mailboxes on our VMS cluster, these users is our  N mobile subscribers, they don't have an access to VMS directly to performs any  repair actions.    >  (I'd be as interested  J > in why there's an error like this lurking, and what software here is at 	 > fault.) N 	I'm too. Can you please provide me some contact to VMS Mail Men to discuss a  situation ?    > J >   The code necessary to verify the component MAIL files is available on - > the Freeware.  It's known as VFYMAIL, IIRC.      	Thanks.     --  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: Wed, 07 Jun 2006 13:15:43 +0400 N From: "Ruslan R. Laishev" <zzLaishev@zzDeltaTelecom.RU-remove.all-zz-to-reply>1 Subject: Re: Wanted:MAIL.MAI structure definition ? Message-ID: <EA2AE58D046CF8B6F99FE3273AAB84A6@NNTP.DeltaTel.RU>    Tom Linden wrote:   3 > On Tue, 06 Jun 2006 11:25:46 -0700, Hoff Hoffman  # > <hoff-remove-this@hp.com>  wrote:  >  >> Ruslan R. Laishev wrote:  >>C >>>     Under high load and concurrent access with POP3 and other   G >>> application to VMS mailbox we have frequent problems when MAIL.MAI  F >>> is  empty but user home contains MAIL$****.MAI files. I'd like to F >>> embending  an additional functionality to POP3 server to checking : >>> losen MAIL$*.MAI  files and deleting it. Just for FUY. >> >>I >>    Sounds like there's a bug somewhere, and I'm not sure I'd want to   F >> have a POP3 tool deleting files from underneath MAIL.  (I'd be as  B >> interested in why there's an error like this lurking, and what  >> software  here is at fault.)  >>I >>    The code necessary to verify the component MAIL files is available  2 >> on  the Freeware.  It's known as VFYMAIL, IIRC. >  > K > I understand that the layout is subject to change, but why couldn't the    > definition( > be included in starlet.  Just curious. 	Yes!      >  > Tom  >    --  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: Wed, 07 Jun 2006 05:51:25 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition , Message-ID: <4486A161.D6971A8D@teksavvy.com>   "Ruslan R. Laishev" wrote:Y >         Agreed. But, we have ~40 k VMS mailboxes on our VMS cluster, these users is our O > mobile subscribers, they don't have an access to VMS directly to performs any  > repair actions.     @ Do you know for a fact that the stray message files that have noE pointers in MAIL.MAI are valid messages, or are they deleted messages H where the pointer was removed from mail.mai but the delete of the actual
 file failed ?   B (consider a case where the file is locked for some reason, the POPG server can delete the record in mail.mai but woudln't be able to delete  the actual contents file.)      G This is where there is a big difference between ALLIN1 and MAIL. ALLIN1 F comes with procedures to repair a user,s mailbox, reset its user countG etc etc. There is also a file cabinet verification that looks for stray  files as well as missing files.    ------------------------------   Date: 7 Jun 2006 06:13:52 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) 1 Subject: Re: Wanted:MAIL.MAI structure definition 3 Message-ID: <qk2ZoYeotD8C@eisner.encompasserve.org>    In article <EA2AE58D046CF8B6F99FE3273AAB84A6@NNTP.DeltaTel.RU>, "Ruslan R. Laishev" <zzLaishev@zzDeltaTelecom.RU-remove.all-zz-to-reply> writes: >  > Tom Linden wrote:   L >> I understand that the layout is subject to change, but why couldn't the  
 >> definition ) >> be included in starlet.  Just curious.  > 	Yes!   D NO !!!   Starlet is the definitions that remain valid for subsequent versions of VMS.   ------------------------------   Date: 7 Jun 2006 07:14:50 -0500  From: briggs@encompasserve.org1 Subject: Re: Wanted:MAIL.MAI structure definition 3 Message-ID: <$EQADg8MD+Tq@eisner.encompasserve.org>   M In article <Uzphg.9661$3i3.8801@trnddc08>, John Santos <john@egh.com> writes:  > JF Mezei wrote:  >> Hoff Hoffman wrote: >>  H >>>instance, we'd be using XML and/or a relational database, and some of, >>>these pieces would be (far) more visible. >>   >>   >>  1 >> Why XML ? Why not use simple RFC822 concepts ?  >>   > E > If I am not mistaken, RFC822 relates to mail transport, not to mail 
 > storage.   RFC822 is message format.  RFC821 is mail transport.   ? I'm no expert, but I'd expect a well specified XML format to be 8 easier to create and to parse than standard RFC822+MIME.  A On the other hand, translating between XML and RFC822+MIME in the A SMTP gateway component could be unneccessary if the message store E were natively RFC822+MIME.  And the POP3 component would be similarly  simplified.    ------------------------------  % Date: Wed, 07 Jun 2006 05:43:20 -0700 # From: "Tom Linden" <tom@kednos.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <op.tar0aihnzgicya@hyrrokkin>   / On Tue, 06 Jun 2006 16:39:19 -0700, JF Mezei  =   % <jfmezei.spamnot@teksavvy.com> wrote:    > Tom Linden wrote: I >> As I said, it was just curiosity.  If there is not a compelling reaso=  n  =   >> to I >> keep something proprietary, then starlet it. There, I created a new  =    >> verb. > F > Yes, but it begs the question: which came first: the library, or the$ > node ? (starlet)   :-) :-) :-) :-) >  > 8 > To starlet or not to starlet, that is the question :-)( I ahve to withdraw and agree with Larry, to Lib or not lib.   ------------------------------  % Date: Wed, 07 Jun 2006 05:49:37 -0700 # From: "Tom Linden" <tom@kednos.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <op.tar0kz06zgicya@hyrrokkin>   I On Tue, 06 Jun 2006 16:44:00 -0700, Hoff Hoffman <hoff-remove-this@hp.co=  m>  =    wrote:   > Tom Linden wrote:  > I >> As I said, it was just curiosity.  If there is not a compelling reaso=  n  =   >> to I >> keep something proprietary, then starlet it. There, I created a new  =    >> verb. > I >    I'd flip that over.  If there's not a compelling reason to share a =   =  I > particular interface -- to render the interface public, or at least to=    =   @ > allow some sort of sharing -- then keep the interface private. > I >    Opening any arbitrary interface runs contrary to the typical opacit=  y  =  D > of the internal interfaces and of application modularity and of  =  E > long-standing programming practices.  And it makes the usual and  =   I > expected application compatibility far more difficult to achieve and t=  o  =   > maintain.  > D >    If I had the cycles to re-implement MAIL all over again, for  =  I > instance, we'd be using XML and/or a relational database, and some of =   =  I > these pieces would be (far) more visible.  But opening up traditional =   =  I > internal APIs or database file organizations to visibility obviously  =   I > invites folks to use the APIs, and this is access is most definitely a=    =   H > two-edged sword.   With XML or a relational database -- or a way to  =  I > export to same -- maintaining compatibility is easier, and defending  =   G > against corruptions -- whether in the code, or in something that a  =   8 > programmer has hooked into the interface -- is easier. > I >    There have been changes to the naming of various MAIL files over th=  e  =  I > years, for instance, and there are definite limits to the current MAIL=    =   I > design.  If we open the database API, we effectively codify the curren=  t  =  F > design in concrete, and make it far harder (if not impossible) to  =  8 > re-work these interfaces and these designs compatibly. > H >    If there are particular requirements not met within the existing  =  I > interface(s), then these should be addressed through callable MAIL or =   =  I > similar extensions.  Opening up the internals of an arbitrary hunk of =   =  I > code serves no purpose, and (in my experience) tends to cause problems=    =   I > for everybody involved.  I've ported code, for instance, that expected=    =   I > modifications directly to the underlying operating system in support o=  f  =  3 > the application code -- kernel patches.  Shudder.  > I I see the merit to your arguments.  I am not convinced that XML is a ste=  p I forward.  I have looked at embedding an XML parser in PL/I as IBM has do=  neI and is used as part of their Websphere package.  Personally, I don't thi=  nkI anyone should have to write XML, if you need to use it as an interface t=  hen I let's develop tools to generated it.  If I have understood correctly, ma=  ilI is organised as an ISAM file.  Such files are eminently more efficient t=  han 
 relation DBs.    ------------------------------  * Date: Wed, 7 Jun 2006 15:20:27 +0000 (UTC) From: david20@alpha2.mdx.ac.uk1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <e66qrr$k24$1@news.mdx.ac.uk>   T In article <$EQADg8MD+Tq@eisner.encompasserve.org>, briggs@encompasserve.org writes:N >In article <Uzphg.9661$3i3.8801@trnddc08>, John Santos <john@egh.com> writes: >> JF Mezei wrote: >>> Hoff Hoffman wrote:  >>> I >>>>instance, we'd be using XML and/or a relational database, and some of - >>>>these pieces would be (far) more visible.  >>>  >>>  >>> 2 >>> Why XML ? Why not use simple RFC822 concepts ? >>>  >>  F >> If I am not mistaken, RFC822 relates to mail transport, not to mail >> storage.  >  >RFC822 is message format. >RFC821 is mail transport. > @ >I'm no expert, but I'd expect a well specified XML format to be9 >easier to create and to parse than standard RFC822+MIME.  > B >On the other hand, translating between XML and RFC822+MIME in theB >SMTP gateway component could be unneccessary if the message storeF >were natively RFC822+MIME.  And the POP3 component would be similarly >simplified.  M Any new mail store would also need to support IMAP 4 and an API which can be  J used for web access and for various mail tools (including a mail-handling  facility similar to DELIVER).   
 David Webb Security team leader CCSS Middlesex University   ------------------------------  # Date: Wed, 07 Jun 2006 15:58:33 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: Wanted:MAIL.MAI structure definition 1 Message-ID: <JIChg.1610$ku2.875@news.cpqcorp.net>    Tom Linden wrote:   K > I see the merit to your arguments.  I am not convinced that XML is a step 
 > forward.  E    For an arbitrary operation, XML is a massively large step forward  E from a locally-defined and locally-parsed data format -- it gets the  E application out of the business of processing the structures and the  H format, and into the business of dealing with the data.  Is it the most D efficient?  No.  Does it work?  Yes.  And XML is seriously flexible.  B > I have looked at embedding an XML parser in PL/I as IBM has doneL > and is used as part of their Websphere package.  Personally, I don't thinkM > anyone should have to write XML, if you need to use it as an interface then ( > let's develop tools to generated it.    I    libxml2 works quite nicely, and I've been (re)porting versions of it.  F   Versions are available at the Freeware V8 staging area -- and FWIW, L the submission deadline for Freeware V8 is rapidly approaching: 15-Jun-2006.  & > If I have understood correctly, mailM > is organised as an ISAM file.  Such files are eminently more efficient than  > relation DBs.   E    More efficient, and less flexible -- it's a trade-off.  There are  C serious limits within the current design, such as the inability to  H generally search the mail file, or to have a message in two folders, or 9 to handle the information in a transactional format, etc.    ------------------------------   End of INFO-VAX 2006.315 ************************