1 INFO-VAX	Tue, 21 Sep 2004	Volume 2004 : Issue 525       Contents:> Re: 1920x1200 resolution with VMS and the HP L2335 LCD monitor% AlphaServer DS10L - IDE disk question $ Completed batch job still executing?( Re: Completed batch job still executing?1 Re: Finding who the DNS server (resolver library) 1 Re: Finding who the DNS server (resolver library)  Re: insufficient virtual memory  Mixed Cluster certification   Re: need quick EDT or TPU script Re: Off-the-wall CI Question Re: Off-the-wall CI Question Re: Off-the-wall CI Question Re: Off-the-wall CI Question Re: Off-the-wall CI Question Re: Off-the-wall CI Question Re: Off-the-wall CI Question" Re: OpenVMS: 4GL x Web Development" Re: OpenVMS: 4GL x Web Development) Re: OT: AMD opens new Boston design plant  Program to create users  Re: Program to create users  RMS and threads  Re: RMS and threads   Re: TCP/IP cluster interconnect?  Re: TCP/IP cluster interconnect?( Re: VAX 6000 replacement with CHARON-VAX Re: VMS on IBM's Itanium Re: VMS on IBM's Itanium5 Re: Windoze not rebooted monthly shuts down airports! 5 Re: Windoze not rebooted monthly shuts down airports! : Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions. [OT]: McNeally understands Re: [OT]: McNeally understands  F ----------------------------------------------------------------------  # Date: Tue, 21 Sep 2004 07:38:27 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu>G Subject: Re: 1920x1200 resolution with VMS and the HP L2335 LCD monitor - Message-ID: <TTQ3d.79494$MQ5.28149@attbi_s52>    Vance Haemmerle wrote:   (snip)  J > The Powerstorm 350 can do 24bit color at 1920x1200 at 60 and 75 Hz.  TheG > monitor says it can do 1920x1200 only at 60Hz, which is what I've set H > the card.  I was thinking that since both 1600x1200 and 1920x1200 haveJ > the same number of lines there must be something about the two standardsI > that differ so that the monitor can tell the difference.  Almost all of D > the other standards that it supports as presets: 640x480, 720x400,G > 800x600, 832x624, 1152x720, 1280x1024, 1600x1000 and 1680x1250 have a I > differing number of lines.  There is another set, 1024x768 and 1280x768 E > at 60Hz, in which it would have to tell the difference another way. G > Since the Powerstorm can't do the second of these, I can't test that.   C In analog tradition the monitor doesn't know anything about pixels, B but couples the signal through an amplifier to the cathode or grid on the CRT.   ? An LCD monitor has discrete pixels, unlike a CRT, and so had to E have some idea where they are.  As far as I know, when the horizontal F pixel count doesn't match the monitor, it interpolates from the signalA it gets, which results in fuzzy looking characters on the screen.    -- glen    ------------------------------  % Date: Tue, 21 Sep 2004 21:59:42 +1000 # From: "Gremlin" <not-here@all.mate> . Subject: AlphaServer DS10L - IDE disk question/ Message-ID: <415017ae$1@duster.adelaide.on.net>   L Can a AlphaServer DS10L use a large IDE drive - say 200Gb?  The manuals talkK about 30Gb drives, but perhaps they are old enough not to know about larger @ ones?  Has anyone configured a DS10L with a large drive for VMS?   TIA    ------------------------------    Date: 21 Sep 2004 08:09:29 -07000 From: chris@townleyc.demon.co.uk (Chris Townley)- Subject: Completed batch job still executing? < Message-ID: <93b50805.0409210709.9e8217f@posting.google.com>  E Had a few strange ones on a development AlphaServer 400 4/166 running  VMS 6.2   C Submitted my overnight build job - job log file says all completed, F shows the VMS job terminated, and output from LOGOUT/FULL. The process* is no longer visible fron SHOW SYSTEM etc.  8 However the batch queue show the job as still executing.  ? If I delete the entry it moves to aborting, and stays there - a  further delet/entry returns ( %DELETE-E-NOTDELETED, error deleting 104C -JBC-E-INCOMPLETE, previous incomplete operation prevents execution + so I have to use stop/queue/reset to clear.   D This was happening a few weeks ago, so I shutdown the queue manager,D and restarted with the NEW_VERSION qualifier. All OK for a few days, then twice again.   
 Any ideas?   --  
 Chris Townley  chris.townley@spicers.net    ------------------------------  + Date: Tue, 21 Sep 2004 16:28:18 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)1 Subject: Re: Completed batch job still executing? 1 Message-ID: <newscache$j1ge4i$1g41$1@news.sil.at>   o In article <93b50805.0409210709.9e8217f@posting.google.com>, chris@townleyc.demon.co.uk (Chris Townley) writes: N >Had a few strange ones on a development AlphaServer 400 4/166 running VMS 6.2 >  >Any ideas?   & Upgrade to a more recent VMS version ? Install all qman related ECOs ?    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Mon, 20 Sep 2004 23:21:45 -0700  From: Z <z@no.spam> : Subject: Re: Finding who the DNS server (resolver library)0 Message-ID: <10kvi3ddavvteb5@corp.supernews.com>   JF Mezei wrote: O > In order to emulate the finctionlaity of NSLOOKUP, one must find out the host H > anme of the DNS server serving the host the application is running on. ... O > However, since there can be multiple servers used by the resolver, I *ASSUME* R > that one could potentially find TCPIP$BIND_SERVER001 002 etc.  Is this correct ? > P > Must the logical point to a dotted decimal address or could one expect a fullyX > qualified host name ? (which might get resolved in the local hosts file for instance). > M > Also, if mutiple servers are available, do the logicals remain the same, or P > does the system rotate them to do load balancing amongst the various servers ? > I > Is there some recommended logic to scan and choose one of the available  > servers ?   E Why not use $TCPIP SHOW NAME_SERVICE and look at the "Servers:" list?    ------------------------------  % Date: Tue, 21 Sep 2004 02:49:37 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> : Subject: Re: Finding who the DNS server (resolver library), Message-ID: <414FCEF5.C99DEF63@teksavvy.com>   Z wrote:G > Why not use $TCPIP SHOW NAME_SERVICE and look at the "Servers:" list?   N Because there are no callable routines to get that info from inside a program.   ------------------------------    Date: 21 Sep 2004 02:48:16 -07000 From: chris_doran@postmaster.co.uk (Chris Doran)( Subject: Re: insufficient virtual memory= Message-ID: <948f0720.0409210148.5e3a70ed@posting.google.com>   d John F <john@SeeSigForAddress.invalid.com> wrote in message news:<cila1v$pkf$1@reader1.panix.com>...3 > Chris Doran <chris_doran@postmaster.co.uk> wrote: ; > : John Forkosh <john@SeeSigForAddress.invalid.com> wrote:  > : >... I've reproduced< > : > the code along with a test driver below, and I've also- > : > left a copy at www.forkosh.com/md5str.c  > : > $ > : > I originally got the code from3 > : >      http://www.cr0.net:8040/code/crypto/md5/ : > : > and I'd guess it's all the #undef's and re-#define's? > : > of F that's somehow causing decc grief.  Try it yourself. # > : > It should _easily_ compile as " > : >      cc/define=TEST md5str.c, > : > But that sends my VS4K/90 into a loop. >   G > : Hmmm, no problem here, but I have an earlier VMS (6.2) and probably E > : DECC (5.2-003). I tried it on VAX-3100/40 and Alpha-3000/600 with + > : PGFLQUOTA 100,000 (Alpha); 60,000 (VAX) 0 > : VIRTUALPAGECNT 800,000 (Alpha); 73,536 (VAX) > : I > : Starting from the file at forkosh.com which I httped to W2K and FTPed F > : to VMS, I had to SET FILE/ATT=RFM:STMLF otherwise I got an EXQUOTAI > : when I tried to TYPE or EDT the file. C didn't EXQUOTA, but generated @ > : a rubbish object file which turned out to be due to two junkE > : characters at the very start of the file. After removing these it E > : compiled in seconds and ran OK, though I got different numbers to 1 > : yours, probably due to messing with the file.  > C > I usually ftp zip files to and from other systems.  Then unzip -a 7 > seems to handle vms text file attributes pretty well.   ? Sure, I just threw in that paragraph in case it was part of the  problem.  I > : The only case I can remember C running out of quota and/or hanging is E > : when you do something silly like a recursive #define, though it's H > : obviously not that simple here. CC/PREPROCESS_ONLY, ctrl/C, and look= > : at the .i file might help you if it's got hung like that.  > : I > : The brute force method on problems like this is to keep removing bits H > : of code until the problem goes away, then stare at the line(s) which > : make it come back. > :  > : I hope this helps a bit.	 > : Chris  > B > Thanks, Chris.  I basically tried the brute force method.  FirstB > I put an #if 0...#endif around all the P() macro invocations andA > re-#define's if F() in md5_process() to confirm the problem was > > related to that.  And, sure enough, it compiled immediately.A >      Then I got rid of the re-#define's by #define'ing separate H > F1()...F4() and corresponding P1()...P4(), and replacing all the P()'sI > with the appropriate P1()...P4().  But I guess I was too smug about it, ) > because the compiler continued to hang. I >      So I manually expanded the F()'s and S()'s in the P()'s to get rid F > of any possible preprocessor confusion.  Still no luck, which struckA > me as very odd, since by this point the P() macros looked quite ' > straightforward if a bit complicated. B >      Out of frustration, I tried leaving a single P() invocationH > in the compiler's sight, hiding all the others between #if 0...#endif.K > Very oddly, _that_ compiled fine.  Two, three P()'s continued to compile, G > but the compile time started to increase exponentially (or maybe even 3 > combinatorially faster) after six or seven P()'s. E >      The next step, I suppose, would be to simplify the expressions C > defining the P()'s to see if the problem could be better isolated C > and identified.  But I was running out of time, and my "fiduciary C > responsibility" vis-a-vis this thing was to get it working.  So I B > just turned the macros into functions, and that compiled and ranA > correctly right away.  I've left that final vax-friendly source C > at www.forkosh.com/md5vax.c in case you or anybody else wants it.   F Assuming the compiler in-lines your functions, or can be persuaded to,1 you've achieved the same effect as macros anyway.   F What compiler version has this problem? I'm stuck in the doldrums of CF and VMS versions which were already old when my employer abandoned VMSD for inferior systems in case I need to support a customer who hasn'tA downgraded. In this instance it looks as if this is just as well!    Chris    ------------------------------  + Date: Tue, 21 Sep 2004 17:43:37 +0000 (UTC) . From: "Robert H" <robert.heyes@btinternet.com>$ Subject: Mixed Cluster certification2 Message-ID: <cipp89$hb0$1@hercules.btinternet.com>  K Can anyone direct me to a document which highlights what is possible for a  ' mixed cluster, or tell me if they know.   L I am looking at upgrading one of our core systems but I cannot upgrade that K Alpha due to other software restrictions so I'm looking at getting another  L Alpha, which would be at the bare bones be 7.3 while my existing cluster is M 7.2-1. I am guessing I would be safe clustering 7.2-1 with a 7.3 machine but  K anything above 7.3 would not be certified...? Ideally I would love to take  @ the new machine to 7.3-2 but I dont think this will be possible.   TVM, Rob    ------------------------------    Date: 21 Sep 2004 05:40:23 -07004 From: john.powers@airwidesolutions.com (John Powers)) Subject: Re: need quick EDT or TPU script = Message-ID: <6e87f23f.0409210440.5456c832@posting.google.com>   @ My info-vax connection seems very slow, and several people have ? already replied here, but I notice a problem with lots of these  replies, so I'm adding my 2cw.  & helbig@astro.multiCLOTHESvax.de wrote:  
 >Hi folks, >  > F >I have some text files which, when looked at in EDT, have an explicit >  >      >  > I >(that's GOLD 13 GOLD KP3) at the end of each line.  The attributes look  I >the same as a proper text file, so SET FILE/ATTR (or CONV/FDL) probably  G >wouldn't work.  Also, the old TECO trick doesn't work either (I think  - >this gets rid of carriage return-line feed).  > G >In EDT, I can do KP. <RETURN> KP6 PF1 PF3 <RETURN> <RETURN> and every  6 >time I hit PF1 KP<ENTER> then one line gets replaced. > H >Is there any way to automate this in EDT or TPU (i.e. what I need is a I >DCL procedure which takes a list of file names to correct as its single   >input parameter). > I >I'm reasonably sure EDT or TPU or FORTRAN or DCL could do this, but I'm   >really in a hurry.  >   G Lots of replies suggest globally replacing/removing the <CR> character. G However in your email you explicitly say that you want to remove the CR E characters at the end of line. A global remove will kill any ascii 13 6 characters that may be correctly in place in the file.  E Some time back I had a similar problem with some text files that went E through a poorly written C-program so that lots of lines had unwanted F null characters (ascii 0) at end of line, so I wrote the following bitE of TPU. I have replaced in the code the term ascii(0) with ascii (13)  and it does what you want. HTH.   G I also prefer to use the file_search command inside TPU to loop through G the files, as this seems more efficient than using F$search in DCL, and 1 repeatedly activating the TPU image for each one.   G Note that I wrote this in a rush, so it is a pretty bare-bones piece of E code, with no error-checking for write-privilege, or spare disk space E availability. If there are problems, it just falls in an untidy heap. 2 You are welcome to add some ON_ERROR coding. ICBB.   Cheers, John   tpu code follows..   To use it you need to ( $ DEFINE /USER FILE_LIST <wildcard_spec>- $ EDIT /TPU /NODISPLAY /COMMAND=killwild.tpu     and here is KILLWILD.TPU   ! killwild.tpu  H procedure eve_kill_end_nulls    !  Remove null characters at end of line  5 local found_range;      ! Position where we found one    loop6   found_range := search_quietly (ascii(13) & line_end,)                                  forward, *                                  no_exact,1                                  current_buffer);    exitif (found_range = 0);    position (found_range);    erase_character (1); endloop;  
 endprocedure;   , local the_wildcard_spec, ! The wildcard spec:       the_file;          ! filespec for each matching file  / the_wildcard_spec := file_parse ("FILE_LIST:"); = if file_parse (the_wildcard_spec,"","",DEVICE) = "FILE_LIST:"  then<   message ("Logical name FILE_LIST has not been defined!!");   quit (0,off);  endif;   the_file := file_search(""); loop-   the_file := file_search(the_wildcard_spec);    exitif the_file = ""; 3   the_buffer := create_buffer ("IN_BUFF",the_file);    position (the_buffer);   eve_kill_end_nulls;    write_file (the_buffer);   delete (the_buffer); endloop;  
 quit (1,off);    ------------------------------  # Date: Tue, 21 Sep 2004 12:50:27 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net>% Subject: Re: Off-the-wall CI Question 4 Message-ID: <4150239C.4090603@TrashThis.comcast.net>   David J Dachtera wrote:   G > I realize that's semantically ambiguous. Both might apply: an off-the G > wall question about CI or a question about an off-the-wall CI idea...  >  > Here's my problem: > I > For various reasons, I need to move some gear out of sequence, and with < > an elevated urgency. That means I need to BS a CI somehow. > F > Ideally, I'd want a star-coupler and enough CI cables to do the job.E > However, dollars, time and space are all in extremely short supply.  > B > So, I want to know if this has "a snowflake's chance in hell" ofF > working: I want to try connecting a CIPCA directly to an HSJ with noI > intervening Star Coupler: that is, the TX of both channels go to the RX , > ports of the other device, and vice-versa. > H > *VERY* unsupported, I'm sure - but might it work long enough to get meH > by (eight or ten weeks) until the SAN issues can be resolved and I can > scrap the mickey-mouse bit?  > ) > Comments? Commendations? Condemnations?  >  > D.J.D.  J I don't think so.  The star coupler serves to reduce the signal amplitude;L without it, I suspect the raw transmit signal may swamp the receiver.  Also,G the transformer in the star coupler serves to DC-isolate the end nodes,  which could be a problem.  --   Cheers, Bob    ------------------------------  # Date: Tue, 21 Sep 2004 12:51:04 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net>% Subject: Re: Off-the-wall CI Question 4 Message-ID: <415023C0.5060600@TrashThis.comcast.net>   David J Dachtera wrote:   G > I realize that's semantically ambiguous. Both might apply: an off-the G > wall question about CI or a question about an off-the-wall CI idea...  >  > Here's my problem: > I > For various reasons, I need to move some gear out of sequence, and with < > an elevated urgency. That means I need to BS a CI somehow. > F > Ideally, I'd want a star-coupler and enough CI cables to do the job.E > However, dollars, time and space are all in extremely short supply.  > B > So, I want to know if this has "a snowflake's chance in hell" ofF > working: I want to try connecting a CIPCA directly to an HSJ with noI > intervening Star Coupler: that is, the TX of both channels go to the RX , > ports of the other device, and vice-versa. > H > *VERY* unsupported, I'm sure - but might it work long enough to get meH > by (eight or ten weeks) until the SAN issues can be resolved and I can > scrap the mickey-mouse bit?  > ) > Comments? Commendations? Condemnations?  >  > D.J.D.  J I don't think so.  The star coupler serves to reduce the signal amplitude;L without it, I suspect the raw transmit signal may swamp the receiver.  Also,G the transformer in the star coupler serves to DC-isolate the end nodes,  which could be a problem.  --   Cheers, Bob    ------------------------------  # Date: Tue, 21 Sep 2004 12:52:04 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net>% Subject: Re: Off-the-wall CI Question 4 Message-ID: <415023FC.9090801@TrashThis.comcast.net>   David J Dachtera wrote:   G > I realize that's semantically ambiguous. Both might apply: an off-the G > wall question about CI or a question about an off-the-wall CI idea...  >  > Here's my problem: > I > For various reasons, I need to move some gear out of sequence, and with < > an elevated urgency. That means I need to BS a CI somehow. > F > Ideally, I'd want a star-coupler and enough CI cables to do the job.E > However, dollars, time and space are all in extremely short supply.  > B > So, I want to know if this has "a snowflake's chance in hell" ofF > working: I want to try connecting a CIPCA directly to an HSJ with noI > intervening Star Coupler: that is, the TX of both channels go to the RX , > ports of the other device, and vice-versa. > H > *VERY* unsupported, I'm sure - but might it work long enough to get meH > by (eight or ten weeks) until the SAN issues can be resolved and I can > scrap the mickey-mouse bit?  > ) > Comments? Commendations? Condemnations?  >  > D.J.D.  J I don't think so.  The star coupler serves to reduce the signal amplitude;L without it, I suspect the raw transmit signal may swamp the receiver.  Also,G the transformer in the star coupler serves to DC-isolate the end nodes,  which could be a problem.  --   Cheers, Bob    ------------------------------  # Date: Tue, 21 Sep 2004 12:51:54 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net>% Subject: Re: Off-the-wall CI Question 4 Message-ID: <415023F3.7080902@TrashThis.comcast.net>   David J Dachtera wrote:   G > I realize that's semantically ambiguous. Both might apply: an off-the G > wall question about CI or a question about an off-the-wall CI idea...  >  > Here's my problem: > I > For various reasons, I need to move some gear out of sequence, and with < > an elevated urgency. That means I need to BS a CI somehow. > F > Ideally, I'd want a star-coupler and enough CI cables to do the job.E > However, dollars, time and space are all in extremely short supply.  > B > So, I want to know if this has "a snowflake's chance in hell" ofF > working: I want to try connecting a CIPCA directly to an HSJ with noI > intervening Star Coupler: that is, the TX of both channels go to the RX , > ports of the other device, and vice-versa. > H > *VERY* unsupported, I'm sure - but might it work long enough to get meH > by (eight or ten weeks) until the SAN issues can be resolved and I can > scrap the mickey-mouse bit?  > ) > Comments? Commendations? Condemnations?  >  > D.J.D.  J I don't think so.  The star coupler serves to reduce the signal amplitude;L without it, I suspect the raw transmit signal may swamp the receiver.  Also,G the transformer in the star coupler serves to DC-isolate the end nodes,  which could be a problem.  --   Cheers, Bob    ------------------------------  # Date: Tue, 21 Sep 2004 12:52:39 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net>% Subject: Re: Off-the-wall CI Question - Message-ID: <ruV3d.233328$mD.60503@attbi_s02>    David J Dachtera wrote:   G > I realize that's semantically ambiguous. Both might apply: an off-the G > wall question about CI or a question about an off-the-wall CI idea...  >  > Here's my problem: > I > For various reasons, I need to move some gear out of sequence, and with < > an elevated urgency. That means I need to BS a CI somehow. > F > Ideally, I'd want a star-coupler and enough CI cables to do the job.E > However, dollars, time and space are all in extremely short supply.  > B > So, I want to know if this has "a snowflake's chance in hell" ofF > working: I want to try connecting a CIPCA directly to an HSJ with noI > intervening Star Coupler: that is, the TX of both channels go to the RX , > ports of the other device, and vice-versa. > H > *VERY* unsupported, I'm sure - but might it work long enough to get meH > by (eight or ten weeks) until the SAN issues can be resolved and I can > scrap the mickey-mouse bit?  > ) > Comments? Commendations? Condemnations?  >  > D.J.D.  J I don't think so.  The star coupler serves to reduce the signal amplitude;L without it, I suspect the raw transmit signal may swamp the receiver.  Also,G the transformer in the star coupler serves to DC-isolate the end nodes,  which could be a problem.  --   Cheers, Bob    ------------------------------  # Date: Tue, 21 Sep 2004 13:50:11 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> % Subject: Re: Off-the-wall CI Question 3 Message-ID: <nkW3d.11290$tH4.5267@news.cpqcorp.net>    David J Dachtera wrote: = > I want to try connecting a CIPCA directly to an HSJ with no I > intervening Star Coupler: that is, the TX of both channels go to the RX , > ports of the other device, and vice-versa.  ? Bob is right: this overdrives the receivers and is unsupported.   H Now that Fast_Path for PEDRIVER and LANs is available (avoiding Primary F CPU saturation in interrupt state on SMP boxes that was alleviated in B the past by using Fast_Path on CI, which has been available since H version 7.1), and host-based mini-merge, the last technical hurdles I'm H aware of in moving off of CI seem to have been overcome, and most folks ? who used CI before can now go to Gigabit Ethernet as a cluster  + interconnect and Fibre Channel for storage.   F I'm sure this is freeing up CI hardware all over the country. I see a I star coupler on eBay right now for $300. I suspect you could call around  G and find any number of customers in the Chicago area who have old star  : couplers and cables they would probably lend you for free.  F Alternatively, could you MSCP-serve the storage during the transition?   ------------------------------  # Date: Tue, 21 Sep 2004 16:15:05 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net>% Subject: Re: Off-the-wall CI Question + Message-ID: <csY3d.21407$wV.6657@attbi_s54>   J My apologies to all for sending that reply several times.  My SMTP server H bounced the first reply because of a bad copy (BCC) address, and I triedL to resend without realizing that the reply had gone to the NG but not to the BCC addresses. --   Cheers, Bob    ------------------------------   Date: 21 Sep 2004 07:21:33 GMT+ From: "Doc." <doc.cypher@openvms-rocks.com> + Subject: Re: OpenVMS: 4GL x Web Development 7 Message-ID: <Xns956B5F69B4E30dcovmsrox@212.100.160.123>   & %NEWS-I-NEWMSG, Fabio Cardoso wrote in5 news:f30679fb.0409201635.79228a36@posting.google.com    A > We have one specifc system under Gembase - old version - but no G > dedicated developer anymore. But we have other legacy databases (RDB) B > that we would like fast development to manage/query it. Just it.  L Well, Gembase is pretty easy to pick up, and you can get existing databases H mapped onto it.  I don't think Ross's support of VMS will be going away I anytime soon, they've a significant number of clients using VMS and they  L use it as their development environment because there's simply nothing that J beats CMS.  Gembase was originally developed on VMS and that shows in the 	 language.   J Latest versions of Gembase support a web interface via Internet Explorer, 5 so clients don't have to use terminal or thin client.      Doc. --  G OpenVMS:     Eight out of ten hackers prefer *other* operating systems. G http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.    ------------------------------  % Date: Tue, 21 Sep 2004 18:45:46 +0200 * From: Paul Sture <nospam@sture.homeip.net>+ Subject: Re: OpenVMS: 4GL x Web Development + Message-ID: <2rb45qF1829sqU1@uni-berlin.de>    Bob Ceculski wrote: u > fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in message news:<f30679fb.0409200831.33a1f2f4@posting.google.com>...  > 0 >>Do you know what is the most used 4GL language2 >>under OpenVMS ? Gembase, PowerHouse, Rally etc ?@ >>Does it still a good option for development (Term/Thin client)7 >>or would be better to develop Web-based applications?  >>	 >>Regards  >> >>FC >  > 2 > synergy DBL (DIBOL) has a very good 4gl feel and. > development tools for it, and it also can be. > developed as a fat or thin client app with a" > backend to OpenVMS databases ...  & Is there a Hobbyist version available?   ------------------------------    Date: 21 Sep 2004 01:17:37 -0700' From: icerq4a@spray.se (David Svensson) 2 Subject: Re: OT: AMD opens new Boston design plant= Message-ID: <734da31c.0409210017.18879ac3@posting.google.com>   a JF Mezei <jfmezei.spamnot@teksavvy.com> wrote in message news:<414F5557.4D14D800@teksavvy.com>... ! > Found an interesting tidbit at: c > > http://news.com.com/Critical+Mass.+for+AMDs+chip+designs/2100-1006_3-5371721.html?tag=nefd.lede  >  > ##O > The bulk of the new team, about 60 design engineers out of a total of 90, was M > already in the neighborhood--they were stationed at a nearby outpost of Sun K > Microsystems. The engineers, who came on board en masse in July, had been J > working on new processors for Sun, before the computer maker shifted itsO > processor design strategy and canceled two projects, including its UltraSparc G > V. Many of the designers also had worked on Digital Equipment's Alpha J > processor at one time or another, considered a good pedigree in the chip	 > world.   > ## > N > So, this begs the question: how many ex Alpha designers are still at Intel ?N > Seems that even Sun had stolen enough to open facilities in the Boston area.  . This is what Paul Demone says about it at RWT.  7 "When Compaq killed the EV8 project Intel picked up the 4 EV8 and Alpha compiler teams nearly intact, over 2005 people IIRC. The remaining Alpha engineers working on 4 EV7 and EV79 for HP, numbering close to 200, were to5 be offered employment at Intel under similar terms as 5 the first group as their Alpha work was completed and 6 AFAIK most did go to Intel. The Intel Tukwila IPF team, is effectively the former Alpha design team.  5 In comparison the number of Alpha engineers that have 0 gone to AMD and Sun (many subsequently left BTW)  over the years is much smaller."   ------------------------------    Date: 21 Sep 2004 05:58:51 -0700) From: javiercoego@yahoo.es (Javier Coego)   Subject: Program to create users= Message-ID: <17d2ba72.0409210458.3ecc7b4d@posting.google.com>    - Hi, everyone. -   ? - I need to create a program in C/C++ language which performs a D massive user creation. - These users are supplied via a text file. -  E - Has anyone tried to write a similar program? - I've taken a look to F pwd.h functions, but all of them only allow to GET user information. -  8 - This program could be also written in DCL, perl, ... -   - Thanks in advance. -   - Kind regards. -    Javi   ------------------------------  % Date: Tue, 21 Sep 2004 14:11:37 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> $ Subject: Re: Program to create users+ Message-ID: <2ranpbF172ekgU1@uni-berlin.de>    Javier Coego wrote:  > - Hi, everyone. -  > A > - I need to create a program in C/C++ language which performs a F > massive user creation. - These users are supplied via a text file. - > G > - Has anyone tried to write a similar program? - I've taken a look to H > pwd.h functions, but all of them only allow to GET user information. - > : > - This program could be also written in DCL, perl, ... -  < What's wrong with the standard program that comes with every. VMS system ?  The program is called AUTHORIZE.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------    Date: 21 Sep 2004 04:43:52 -0700$ From: "SteveL" <infovax@hotmail.com> Subject: RMS and threadsB Message-ID: <1095767032.531018.60110@k17g2000odb.googlegroups.com>  	 Hi folks,   D I've Googled, digested what I found, Googled some more, and am stillE not convinced that I fully understand a performance problem that I've  observed....  C I'm using DEC C V6.0-001 under OpenVMS 7.3-1, with 2 physical CPUs. @ I've also run my test harness on a 4 CPU system and made similar
 observations.   E I have a test harness which creates multiple threads, and each thread D is responsible for writing to a file.  Each thread has its own file.  D I've dutifully compiled and linked the test harness with the correctA flags (/reent=multi, /threads_enable=(multi, upcall)).  I've also A linked /sysexe to resolve my access to the high resolution clock.    I've observed the following:  D 1.  If I have the main thread create all of the threads and the justG block waiting for all threads to terminate (pthread_join), letting each C thread write records autonomously, it's "fast" (c. 7 seconds for my  specific test case).  F 2.  If I change that to represent a more realistic scenario, where theG master thread co-ordinates the work, it's "slow" (c. 10 seconds).  I'll : expand on what I mean by co-ordinating in a just a moment.  A 3.  If I change the $PUTs to $GETs, it's fast (c. 6 seconds in my G baseline test).  Even with the master thread co-ordinating the threads. 9 Ergo, the co-ordination itself isn't the limiting factor.   F 4.  If I dummy out the $PUT/$GET entirely, so that each thread wake-upD only increments a longword before going back to sleep, it's fast (c.F 1.5 seconds).  Again, this is with the master thread co-ordinating the worker threads.   E In all cases, I don't appear to be resource constrained - the DIO and 1 CPU rates are both below maximum observed limits.   E The co-ordination is intended to work as follows (it's pretty basic):   F There an "idle count" global, protected by a mutex and associated withF a condition variable.  When work is handed off to a worker thread, the/ idle count is decremented by the master thread.   F As threads return to their idle state, they increment this idle count.B When a thread notices that ALL threads are now idle, the condition variable is signalled.  4 The master thread blocks on this condition variable.  G The worker thread wake-up mechanism is, again, pretty basic.  There's a G condition variable/mutex pair associated with each thread.  The threads D block on their own condition variable, and the master thread signalsD that condition variable when it wants the thread to write a batch of records.   So:s  F - RMS itself isn't particularly slow when used with threads.  In fact,C there are some real gains to be had in my specific case.  I can seec: this from my first test, where each thread is independent.  G - The cross-thread co-ordination isn't inherently slow.  I can see thish: from my "do nothing" test, and infer it from my $GET test.  D However... when I stick the two together (master thread co-ordinates 'n' writer threads), it's slow!   ? If anyone can offer any suggestions (possible insights into the-8 scheduling algorithm, for example) I'd be most grateful.  ? I'm happy to post my 500+ line test harness if anybody's *that*x interested... ;)   Many thanks, SteveL.v   ------------------------------  % Date: Tue, 21 Sep 2004 10:59:53 -0400r( From: "Hein" <hein.nomail@hp.nomail.com> Subject: Re: RMS and threads* Message-ID: <41504288@usenet01.boi.hp.com>  / "SteveL" <infovax@hotmail.com> wrote in messagew< news:1095767032.531018.60110@k17g2000odb.googlegroups.com... > Hi folks,d >   F > 1.  If I have the main thread create all of the threads and the justI > block waiting for all threads to terminate (pthread_join), letting eachoE > thread write records autonomously, it's "fast" (c. 7 seconds for mye > specific test case). > H > 2.  If I change that to represent a more realistic scenario, where theI > master thread co-ordinates the work, it's "slow" (c. 10 seconds).  I'll < > expand on what I mean by co-ordinating in a just a moment.  * Hmm, I find your result entirely expected.9 With the autonomous threads 'works' goes on concurrently,j8 when you use the master to control, all overlap is gone.G This should be more pronounced when disk IO is involved (The $PUT case)e   Hein.:   ------------------------------    Date: 21 Sep 2004 07:50:32 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)t) Subject: Re: TCP/IP cluster interconnect? 3 Message-ID: <t8nXNBNSQamL@eisner.encompasserve.org>0  ` In article <414F7DF7.C54A6E94@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: > J > Well, yes and no. SCS pre-dates the seven-layer model, and was a productC > separate from VMS until it was more intimately integrated and not  > installed spearately.   C    TCP/IP and DECnet Phase I through IV all predate the seven-layerhH    model.  IIRC TCP/IP has four laters and DECnet on VMS has 6 (at leastD    when using FAL), but other DECnet components and DECnet on other F    systems typically has 7.  And DECnet was a separate product before     VMS 3.0.h  @    I believe SCS was latent in some versions of VMS prior to itsC    official first ship, but I don't recall it ever being separatelys    installable.n  C    VMScluster is a technology that networks VMS kernels to create aeC    single tighly bound domain, a very different approach from otherf7    "clusters" or networks, but a network none the less.h   ------------------------------    Date: 21 Sep 2004 09:11:47 -0500 From: briggs@encompasserve.org) Subject: Re: TCP/IP cluster interconnect?a3 Message-ID: <Zagqt6vzi5FI@eisner.encompasserve.org>   ` In article <414F7DF7.C54A6E94@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes:D > The idea of a an SCS <-> TCP/IP gateway has also been "floated" inF > various threads. Again, the latency and possibility (probability) ofH > packet loss would introduce some challenging issues, to say the least,C > and probably introduce many more problems than it seeks to solve.(  G I don't think a sane person would use an SCS <-> TCP/IP gateway.  You'd B want SCS <-> IP or SCS <-> UDP.  I'll assume that's what you mean.  C Latency, of course, is not an issue that is peculiar to IP.  If youmC have a multi-hop delivery path you're going to have per-hop latencyw@ (barring cut-through switching anyway).  If you have congestion,D you'll have queueing latency (or packet loss, pick your poison).  If@ you have long distances, you'll have speed-of-light latency.  ItD doesn't matter in principle whether the delivery path is IP, DECnet, switched Ethernet or ATM.e  @ Packet loss is also not peculiar to IP.  It is a function of theA communications link and, in some cases, the result of congestion.w  A Objections to an SCS <=> IP gateway should, accordingly, be aimede@ at the connectivity underlying the IP network rather than at IP.  D An IP link from point A to point B with 10 ms latency and negligibleE packet loss should be just as useful as a switched Ethernet link from1A point A to point B with 10 ms latency and negligible packet loss.G  > While I wouldn't be happy clustering over the Internet, I'd be5 perfectly happy to cluster over IP over ATM over DS3.t   	John Briggs   ------------------------------  % Date: Tue, 21 Sep 2004 15:15:49 +0200w0 From: Keith Cayemberg <keith.cayemberg@arcor.de>1 Subject: Re: VAX 6000 replacement with CHARON-VAXAB Message-ID: <41502985$0$18550$9b4e6d93@newsread2.arcor-online.net>   Bob Koehler wrote:^ > In article <414C8669.DC539BFF@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > L >>Which is why I could take my all mighty microvax II's system disk, plug itP >>into a 6000 and boot. Sire, some device names would change (ethernet, serial),H >>but wouldn't the rest work fine ? (assuming proper licences of course) >> >  > J >    It depends on the version of VMS.  There are older versions that willE >    boot on an MV II and not on a 6000.   Then it depends on memory,oG >    pagefile, and swapfile.  I'm not sure a lot of 6000 were sold with E >    only 16MB.  You might get all hung up with a severly out of tuneS >    memory management system. >  > J >>But since wintel or alpha do not have q-bus, then it is a given that theN >>emulator can only "fake" a limited number of q-bus devices because each must >>be coded into the emulator.  >  > E >    I've seen Alpha with Qbus adapters, and vendors of Qbus adapterslL >    for Wintel.  And I've seen Qbus based systems with 68K chips in them.  0 >    Qbus may show up where you least expect it. >   I And the Logical Company is selling them. Their PCI to Q-Bus adapters for eE Alpha and Pentium platforms can be used by CHARON-VAX, CHARON-11 and r
 Ersatz-11.( http://www.logical-co.com/Pci/genpci.htm( http://www.logical-co.com/Qbus/q-bus.htm   Cheers!e   Keith Cayembergy   ------------------------------    Date: 21 Sep 2004 07:59:56 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: VMS on IBM's Itaniumd3 Message-ID: <mvUU4HJ40p9o@eisner.encompasserve.org>o  j In article <ZOD3d.11171$AK3.1473@news.cpqcorp.net>, "Fred Kleinsorge" <fred.nospam@nospam.dec.com> writes: > K > We aren't Windows.  We don't have the infrastructure set up to run on any:J > platform that meets specific requirements (or rather, the platform wouldL > have to effectively meet HP requirements today).  We are a part of HP, andM > we are in business to sell HP hardware, software and services - so while weeN > are not actively doing anything that would stop it from working, we are alsoM > not actively making sure it will work either.  Our customer base in generalvN > won't use unsupported hardware in production.  Finally, when you look at theL > Itanium hardware being sold by others, there is no compelling advantage to > not use the HP hardware.  A    Which means HP is potentially making the same mistake KO made,gF    thinking he was manufacturing computers instead of realizing he was    selling terrific software.   G    While the above plan is certainly easy to justify as a business casebD    and for the initial deployments (early MS-DOS on ran on IBM PC's,H    that's all there was until Compaq cloned the hardware so closely that;    MS-DOS would run), it is not a sound long term strategy.6  B    I propose VMS 9.0 have as a goal support on at least 3 vendor'sD    platforms.  Then HP will have learned how to make money like Bill    Gates makes money.    ------------------------------    Date: 21 Sep 2004 08:00:38 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)w! Subject: Re: VMS on IBM's Itaniums3 Message-ID: <iKDWccYMfFiY@eisner.encompasserve.org>l  n In article <f30679fb.0409201004.7791bb9d@posting.google.com>, fabiopenvms@yahoo.com.br (Fabio Cardoso) writes: > @ > I am being migrated from VMS to the Linux team in a few weeks.' > The company will run Linux/Mainframe.b      Our condolences.u   ------------------------------    Date: 21 Sep 2004 07:54:28 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > Subject: Re: Windoze not rebooted monthly shuts down airports!3 Message-ID: <5NXF4e+SI5L+@eisner.encompasserve.org>m  ^ In article <3uC3d.2$B7.1146@news.uswest.net>, "Michael D. Ober" <mdo.@.wakeassoc..com> writes:G > Running the US Air Traffic Control system on Windows 95, 98, or ME isoH > criminal!  Windows NT, 2000, XP, and 2003 don't have this bug.  As forJ > running on Windows vs. VMS, that's a different story - the FAA has neverN > used VMS.  It used to use IBM iron as this system predates VMS.  This sounds* > like another case of VMS (non)marketing.  J    Techies who were working on IBM's (later canceled) 1980's FAA contract H    tell me they spent a lot of time trying to emulate VMS paradigms.  AnH    understanding of the problem showed that what they really needed was D    the world's largest VMScluster, much larger geographically and in8    number of nodes than VMScluster supports, even today.   ------------------------------  % Date: Tue, 21 Sep 2004 10:33:51 -0400 < From: "Peter Weaver" <WeaverConsultingServices@sympatico.ca>> Subject: Re: Windoze not rebooted monthly shuts down airports!+ Message-ID: <2rasehF181i91U1@uni-berlin.de>y   John Smith wrote:a >...G > As I recall, most of the traffic over the western North Atlantic (ie.sB > just about anything that flies a northerly great circle route toE > Europe from North America), is handled by Nav Canada out of Gander,t9 > Newfoundland. That ATC system, I believe, is VMS-based.   2 Still VAX/VMS based last I heard about a year ago.   -- r Peter Weaver Weaver Consulting Services Inc.i Canadian VAR for CHARON-VAXe www.weaverconsulting.cau   ------------------------------  % Date: Tue, 21 Sep 2004 10:14:53 +0100l- From: John Laird <nospam@laird-towers.org.uk> C Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions. 8 Message-ID: <lurvk0lglst9vptukejcb4hhnvnr4chk3g@4ax.com>  A On Mon, 20 Sep 2004 09:48:39 -0500 (CDT), sms@antinode.org wrote:c  I >   I assumed that the _intention_ of "-V" was to get the file attributescF >right if the archive was unpacked on a VMS system, not necessarily to@ >produce corrupt files on non-VMS systems.  Clearly, the currentG >_implementation_ offers file corruption as a bonus for a non-VMS user.p  H Who shouldn't be using -V then.  I suggest you also test your changes onK indexed files, especially ones not closed properly.  It is vital to includep2 all allocated blocks and not pay attention to EOF.   --   Give me patience!  RIGHT NOW!    Mail john rather than nospam...-   ------------------------------    Date: 21 Sep 2004 06:56:26 -0700+ From: shoppa@trailing-edge.com (Tim Shoppa):C Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.t= Message-ID: <bec993c8.0409210556.26964dd3@posting.google.com>t  G sms@antinode.org wrote in message news:<04092017270038@antinode.org>...m  >  What you _do_ get is useless,I > erroneous NUL padding.  (Or do you actually believe that the almost 16KtE > of NULs is really a clever encoding of the VMS file attributes?  OrbH > perhaps a file exactly 16K bytes long has exactly zero "extra stuff"?  > Let's get serious.).  I Whoa!  Calm down there.  I'm not saying that the extra stuff isn't there.dG I agree fully that it is there.  And if you do any VMS file format thath/ has RMS record lengths all those are there too.-  L But, please, stop, take a step back, and look at the info-zip documentation:  A        -V     [VMS] Save VMS file attributes.  zip archives  cre-pA               ated  with this option will generally not be usable                on other systems.r  ? They (and I) make no guarantee that Info-zip's "-V" option willeK produce what any particular person (including you) wants when unzipped on aoG non-VMS system.  In general there's a bunch of RMS junk between records E and potentially random junk at the end.  The case you're all hyped uph3 about (stream LF) is indeed the best case but stilla not perfect.  I You're perfectly free to hack up the innards of Info-zip however you want D to do whatever you think it should do.  But we still aren't into theG realm of "problem" much less "solution" because it's working exactly asd documented.>  G >    Please, before telling me again that ZIP -V _should_ work this wayoK > because it _does_ work this way, do us all a favor and look at the code. ( > IT'S BROKEN.  % Look at the documentation.  IT WORKS.    Tim.   ------------------------------  + Date: Tue, 21 Sep 2004 09:07:17 -0500 (CDT)T From: sms@antinode.orgC Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.e) Message-ID: <04092109071782@antinode.org>C  @ Subj:	Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.  - From: John Laird <nospam@laird-towers.org.uk>n  C > On Mon, 20 Sep 2004 09:48:39 -0500 (CDT), sms@antinode.org wrote:e > K > >   I assumed that the _intention_ of "-V" was to get the file attributesxH > >right if the archive was unpacked on a VMS system, not necessarily toB > >produce corrupt files on non-VMS systems.  Clearly, the currentI > >_implementation_ offers file corruption as a bonus for a non-VMS user.   ! > Who shouldn't be using -V then.u  F    I'm curious.  Is that your response to _all_ programs with features that misbehave?h  + >   I suggest you also test your changes ongM > indexed files, especially ones not closed properly.  It is vital to includeo4 > all allocated blocks and not pay attention to EOF.  @    First, if I had to pick a defect, I'd choose to have properlyC structured files come out right and badly structured files come outl( wrong, rather than the other way around.  dD    Second, what makes you think it does this now?  (Not that I wouldF rule it out.)  How would I test the results?  For example, does BACKUP& /COMPARE check "all allocated blocks"?  D > Subj:   Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.:    Third, just as a reminder, I did say ---------^^^^^^^^.  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------  + Date: Tue, 21 Sep 2004 11:23:23 -0500 (CDT)n From: sms@antinode.orgC Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.T) Message-ID: <04092111232333@antinode.org>!  + From: shoppa@trailing-edge.com (Tim Shoppa)d  I > sms@antinode.org wrote in message news:<04092017270038@antinode.org>...D" > >  What you _do_ get is useless,K > > erroneous NUL padding.  (Or do you actually believe that the almost 16KiG > > of NULs is really a clever encoding of the VMS file attributes?  OriJ > > perhaps a file exactly 16K bytes long has exactly zero "extra stuff"?  > > Let's get serious.)i > K > Whoa!  Calm down there.  I'm not saying that the extra stuff isn't there.(I > I agree fully that it is there.  And if you do any VMS file format that 1 > has RMS record lengths all those are there too.i  D    I'm still not clear on which "extra stuff" you're talking about. B And, as I've tried repeatedly to make clear, I don't expect usefulH results in this situation for a file with embedded record lengths.  And,$ of course, my files don't have them.  N > But, please, stop, take a step back, and look at the info-zip documentation: > C >        -V     [VMS] Save VMS file attributes.  zip archives  cre-aC >               ated  with this option will generally not be usable.! >               on other systems.u > A > They (and I) make no guarantee that Info-zip's "-V" option willsM > produce what any particular person (including you) wants when unzipped on a"I > non-VMS system.  In general there's a bunch of RMS junk between recordsCG > and potentially random junk at the end.  The case you're all hyped up 5 > about (stream LF) is indeed the best case but stillv > not perfect.  F    I interpreted "generally" here as refering to files like those withC embedded record lengths.  You may interpret it as refering to filesvD whose sizes are not N* 16K.  We may have to agree to differ on this.  K > You're perfectly free to hack up the innards of Info-zip however you wantvF > to do whatever you think it should do.  But we still aren't into theI > realm of "problem" much less "solution" because it's working exactly ase
 > documented.i       As you read and interpret it.  I > >    Please, before telling me again that ZIP -V _should_ work this way M > > because it _does_ work this way, do us all a favor and look at the code. e > > IT'S BROKEN. > ' > Look at the documentation.  IT WORKS.C  H    If you call describing a four-byte file (with sizes "1/35") as havingB an "uncompressed size" of 16384 bytes "working", then I doubt that1 there's much I can say to convince you otherwise.a  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547u   ------------------------------  % Date: Tue, 21 Sep 2004 09:02:17 -0400e# From: "John Smith" <a@nonymous.com> # Subject: [OT]: McNeally understands", Message-ID: <X76dnUzreLH-u83cRVn-rg@igs.net>  L http://story.news.yahoo.com/news?tmpl=story&cid=1620&ncid=1208&e=1&u=/sv/200$ 40921/tc_sv/suntriestowoowallstfirms   Sun tries to woo Wall St. firmsh  % By Therese Poletti and Dean Takahashiu Mercury News  H Sun Microsystems made some of its first sales in the early 1980s sellingJ workstations to Wall Street. Now the struggling Santa Clara computer makerH is returning to its roots with a campaign to win back some of its former financial-industry customers.e  K President and Chief Operating Officer Jonathan Schwartz today will unveil agJ new line of Sun servers designed to woo Wall Street back into Sun's orbit.K Schwartz hopes to convince these consumers of bleeding-edge technology thatoJ the new products are as cheap and powerful as the Linux-based servers thatK have stolen much of the company's Wall Street business over the past couplel	 of years.o  J After its founding in 1982, Sun scored its first customers on Wall Street,K where companies bought its networked workstations that could crunch numbers-A and run financial software more cheaply than mainframe computers.C  J Sun began losing its grip on the information-technology departments of theL world's biggest investment-banking firms and other trading houses during the$ bust that followed the dot-com boom.  H Faced with lower trading volumes and excess capacity, financial-servicesG firms began buying lower-cost servers using Intel chips and running thetK open-source Linux operating system. Instead of supplying these new machinestI to Wall Street, Sun tried to stem the tide by promoting computers runningr Sun's own chips and software.e   Linux deployed NowI Morgan Stanley, Merrill Lynch and other firms are using Linux in parts ofeL their operations. TowerGroup, a research and consulting firm that focuses onK the financial-services industry, reported in a January study that Linux was E deployed on 9 percent of all servers in the North American securities K industry. TowerGroup projects that Linux will continue to grow at an annualu1 rate of 22 percent in North America through 2006.r  F Sun Chief Executive Scott McNealy in an interview said the company has8 refocused on low-cost technology for its core customers.  L "We aren't going to announce Sun TV sets, or Sun digital cameras or a patentF for a new Sun inkjet cartridge," said McNealy, taking a jab at SiliconI Valley rival Hewlett-Packard. "This event will be very focused on solving $ complex network computing problems."  K John Fowler, executive vice president of network systems at Sun, noted that B financial firms that switched to competitors' computers remain SunC customers. He noted that Sun servers still handle trading and others( transactions for many Wall Street firms.  L McNealy, who will join Schwartz in New York next week, said Sun now offers aF more appealing mix of products, including Linux-based servers that useF Advanced Micro Devices' low-cost Opteron chips. Those servers start at. $8,495 for a server with four microprocessors.  K McNealy said Sun also plans to tout Solaris 10, its upcoming version of itsCB Solaris operating system. Solaris 10 will run on both SPARC, Sun'sI proprietary processors, and on servers designed around both AMD chips andm Intel chips.  L Sun also plans to announce a new simplified data-storage system that it saysL will help Wall Street firms deal with the Sarbanes-Oxley financial reporting regulations.  J Joel Scotkin, CEO of Random Walk, which resells both Sun and IBM equipmentH to financial firms, said Wall Street customers are likely to welcome theI features of Solaris 10. The operating system will offer a new file systemaF and the ability to isolate parts of computers into "containers." TheseE containers protect one part of the machine that supports a particularrF application from the rest of the machine when another program crashes.  K But Scotkin noted that IBM's Power5-based servers are well-received on WallhC Street and that IBM appears to be ahead in so-called virtualization F technology, which resembles Sun's containers and enables a customer to maximize a server's use.  K `Frequent disconnect' Some analysts said Sun's financial problems of recentfD years and a perception that it has lost focus has contributed to the- company's diminished presence on Wall Street.u  I "There has been a frequent disconnect from what customers have heard fromaI headquarters and what they have heard from the sales force," said Michael J Dortch, a principal business analyst at consulting firm the Robert Frances Group.  H Sun recently completed its annual sales force reorganization, but DortchC said it is not clear if that will help. "It doesn't matter how they G reorganize, it matters how it plays out at the customer site," he said.   H For its part, Sun said it hopes to recapture its leading position in the financial-services industry.  J "It's an opportunity to re-establish ourselves," said McNealy. "We put the story back together."e   ------------------------------    Date: 21 Sep 2004 10:47:05 -0700( From: bob@instantwhip.com (Bob Ceculski)' Subject: Re: [OT]: McNeally understandse= Message-ID: <d7791aa1.0409210947.619e21d1@posting.google.com>   W "John Smith" <a@nonymous.com> wrote in message news:<X76dnUzreLH-u83cRVn-rg@igs.net>...  > L > Joel Scotkin, CEO of Random Walk, which resells both Sun and IBM equipmentJ > to financial firms, said Wall Street customers are likely to welcome theK > features of Solaris 10. The operating system will offer a new file systemnH > and the ability to isolate parts of computers into "containers." TheseG > containers protect one part of the machine that supports a particularoH > application from the rest of the machine when another program crashes. > M > But Scotkin noted that IBM's Power5-based servers are well-received on WallnE > Street and that IBM appears to be ahead in so-called virtualizationwH > technology, which resembles Sun's containers and enables a customer to > maximize a server's use.  < VMS has had clusters for over 20 years now and Galaxy for 10< I think ... welcome to something you could have had 10 years
 ago ... :)   ------------------------------   End of INFO-VAX 2004.525 ************************