1 INFO-VAX	Thu, 30 Sep 2004	Volume 2004 : Issue 543       Contents:3 "frozen" application by using Advanced Server Share 7 Re: "frozen" application by using Advanced Server Share 7 Re: "frozen" application by using Advanced Server Share ' #IFDEFs in a multi platform environment + Re: #IFDEFs in a multi platform environment + Re: #IFDEFs in a multi platform environment + Re: #IFDEFs in a multi platform environment + Re: #IFDEFs in a multi platform environment + Re: #IFDEFs in a multi platform environment  Re: *.CDD file for CONNX Re: As seen in WSJ Re: As seen in WSJ4 Re: Good places in EU to study Networking/Clustering, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations> Re: Interbase on VMS (was Re: "Oracle RDB" licensing question) Re: Odd behavior in XFC cache  SHOW DEVICE/FILES with FORTRAN? 3 Re: TCPIP$SMTP_SEND_FROM_FILE, what's its future??? # RE: Tiny pickings for Itanium OEM's # Re: Tiny pickings for Itanium OEM's $ Re: Why does Ghostscript build fail? WRQ OpenVMS Survey Re: WRQ OpenVMS Survey Re: WRQ OpenVMS Survey  F ----------------------------------------------------------------------    Date: 30 Sep 2004 04:24:56 -0700" From: udo.kaul@merck.de (Udo Kaul)< Subject: "frozen" application by using Advanced Server Share= Message-ID: <302d60f2.0409300324.24effe03@posting.google.com>   F We've got a Performance Problem with a Application which is running on2 a Citrix Terminalserver Farm. The Application use C one Advanced Server V7.3-130A Share for storing Configuration Data   and Result Data.  8 If we start the Application from a ICA-Client ( with one/ Terminalserver in the farm) everything is fine. @ If we start the Application from a ICA-Client ( with two or moreC Terminalserver in the farm) , the Application is frozen for 20 - 40  sec.? After that the Application is running . The frozen Situation is E repeating several times.What the Application do is to open some Files , which contains Information about the system.2 These open files we can see with admin show open .  8 If we use a Win2000 Share, we didn't saw these Problems.   Does anybody has any idea ?   F Does the RMS handling for open files from VMS cause this Problems ?      Enviroment :B ES40 with OpenVMS 7.3-2, TCPIP V5.4 - ECO 2, MA8000 Storage System   best regards Udo   ------------------------------  % Date: Thu, 30 Sep 2004 09:08:21 -0400 $ From: "PEN" <paul.nuneznosp@mhp.com>@ Subject: Re: "frozen" application by using Advanced Server Share, Message-ID: <cjh0g8$j0j$1@hplms2.hpl.hp.com>   Hi Udo,   C If you suspect the Advanced Server, check the server logs, etc for   indications of errors:  ! $ admin/analyze/since=<date:time> ' $ admin sh event/full/since=<date:time> 1 $ type/tail pwrk$lmlogs:pwrk$lmsrv_<nodename>.log   ; But, I suspect for this type if issue, you won't find much.   J If you could get a trace of this behavior I'd be happy to look at it.  If G you're unsure of which terminal server would be accessing the Advanced  K Server, use tcpdump and capture traffic from all of them.  Not sure of the  = exact syntax (don't have a tcpip v5.4 system at my disposal):   F $ tcpdump -w outputfile.bin -b 300 -s 1500  host <termsrv1-ipaddr> or  <trmsv2-ipaddr>   7 Some things that come to mind that may be at play here:   # Opportunistic Locking - To disable:   2     $ edit pwrk$common:pwrk.ini   ! Add the lines:  
         [PLM]          ENABLE_OPLOCKING=NO   L Alias filename processing (if the directory contains lots of files which do H not comply with the DOS 8.3 naming convention) - To disable (ECO3 only):  3     $ edit pwrk$common:pwrk.ini    ! Add the lines:   
     [ODS2]     DISABLE_ALIAS_FILENAMES=YES   G Directory Cache - If the .DIR file containing the files in question is  I larger than 512 blocks, it will not be cached and will dramatically slow  K performance.  If the .DIR file is less than 1024 blocks, the dircache size  A can be increased to the max of 1024 to allow for it to be cached:        $ edit pwrk$common:pwrk.ini 
     [ODS2]     DIR_CACHE_LIMIT=1024  I Any modifications to pwrk.ini require the Advanced Server be restarted...    HTH,   Paul  0 "Udo Kaul" <udo.kaul@merck.de> wrote in message 7 news:302d60f2.0409300324.24effe03@posting.google.com... H > We've got a Performance Problem with a Application which is running on3 > a Citrix Terminalserver Farm. The Application use D > one Advanced Server V7.3-130A Share for storing Configuration Data > and Result Data.: > If we start the Application from a ICA-Client ( with one1 > Terminalserver in the farm) everything is fine. B > If we start the Application from a ICA-Client ( with two or moreE > Terminalserver in the farm) , the Application is frozen for 20 - 40  > sec.A > After that the Application is running . The frozen Situation is G > repeating several times.What the Application do is to open some Files . > which contains Information about the system.4 > These open files we can see with admin show open . > : > If we use a Win2000 Share, we didn't saw these Problems. >  > Does anybody has any idea ?  > E > Does the RMS handling for open files from VMS cause this Problems ?  >  > Enviroment :D > ES40 with OpenVMS 7.3-2, TCPIP V5.4 - ECO 2, MA8000 Storage System >  > best regards Udo     ------------------------------   Date: 30 SEP 2004 14:04:14 GMT4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)@ Subject: Re: "frozen" application by using Advanced Server Share6 Message-ID: <30SEP04.14041426@thuria.waisman.wisc.edu>  ( In a previous article, (Udo Kaul) wrote:  B ->If we start the Application from a ICA-Client ( with two or moreE ->Terminalserver in the farm) , the Application is frozen for 20 - 40  ->sec.  & In addition to Paul's suggestions try:  # $ @sys$manager:pwrk$define_commands  $ PWMON SERVER  I Then run the app. Watch the "Nr of SMB active workthreads". Does it begin ' climbing during the 20-40 second hang?     --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison 8 --                 karcher.nomorespym@waisman.wisc.edu     ------------------------------  % Date: Thu, 30 Sep 2004 04:12:17 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: #IFDEFs in a multi platform environment, Message-ID: <415BBFCF.A8FEB52D@teksavvy.com>  L Someone on the OSU mailing list reported that by defining __ALPHA to compileJ the OSU software on that IA64 thing, the C compiler generated some errors.  M This got me to think: With VMS likely to exist on VAX, Alpha, IA64 and AMD64, I would it be better for applications to use __VMS32 and __VMS64 instead of 2 platform specific names such as __VAX and __ALPHA?  M This way, they would be independant from C compiler specific definitions, and M one woudln't actually have to make changes to programs that run on any of the - 64 bit platforms VMS may be called to run on.   J Deep down kernel stuff can still make use of platform specific ifdefs whenL necessary, but normal user mode applications wouldn't need any modifications. and addition of more ifdefs for each platform.   ------------------------------  # Date: Thu, 30 Sep 2004 14:22:31 GMT 4 From: "Fred Kleinsorge" <fred.nospam@nospam.dec.com>4 Subject: Re: #IFDEFs in a multi platform environment2 Message-ID: <HEU6d.12083$Cv7.423@news.cpqcorp.net>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:415BBFCF.A8FEB52D@teksavvy.com...F > Someone on the OSU mailing list reported that by defining __ALPHA to compile L > the OSU software on that IA64 thing, the C compiler generated some errors. > H > This got me to think: With VMS likely to exist on VAX, Alpha, IA64 and AMD64,K > would it be better for applications to use __VMS32 and __VMS64 instead of 4 > platform specific names such as __VAX and __ALPHA? > K > This way, they would be independant from C compiler specific definitions,  and K > one woudln't actually have to make changes to programs that run on any of  the / > 64 bit platforms VMS may be called to run on.  > L > Deep down kernel stuff can still make use of platform specific ifdefs when@ > necessary, but normal user mode applications wouldn't need any
 modifications 0 > and addition of more ifdefs for each platform.  A There are specific reasons that code may need to know the precise F architecture (I do not think __AMD64 is likely to be one of them).  InI general you can accomplish what you want by simply using __VAX as meaning L 32-bit, and anything else as 64-bit.  If you want to define specific symbols) for that meaning - that's fairly trivial.   J In retrospect, most of the changes needed in porting truly are a result ofG an inappropriate use of __ALPHA to mean NOT __VAX.   The compiler is (I @ believe) being changed so that the redefinition of __ALPHA is anH informational as opposed to a warning - for those not able or willing to make the source code changes.    ------------------------------  # Date: Thu, 30 Sep 2004 15:07:50 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> 4 Subject: Re: #IFDEFs in a multi platform environment2 Message-ID: <ajV6d.12088$i8.7513@news.cpqcorp.net>  ? "Fred Kleinsorge" <fred.nospam@nospam.dec.com> wrote in message L news:HEU6d.12083> In retrospect, most of the changes needed in porting truly are a result of  >  The compiler is (I B > believe) being changed so that the redefinition of __ALPHA is anJ > informational as opposed to a warning - for those not able or willing to > make the source code changes.   ?     Fred is correct.  Based on user feedback, we've changed the      message from -W- to -I-        Ed Vogel     HP C Engineering.    ------------------------------  % Date: Thu, 30 Sep 2004 11:24:05 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>4 Subject: Re: #IFDEFs in a multi platform environment. Message-ID: <415BECD5.24364.2FD5A67@localhost>  / On 30 Sep 2004 at 14:22, Fred Kleinsorge wrote: B > In retrospect, most of the changes needed in porting truly are aD > result of an inappropriate use of __ALPHA to mean NOT __VAX.   TheC > compiler is (I believe) being changed so that the redefinition of E > __ALPHA is an informational as opposed to a warning - for those not 2 > able or willing to make the source code changes.  C The Itanium porting guide says not to redefine "__ALPHA" and other  C such pre-defined symbols.  Doing so will cause the system-provided   header files to break.  B It's a pain, but I changed about 200 "#ifdef __ALPHA" to "#ifndef ; VAX" in my client's code.  And you will have to do it, too.   D The good news is that you'll probably not have to change this again  for the next processor.   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com   ------------------------------  % Date: Thu, 30 Sep 2004 12:41:26 -0400 # From: "John Smith" <a@nonymous.com> 4 Subject: Re: #IFDEFs in a multi platform environment, Message-ID: <f4SdnUrl2Z-oqsHcRVn-iw@igs.net>   Stanley F. Quayle wrote:1 > On 30 Sep 2004 at 14:22, Fred Kleinsorge wrote: C >> In retrospect, most of the changes needed in porting truly are a E >> result of an inappropriate use of __ALPHA to mean NOT __VAX.   The D >> compiler is (I believe) being changed so that the redefinition ofF >> __ALPHA is an informational as opposed to a warning - for those not3 >> able or willing to make the source code changes.  > D > The Itanium porting guide says not to redefine "__ALPHA" and otherD > such pre-defined symbols.  Doing so will cause the system-provided > header files to break. > C > It's a pain, but I changed about 200 "#ifdef __ALPHA" to "#ifndef = > VAX" in my client's code.  And you will have to do it, too.  > E > The good news is that you'll probably not have to change this again  > for the next processor.   	 Power 5??    ------------------------------    Date: 30 Sep 2004 12:13:23 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 4 Subject: Re: #IFDEFs in a multi platform environment3 Message-ID: <dHXUjSx8Abdm@eisner.encompasserve.org>   c In article <415BECD5.24364.2FD5A67@localhost>, "Stanley F. Quayle" <squayle@insight.rr.com> writes:  > D > It's a pain, but I changed about 200 "#ifdef __ALPHA" to "#ifndef = > VAX" in my client's code.  And you will have to do it, too.   E    I'm sure I'm not the only one who has a replace_all.com to do this C    sort of thing.  Generally the first pass can handle about 190 of ;    those 200 cases and the second pass can get 6 to 8 more.   G    We're talking minutes.  It's the regression testing that takes time.    ------------------------------    Date: 30 Sep 2004 00:59:55 -0700# From: dooleys@snowy.net.au (dooley) ! Subject: Re: *.CDD file for CONNX = Message-ID: <1ca82fc6.0409292359.25570534@posting.google.com>   e David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<415B59E0.DEBC0965@comcast.net>...  > dooley wrote:  > > i > > David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<415A1DBA.A487E357@comcast.net>... - > > I seem to be missing the problem here.... B > > I assume there is some sort of data structure in place on vms,/ > > or there wouldn't be any need to use connx. F > > Connx can understand almost any structure, from a database schema,F > > vms .ddl files, powerhouse dictionaries and .pdl files, vms commonB > > data dictionary, and even basic, cobol, and dibol definitions.E > > If you don't have any of these, you can still create it manually, 2 > > by adding each table and defining its columns.D > > After you have created or imported your definition, you generate1 > > the connx .cdd by clicking the "save" button. A > > Then you create a connx data-source on your pc that is linked I > > to this cdd, and then you can use it like any other odbc data source.  > * > Good feature - potentially quite useful. I know  D > ...if one has the source code, CDD, etc. Even then - I've seen badJ > source code that doesn't use (predates) CDD or include directives and no@ > one program has the entire layout for one or more files in the > application. > C > Remember: we're talking RMS here - no RDBMS from which to extract 8 > schema, and if no source then probably no CDD, either. > I > In that case, one could try to reverse-engineer the programs and files, ! > and try to make good guesses...  > H > ...which brings us back to the original question: how to GENERATE .CDD > files for CONNX.@ Based on what? Are you expecting it to generate a structure from9 the content of an RMS file? I repeat my earlier assertion D > > After you have created or imported your definition, you generate1 > > the connx .cdd by clicking the "save" button. ; If you don't have the source any more, I hope you have some  documentation,1 bacause you will have to import from a text file. - Again, this is extracted from the connx help.  Phil  B The RMS text file import specification should be used only if yourF record layouts are not COBOL FD, DIBOL, Formatted DDL, Powerhouse PDL, BASIC, or VAX or Alpha CDD format. : The first line of each record layout should be as follows:C CONNXTABLE, <TableName>, <RMS File Name>,<Record Length>, <SQL View  Clause> 1 Note: Inclusion of a SQL View Clause is optional. > One import text file may contain multiple record layouts, each starting& with the same header line shown above.B Each subsequent line in the file represents a column in the record layout. ' The format for each line is as follows: ? <column name>, <column length>, <column offset>, <column type>, B <column scale>, <column base>, <column fraction>, <column comment>2 The following is an example of an RMS import file.+ CONNXTABLE, CompanyTable, COMPTABLE.DAT, 64 6 Company, 30, 0, 1, 0, 0, 0, This is the Company Field.3 Title, 10, 30, 1, 0, 0, 0, This is the Title Field. 1 Name, 20, 40, 1, 0, 0, 0, This is the Name Field. / Age, 4, 60, 14, 0 ,0 ,2, This is the Age Field.    ------------------------------  % Date: Thu, 30 Sep 2004 11:58:38 -0400 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: As seen in WSJ , Message-ID: <415C2D2E.4020901@tsoft-inc.com>   John Smith wrote:    > Bob Ceculski wrote:   @ >>soon for the x86 boat anchor oopsteron will be 2010 ... that's> >>5 years, then it will start to look like a 286 chip ... epicA >>if perfected and with that spark it needs from the vms customer < >>base will by then with ev9 and 10 features surpass all x86@ >>boat anchors ... the alpha team will come thru again just like= >>they did on alpha ... and vms will make or break itanium by > >>giving it that spark in sales and proof that it can and will< >>outperform the x86 boat anchor by a wide margin ... unless; >>someone else can come up with something better than epic, ? >>x86 and risc for that matter will hit that little wall called : >>moores law just like the 32bit x86 is now, and barring aA >>brainstorm chip, itanium will tke over, and we the vms customer A >>base will be that spark to bring itanium to its full potential!  > I > Me thinks your medication dosage needs a bit of adjustment. Hard to say 2 > whether you need more or less of whatever it is.    N I think you may have discovered the problem!  Regardless, it's a great guess, 4 and I'm still trying to recover some composure.  :-)  / Not that this would mean anything to boob, but:   Q 1) Could anybody, much less the producer of a good CPU, really stand still for 6   years?  Doubtful.   . 2) It's doubtful EPIC could ever be perfected.  K 3) Moore's law mentioned that performance would double every 18 months, or  6 something like that.  It has nothing to do with walls.   4) It's already an overdose.     Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Thu, 30 Sep 2004 17:32:54 GMT ! From: Nigel Barker <nigel@hp.com>  Subject: Re: As seen in WSJ 8 Message-ID: <e6gol052evsdur617mnnkigtsvq6l7f8mh@4ax.com>  M On Thu, 30 Sep 2004 11:58:38 -0400, David Froble <davef@tsoft-inc.com> wrote:   R >1) Could anybody, much less the producer of a good CPU, really stand still for 6  >years?  Doubtful.  M It's amazing how times change. After the launch of the VAX 11/780 it was five 8 years before DEC brought out a faster CPU in the 11/785.   -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  % Date: Thu, 30 Sep 2004 10:33:54 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> = Subject: Re: Good places in EU to study Networking/Clustering + Message-ID: <2s22d9F1f6ci9U1@uni-berlin.de>    Alex Daniels wrote: > > "Fabio Cardoso" <fabiopenvms@yahoo.com.br> wrote in message 9 > news:f30679fb.0409290845.3a1fadd6@posting.google.com...  > : >>Do you know good institutions in EU where is possible to5 >>have a specialization in Network/Clustering (Open)?  >> >>UK and DE are welcome !  >>	 >>Regards  >> >>FC >  > " > http://www.ecctisclearing.co.uk/ > http://www.ucas.ac.uk/ > A > You will find lots of network related courses from those links.   @ And you should be prepared to spend a *lot* of money, given that< you are not a UK citizen.  Somehow I don't think it would be worth it for you ...  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  # Date: Thu, 30 Sep 2004 07:59:48 GMT ! From: Nigel Barker <nigel@hp.com> 5 Subject: Re: HP admits discontinued IA64 workstations 8 Message-ID: <62rkl09a6966kjgi4d0lu0pgh2l9p8omu5@4ax.com>  K On Tue, 28 Sep 2004 15:24:16 -0400, JF Mezei <jfmezei.spamnot@teksavvy.com>  wrote:  N >No matter what marketers tell you, any migration to a different architecture,O >even if on same OS requires recertification, testing, migration plan, parallel M >testing etc and that costs a lot of money to the customer, even if the OS is 
 >the same.C >That is something which the VMS engineers seem to refuse to admit.   N I quite agree & that is certainly not something that you could ever accuse VMSO engineering of ignoring. Don't forget that VMS has already migrated from VAX to O Alpha & many lessons were learned then. This time the porting is easier but the A QA, testing, re-certification etc still takes just the same time.   N On the other hand just as with the introduction of Alpha the Sales & MArketing+ people can be a little over enthusiastic:-)    -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  % Date: Thu, 30 Sep 2004 04:28:24 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <415BC395.C0E0E024@teksavvy.com>   Nigel Barker wrote: P > I quite agree & that is certainly not something that you could ever accuse VMSQ > engineering of ignoring. Don't forget that VMS has already migrated from VAX to Q > Alpha & many lessons were learned then. This time the porting is easier but the C > QA, testing, re-certification etc still takes just the same time.   I Difference is that VMS customers really could convert at a leasurely pace N because VAX had not been EOLed before Alpha was even available to run VMS, andJ in fact, VAX got a few enhancements well beyond the introduction of usable Alpha-VMS machines.   J Alpha has been EOLed 3 years ago, and the last Alpha chip has already beenN relased, before VMS is commercially available on that IA64 thing. So customersN do not have as much time to plan a migration, especially considering that whenM VMS was made commercially available on Alpha, it was hoped Alpha would have a / great future and re-propell Digital to the top.   K At this point in time, there is much talk about IA64 not reaching predicted L targets, with narrowing market niches and there is already speculation aboutL whether IA64 will survive against the 64 bit 8086. So instead of hoping IA64K might make VMS a industry leader again, the fears is that it will be pulled J down by the sinking IA64 unless the 64 bit 8086 lifeboat is launched soon.  N So it is a VERY different environment from the early 1990s. Remember that backH then, the VMS marketplace had not completely eroded and while already inK decline, still have a fair amount of momentum, and applications. This is no  longer the same.   ------------------------------  % Date: Thu, 30 Sep 2004 06:50:49 -0700 # From: "Tom Linden" <tom@kednos.com> 5 Subject: Re: HP admits discontinued IA64 workstations ( Message-ID: <opse47ezmfzgicya@hyrrokkin>  D On Thu, 30 Sep 2004 07:59:48 GMT, Nigel Barker <nigel@hp.com> wrote:  I > On Tue, 28 Sep 2004 15:24:16 -0400, JF Mezei <jfmezei.spamnot@teksavvy=  .com>  > wrote: > I >> No matter what marketers tell you, any migration to a different archi=  tecture,I >> even if on same OS requires recertification, testing, migration plan,= 	  parallel I >> testing etc and that costs a lot of money to the customer, even if th=  e OS is  >> the same.E >> That is something which the VMS engineers seem to refuse to admit.  > I > I quite agree & that is certainly not something that you could ever ac=  cuse VMSI > engineering of ignoring. Don't forget that VMS has already migrated fr= 	 om VAX to I > Alpha & many lessons were learned then. This time the porting is easie= 	 r but the C > QA, testing, re-certification etc still takes just the same time.   I Migrating from VAX to Alpha was an incompetent and reckless business dec=  ision I as is proven by the number of VAX users still out there  (we are still s=  ellingI VAX licenses!)  The decision to go from Alpha to Itanium is worse yet, b=  ecauseI of the prior experience with the dislocation to the customer base.  And =  pleaseG don't use the argument that VAX had run out of steam and that it wasn't I extendible to 64 bits, that is demonstrabaly codswallop as evidenced by =  AMD % for example, or better yet, z-series.    > I > On the other hand just as with the introduction of Alpha the Sales & M=  Arketing- > people can be a little over enthusiastic:-)  >  > -- > Nigel Barker! > Live from the sunny Cote d'Azur  >    ------------------------------    Date: 30 Sep 2004 10:54:55 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 5 Subject: Re: HP admits discontinued IA64 workstations 3 Message-ID: <yWYUxmpixD3o@eisner.encompasserve.org>   u In article <415b3fd7$0$22749$db0fefd9@news.zen.co.uk>, "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> writes: = > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  ( > news:41587174.68275C40@teksavvy.com... >> re: sound support.  >>I >> Perhaps HP will take "Dectalk" and dust it off and put it back on the  
 >> market, > 6 > Don't quote me, but I do not believe hp own DECtalk. > J > Another company have it on the market, albeit probably not the specific  > boxes you may be thinking of.   E When they took over, they went to a software implementation on Alpha, 
 skipping VMS.    ------------------------------    Date: 30 Sep 2004 10:56:12 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 5 Subject: Re: HP admits discontinued IA64 workstations 3 Message-ID: <FRdF3Uctmqo6@eisner.encompasserve.org>   N In article <opse47ezmfzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:  K > Migrating from VAX to Alpha was an incompetent and reckless business dec=  > ision 9 > as is proven by the number of VAX users still out there   L I disagree.  Why should I buy a new computer if the old one serves me well ?   ------------------------------  % Date: Thu, 30 Sep 2004 12:05:40 -0400 # From: "John Smith" <a@nonymous.com> 5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <8dSdnT02Bp9Os8HcRVn-vA@igs.net>   Tom Linden wrote: F > On Thu, 30 Sep 2004 07:59:48 GMT, Nigel Barker <nigel@hp.com> wrote: > / >> On Tue, 28 Sep 2004 15:24:16 -0400, JF Mezei ( >> <jfmezei.spamnot@teksavvy.com> wrote: >>C >>> No matter what marketers tell you, any migration to a different G >>> architecture, even if on same OS requires recertification, testing, F >>> migration plan, parallel testing etc and that costs a lot of money0 >>> to the customer, even if the OS is the same.F >>> That is something which the VMS engineers seem to refuse to admit. >>F >> I quite agree & that is certainly not something that you could ever@ >> accuse VMS engineering of ignoring. Don't forget that VMS hasG >> already migrated from VAX to Alpha & many lessons were learned then. 7 >> This time the porting is easier but the QA, testing, 7 >> re-certification etc still takes just the same time.  > F > Migrating from VAX to Alpha was an incompetent and reckless business
 > decisionB > as is proven by the number of VAX users still out there  (we are > still selling C > VAX licenses!)  The decision to go from Alpha to Itanium is worse  > yet, becauseD > of the prior experience with the dislocation to the customer base. > And pleaseB > don't use the argument that VAX had run out of steam and that it > wasn'tF > extendible to 64 bits, that is demonstrabaly codswallop as evidenced > by AMD' > for example, or better yet, z-series.     5 I fully concurr about the customer dislocation issue.    No excuses for anyone but.... I at the time (late 80's), wasn't it widely thought that CISC *was* running K out of steam and that RISC really was the only viable choice at the time? I L believe, and stand to be corrected, that it has only been since the mid/lateH 90's that events have shown that CISC could have successfully evolved to% much high performance, rivaling RISC.   K That Alpha was, and still is, a highly competitive design, and has/has room J to further evolve doesn't make it a failure - the only failure was that of1 management in not believing in their own product.    ------------------------------    Date: 30 Sep 2004 12:09:22 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 5 Subject: Re: HP admits discontinued IA64 workstations 3 Message-ID: <v5gHW5nrD635@eisner.encompasserve.org>   R In article <8dSdnT02Bp9Os8HcRVn-vA@igs.net>, "John Smith" <a@nonymous.com> writes: >  > No excuses for anyone but.... K > at the time (late 80's), wasn't it widely thought that CISC *was* running M > out of steam and that RISC really was the only viable choice at the time? I N > believe, and stand to be corrected, that it has only been since the mid/lateJ > 90's that events have shown that CISC could have successfully evolved to' > much high performance, rivaling RISC.   H    There were also a few customers for whom 32 bit was getting to be tooE    small.  Not enough to justify the expense of coming out with a new $    architecture, but real customers.  H    Could DEC have succeeded with a 64 bit extended VAX?  The name "EVAX"H    is not completely hidden with respect to Alpha.  But any company thatI    can't sell the worlds fastest processor with the customer's choice of  D    either the world's best OS or a damn good UNIX has too much of a >    marketing problem to sell much of anything, which means the&    engineering cost is always too big.   ------------------------------  # Date: Thu, 30 Sep 2004 17:30:50 GMT ! From: Nigel Barker <nigel@hp.com> 5 Subject: Re: HP admits discontinued IA64 workstations 8 Message-ID: <kufol0t3ff254qqaeihtrediqhji1bj7af@4ax.com>  H On Thu, 30 Sep 2004 12:05:40 -0400, "John Smith" <a@nonymous.com> wrote:   >No excuses for anyone but....J >at the time (late 80's), wasn't it widely thought that CISC *was* runningL >out of steam and that RISC really was the only viable choice at the time? IM >believe, and stand to be corrected, that it has only been since the mid/late I >90's that events have shown that CISC could have successfully evolved to & >much high performance, rivaling RISC.  O Indeed that was the perceived wisdom at the time. It was quite an eye opener to P benchmark the first DEC Ultrix machines running on MIPS chips. They were so muchO faster than the VAX we knew & loved. The first Alphas seemed amazing running at K 150-200MHz. Ten years ago it was inconceivable that x86 would be running at 
 3.6GHz today.    -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------   Date: 30 Sep 2004 17:40:40 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)5 Subject: Re: HP admits discontinued IA64 workstations + Message-ID: <2s2uooF1gru29U1@uni-berlin.de>   3 In article <FRdF3Uctmqo6@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:P > In article <opse47ezmfzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes: > L >> Migrating from VAX to Alpha was an incompetent and reckless business dec= >> ision: >> as is proven by the number of VAX users still out there > N > I disagree.  Why should I buy a new computer if the old one serves me well ?  E I'm confused.  You disagree and then your next sentence justifies the  statement you disagreed with?    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Thu, 30 Sep 2004 16:14:23 GMT % From: "John Vottero" <John@mvpsi.com> G Subject: Re: Interbase on VMS (was Re: "Oracle RDB" licensing question) = Message-ID: <zhW6d.10024$Ag7.3467@newssvr15.news.prodigy.com>   / "John Smith" <a@nonymous.com> wrote in message  & news:a92dnc6xbsDoNcTcRVn-og@igs.net... [snip] >  > K > DEC's sale of RDB to Oracle has to rank up there amongst the more stupid   > ofF > their decisions, especially if the NT/unix port was to be imminentlyJ > released as was thought at the time. As I have previously written here,  > DEC I > could have spun-off the Rdb unit and sold 49% or more of the stock for   > moreI > money than they received from Oracle. The stock market would have been   > very6 > receptive at that time if the unix/NT port was real. > L > Another mistake was not ensuring that the deal with Oracle included an RdbJ > run-time license included with each copy of VMS (if memory serves, that  > was + > part of the NAS-200 and higher licences).  >   K Selling Rdb was clearly a mistake.  I would also argue that porting Rdb to  M Unix and NT was a mistake.  They should have been working on integrating Rdb TL into VMS.  Digital had a 10 to 15 year head start on everyone else and they J managed to squander it.  Now, Microsoft is catching up and you don't seem J them talking about porting SQL Server to other operating systems, you see L them shipping a free run-time license and integrating the database into the  operating system.    ------------------------------  # Date: Thu, 30 Sep 2004 16:34:58 GMTm1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> & Subject: Re: Odd behavior in XFC cache1 Message-ID: <SAW6d.12103$Ze.257@news.cpqcorp.net>    Andrew Robert wrote:K > Is there a limit to XFC somewhere or is there something else I should be I3 > tuning to take advantage of the increased memory?k  / An answer from Mark Hopkins, the XFC developer:o ---e; XFC creates its virtual address space at boot time based onc< VCC_MAX_SIZE.  If the attempt fails, then we cut the request: in half and try again (note this is allocating the address= space and not the memory).  Since the cache gets to 8GB, thisn0 didn't happen in this case.  What does the field< 'Maximum size (Mbytes)' from the DCL show memory/cache show?; If this shows 10G, but 'Allocated' only gets to 8GB, it mayN8 be that the system simply isn't allowing XFC to grow the dynamic region.e  0 Here is the rules for XFC dynamic memory growth:  4          - XFC can get additional memory as long as:/                  - free pages >= GROWLIM    and-A                  - free pages - requested pages >= FREELIM    and0@                  - free pages + modified pages - requested pages:                                  >= FREEGOAL + MPW_HILIMIT  H          - We start reclaiming XFC memory if free pages + modified pagesB            drops below FREELIM + MPW_HILIMIT.  We then ask for the deficit.  @          - If we notice that free pages + modified pages exceeds MPW_HILIMIT C            + FREEGOAL, we cancel any still outstanding reclamation.   B The current released XFC versions do not track the number of times memoryE expansion was denied - the next version of XFC will have counters form this.v   Mark  H Ps I just looked and the boottime behavior I described (i.e. halving theH request) was not in the original XFC - it has been added in the remedialH streams.  The previous behavior was to either crash or boot with caching off altogether.h   ------------------------------  % Date: Thu, 30 Sep 2004 12:49:07 -0500r( From: brandon@dalsemi.com (John Brandon)( Subject: SHOW DEVICE/FILES with FORTRAN?1 Message-ID: <04093012490704@dscis6-0.dalsemi.com>   M I have been looking around for a snippet of code to perform the following DCLy command:   $ SHOW DEVICE /FILES <device>-    H I want to be able to do this in FORTRAN - but beggars can't be choosers!    K I have been searching through the archives and have yet to stumble upon anye tangible information.0  , Can someone point me in the right direction?   TIA!       J*o*h*n B*r*a*n*d*o*ne VMS Systems Administratora* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Thu, 30 Sep 2004 18:12:20 +0800g From: prep@prep.synonet.com < Subject: Re: TCPIP$SMTP_SEND_FROM_FILE, what's its future???- Message-ID: <87r7ok3w1n.fsf@prep.synonet.com>'  5 Alan Frisbie <Usenet01REMOVE@Flying-Disk.com> writes:r   > JF Mezei wrote:  >> "Keith A. Lewis" wrote:  M >>> The MAIL$SEND_* routines are supported and work with tcp/ip.  For myself,  >>> I'll stick to those.  O >> Those routines do not allow you to create anything else than text files, and<O >> lack much more flexibility that SFF grants if you use it with privs (such asb  >> specifying the from address).  C > I wish there were some way to allow this *without* privs, perhapsiA > with an identifier.  I have an application at a customer's siteaF > which needs to send an e-mail, but with a return address pointing atD > the user's (yuck) Microsoft Exchange Server account.  For example,? > VMS user FRISBIE needs to send mail with a "From:" address of]B > Alan.Frisbie@Example.com.  Can anyone think of an easy way to do > this without privs?e  G A From message header can contain anything, but if it is set explicitlyd+ a Sender header should be included as well.   2 The above is a classic call for a Reply-To header.   -- c< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda._@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 30 Sep 2004 08:11:13 -0400i' From: "Main, Kerry" <kerry.main@hp.com>n, Subject: RE: Tiny pickings for Itanium OEM'sR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB45D450@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20c# > Sent: September 29, 2004 11:54 PM  > To: Info-VAX@Mvb.Saic.Com . > Subject: Re: Tiny pickings for Itanium OEM's >=20 > David Froble wrote:iA > > Well, as we found out, Alpha NT was a product just as long=20i > as the platforma/ > > vendor shelled out the funds to make it so.I >=20B > I am not sure of that. I think that Microsoft was originall;y=20 > quite opened towB > having NT on many platforms. However, at one point, Microsoft=20 > decided to only 5 > continue on platforms that showed growth potential.a >=20@ > When Compaq told Gates that i didn't intend to make Alpha a=20 > growth platform,A > Microsft quickly lost interest and told Compaq it woudl only=20-
 > continue ifa= > Compaq paid for it (knowing full well Compaq wouldn't pay).. >=20  H Nope - Dave was correct i.e. Compaq like IBM and MIPS before them bailedB from supporting Windows on their platforms when the costs of doingF everything with limited MS assistance (marketing, packaging, resources( etc) became not a good business case.=20  B In each case, Microsoft only dropped the platform after the vendor dropped it.o   Regards   
 Kerry Main Senior Consultantr HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477a kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  % Date: Thu, 30 Sep 2004 11:59:22 -0400h# From: "John Smith" <a@nonymous.com>-, Subject: Re: Tiny pickings for Itanium OEM's, Message-ID: <caednYooy8TEsMHcRVn-rQ@igs.net>   Main, Kerry wrote: >> -----Original Message-----t7 >> From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]k$ >> Sent: September 29, 2004 11:54 PM >> To: Info-VAX@Mvb.Saic.Com/ >> Subject: Re: Tiny pickings for Itanium OEM'sI >> >> David Froble wrote:> >>> Well, as we found out, Alpha NT was a product just as long >> as the platform/ >>> vendor shelled out the funds to make it so.a >>@ >> I am not sure of that. I think that Microsoft was originall;y >> quite opened to@ >> having NT on many platforms. However, at one point, Microsoft >> decided to only6 >> continue on platforms that showed growth potential. >>> >> When Compaq told Gates that i didn't intend to make Alpha a >> growth platform,e? >> Microsft quickly lost interest and told Compaq it woudl onlye >> continue if> >> Compaq paid for it (knowing full well Compaq wouldn't pay). >> >nC > Nope - Dave was correct i.e. Compaq like IBM and MIPS before them E > bailed from supporting Windows on their platforms when the costs ofoD > doing everything with limited MS assistance (marketing, packaging,1 > resources etc) became not a good business case.. >>D > In each case, Microsoft only dropped the platform after the vendor
 > dropped it.D    F Funny....Digital used to brag about the 'fact' that it had the largest number of MSCE's on the planet.   J If memory serves me correctly, didn't Digital have a huge contract with MSI to do Windows customer support out of the Hull/Kanata facilities, ie. you @ called MS but actually spoke with Digital employees for support?   ------------------------------  % Date: Thu, 30 Sep 2004 18:17:16 +0800s From: prep@prep.synonet.comn- Subject: Re: Why does Ghostscript build fail? - Message-ID: <87mzz83vtf.fsf@prep.synonet.com>   / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:r   > Lawrence Bleau wrote: , >> Any hints on where I should go from here?  A > Ghostscript needs a whole bunch or libraries to build properly.r  R > There are prebuilt images of ghistscript which might save you a lot of problems.  O > Note that ghostscript, by itself, does the conversionf rom postscript to manys" > output formats such as jpeg etc.  N There is a copy of Ghostscript tucked away in Dec Document if you have the CDs handy.   -- _< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.'@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 30 Sep 2004 10:07:31 -0400n" From: "Hal Kuff" <kuff@tessco.com> Subject: WRQ OpenVMS Survey-- Message-ID: <cjh3up$88j@library1.airnews.net>r  3 http://websurveyor.net/wsb.dll/12108/OpenVMS_04.htmu   ------------------------------  % Date: Thu, 30 Sep 2004 09:12:20 -07008+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>e Subject: Re: WRQ OpenVMS Surveyo' Message-ID: <415C3064.8060909@MMaz.com>o   Hal Kuff wrote:c  4 >http://websurveyor.net/wsb.dll/12108/OpenVMS_04.htm >  i > E This isn't a survey, this is just gathering contact & marketing data!      Barrym   --    > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                        g   ------------------------------  # Date: Thu, 30 Sep 2004 16:21:36 GMT:/ From: "Jeff Goodwin" <jgoodwin@maine.rrr-r.com>i Subject: Re: WRQ OpenVMS SurveyE7 Message-ID: <koW6d.26442$yg.26087@twister.nyroc.rr.com>.  6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! news:415C3064.8060909@MMaz.com..., > Hal Kuff wrote:s >e6 > >http://websurveyor.net/wsb.dll/12108/OpenVMS_04.htm > >o > >LG > This isn't a survey, this is just gathering contact & marketing data!t >  >  > Barryi >oI I went to the page and the same thought went through my mind.  I searched H for a place to put my requests in for product changes (like resuming LAT support), and found none."   -Jeffa   ------------------------------   End of INFO-VAX 2004.543 ************************