1 INFO-VAX	Sat, 22 Nov 2003	Volume 2003 : Issue 648       Contents: a pix to VT100 ascii converter? # Re: a pix to VT100 ascii converter? # Re: a pix to VT100 ascii converter?  Re: Backwards File Dump - Re: Building a cluster using HP's SBW program   Re: Compaq Secure Web Server 1.3 Compaq Secure Web Server 1.3  Re: Compaq Secure Web Server 1.3  Re: Compaq Secure Web Server 1.3  Re: Compaq Secure Web Server 1.3  Re: Compaq Secure Web Server 1.38 Re: DCL Enhancements: Error messages for OPEN and DEFINE8 Re: DCL Enhancements: Error messages for OPEN and DEFINE8 Re: DCL Enhancements: Error messages for OPEN and DEFINE8 Re: DCL Enhancements: Error messages for OPEN and DEFINE Re: Disk cluster size questionA Re: Efficiency Question: Large Arrays vs. Indexed Files on Alphas A Re: Efficiency Question: Large Arrays vs. Indexed Files on Alphas  IRC? Re: IRC? Re: lat for linux problem  Re: Main memory for galaxy. Re: Many CDs in the Alpha "condist" these days& Re: Only hope for Intel is alpha chip?% Re: Peoplesoft Financials and OpenVMS $ Re: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 8 Re: SYS$LIBRARY:TRACE_V74.EXE on VMS 7.3-1 causing error Re: TELNET/PORT P Re: Unable to stop FormFeed to DEC LA75, connected to a DEC 90m Server, using LP  what protections does MAIL need?* Re: [OT] Mac OS X: system folder not found  F ----------------------------------------------------------------------  % Date: Sat, 22 Nov 2003 10:58:50 +0100 " From: Didier Morandi <no@spam.com>( Subject: a pix to VT100 ascii converter?3 Message-ID: <3fbf3382$0$2380$626a54ce@news.free.fr>   P I'm considering to be able to convert a digital picture to its "image" in plain  ascii characters.   O Remember these posters we had when the Dataproducts line printer came out back  J in the 80'? we were able to print four or five listing pages representing J someone or someone else. All the "picture" made with simple ascii letters.  < I never knew how these posters were actually built. By hand?  P Anyway, does someone know if there is such "tool" to scan a jpeg or gif or tiff 1 or bmp picture and produce an ascii "equivalent"?   N I understand that the size of a genuine VT100 character is much bigger than a  pixel, but I'm just wondering.   D.   ------------------------------  % Date: Sat, 22 Nov 2003 05:21:58 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>, Subject: Re: a pix to VT100 ascii converter?) Message-ID: <3FBF38AE.170781CA@istop.com>    Didier Morandi wrote: P > Remember these posters we had when the Dataproducts line printer came out backK > in the 80'? we were able to print four or five listing pages representing L > someone or someone else. All the "picture" made with simple ascii letters. > > > I never knew how these posters were actually built. By hand?  D Nop.  they assign various printable characters to a darkness factor.  O For instance, an M is darker than an I and a space is equivalent to full white.   I So you convert the image to grayscale, then for each pixel, you determine @ which printable character best represents the value of the pixel (light/darkness intensity).   N however, these techniques worked well for very large printouts seen from afar.M For a VT100, you'd be too close to really see much of the shapes/images since % you'd be seing the actual characters.   M If you have VT240 or DECterm, you can then use sixel, at which point, you can M send a bitmap representation. However, unless you have colour, you'll have to 4 use dithering to convert gray values to black/white.   ------------------------------    Date: 22 Nov 2003 12:21:46 +0100K From: pmoreau@ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40) , Subject: Re: a pix to VT100 ascii converter?! Message-ID: <WhoXEf+oHks$@sinead>   X In article <3fbf3382$0$2380$626a54ce@news.free.fr>, Didier Morandi <no@spam.com> writes:R > I'm considering to be able to convert a digital picture to its "image" in plain  > ascii characters.  [...] > > I never knew how these posters were actually built. By hand? > R > Anyway, does someone know if there is such "tool" to scan a jpeg or gif or tiff 3 > or bmp picture and produce an ascii "equivalent"?   M Take a look at aalib library (Ascii Art Library). Version 1.0 is available at  the DECwindows archive:   ! http://decwarch.free.fr/libs.html   L With the libraries, you'll find some utilities (a file viewer a la Xv and an. fli/flc animation viewer . Very impressive ...   Patrick  --O =============================================================================== N pmoreau@ath.cena.fr  (CENA)      ______      ___   _          (Patrick MOREAU)4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================    ------------------------------   Date: 22 Nov 2003 09:43:01 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>  Subject: Re: Backwards File Dump5 Message-ID: <DTiotGxQ0bj6-pn2-5SOJbOKwxThm@localhost>   F On Sat, 22 Nov 2003 03:32:10 UTC, JF Mezei <jfmezei.spamnot@istop.com> wrote:   > Wayne Sewell wrote: O > > True, values in arrays, including characters in strings, display backwards. L > > But as far as discrete numeric values are concerned (when initialized asE > > numeric values, not "bit strings"), what you see is what you get.  > I > When you dump a file to see what sort of line terminator it has, is the N > reverse ordering of bytes natural ? Endianness has no relevancy when dumping> - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  - ^ > files especially text files.  ; That's a bit of a bald statement JF. (My first thought was  F 'bo**cks'.:-) Endianness _does_ make a difference, as many people have+ pointed out. However, I can see your point.   E The terminator is something you'd normally look for in hex. So you'd  > like a straight dump in sentence order allowing you 'see' the 5 terminators more easily. With VMS dump you get both.    F Use DUMP /BYTE, look at the ascii, where the non-printables stand out E like a sore thumb, and if the displayed ascii representation doesn't  E tell you what the terminator is, scan the hex on that line, right to   left. and you'll quickly find the terminator value.   E A DUMP_ASC utility _will_ give you the same display on both a little  A and big endian machine, that is true, because (ascii) characters  C follow bytes that start at address 0. With binary data, especially  D records on non-aligned boundaries, VMS DUMP lets you see the values F and the layout. Especially given the /BYTE, /WORD etc qualifiers. I do' this, on average, at least once a week.   F So on BigEndian machine you see things more clearly with the hex left E to right. On (litlle-endian) VMS, generally, it is more legible with  E the binary right to left. And the ascii is there in 'sentence order'   as well. Perfect!   = I have to admit, I've never been able to understand people's  = difficulty with the DEC dump display. Its just right for DEC  ' platforms! (It would be ok on x86 too).   F I remember having a similar discussion with and IBM-experienced bloke,F some 20 yrs ago. We were trying to trace a fault in his code and were D looking at the o/p from RSX DMP. He didn't understand it because he B didn't know the pdp-11 was litttle-endian. (Echoing Paul here) He * didn't even know there was such a thing...   --   Cheers - Dave.   ------------------------------  % Date: Sat, 22 Nov 2003 12:27:15 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 6 Subject: Re: Building a cluster using HP's SBW program' Message-ID: <3FBFAA83.FC48E948@fsi.net>    Peter Weaver wrote:  >  > Hoff Hoffman wrote:  > >...@ > >   Phone numbers and email addresses for Watson/SBW folks are+ > >   available on the website.  (I located 2 > > <http://h18002.www1.hp.com/alphaserver/acu/>.) > >... > > > Like I said, I asked them the same question October 14 and I> > am still waiting for them to finish their "investigation." I: > just hoped that someone here had already figured it out.  H At teh rsik of sounding like a smart-ass, follow-up with them ("Any news; yet?"). It's a good bet you've "fallen through the cracks".    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sat, 22 Nov 2003 15:01:16 +0200 * From: Mike Rechtman <rechtman@tzora.co.il>) Subject: Re: Compaq Secure Web Server 1.3 : Message-ID: <bpnmmp$1q92r2$1@ID-103225.news.uni-berlin.de>   Frank wrote: > Hi, M >      I can't seem to get the web server up and running. I download plus the N > other add-ons such as Java, php and perl. I also update my vms very much. IsM > currently running OpenVms 7.3-1 with the lastest update-v0100 and few other N > updates for dcl , pcsi.... I have read the manual , which are very long, andK > I have done what they tell me to but when I go into http://192.168.7.211/ G > which is my vms internal ip, it won't work.... any ideas... I run the M > configuration file, plus I checked the httpd.conf file, I have a index.html M > file on the htdocs and I also run the jakarta prodecure . I have start that J > process plus the server using apache$startup... Please, any help will beM > good... I'm running all of this on a alpha with 128mb ram, 4gb hard drive , ( > alpha workstation 255 4/266 ... thanks >  > Francisco  >  >   5 Bit difficult to make out what actually went wrong... 1 Perhaps to analyze which component is faulting :- D 1 uninstall (PROD REMOVE) _all_ the components (in reverse order of  installation!)D 2 install vanilla CSWS - check whether you see the Apache test page.< 3 install e.g. PHP - check whether you see the PHP test page	 4  etc...    Mike --  J New to Usenet? read http://eisner.encompasserve.org/~rechtman/post_hlp.htmE --------------------------------------------------------------------- E Usual disclaimer: All opinions are mine alone, perhaps not even that. D Mike Rechtman                                 *rechtman@tzora.co.il*C    "20% of a job takes 80% of the time, the rest takes another 80%" E ---------------------------------------------------------------------    ------------------------------  % Date: Sat, 22 Nov 2003 07:48:11 -0500 & From: "Frank" <orte8038@bellsouth.net>% Subject: Compaq Secure Web Server 1.3 : Message-ID: <oTIvb.24426$ow5.10636@bignews2.bellsouth.net>   Hi, K      I can't seem to get the web server up and running. I download plus the L other add-ons such as Java, php and perl. I also update my vms very much. IsK currently running OpenVms 7.3-1 with the lastest update-v0100 and few other L updates for dcl , pcsi.... I have read the manual , which are very long, andI I have done what they tell me to but when I go into http://192.168.7.211/ E which is my vms internal ip, it won't work.... any ideas... I run the K configuration file, plus I checked the httpd.conf file, I have a index.html K file on the htdocs and I also run the jakarta prodecure . I have start that H process plus the server using apache$startup... Please, any help will beK good... I'm running all of this on a alpha with 128mb ram, 4gb hard drive , & alpha workstation 255 4/266 ... thanks  	 Francisco    ------------------------------  # Date: Sat, 22 Nov 2003 13:02:23 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")) Subject: Re: Compaq Secure Web Server 1.3 6 Message-ID: <00A2943E.47744315@SSRL.SLAC.STANFORD.EDU>  c In article <oTIvb.24426$ow5.10636@bignews2.bellsouth.net>, "Frank" <orte8038@bellsouth.net> writes:  >Hi,L >     I can't seem to get the web server up and running. I download plus theM >other add-ons such as Java, php and perl. I also update my vms very much. Is L >currently running OpenVms 7.3-1 with the lastest update-v0100 and few otherM >updates for dcl , pcsi.... I have read the manual , which are very long, and J >I have done what they tell me to but when I go into http://192.168.7.211/F >which is my vms internal ip, it won't work.... any ideas... I run theL >configuration file, plus I checked the httpd.conf file, I have a index.htmlL >file on the htdocs and I also run the jakarta prodecure . I have start thatI >process plus the server using apache$startup... Please, any help will be L >good... I'm running all of this on a alpha with 128mb ram, 4gb hard drive ,' >alpha workstation 255 4/266 ... thanks   O Did you run sys$manager:apache$config?  You don't mention that you did, and you O have to do it.  (It sets file permissions appropriately so that  Apache$WWW can K read its own config files, among other things.)  Without that, Apache won't  start proprely.    Try   ( $ PIPE SHOW SYSTEM | SEA SYS$PIPE APACHE  : and see if you actually have any Apache processes running.  O If not, look in apache$specific:[000000...] for a logfile with two dollar signs J in the name - can't remember the name exactly now - and that will show any( error message Apache threw before dying.   -- Alan  >  --  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------  % Date: Sat, 22 Nov 2003 10:59:42 -0500 & From: "Frank" <orte8038@bellsouth.net>) Subject: Re: Compaq Secure Web Server 1.3 9 Message-ID: <YGLvb.25195$ow5.6941@bignews2.bellsouth.net>   / Thanks... I'll try to reinstall and do it again    thanks  1 "Frank" <orte8038@bellsouth.net> wrote in message 4 news:oTIvb.24426$ow5.10636@bignews2.bellsouth.net... > Hi, I >      I can't seem to get the web server up and running. I download plus  the K > other add-ons such as Java, php and perl. I also update my vms very much.  IsG > currently running OpenVms 7.3-1 with the lastest update-v0100 and few  other J > updates for dcl , pcsi.... I have read the manual , which are very long, and K > I have done what they tell me to but when I go into http://192.168.7.211/ G > which is my vms internal ip, it won't work.... any ideas... I run the B > configuration file, plus I checked the httpd.conf file, I have a
 index.htmlH > file on the htdocs and I also run the jakarta prodecure . I have start thatJ > process plus the server using apache$startup... Please, any help will beK > good... I'm running all of this on a alpha with 128mb ram, 4gb hard drive  , ( > alpha workstation 255 4/266 ... thanks >  > Francisco  >  >    ------------------------------  % Date: Sat, 22 Nov 2003 17:12:29 +0100 " From: Didier Morandi <no@spam.com>) Subject: Re: Compaq Secure Web Server 1.3 3 Message-ID: <3fbf8b0e$0$2357$626a54ce@news.free.fr>    Frank wrote:   > Hi, M >      I can't seem to get the web server up and running. I download plus the N > other add-ons such as Java, php and perl. I also update my vms very much. IsM > currently running OpenVms 7.3-1 with the lastest update-v0100 and few other N > updates for dcl , pcsi.... I have read the manual , which are very long, andK > I have done what they tell me to but when I go into http://192.168.7.211/ G > which is my vms internal ip, it won't work.... any ideas... I run the M > configuration file, plus I checked the httpd.conf file, I have a index.html M > file on the htdocs and I also run the jakarta prodecure . I have start that J > process plus the server using apache$startup... Please, any help will beM > good... I'm running all of this on a alpha with 128mb ram, 4gb hard drive , ( > alpha workstation 255 4/266 ... thanks  P As an addendum to what Mike wrote, turn file access failure alarm reporting on.  May help (very often helps...)  & $ set audit/alarm/enable=file=fail=all	 $ rep/ena    D. --  N     Read the latest VAX/VMS to Itanium Migration News  | mirrors   | downloadsJ   www.openvms.org/dmorandi/vaxvms2itanium_200311en.pdf   en USA        n/aI www.didiermorandi.com/vms/vaxvms2itanium_200311en.pdf   en Europe    2615 I www.didiermorandi.com/vms/vaxvms2itanium_200311fr.pdf   fr Europe     512 I www.didiermorandi.com/vms/vaxvms2itanium_200310en.pdf   en Europe     372 I www.didiermorandi.com/vms/vaxvms2itanium_200310fr.pdf   fr Europe     136   ;                   Discover the FutureVAX: www.futurevax.com   K      didier morandi  ~ sarl au capital de 8 000 euros ~  Revendeur agr HP G          Expertise en environnement DIGITAL ~ Formation ~ Programmation K      Offshore ~ 5 av. A. Durand 31700 Blagnac France. Tl: 33(0)5 6131 6287 H        SIRET 448 694 851 00016 RCS Toulouse http://www.didiermorandi.com   ------------------------------  % Date: Sat, 22 Nov 2003 17:27:15 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)) Subject: Re: Compaq Secure Web Server 1.3 ; Message-ID: <3fbf8e63.524144494f47414741@radiogaga.harz.de>   K Alan Winston - SSRL Admin Cmptg Mgr (winston@SSRL.SLAC.STANFORD.EDU) wrote: * > $ PIPE SHOW SYSTEM | SEA SYS$PIPE APACHE   An easier way (IMHO) is      $ SHOW SYSTEM /OWNER=APACHE$WWW  K with the added bonus that you see any Tomcat process as well (provided it's  correctly set up).  K > If not, look in apache$specific:[000000...] for a logfile with two dollar I > signs in the name - can't remember the name exactly now - and that will 3 > show any error message Apache threw before dying.   G That'll be APACHE$$SERVER.LOG for the main process, and APACHE$000.LOG, E APACHE$$001.LOG, etc. for the children. Also, once the processes have E started up, APACHE$ROOT:[LOGS] has access and error logs (but that is  subject to configuration).   cu,    Martin --  A                      | Martin Vorlaender  |  VMS & WNT programmer . Microsoft's answer   | work: mv@pdv-systeme.deA to OpenVMS is        |   http://www.pdv-systeme.de/users/martinv/ 5 Windows NT 10.0.     | home: martin@radiogaga.harz.de    ------------------------------   Date: 22 Nov 2003 09:43:00 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE 5 Message-ID: <DTiotGxQ0bj6-pn2-GTN3mCn2EcCs@localhost>   E On Thu, 20 Nov 2003 10:45:28 UTC, Didier Morandi <no@spam.com> wrote:    > Paul Repacholi wrote:  > G > > But you are NOT reopening the file! You are superceding the logical F > > from the first open, but that is just a coincedence, it could well > > be any logical.  > P > I repeat. You are NOT superceding anything. Just nothing happens. This is the 4 > issue. Try with two files on two different disks : >  > DTL02> open/read ch A.A  > DTL02> sh log ch. >     "CH" = "_DTL02$DKA0" (LNM$PROCESS_TABLE) > DTL02> sh def  >    SYS$SYSROOT:[SYSMGR]  >    =   SYS$SYSROOT:[SYSMGR]  >    =   SYS$COMMON:[SYSMGR]
 > DTL02> mora  > DTL02> sh def  >    DKA100:[MORANDI]  > DTL02> open/read ch A.A  > DTL02> sh log ch. >     "CH" = "_DTL02$DKA0" (LNM$PROCESS_TABLE) > DTL02> > , > Logical name did NOT change (fortunately). >  > D. >    So the issue is :-  F Should a warning message be issued to inform the programmmer/user thatF his required action did not complete as expected? The procedure itself. would/should then/still behave as it ever had.  , Should there be a method of inhibiting this?  5 What should the default for the reporting-inhibit be?   F I could live with the warning suddenly appearing. I tend to re-Q/A allE my stuff when me move VMS or Compiler versions and have had a number  1 of things 'break' or change on me over the years.   A e.g. in a Q/A test procedure I used to use DIFF /PA to check for  D variations between one run and the next. It all worked very happily C until /PAGE was introduced... Serves me right for forgetting the 4   significant character rule.    --   Cheers - Dave.   ------------------------------  % Date: Sat, 22 Nov 2003 10:52:42 +0100 " From: Didier Morandi <no@spam.com>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE 3 Message-ID: <3fbf3214$0$2352$626a54ce@news.free.fr>    Dave Weatherall wrote:  H > Should a warning message be issued to inform the programmmer/user thatH > his required action did not complete as expected? The procedure itself0 > would/should then/still behave as it ever had. > . > Should there be a method of inhibiting this? > 7 > What should the default for the reporting-inhibit be?  > H > I could live with the warning suddenly appearing. I tend to re-Q/A allG > my stuff when me move VMS or Compiler versions and have had a number  3 > of things 'break' or change on me over the years.  > C > e.g. in a Q/A test procedure I used to use DIFF /PA to check for  F > variations between one run and the next. It all worked very happily E > until /PAGE was introduced... Serves me right for forgetting the 4   > significant character rule.   @ Should a warning be implemented by Guy P., my solution would be:  # $ on warning then gosub ERR_HANDLER  ../..  $ open/read ch 'file'     
 $ERR_HANDLER: P $ if $severity .eqs. "2" then goto FATAL_ERROR                  !does not changeN $ status = $status                                              !  the $status
 $ set noonK $ say    "*** ERROR: ",f$message(status)                        !to logfile J $ say1   "*** ERROR: ",f$message(status)                        !to screenP $ log_it f$message(status)                                      !to journal file# $ on warning then gosub ERR_HANDLER L $ return                                                        !ERR_HANDLER $!
 $FATAL_ERROR:  $ status = $statusK $ say    "*** ERROR: ",f$message(status)                        !to logfile J $ say1   "*** ERROR: ",f$message(status)                        !to screenP $ log_it f$message(status)                                      !to journal file $ log_it "STOP on fatal error" $ log_it "Subprocess killed."  $ close/nolog jnl_chanP $ stop/id=0                                                     !PSO: fatal exit   D.   ------------------------------  % Date: Sat, 22 Nov 2003 18:00:00 +0100 * From: Paul Sture <nospam@sture.homeip.net>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE 0 Message-ID: <3FBFA420.7A3D5736@sture.homeip.net>   jlsue wrote: > J > On Wed, 19 Nov 2003 19:24:24 +0100, Paul Sture <nospam@sture.homeip.net> > wrote: >  > > 9 > >It _has_ to be compatible with current behaviour IMHO.  > >   > >Let's look at HELP OPEN/ERROR > > & > >     If the /ERROR qualifier is not< > >     specified, the current ON condition action is taken. > > K > >Oh dear, currently working procedures could suddenly do a silent jump in I > >the code if the default were changed. There's simply too much code out  > >there...  > K > But how is that different than the change that required a "$" on each DCL  > command line?  >   E Sorry, I'm going to dig my heels in on this one, because I feel it is 
 important.  F I'd be happy to give you a fixed  price quote for fixing a few millionA lines of code for the "$" at the start of each line problem. It's # something I could largely automate.   E OTOH, I could only give you a time and materials quote for the change H suggested here in the default behaviour of OPEN, and would not commit toB more than a few thousand lines at a time - I would need to see the. general quality of the code before each quote.  ! That is the essential difference.   @ Feedback welcome, but I do believe there's a massive difference.   ------------------------------    Date: 22 Nov 2003 10:43:22 -0800. From: spamsink2001@yahoo.com (Alan E. Feldman)A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE = Message-ID: <b096a4ee.0311221043.7077bf26@posting.google.com>   b Paul Sture <nospam@sture.homeip.net> wrote in message news:<3FBDC130.3A2617AE@sture.homeip.net>... > jlsue wrote: > > L > > On Wed, 19 Nov 2003 19:24:24 +0100, Paul Sture <nospam@sture.homeip.net>
 > > wrote: > >  > > > ; > > >It _has_ to be compatible with current behaviour IMHO.  > > > " > > >Let's look at HELP OPEN/ERROR > > > ( > > >     If the /ERROR qualifier is not> > > >     specified, the current ON condition action is taken. > > > M > > >Oh dear, currently working procedures could suddenly do a silent jump in K > > >the code if the default were changed. There's simply too much code out 
 > > >there...  > > M > > But how is that different than the change that required a "$" on each DCL  > > command line?  >  > IIRC that was not silent.   ; Is this in reference to the change made, c. 1985-1989, that F continuation lines had to NOT start with a dollar sign? Or a post v6.2 change?   N > > If it's an error situation, and an error is not being reported, then it isH > > a *latent* bug in the code and/or DCL that will eventually bite you. > > L > > In this particular case, it HAS caused problem for myself and some otherJ > > customers.  It is entirely non-intuitive, and inconsistent, that a DCLO > > procedure exiting abnormally, leaving a file opened, would *appear* to open K > > the file, but really just continue from the last position.  I know that M > > this should be handled by "on" conditions, but that's not always going to  > > happen.  > > N > > Another example that's less so obvious (as I believe Didier showed before)L > > was where two pieces of code open different files but use the same name.G > > Again, not reporting an error is a big problem.  And the programmer K > > shouldn't have to know/code something special to make that error report  > > correctly. > > ' > > Latent bugs are pretty scarey, imho  > G > I'll agree about the inconsistencies, and it should perhaps have been 8 > fixed in the V4.0 timeframe, when plenty of DCL broke. > J > It's simply been there so long that changing the default behaviour would > be equally scary.   E I understand your point. And the last thing I want is to scare people F off of VMS (as Larry Kilgallen warned in another post in this thread).C However, this would only affect places doing upgrades to what would C soon be the latest version. It would only immediately affect places B doing upgrades to that soon-to-be latest version. Such places mostA likely routinely upgrade and if they can do the upgrades they can C probably deal with the new OPEN behavior. And the new OPEN behavior @ would only affect command procedures that actually used the OPENB command "incorrectly". I don't think there'd be that many of them.E You'd have to code a self-correcting OPEN statement bug for your code C to work anyway. I mean if you OPEN a file, but you already OPENed a C different file with the same logical name, then I think it would be F rather unlikely that your code would work because the file you thoughtC you OPENed is not the one that is actually opened. How could such a F code work correctly? In which case just how much code could break with( this change in OPEN? I'd guess not much.  B So I don't think it would cause too much pain and it would make itA easier for beginning DCL coders and it would correctly display an D error message when needed. And it would make it easier for all of usF to catch such OPEN errors. And good error messages are one of the many great things about VMS.   C > I've known about it for at least 20 years, and even used it to my 5 > advantage on occasions (usually for DCL debugging).    Can you tell us how?   G > I'm arguing that it's too late now to change the _default_ behaviour.  > F > Far easier to document it as a "feature", and as suggested elsewhereI > have a logical or appropriate SET command to enable enhanced OPEN error  > checking (off by default).  E Additionally you could add a step to the upgrade procedure that would E ask the upgrader about which OPEN he wants (correct, or incorrect :-) @ and force him to answer the question or the upgrade fails. OK, IF wouldn't phrase it that way. Maybe it should just say "new or old". OrC it could go into a nearly full screen explanation of the issue, and - after the answer is given ask "Are you sure?"   @ And there is, as always, the "Be careful what you wish for" bit.   Disclaimer: JMVHO  Alan E. Feldman    ------------------------------    Date: 22 Nov 2003 01:01:14 -08007 From: jones.computer.srv@worldnet.att.net (Daryl Jones) ' Subject: Re: Disk cluster size question = Message-ID: <8a646952.0311220006.55cd51b6@posting.google.com>   [ Drew Shelton <DREW@SEMATECH.Org> wrote in message news:<01L3AQMZ4VB2005RHZ@SEMATECH.Org>... G > I'm planning an upgrade from VMS 7.1-2 to 7.3-1, and I'd like to take K > advantage of smaller disk cluster sizes to conserve disk space.  Is there H > any reason (such as performance) not to have the smallest cluster size > possible?  > 	 > Thanks,  > Drew > N > ============================================================================8 > Drew Shelton                         drew@sematech.org; > VMS Systems Manager                  office: 512-356-7575 ; > Sematech                             fax:    512-356-7600  > 2706 Montopolis Drive M > Austin, TX 78741-6499                I speak for myself only, not Sematech. D >     "OpenVMS is today what Microsoft wants Windows NT v8.0 to be!"K >                                                         - Compaq, 9/22/98 N > ============================================================================ Dear Drew Shelton:  E I had a similar discussion on this topic around March 11, 2003 with a ; Mr. Hein Vandenheuvel of HP. The discussion went like this:   C Daryl Jones: You have introduced a new notion that the Disk Cluster C size to be in the hundreds. Since I have been with VMS from 2.5 and D on, I have always kept the Disk cluster size to a small number basedF upon the usual file size that was in the disk. I assume the large DiskE Cluster size is for databases. Here I tried to match the Disk Cluster 1 size to database disk I/O size by asking the DBA.   C Mr. Hein Vandenheuvel: My current thinking is that the cluster size C choice should be as large as possible with the limiting factor just D being the acceptable accumulated EOF waste. This holds true for DB'sC and RMS. I'd still pick a 'nice' number like 720(1*2*3*4*5*6) which E divides by many factors and will thus work optimal with DB page sizes  and RMS bucket sizes.   ) I found his discussion most enlightening.   
 Good Luck, Daryl Jones    ------------------------------  % Date: Sat, 22 Nov 2003 01:55:30 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>J Subject: Re: Efficiency Question: Large Arrays vs. Indexed Files on Alphas) Message-ID: <3FBF0858.C962E935@istop.com>   J With an RMS based solution, if you ever cluster your 2 machines, then theyE will be able to access the same files and the record locking and more J importantly cache coherence will all be handled on your behalf without any program changes.  G This may not be so important if you never intend to modify those files.    ------------------------------  # Date: Sat, 22 Nov 2003 16:40:18 GMT 6 From: Jeffrey Coffield <jeffrey@digitalsynergyinc.com>J Subject: Re: Efficiency Question: Large Arrays vs. Indexed Files on Alphas= Message-ID: <SjMvb.17642$tS2.6948@newssvr29.news.prodigy.com>    Randy Park wrote: M > On 20 Nov 2003 14:38:14 -0800, hoefelmeyer@hotmail.com (Cheryl Hoefelmeyer)  > wrote: >  > H >>We have a GS80 and an ES40, not clustered, each running OpenVMS 7.3. IG >>am writing a program in Basic that will run on each box, and I have a G >>question regarding which of the following would be most efficient, in 
 >>general. >>H >>The program will operate on three very large files, and at one point I >>can eitherB >>(1) decide to read some fields of some records into an array and; >>search for information sequentially through the array, or H >>(2) read the information into another file and access it each time via >>single read.H >>The number of elements or records in this circumstance is not expected >>to exceed 10,000.  >>) >>Elsewhere in the program, I can either  H >>(1) maintain records that will eventually be written to an output fileF >>in an array because they may need to be updated some number of times& >>before a final record is written, orD >>(2) write the first record to the output file and just update each >>time it is necessary.4E >>The first option would call for reading sequentially through a very0H >>large array to find the proper record to update each time a new recordD >>is added. The second calls for 1-3 file operations per each recordA >>added. The number of records maintained here is on the order ofr >>1,000,000. >>H >>So, for each of these, which is the best option in general? Years ago,D >>I/O on DEC boxes was such a bottleneck that the array option wouldE >>generally be the faster route, but I&#8217;m no longer sure that isE >>such a big issue now.r >  > E > Yes, I remember those days with I/O in BASIC was a bottleneck.  VMS E > was a lot slower than RSTS/E back in the late 70s and early 80s forr0 > indexed file operations.  Those days are gone. > H > Based upon what you've written, with the volume of data that you have,G > I'd go ahead an use an RMS Indexed file.  With good bucket sizing andlH > other design parameters, you can get pretty good performance.  The topM > two index buckets will probably end up getting cached.  In addition, you'llbO > be able to use a variety of tools, like report writers, on your data, and youA) > would be able to easily share the data.  > H I have found that an RMS file with appropriate segmented alternate keys C actually will perform better than an in memory array. The trick is tJ determining the specific key structure that will benefit your application.   ------------------------------  % Date: Sat, 22 Nov 2003 12:01:32 -0500-& From: "Frank" <orte8038@bellsouth.net>
 Subject: IRC?-: Message-ID: <VAMvb.25229$ow5.16113@bignews2.bellsouth.net>   Hi,r,     is there any groups for OPENVMS in IRC ? thanks   ------------------------------  # Date: Sat, 22 Nov 2003 18:44:53 GMTo From: Jim Duff <jim@127.0.0.1> Subject: Re: IRC?oH Message-ID: <F8Ovb.98490$Ec1.4564217@bgtnsc05-news.ops.worldnet.att.net>   Frank wrote: > Hi, . >     is there any groups for OPENVMS in IRC ? > thanks >  >   B I run #OpenVMS on Austnet (http://www.austnet.org).  However, the ! traffic is light to non-existant.    Regards, Jim. -- w http://www.eight-cubed.com/l   ------------------------------  % Date: Sat, 22 Nov 2003 12:14:49 -0600s1 From: "David J. Dachtera" <djesys.nospam@fsi.net>u" Subject: Re: lat for linux problem' Message-ID: <3FBFA799.2FD916E6@fsi.net>h   H Vlems wrote: >  > John,  > I > glad that helped. But there is a connection between DECnet and terminal K > servers. The older units, the DS100/200/300 use a derivative of DECnet to " > download their operating system.  B Well, technically, no. In DECnet, MOP is facilitated by the DECnet< executor. Then, LANACP came along and DECnet was no longer a requirement.  , > But they also may be managed thru NCP (theN > CONNECT NODE command) and that's where the DECnet address check was probably	 > needed.m  D Well, technically, the DECnet address is not 100% mandatory. At someH point, it became possible for any node with line service enabled and theG requested load image available to service a load request, regardless ofsB whether the requesting device was registered in that node's DECnet	 database.e   -- a David J. Dachteram dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------    Date: 22 Nov 2003 10:12:34 -0600+ From: young_r@encompasserve.org (Rob Young)o# Subject: Re: Main memory for galaxys3 Message-ID: <0$d87KMlBj9T@eisner.encompasserve.org>D  a In article <jFBvb.61020$Eq1.47199@twister.rdc-kc.rr.com>, "Mike Naime" <mnaime@kc.rr.com> writes:sE > Well, That explains why I have never heard/used GCU.  We do not usesH > graphical consoles on our systems. (Or Galaxy anymore for that matter) > I > Our systems are all hard partitioned now.  The maintenance requirements.J > (Monolithic firmware upgrades) and CD ROM hardware need is what drove usJ > away from Galaxy.  Why buy the larger box and split it up if I can buy 8L > smaller boxes for less and then have no requirement to take down 8 systems1 > at the same time to perform a firmware upgrade.r >   A 	In your case with your application , it makes little sense.  Buty 	you may have seen that coming?e   	Where Galaxy does make sense:  ; 		1) Day versus night load.  CPUs migrate to backup serversi 			or report run servers.l  < 		2) Active-active clustering with substantial lock traffic.2                        locks through shared memory  ? 		3) Very high LAN traffic - applications using heavy net comm.s 			LAN through shared memory  2 	And I'm sure overlaps with various Galaxy models.  C 	But applications that have fallover clustering - where one node is=7 	"the man" - it seems Galaxy is not a good fit at all. _   				Rob_   ------------------------------  % Date: Sat, 22 Nov 2003 12:25:20 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 7 Subject: Re: Many CDs in the Alpha "condist" these days ' Message-ID: <3FBFAA10.3C60F94E@fsi.net>_   Didier Morandi wrote:A > N > In two weeks time, I received two sets of CDs from HP, the Software ProductsQ > Library (SPL) set and the HP OpenVMS set. Some of them I have no idea what they=: > are (since I stopped being a "Customer" since 17 years). >  > Here is the list:- >  > SPL disks 1 to 9: ok  > OpenVMS Freeware v5, 1 & 2: ok > OpenVMS Alpha OS 7.3-1 : ok> > Doc 1 & 2: okc > Pathworks32: oke > TCP/IP MUP: ok@ > Firmware update 6.2 & 6.5: ok (I suppose I can trash the 6.2?)  E Most of the following will reveal themselves via DIRECTORY or you cane< explore some of them in WhineBloze (sicne they're ISO-9660).   > Open Source Tools: ?  ; Should contain various README files and such. Check it out.t  ? > OpenVMS Alpha Layered Products: ? (a complement for the SPL?)   % Stuff that didn't fit on the o.s. CD.e   > System Tools dec 2002: ? > System Tools 1.4 sept 2001: ?   ' Again, see the disc and/or the READMEs.n   > BEA Weblogic Server 7.0: ?   See http://www.bea.com/    > eBusiness Infrastructure: ?i  ? Various internet bits for building an eCommerce server on a VMS(	 platform.o   -- s David J. Dachteran dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/i   ------------------------------   Date: 22 Nov 2003 07:46:17 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>/ Subject: Re: Only hope for Intel is alpha chip?t5 Message-ID: <DTiotGxQ0bj6-pn2-P3DxiwvVFNuY@localhost>n  C On Thu, 20 Nov 2003 14:28:20 UTC, jlsue <jefflsxxxz@sbcglobal.net> e wrote:  K > On 20 Nov 2003 07:37:54 GMT, "Dave Weatherall" <djw-nothere@nospam.nohow>h > wrote:   <Snip> '  G > >On the other hand, Intel/HP could just redefine 'Industry-Standard'.u > K > Well, it's not as if this hasn't been redefined at least a thousand timessI > in the past few years by all vendors anyway.  I doubt it's actually hadaK > much of a hard-and-fast definition, other than it usually included WinteleL > (and sometimes Win/AMD, though not normally in mid- and high-end servers).  E Fair enough Jeff. I can see you're not overwhelmed by the use of the o term.h   -- r Cheers - Dave.   ------------------------------  % Date: Sat, 22 Nov 2003 12:17:31 -0600l1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s. Subject: Re: Peoplesoft Financials and OpenVMS' Message-ID: <3FBFA83B.51321A9D@fsi.net>    John Smith wrote:s > # > Funny you should mention that....  > N > I was in a doctor's office today and while waiting I did what most people doC > while they wait....read one of the magazines in the waiting room.  > D > No, not Computerworld, or Datamation, or InformationWeek, but TimeK > magazine...you know the one...a general interest magazine usualy found in1N > doctor's offices, a magazine with some news, some entertainment, some sports > articles.....  > M > And by gosh, guess what was in that September 2003 issue? (I forget exactly E > which weekly issue it was but it was in the last half of September): >  > ....give up? > E > A full page color ad for their eSeries servers running AIX. It alsoe7 > mentioned security, reliability, capacity, and Linux.h > J > I guess Alphaservers and VMS offer none of that (ex-Linux), otherwise HP > would surely be advertising.  E So, maybe the thing to do would be to find a Sep-2003 Time, mark thataE page and forward the publication - one copy each - to Carly, Mark. G.e@ and whoever else with a note attached asking the question (VMS's ad-worthiness).g   --   David J. Dachtera  dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/"   ------------------------------  % Date: Sat, 22 Nov 2003 02:05:06 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>- Subject: Re: Routable Protocol for Clustering-) Message-ID: <3FBF0A97.E048A1A8@istop.com>1   David Froble wrote:iK > If you have a multi-site cluster for disaster tolerance, then you need to : > approach the networking group with a 2x4 and pink slips.  K Keith Parris has shown examples where a cluster "sharing" its LAVC link hadiB mega problems due to other devices on the lan interfering with it.  M I would surmise that the original poster was asked if they couldn't folsk thelI SCS traffic onto their exsiting IP network to eliminate the need for thatdJ "dedicated" link. In that context, the answer is not only "no SCS can't goL onto IP", but also "SCS is important enough that it deserves its own link to0 ensure system availability with no disruptions".   ------------------------------  % Date: Sat, 22 Nov 2003 08:01:18 -0600o( From: Wayne Sewell <wayne@tachysoft.com>- Subject: Re: Routable Protocol for Clusteringe/ Message-ID: <00A29457.45C3D60F.1@tachysoft.com>w  ) >From: David Froble <davef@tsoft-inc.com>a >X-Newsgroups: comp.os.vms. >Subject: Re: Routable Protocol for Clustering& >Date: Sat, 22 Nov 2003 01:22:43 -0500   >Bob Koehler wrote:h >a >> In article <92EFB80E551BD511B39500D0B7B0CDCC11053206@ohms.electric.ci.austin.tx.us>, "Stuart, Ed" <Ed.Stuart@austinenergy.com> writes:r >>  H >>>We keep getting pressure from our networking group to consolidate ourO >>>multi-site VMS cluster.  They want this consolidation so they do not have to.H >>>worry about network configurations that support the non-routable LAVCM >>>protocol.  Are there any plans to make LAVC routable or tunnel LAVC in IP?- >>>- >>>Eds >>>i >> mJ >>    Making LAVC routable just doesn't make sense, neither does tunnelingG >>    it.  When you've got your systems linked at the kernel you need as$ >>    quick, tight network protocol. >> % >> - >-K >If you have a multi-site cluster for disaster tolerance, then you need to -9 >approach the networking group with a 2x4 and pink slips.0 > Q >Another case of the networking people no longer providing a service, but rather sG >dictating what you can and can't do.  Do you really need these clowns?n >s    H In version 6.x of tapesys, I added tcp/ip support for connections to theC database manager.  On the surface, this makes no sense, because thenJ communication is always vms to vms, and decnet is always available, right?  N Wrong.  Some sites have network dickweeds who ban the decnet protocol.  Again,L simply because they are not familiar with it.  Also, billy and eunuchs don't use it, so it must be bad.  9 As far as I'm concerned tcp/ip is for vms-to-non-vms.  OrcL vms-to-vms-via-non-vms, i.e. the internet.  I think it is just plain dumb toM use tcp/ip for vms to vms locally at a site.  You lose features such as known G objects and the file access listener (including network access of filesi7 directly from dcl), which have no equivalent in tcp/ip.k  N Anyway, the tapesys database manager will accept connections from client nodesM using ICC, decnet, and tcp/ip simultaneously.  Which is used for a particular M node depends on what transports are available to that node.  For instance, toeN connect with icc a node must be running at least 7.2 of vms and must be in the same cluster as the manager.  F The currently released version of tapesys requires that the connectionK transport used by clients be specified in the parameters file, specifically B TRANS_FOR_DB_COMM is set to decnet, cluster (ICC), or tcpip.  SomeN configurations are complex, with some nodes in the cluster, and some outside. 6 Also, some nodes are running above 7.2 and some below.  M When decnet is arbitrarily banned, the connections get more complicated yet. .N So the best approach is to use "cluster" as the default transport and overrideB individual nodes with the TRANS_FOR_DB_COMM_<nodename> parameters.  M In tapesys 6.1.19, which has not been released, this is greatly simplified by K making TRANS_FOR_DB_COMM a list, allowing the client to try to connect withb, multiple protocols, ordered by desirability.  N Therefore the default for TRANS_FOR_DB_COMM is now "cluster,decnet,tcpip".  IfN ICC is available to the client, it will be used.  If not, decnet.  tcp/ip will8 be used only if network lamebrains have disabled decnet.  K Again, this is not yet released, but if any tapesys customers would like tot+ have it early, a minipatch can be provided. O ===============================================================================AN Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html   eO ===============================================================================nH Randolph Duke (in Trading Places): "Mother always said you were greedy."1    Mortimer Duke: "She meant it as a compliment!"    ------------------------------    Date: 22 Nov 2003 08:26:08 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)i- Subject: Re: Routable Protocol for Clusteringe- Message-ID: <tYFN9CvlVjpf@malvm7.mala.bc.ca.>=  3 In article <rqsvb.9509$5a1.5420@news.cpqcorp.net>,  )     hoff@hp.nospam (Hoff Hoffman) writes:a   > L >   SCS needs to be in operation before IP can even start -- for what shouldK >   be obvious reasons -- and SCS access involves operations in a much morelL >   restricted and restrictive system run-time environment than is presentlyK >   possible with IP.  The TCP/IP stack has user-mode components and to get6L >   SCS to effectively operate over IP, we'd have to pull and/or build an IPI >   stack into the OpenVMS kernel (or potentially out into a controller).n >   =     ISTM that in principle it would be quite easy to build annL external "router" box that could send SCS traffic over IP. All it would needH to do is listen for all SCS messages ( or a pre-defined subset - such asL all of them for a particular cluster ), encapsulate them into IP packets andQ send them on to the partner "router"(s) at the remote site(s), which would inject Q them onto the local network. It could work much like a switch does now - floodingIM all traffic initially and learning which nodes are local and which are remote  from watching the traffic.  M     This might be a fun project for a hobbyist to cobble together - of course,* it wouldn't be a supported configuration.    ------------------------------  % Date: Sat, 22 Nov 2003 01:54:15 -0500-* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <4padnd3yxt2JlSKiRVn-gQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:NOX6Zv97+mXz@eisner.encompasserve.org...o@ > In article <a6mdnc3f6PtCMyCiRVn-jg@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > > < > > "Rob Young" <young_r@encompasserve.org> wrote in message >  >  > >>? > >> No - just your view.  In February Intel execs were stating, > >> 18 MByte L3 for Montecito.l > >o6 > > Look at the date on the post you quoted, you dolt. > >  >e? > Yes, January.  My point here of course is that within a montho> > the actual cache of Montecito changed and went to 18 MBytes.@ > Fast forward 9 months and it changed again, to 24 months.  NowB > either they are very fast developers or Intel is playing cat and > mouse.  D Or, as noted, Intel was scrambling to compensate for process delays.  L Intel presented a clear strategy in early 2002:  nothing but process shrinksI and cache-size increases for the McKinley for the duration of the roadmappL that they presented.  That roadmap stopped with the 90 nm. Montecito in 2004I (see, for example, http://www.nwfusion.com/news/2002/0416necintel.html ofsI 4/16/02, which also makes it clear that the 2004 product would enjoy only L 'little enhancements' over its predecessors), a product designed to continueE yearly process-shrink bumps in Itanic's clock rate to open up a clearrK performance lead over competitors (remember, *you* were the one touting theEL speed of Intel's process advances as an insurmountable advantage over Alpha)K while at the same time markedly decreasing chip area (and hence costs) as a H double whammy.  On that schedule, there would have been time for nothingL more than these minor changes for Montecito in 2004 - in particular, no time@ to design in dual cores and the new on-chip bus to service them.  H What seems most likely is that Intel started realizing before the end ofL last year that it wouldn't have its 90 nm. Montecito process (at one point IG think said to be SOI, but I haven't heard anything about that recently):F ready to ship a server-quality processor in 2004, and began looking atE options.  Slipping Montecito a year to 2005 (and giving Madison minorRL clock-rate and cache-size kickers to try to hold the fort for the additionalI year without the significant performance boost that Montecito should havedL provided) became necessary, but with luck the consequences of this would not0 cascade beyond the absence of Montecito in 2004.  L And what I said later in that same 1/16/03 post that you quoted appears evenJ more likely today:  that the enhancements later 'revealed' for the slippedK Montecito may well have been planned for 2005 all along.  There was mention0L of a 2005 'bump' for Montecito in early 2002, and only slightly later rumorsH about a mysterious 'Chivano' - or 'Shavano', depending on the reporter -H scheduled for 2005 with supposed 'Alpha features' also appeared.  At theJ time, I suspected that 'Alpha features' might have meant the appearance ofE EV7-style on-chip glue for Montecito, but now it looks as if it meanteL Intel's toy SMT - though of course that's no 'Alpha feature', despite having1 the same name as the significant EV8 enhancement.:  I If you recall, 'way back just after the Alphacide Compaq was also toutingEI 'Alpha features' in future Itanics prior to 2006:  while the realities of-J development latency made it clear that this was absolute rubbish as far asK any technology transfer was concerned, it's entirely possible that the sameOI kind of toy SMT that Intel created for x86 was being readied to bolt ontooF Itanic2 as well in 2005, after the McKinley core team's other work wasC finished (in fact, I think I've seen a post by Intel's Alex JohnsoneL asserting that the SMT now projected for Montecito was an Intel effort begunH before the Alpha team ever arrived there, but I can't find it now).  TheA hand-job 'white paper' produced in October, 2001 by Compaq's High J Performance Server Business Unit that purported (though utterly failed) toF substantiate the laughable contention that Alpha couldn't keep up withI Itanic performance did state that Intel had 'multi-threading' designs for D Itanic.  And while Michael Kanellos sometimes doesn't seem to be theJ sharpest knife in news.com's drawer, he may have gotten it half right backL on 1/30/02 when he stated ( http://news.com.com/2100-1001-826527.html ) thatJ hyperthreading would appear in Montecito or Chivano (the half he got wrong3 was that it would have any kind of Alpha heritage).   B As for the dual cores, an X-bit labs article that I just turned upJ  http://www.xbitlabs.com/news/cpu/display/news155.html , 9/12/2002) claimsL that Intel stated at last year's IDF that it would have dual-core Itanics in. 2005.  And an October 23, 2002 PCWorld articleI  http://www.pcworld.com/news/article/0,aid,106278,00.asp ) indicated that I Intel planned a multi-core Itanic in 2005 or 2006.  I even mentioned thatgF Itanic might get dual cores in 2005 in a response to you right here on
 11/1/2002.  I So apparently all that changed last January was that the 90 nm. MontecitorJ that had originally been slated to appear in 2004 got scrapped, a new 9 MBJ 130 nm. Madison replaced it as a place-holder, the existing 'Chivano' 2005K product was renamed Montecito, and what would have been the carry-over 2004mJ Montecito in 2005 was dubbed the enhanced Deerfield.  And to keep the slipE in the move to 90 nm. from looking like, well, a slip, Intel publiclyuJ announced the dual-core renamed Chivano as an advance rather than as being+ what it had been planned to be right along.e  J David Wang just made the suggestion over at realworldtech that perhaps theL latest cache size figure (24 MB vs. the previous 18 MB) was made possible byI scrapping the x86 box on Itanic, since it turns out that the new softwareoH (FX!32-style) emulation is indeed significantly faster than the hardwareL assist (it still doesn't turn Itanic into a P4-equivalent, but it does allowJ 32-bit code to run at about the same speed it would run on a Xeon with theD Itanic clock speed - 1.5 GHz currently being the fastest available).  K (Boy, this has been a trip down memory lane.  I also stumbled across one ofiL Terry's post-Alphacide lap-dog presentations for Compaq where he unabashedlyK trotted out Compaq's suggestion that Itanic would reach a 5 GHz clock speed  by 2005...)    >  >O > > ...s > >s3 > >> Well, you would be wrong about Montecito then." > >RL > > Not according to the statements Intel was making up to the time I posted theuI > > material you quoted (i.e., a month before the 18 MB figure surfaced).  > >  >_ > You are wrong now.  L No, Rob:  the statement that the planned Montecito product for 2004 was a 90J nm., 12 MB part remains true.  That part was cancelled, not changed, and a' new, different part announced for 2005.   .   You weren't wrong then.  You didn't know youA > were wrong as you were using publically available sources which 4 > were wrong.  Both you and your sources were wrong.  C No, Rob:  you're just confused, as usual.  As I noted above, I even L mentioned to you right here in c.o.v. that there might be a dual-core ItanicE product in 2005 - over 2 months before I wrote the description of the / planned 2004 product that you are objecting to.j   >R > >   It is obviouslyrI > >> a new core, right?  How else to explain the multi-threading featuresi> > >> and that Intel states it will appear as 4 CPUs to the OS? > >lG > > The degree to which it can be considered a 'new' core depends (as Io notedeH > > previously) on the nature of that multi-threading support.  EV7, forH > > example, doesn't really qualify as a 'new' Alpha core, despite minor > > changes. > >n > C > But EV7 doesn't support multi-threading and as we know EV7's core 	 > is EV6.   J And Montecito's core appears to be McKinley's, either untouched (i.e., toyF SMT was there all along, just as it was in early P4s) or only slightly changed.   ...   = > They certainly "didn't change their mind", they are playingh > cat and mouse.  K I know you consider faith to be a wonderful thing, Rob, but it's really not " very convincing to the rest of us.   >  Much like they did with P6.  K Not at all like they did with the P6.  The major surprises with P6 were itsoD costly MCM cache technology and the fact that it appeared not in theK expected 500 nm. process generation but in an early roll-out of the 350 nm. L generation, with clock speed to match.  Montecito, rather than introducing aI new process earlier than expected, slipped the expected process by a yearw5 (and moved the name to a new product in the bargain).      Montecito isn't-% > being redesigned on a weekly basis.2  K Exactly.  Montecito got scrapped, not redesigned.  And Chivano got renamed,e not redesigned.a   >o >P: > >   But Intel certainly wasn't/isn't going to let you inD > >> on the details and like many in the industry play cat and mouse > >> with the competition. > >rH > > The fact that Intel announced changes not only to Montecito's publicJ > > schedule (and had to rustle up an interim Madison product as a result) butsK > > to significant aspects of its design (number of cores, cache size) lastHL > > January suggests rather that Intel ran into problems - related to its 90 nm.eJ > > process (and indeed we're seeing some problems there right now, though theyH > > may be getting ironed out) and/or related to the products it felt it wouldwH > > need (e.g., HP's announced intention to create a dual-chip module in 2004E > > may have pointed out a need for a multi-core chip that it had not 
 foreseen). > >  > B > Not just schedule, but feature set.  We know now it is 4 logicalC > CPUs, contains multi-threading and has 24 MByte cache.  We didn'td > know that in January.2  H Of course not:  what you're describing is the Chivano product, and IntelE hadn't said much of *anything* officially about that product until itv  renamed it Montecito in January.   - bill   ------------------------------   Date: 22 Nov 2003 07:46:16 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday5 Message-ID: <DTiotGxQ0bj6-pn2-vXGqodOh4LGB@localhost>j  F On Thu, 20 Nov 2003 13:45:35 UTC, "John Smith" <a@nonymous.com> wrote:   > Dave Weatherall wrote:F > > On Wed, 19 Nov 2003 14:45:35 UTC, jlsue <jefflsxxxz@sbcglobal.net>
 > > wrote: > >o5 > >> On Wed, 19 Nov 2003 01:29:08 -0500, David Froblew! > >> <davef@tsoft-inc.com> wrote:e > >> > >>> John Smith wrote:g > >>>t > >>>> jlsue wrote:s > >>>> > >>>  > >>>eG > >>> You're real encouraging.  It's my fear also.  Just didn't need myh > >>> nose rubbed in it. > >>>  > >>I > >> I hope you noticed who wrote what in this stream and don't attributei# > >> those negative comments to me.b > > E > > It's the fact that it came from "John" that makes it depressing!!m >  > A > I don't know whether to thank you for that remark or apologize.l  ' There's certainly no need to apologise.t  K > I know that I continue to dwell on advertising/marketing issues, and from K > where I sit I just don't see the takeup of VMS systems with new customersgH > occuring  in numbers sufficient to even just offset the decline in theM > number of VMS systems being used by customers. So to use a swimming analog,aH > one can be swimming ahead, treading water, or drowning with respect toG > system sales. Without hard accurate numbers at my disposal I can only M > comment anecdotally based on my observations within the VMS customer base Ir& > know about, and I see only drowning.  E That's what frightening. We know you like/appreciate VMS and (would)  D like to offer/use it in your projects. When one gets the impression F that you don't trust the situation enough to take your customers along@ that road, well depression starts to set in. Especially since I @ suspect that your area of work is not dissimilar to Rob's 'real E world'. i.e. the commercial/finance one that VMS needs for its 'big' d income.r   -  Cheers - Dave.   ------------------------------  % Date: Sat, 22 Nov 2003 02:18:53 -0500i  From: John Santos <JOHN@egh.com>A Subject: Re: SYS$LIBRARY:TRACE_V74.EXE on VMS 7.3-1 causing errors5 Message-ID: <1031122015844.3301A-100000@Ives.egh.com>   * On Fri, 21 Nov 2003, Richard Brodie wrote:   > f > "John N." <JNixon@cfl.rr.com> wrote in message news:f5rvb.21524$86.410787@twister.tampabay.rr.com... > M > > Does anyone know where the logical get's created?  I believe it must have P > > been from some ECO we applied, but we have applied many ECOs and I don't whoO > > the culprit is.  If this is a required logical, I can force the developmente< > > group to change, but I need a reason to make them do so. > B > Earlier versions were defined by DEBUGSETUP, to allow you to runI > debuggers later than the bundled one. It would be in a kit like ADB074,i- > probably installed with a compiler upgrade.n  K As others have noted, it is defined in "SYS$STARTUP:DEBUG$STARTUP_V74.COM", H which is part of ADB074, an ECO kit we were shipped to correct a problemI with using the debugger to examine and modify fields in shareable images.e  H It hasn't shown up yet as an ECO in the regular place (itrc.hp.com) yet.  D I wonder if our problem will be fixed in V7.3-2?  (It worked fine inF V7.2-1 and all earlier versions, but broke when we upgraded to V7.3-1.( Don't know if V7.2-2 or V7.3 were okay.)  B I think there is a chain of issues here.  The ECO uses the logicalB name "TRACE" to replace the standard TRACE image with the one from= the ECO.  By redefining the logicals as process, job or group @ logicals (command file provided in the ECO), individual users or? processes can switch back and forth between the standard V7.3-1s? versions of TRACE (and DEBUG, etc.) and the "V74" versions.  Wet/ want to default to the V74 versions, so we haven&   $ @SYS$STARTUP:DEBUG$STARTUP_V74 V74 in our SYSTARTUP_VMS.COM file.  ? The next step in the chain is that the librarian honors logicaleA names for object files (as it should!) so if you have "TRACE.OBJ"3@ and you specify LIBRARY FOO TRACE, it will translate the logical> name.  $ LIBRARY FOO TRACE.OBJ should work fine.  Or you couldA define a process logical TRACE as TRACE.OBJ.  Or if you keep youro> .OBJ's in a [.OBJ] subdirectory or in an APP_OBJ directory (to- avoid polluting your default directory), theno   $ LIBRARY FOO [.OBJ]TRACE=  or=   $ LIBRARY FOO APP_OBJ:TRACE= should both work fine.  ? BTW, lots of other programs have the same problem.  For examplea8 if the source if TRACE.OBJ is TRACE.BAS or TRACE.C, then   $ BASIC TRACEe  and/orh   $ CC TRACE? both will try to compile sys$share:trace_v74.exe and will coughi up many many errors.  > Keeping your source files in a source directory and explicitlyA specifying that on the compilation command will solve the probleml? here, too.  For example, BASIC SRC:TRACE works fine (where SRC:e4 is a logical name pointing to the source directory.)  > In other words, good project management practices tend to make the problems disappear.n   -- i John Santose Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  + Date: Sat, 22 Nov 2003 11:28:31 +0000 (UTC)sP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TELNET/PORT$ Message-ID: <bpnh8u$gfl$1@online.de>  D In article <bpj85d$hq4$1@online.de>, helbig@astro.multiCLOTHESvax.de3 (Phillip Helbig---remove CLOTHES to reply) writes: -  3 > In article <3FBBE688.D4E6551@istop.com>, JF Mezei3& > <jfmezei.spamnot@istop.com> writes:  > N > > Which router allows you to remap a port to another port ? I'd like to have6 > > that. I have a Netgear RT314 and it won't do that. > G > It's a Linksys.  It's 500 km away right now and I don't remember the b@ > model number.  Email me Sunday if I haven't posted it by then.   The model is called BEFSR41.   ------------------------------    Date: 21 Nov 2003 23:04:40 -0800# From: dooleys@snowy.net.au (dooley)nY Subject: Re: Unable to stop FormFeed to DEC LA75, connected to a DEC 90m Server, using LP:= Message-ID: <1ca82fc6.0311212304.1a5fe86e@posting.google.com>o  Z sdavidson@uss.com wrote in message news:<caf27c79.0311210643.4a0ec2@posting.google.com>...E > We are unable to print just one line of text to a DEC LA75 printer, H > via LPR/LPD, connected to a DEC 90M terminal server (SW V2.2 for 90 M). > running on a DEC Alpha using OpenVMS V7.2-1. > E > Does anyone no how to stop the form feed to the printer so that the E > LA75 will just print a one line message and not form feed using thei > above equipment and software? B In cases like this I have found that the best option is to use the% telnet print symbiont instead of lpr.> Are you using tcpip services?d1 The documentation on telnet queues is quite good.e Advantages are -@ You can direct the output to a relay queue or direct to a device: There is a symbol telnetsym_suppress_formfeeds you can set and also one for raw_tcp: You can also get extensive debugging information using the symbol telnetsym_debug_flags Phil   ------------------------------  + Date: Sat, 22 Nov 2003 16:10:25 +0000 (UTC)tP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)) Subject: what protections does MAIL need? $ Message-ID: <bpo1pg$l50$1@online.de>  = I just encountered a problem sending VMS mail locally betweenhF non-priviledged users on my hobbyist cluster.  It was a problem with aB large message; smaller ones (probably small enough not to need an  external MAIL$* file) worked.f  8 For various reasons, the main mail files are of the form  *    DISK$USER:[USER_NAME.MAIL.MAIL]MAIL.MAI  G It appears that (RW,RW,,) is the proper protection for this file.  But nE what is the proper protection for DISK$USER:[USER_NAME.MAIL]MAIL.DIR,aE DISK$USER:[USER_NAME]MAIL.DIR and DISK$USER:[000000]USER_NAME.DIR so rH that MAIL will work properly?  Is (RW,RW,,) necessary and/or sufficient   here?  Where is this documented?  F It has always been possible for the user in question to receive large H files via SMTP mail.  I gave SYSTEM write permission on the directories G (but not the top-level one) and things now work.  Apparently, SMTP has o$ privs which the normal MAIL doesn't.   Is this documented somewhere?e   ------------------------------  % Date: Sat, 22 Nov 2003 09:22:39 +0100n* From: Paul Sture <nospam@sture.homeip.net>3 Subject: Re: [OT] Mac OS X: system folder not foundy0 Message-ID: <3FBF2ADF.6AC000BA@sture.homeip.net>   Roland Barmettler wrote: >  > Hello Paul > 8 > > Hi Roland, can you tell me where you got it, please?6 > > I haven't managed to locate a copy here in CH yet. > 2 > Believe it or not, in Mediamarkt (Dietikon) :-))H > I got it on the 25th of October where most Mac shops were already sold: > out, but Mediamarkt had still a whole shelf of Panthers. >   ( Ho, hum, got a "sold out" there too. :-(   -- s
 Paul Sture   ------------------------------   End of INFO-VAX 2003.648 ************************