1 INFO-VAX	Thu, 01 Jul 2004	Volume 2004 : Issue 361       Contents: RE: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS RE: A lint Utility for OpenVMS RE: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS RE: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS RE: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler * Re: FTP client to understand ODS-5 volumes* Re: FTP client to understand ODS-5 volumes* Re: FTP client to understand ODS-5 volumes* Re: FTP client to understand ODS-5 volumes* Re: FTP client to understand ODS-5 volumes* Re: FTP client to understand ODS-5 volumes Re: HP AXP 1u Servers = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article * Re: Memory test diags for Alphastation 255 Re: OpenVMS .... no news?  PK* variables for shared scsi ! Re: PK* variables for shared scsi ! RE: PK* variables for shared scsi  Secondary DNS problem ' Re: slap in the face again... thanks HP ' Re: slap in the face again... thanks HP ' Re: slap in the face again... thanks HP ' Re: slap in the face again... thanks HP $ Re: Split I/Os to contiguous file???$ Re: Split I/Os to contiguous file???2 Re: VAX Hardware Support Announcement from NEMONIX1 Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS   F ----------------------------------------------------------------------   Date: 1 Jul 2004 06:00:56 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: RE: A lint Utility for OpenVMS 3 Message-ID: <Kp8D43Qn+37o@eisner.encompasserve.org>   _ In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:   , > If you used PL/I you wouldn't need lint:-)   Likewise for Ada.    And Pascal.   D Is it time to put such C-specific questions in a separate newsgroup,1 presumably called comp.os.vms.self-flagellation ?    ------------------------------  % Date: Thu, 01 Jul 2004 14:07:48 +0200 0 From: Keith Cayemberg <keith.cayemberg@arcor.de>' Subject: Re: A lint Utility for OpenVMS B Message-ID: <40e3fe95$0$21308$9b4e6d93@newsread2.arcor-online.net>   Scott wrote:/ > Does anyone know of a lint utility for DEC C?  > Q > (It would be nice to find one for DEC COBOL, too... but I'm afraid to ask!) :-)  >  > Thank you! > 	 > --Scott   F Aside from the native syntactic and semantic checking capabilities of = the OpenVMS compilers and tools such as DECset PCA LSE/SCA...   H Source Code Analyzer (SCA) is a multilanguage (also COBOL), interactive C cross-reference and static analysis tool. SCA helps you understand  G software projects by enabling you to make inquiries about the contents  D of the code. With SCA, you can quickly locate information about any : program symbol and see the relationships to other symbols.: http://h71000.www7.hp.com/commercial/decset/lse_index.htmlF http://h71000.www7.hp.com/doc/73FINAL/6090/6090_.htm#lang_support_sect2 http://h18000.www1.hp.com/info/SP4229/sp4229pf.pdf: http://h71000.www7.hp.com/commercial/decset/pca_index.html    G I am aware of the following third-party lint-like source code analysis  I SW products which are in some way compatible with OpenVMS SW development  B (mostly running on VMS, but could be a client/server component)...   Cleanscape FortranLint9 http://www.cleanscape.net/products/fortranlint/index.html   / Cleanscape LintPlus C Source Code Analysis Tool 6 http://www.cleanscape.net/products/lintplus/index.html  + CTAGS for Open VMS (Alpha, VAX executables) ' http://www.polarhome.com/ctags/?lang=en  http://ctags.sourceforge.net/    Forcheck http://www.forcheck.nl/   % Gimpel Software - FlexeLint for C/C++  http://www.gimpel.com/  ; LDRA Ltd : Software Development & Testing with LDRA Testbed ' http://www.ldra.co.uk/pages/testbed.htm    Parasoft - Insure++ $ http://www.parasoft.com/jsp/home.jsp Parasoft - Partner Brief5 http://h71000.www7.hp.com/partners/parasoft/index.htm    Pennington - XTRAN4 expert system for symbolic manipulation of languages# http://www.pennington.com/xtran.htm    RTN ANALYZER1 Routine call analyzer for C and BLISS source code  OpenVMS Freeware CD v48 http://h71000.www7.hp.com/freeware/freeware40/ranalyzer/   SYMBOLS 5 Display symbols from .OBJ, .OLB, .EXE, and .STB files  Hunter Goatley's FILESERV < http://vms.process.com/scripts/fileserv/fileserv.com?SYMBOLS   Cheers!    Keith Cayemberg . IBM Business Services GmbH - Hannover, Germany   ------------------------------  * Date: Thu, 1 Jul 2004 13:08:42 +0000 (UTC), From: lewis@PROBE.mitre.org (Keith A. Lewis)' Subject: RE: A lint Utility for OpenVMS . Message-ID: <cc12cq$k84$1@newslocal.mitre.org>   Kilgallen@SpamCop.net (Larry Kilgallen) writes in article <Kp8D43Qn+37o@eisner.encompasserve.org> dated 1 Jul 2004 06:00:56 -0500:` >In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: > - >> If you used PL/I you wouldn't need lint:-)  >  >Likewise for Ada. >  >And Pascal.  L Nobody "needs" lint.  As others have pointed out, DEC C has some pretty goodJ checks built into the compiler.  They get "better" with every release.  SoH much so that upgrading C and C++ compilers has become more work than our) reduced VMS programming staff can handle.   J Ada has all the checks you'd ever want built in.  Pascal may as well, it'sE been 20 years since I used it.  PL/I is not in that category.  If you I substitute a pointer to an integer array for a pointer to some other data L structure, you won't even get a warning.  I'm not saying that's a bad thing,J but that kind of weak type checking is exactly why lint was ever needed in the first place.  E >Is it time to put such C-specific questions in a separate newsgroup, 2 >presumably called comp.os.vms.self-flagellation ?   :^)   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  $ Date: Thu, 1 Jul 2004 06:35:01 -0700# From: "Tom Linden" <tom@kednos.com> ' Subject: RE: A lint Utility for OpenVMS 9 Message-ID: <NDEMLKKEBOIFBMJLCECIAEMJDHAA.tom@kednos.com>      -----Original Message-----5   From: Keith A. Lewis [mailto:lewis@PROBE.mitre.org] '   Sent: Thursday, July 01, 2004 6:09 AM    To: Info-VAX@Mvb.Saic.Com )   Subject: RE: A lint Utility for OpenVMS     ;   Kilgallen@SpamCop.net (Larry Kilgallen) writes in article J   <Kp8D43Qn+37o@eisner.encompasserve.org> dated 1 Jul 2004 06:00:56 -0500:A   >In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom "   Linden" <tom@kednos.com> writes:   > /   >> If you used PL/I you wouldn't need lint:-)    >    >Likewise for Ada.   >    >And Pascal.  B   Nobody "needs" lint.  As others have pointed out, DEC C has some
   pretty good L   checks built into the compiler.  They get "better" with every release.  SoJ   much so that upgrading C and C++ compilers has become more work than our+   reduced VMS programming staff can handle.   L   Ada has all the checks you'd ever want built in.  Pascal may as well, it'sG   been 20 years since I used it.  PL/I is not in that category.  If you K   substitute a pointer to an integer array for a pointer to some other data C   structure, you won't even get a warning.  I'm not saying that's a    bad thing,L   but that kind of weak type checking is exactly why lint was ever needed in   the first place.  E Historically, Lint came about because early C compilers had almost no  SemanticH analysis.  In PL/I,  pointers are a bonafide data type whereas in C theyK are derived from a basic data type.  So in PL/I you don't expect to receive  a I warning when using a pointer in the manner described.  IBM PL/I has added ! attributed pointers as an option,   ! dcl p ptr handle(a);  for example   D and that may be good for certain object oriented programming styles.  G   >Is it time to put such C-specific questions in a separate newsgroup, 4   >presumably called comp.os.vms.self-flagellation ?     :^)   2   --Keith Lewis              klewis {at} mitre.org@   The above may not (yet) represent the opinions of my employer.     --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------   Date: 1 Jul 2004 06:43:03 -0700 - From: soccer13player@yahoo.com (Nom de Plume) ' Subject: Re: A lint Utility for OpenVMS = Message-ID: <f401eb7f.0407010543.2d8415ae@posting.google.com>   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<Kp8D43Qn+37o@eisner.encompasserve.org>...a > In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:  > . > > If you used PL/I you wouldn't need lint:-) >  > Likewise for Ada.  > 
 > And Pascal.  > F > Is it time to put such C-specific questions in a separate newsgroup,3 > presumably called comp.os.vms.self-flagellation ?   * C is for cookie!  It's good enough for me!  ? I have worked on three different OpenVMS systems that had major A applications written in C (manufacturing, telecommunications, and ) financial services).  It all worked fine.   F The key to successful programming is almost never the language.  It is= the processes, procedures, and standards used in development.    JMOD   ------------------------------  $ Date: Thu, 1 Jul 2004 06:55:33 -0700# From: "Tom Linden" <tom@kednos.com> ' Subject: RE: A lint Utility for OpenVMS 9 Message-ID: <NDEMLKKEBOIFBMJLCECIMEMJDHAA.tom@kednos.com>      -----Original Message-----6   From: Nom de Plume [mailto:soccer13player@yahoo.com]'   Sent: Thursday, July 01, 2004 6:43 AM    To: Info-VAX@Mvb.Saic.Com )   Subject: Re: A lint Utility for OpenVMS       ;   Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message  1   news:<Kp8D43Qn+37o@eisner.encompasserve.org>... C   > In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom  "   Linden" <tom@kednos.com> writes:   > 0   > > If you used PL/I you wouldn't need lint:-)   >    > Likewise for Ada.    >    > And Pascal.    > H   > Is it time to put such C-specific questions in a separate newsgroup,5   > presumably called comp.os.vms.self-flagellation ?    ,   C is for cookie!  It's good enough for me!   A   I have worked on three different OpenVMS systems that had major C   applications written in C (manufacturing, telecommunications, and +   financial services).  It all worked fine.    H   The key to successful programming is almost never the language.  It is?   the processes, procedures, and standards used in development.   I Couldn't agree more; however, it is easier to dig a trench with a backhoe  than with a spade.      JMOD      --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004    --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------   Date: 1 Jul 2004 14:35:46 GMT , From: bill@gw5.cs.uofs.edu (Bill Gunshannon)' Subject: Re: A lint Utility for OpenVMS * Message-ID: <2kilq2F2pfuqU2@uni-berlin.de>  9 In article <NDEMLKKEBOIFBMJLCECIMEMJDHAA.tom@kednos.com>, & 	"Tom Linden" <tom@kednos.com> writes: >  >  >   -----Original Message-----8 >   From: Nom de Plume [mailto:soccer13player@yahoo.com]) >   Sent: Thursday, July 01, 2004 6:43 AM  >   To: Info-VAX@Mvb.Saic.Com + >   Subject: Re: A lint Utility for OpenVMS  >    >   = >   Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message  3 >   news:<Kp8D43Qn+37o@eisner.encompasserve.org>... D >  > In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom $ >   Linden" <tom@kednos.com> writes: >  >  1 >  > > If you used PL/I you wouldn't need lint:-)  >  >   >  > Likewise for Ada. >  >   >  > And Pascal. >  >  I >  > Is it time to put such C-specific questions in a separate newsgroup, 6 >  > presumably called comp.os.vms.self-flagellation ? >   . >   C is for cookie!  It's good enough for me! >   C >   I have worked on three different OpenVMS systems that had major E >   applications written in C (manufacturing, telecommunications, and - >   financial services).  It all worked fine.  >   J >   The key to successful programming is almost never the language.  It isA >   the processes, procedures, and standards used in development.  > K > Couldn't agree more; however, it is easier to dig a trench with a backhoe  > than with a spade.  B Depends on the location of the trench.  One size does not fit all.C Use the right tool for the job.  It's a poor workman who blames his B tools.    etc. etc. etc.  If C does a bad job, maybe it wasn't theB right language for the job, or just maybe, the programmer isn't as& good at using it as he thought he was.   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: 1 Jul 2004 10:46:35 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: A lint Utility for OpenVMS 3 Message-ID: <+7cLsym7q+6K@eisner.encompasserve.org>   Y In article <2kilq2F2pfuqU2@uni-berlin.de>, bill@gw5.cs.uofs.edu (Bill Gunshannon) writes:   D > Depends on the location of the trench.  One size does not fit all.E > Use the right tool for the job.  It's a poor workman who blames his D > tools.    etc. etc. etc.  If C does a bad job, maybe it wasn't theD > right language for the job, or just maybe, the programmer isn't as( > good at using it as he thought he was.  A The advantages of higher level languages is that they depend less A on the excellence of the programmer, in particular regarding nits C about the programming language at hand compared to other languages.    ------------------------------   Date: 1 Jul 2004 16:00:08 GMT , From: bill@gw5.cs.uofs.edu (Bill Gunshannon)' Subject: Re: A lint Utility for OpenVMS * Message-ID: <2kiqo8F2rt5vU1@uni-berlin.de>  3 In article <+7cLsym7q+6K@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:[ > In article <2kilq2F2pfuqU2@uni-berlin.de>, bill@gw5.cs.uofs.edu (Bill Gunshannon) writes:  > E >> Depends on the location of the trench.  One size does not fit all. F >> Use the right tool for the job.  It's a poor workman who blames hisE >> tools.    etc. etc. etc.  If C does a bad job, maybe it wasn't the E >> right language for the job, or just maybe, the programmer isn't as ) >> good at using it as he thought he was.  > C > The advantages of higher level languages is that they depend less C > on the excellence of the programmer, in particular regarding nits E > about the programming language at hand compared to other languages.   E While I might agree with the first part I definitely don't agree with G the second.  Unless you are using a totally bullet-proof language (does E one actually exist?) you still have to know what the machine is going G to do when you use any particular structure or feature of the language. F But then, one part of that "excellence of the programmer" would be theG ability to pick the right language for a particular job.  I would never H recommend using C as the first choice for a financials program but then,; I also woudn't recommend COBOL for writting device drivers.    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, 1 Jul 2004 09:16:24 -0700# From: "Tom Linden" <tom@kednos.com> ' Subject: RE: A lint Utility for OpenVMS 9 Message-ID: <NDEMLKKEBOIFBMJLCECIOEMODHAA.tom@kednos.com>      -----Original Message-----5   From: Bill Gunshannon [mailto:bill@gw5.cs.uofs.edu] '   Sent: Thursday, July 01, 2004 9:00 AM    To: Info-VAX@Mvb.Saic.Com )   Subject: Re: A lint Utility for OpenVMS     5   In article <+7cLsym7q+6K@eisner.encompasserve.org>, 2   	Kilgallen@SpamCop.net (Larry Kilgallen) writes:C   > In article <2kilq2F2pfuqU2@uni-berlin.de>, bill@gw5.cs.uofs.edu    (Bill Gunshannon) writes:    > G   >> Depends on the location of the trench.  One size does not fit all. H   >> Use the right tool for the job.  It's a poor workman who blames hisG   >> tools.    etc. etc. etc.  If C does a bad job, maybe it wasn't the G   >> right language for the job, or just maybe, the programmer isn't as +   >> good at using it as he thought he was.    > E   > The advantages of higher level languages is that they depend less E   > on the excellence of the programmer, in particular regarding nits G   > about the programming language at hand compared to other languages.   G   While I might agree with the first part I definitely don't agree with I   the second.  Unless you are using a totally bullet-proof language (does G   one actually exist?) you still have to know what the machine is going I   to do when you use any particular structure or feature of the language.   B Well that is certainly more true for, say, assembler than PL/I andD I guess C fits somewhere in between.  I don't think that you need toH "know what the machine is going to do"  when writing PL/I code, but thenD I am not sure what you are referring to.  Could you cite an example?  H   But then, one part of that "excellence of the programmer" would be theI   ability to pick the right language for a particular job.  I would never J   recommend using C as the first choice for a financials program but then,=   I also woudn't recommend COBOL for writting device drivers.      bill     --L   Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF   bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.   University of Scranton   |@   Scranton, Pennsylvania   |         #include <std.disclaimer.h>     --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------  # Date: Thu, 01 Jul 2004 17:17:31 GMT A From: "Colin Butcher" <colin_DOT.butcher_AT@xdelta_DOT.co_DOT.uk> ' Subject: Re: A lint Utility for OpenVMS < Message-ID: <LGXEc.1116$gp4.9608380@news-text.cableinet.net>  G Now that we have C# (C sharp) as well as C++ I guess we'd be better off H describing C as "C blunt"? I certainly find a blunt instrument handy for- dealing with ill-disciplined C programmers...    --     Hope this helps, Colin. ) colin DOT butcher AT xdelta DOT co DOT uk L Systems Archaeologist - Investigation & troubleshooting of older systems and	 networks.    ------------------------------   Date: 1 Jul 2004 06:12:07 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen)   Subject: Re: DECC /VAXC Compiler3 Message-ID: <PT6PQ6vsaCd2@eisner.encompasserve.org>   F In article <10e757f68jt6u54@corp.supernews.com>, Z <z@no.spam> writes: > Larry Kilgallen wrote:F >> DEC C implements an extended ANSI C and runs on both VAX and Alpha. > > > Which can make badly written code break in rather mysterious? > ways, like having -1 be greater than 100 in a comparison, for 
 > example. > ( > And /STANDARD=VAXC doesn't "fix" this.  1 But switching to a higher level language does :-)    ------------------------------   Date: 1 Jul 2004 07:02:04 -0700 - From: soccer13player@yahoo.com (Nom de Plume)   Subject: Re: DECC /VAXC Compiler= Message-ID: <f401eb7f.0407010602.1acf92a7@posting.google.com>   K Z <z@no.spam> wrote in message news:<10e757f68jt6u54@corp.supernews.com>...  > Larry Kilgallen wrote:G > > DEC C implements an extended ANSI C and runs on both VAX and Alpha.  > > > Which can make badly written code break in rather mysterious? > ways, like having -1 be greater than 100 in a comparison, for 
 > example. > ( > And /STANDARD=VAXC doesn't "fix" this. > = > A few other common gotchas with DEC C are leaving the VAX C ? > .OPT around and linking with VAXCRTL (bad!) and not realizing = > that some functions (socket i/o funcs, IIRC) are not linked , > in properly without the /PREFIX qualifier.  B We ported a major application from VAX to Alpha and had to do someE serious rewrites.  So, I know there is a lot more that has to be done F for complex situations.  However, if one had some simple VAX code thatB was not exactly ANSI and wanted the compiler on an Alpha system toD interpret it like the old VAX compiler, then /STANDARD=VAXC would be appropriate.   JMOD   ------------------------------  # Date: Thu, 01 Jul 2004 14:54:46 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com>   Subject: Re: DECC /VAXC Compiler2 Message-ID: <WAVEc.5168$v13.4629@news.cpqcorp.net>  K "Z" <z@no.spam> wrote in message news:10e757f68jt6u54@corp.supernews.com... > > Which can make badly written code break in rather mysterious? > ways, like having -1 be greater than 100 in a comparison, for 
 > example. > ( > And /STANDARD=VAXC doesn't "fix" this. > &     Would you post an example of this?  :     We know that users are still porting applications from=     VAX C to (DEC/Compaq/HP) C.  If this is an incompatiblity 6     we don't know about, it's difficult for us to fix.       Ed Vogel     HP C Engineering.    ------------------------------  # Date: Thu, 01 Jul 2004 17:13:38 GMT # From: hoff@hp.nospam (Hoff Hoffman)   Subject: Re: DECC /VAXC Compiler2 Message-ID: <6DXEc.5180$o83.4318@news.cpqcorp.net>  F In article <10e757f68jt6u54@corp.supernews.com>, Z <z@no.spam> writes: :Larry Kilgallen wrote: F :> DEC C implements an extended ANSI C and runs on both VAX and Alpha. : = :Which can make badly written code break in rather mysterious > :ways, like having -1 be greater than 100 in a comparison, for	 :example.   ?   The compiler has flagged that coding error for some time now. -   Diagnostics continue to improve, of course.   < :A few other common gotchas with DEC C are leaving the VAX C, :.OPT around and linking with VAXCRTL (bad!)  @   I haven't tried this in some time, but I'd expect the contentsA   of the VAX C RTL to be ignored by the linker as the symbols are >   not prefixed and thus not referenced.  This gets ugly on the>   compilations not using the typical library symbol prefixing.  A                                             ... and not realizing < :that some functions (socket i/o funcs, IIRC) are not linked+ :in properly without the /PREFIX qualifier.   @   The /PREFIX processing has been moving for some time now, and A   the particular compiler behaviour cited was corrected some time -   ago.  The FAQ covers some of this, as well.   B   There have been extensive changes in newer C run-time libraries,@   as well -- I hadn't read the manual in some time and was quiteA   surprised at the number and the scale of the added routines and    features.   A   Of course the best approach for all this does obviously involve B   reading the available documentation, including the VAX C portingC   guide available within the HP/Compaq/DEC C for OpenVMS VAX manual $   set should VAX C code be involved.    N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  % Date: Thu, 01 Jul 2004 10:42:36 +0100 * From: Nic Clews <sendspamhere@[127.0.0.1]>3 Subject: Re: FTP client to understand ODS-5 volumes ' Message-ID: <cc0mes$is6$1@lore.csc.com>    Carl Karcher wrote:  > I > Any suggestions for a GUI FTP client (for Windows) that will understand J > ODS-5 filenames when used with the FTP server on TCPIP V5.4? There was aD > previous post about Mozilla being fixed to handle VMS ftp servers:  ? We're hosting documents from our Intranet webserver on VMS with E documents generated on UNIX and Windows platforms, and we're using an @ ODS5 volume and in general command line FTP to do the transfers.  F I've noticed a bug in the FTP handling where it throws out an error ofE "not being authorized" where in reality it can't handle the filenames B without having the correct parse style on the process in question.    I'll get around to it. Sometime.   --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  $ Date: Thu, 1 Jul 2004 07:20:23 -0600. From: "Michael D. Ober" <mdo.@.wakeassoc..com>3 Subject: Re: FTP client to understand ODS-5 volumes . Message-ID: <zcUEc.3$aq.12993@news.uswest.net>  2 I use WS-FTP against both ODS-2 and ODS-5 volumes.  
 Mike Ober.  + "Dirk Munk" <munk@home.nl> wrote in message , news:cc07ol$33m$1@news1.tilbu1.nb.home.nl... > Carl Karcher wrote: K > > Any suggestions for a GUI FTP client (for Windows) that will understand L > > ODS-5 filenames when used with the FTP server on TCPIP V5.4? There was aF > > previous post about Mozilla being fixed to handle VMS ftp servers: > > 7 > >  http://bugzilla.mozilla.org/show_bug.cgi?id=151501  > > J > > But this only appears to work for ODS-2 type file names (at least withD > > Mozilla V1.7). I might re-open that bug - just looking for other
 > > ideas. > > K > > -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison 9 > > --                karcher.nomorespxm@waisman.wisc.edu  >  > I > You could give WS-FTP a try. A have a rather old pre ods5 lite version,  and evenJ > that is capable of using ods5 names! (I did not do extensive trials, but" > lowercase names etc. work fine). > - > Get more info here: http://www.ipswitch.com  >  >    ------------------------------   Date: 1 Jul 2004 13:43:54 GMT & From: Frank da Cruz <fdc@columbia.edu>3 Subject: Re: FTP client to understand ODS-5 volumes 7 Message-ID: <slrnce858q.1bf.fdc@sesame.cc.columbia.edu>   D On 2004-06-30, Carl Karcher <karcher@thuria.waisman.wisc.edu> wrote:I : Any suggestions for a GUI FTP client (for Windows) that will understand J : ODS-5 filenames when used with the FTP server on TCPIP V5.4? There was aD : previous post about Mozilla being fixed to handle VMS ftp servers: : 5 :  http://bugzilla.mozilla.org/show_bug.cgi?id=151501  : H : But this only appears to work for ODS-2 type file names (at least withB : Mozilla V1.7). I might re-open that bug - just looking for other : ideas. : G Why should the client need to understand server-side names for purposes 2 of GET, MGET, PUT, MPUT, CD, etc?  It's just text.  K The problem is that GUI FTP clients get server-side file lists by sending a L LIST command to the server and then parsing the result, thus every client onH every platform must understand the directory-listing format of every FTPK server on every other platform, and all must be recoded when things change. H What a dumb idea.  This is, for example, why the built-in FTP clients of2 some Web browsers don't work with VMS FTP servers.  F The right way to have done this would have been for the server to sendK tagged information: filename=xxxx, date=xxxx, size=xxxx, etc, in a standard I format.  There has been some progress on this front, notably the addition G of MLSD to the FTP specification.  It's not perfect, but it's a step in  the right direction (sort of):  ,   http://www.columbia.edu/kermit/newftp.html  L Given a mechanism like this, servers and clients don't have to know anythingD about each other's file systems or naming conventions.  Which is howD platform-independent open networking standards are supposed to work.   - Frank    ------------------------------  * Date: Thu, 1 Jul 2004 09:13:15 -0500 (CDT) From: sms@antinode.org3 Subject: Re: FTP client to understand ODS-5 volumes ) Message-ID: <04070109131585@antinode.org>   & From: Frank da Cruz <fdc@columbia.edu>  I > Why should the client need to understand server-side names for purposes 4 > of GET, MGET, PUT, MPUT, CD, etc?  It's just text.  D    One reason might be that a VMS DIRECTORY listing for an ODS5 fileH system tends to provide a name like "a^.b.c;1" or "a^_b^_c.d;1", while a/ non-VMS user might prefer "a.b.c" or "a b c.d".   A    Everything's complicated, I always say.  Of course, for a real : nightmare, I prefer trying to parse a UNIX "ls -l" report.  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------   Date: 1 Jul 2004 16:05:22 GMT & From: Frank da Cruz <fdc@columbia.edu>3 Subject: Re: FTP client to understand ODS-5 volumes 7 Message-ID: <slrnce8di2.hcp.fdc@sesame.cc.columbia.edu>   9 On 2004-07-01, sms@antinode.org <sms@antinode.org> wrote: ( : From: Frank da Cruz <fdc@columbia.edu> : J :> Why should the client need to understand server-side names for purposes5 :> of GET, MGET, PUT, MPUT, CD, etc?  It's just text.  : F :    One reason might be that a VMS DIRECTORY listing for an ODS5 fileH : system tends to provide a name like "a^.b.c;1" or "a^_b^_c.d;1", while3 : a non-VMS user might prefer "a.b.c" or "a b c.d".  : E But how can an FTP client be expected to convert between the filename G notation of its own platform (say, Windows) and every other platform on I earth?  Obviously it can't, and anyway nowadays most people who write FTP * clients assume the server is Unix, period.  H The idea of having a common intermediate representation for filenames isK appealing but will probably never happen.  So to get file from an ODS5 file K system, the user of Windows client will have to know how to spell its name. A The same holds for wildcards -- there has never been an effort to E standardize filename-matching patterns across different platforms and G file systems, so the user of the client is obliged to know the server's 	 notation.   J A standard syntax for pathnames, on the other hand, is pretty much alreadyG upon us: it is Unix notation, used already in URLs and in "TVFS" -- the H Trivial Virtual File System implemented in increasingly many FTP clientsG and servers, and perhaps by some VMS ones, so that "get subdir/foo.bar" . would be equivalant to "get [.subdir]foo.bar".  C :    Everything's complicated, I always say.  Of course, for a real < : nightmare, I prefer trying to parse a UNIX "ls -l" report. : I No kidding.  To get a structured list of filenames and properties from an H ODS5 server, or any other file system, the client and server should both implement MLSD.    - Frank    ------------------------------   Date: 1 JUL 2004 14:07:49 GMT 4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)3 Subject: Re: FTP client to understand ODS-5 volumes 5 Message-ID: <1JUL04.14074949@thuria.waisman.wisc.edu>   J In a previous article, David J Dachtera <djesys.nospam@comcast.net> wrote: . F ->Would that not be more a function of the VMS-side server than of the	 ->client?   H You mean like having a switch to tell the server to format the output soG it looks like unix to the client? Sure that would be great and MultiNet E has it (TCPIP doesn't). I didn't want to wait for hell to freeze over 4 though so I thought I'd inquire about clients first.  G If WS_FTP can handle the output as some have indicated I'd be thrilled. 0 I've tried an old version of WS_FTP that didn't.   Thanks for the responses.    --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison 8 --                 karcher.demungthis@waisman.wisc.edu     ------------------------------  * Date: Thu, 1 Jul 2004 10:56:42 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: HP AXP 1u Servers) Message-ID: <cc0qla$8fh$1@news.mdx.ac.uk>   i In article <newscache$wi450i$v58$1@news.sil.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:fo >In article <f30679fb.0406300847.119a3bab@posting.google.com>, fabiopenvms@yahoo.com.br (Fabio Cardoso) writes: 6 >>Our beloved HP dont develop 1U AXP servers anymore ? >>/ >>http://h18002.www1.hp.com/alphaserver/ds.htmln >s >Yup. And this not new.TD >Remember Alpha is now for OpenVMS only and OpenVMS is not commodity- >and also seems not destined for entry level.v >m  ) You can still buy TRU64 systems on Alpha.'  
 David Webb VMS and Unix team leader CCSS Middlesex University  I >But used DS10L 6/466 (probably from some TELCOs) were sold in quantitiesn >for $300 on EBAY last year.C >I got a DS10 for about $620 (but I missed the 512MB DIMMs for $1!)e >t >So, what was your point ? >- >--  >Peter "EPLAN" LANGSTOEGER& >Network and OpenVMS system specialist >E-mail  peter@langstoeger.ateG >A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realista   ------------------------------  # Date: Thu, 01 Jul 2004 06:53:00 GMTt/ From: JF Mezei <"jfmezei"@spamnot@teksavvy.com>rF Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <5d5f67704f5eaf2cd2f6c2ec8b15666f@news.teranews.com>   Rob Young wrote:P >         $55 million total in Itanium Altix supercomputer sales to 2 customers.  I Woopty doo. 2 customers. Alpha had more and Compaq found a way to kill ita$ because it wasn't widespread enough.    F >         Three days ago, Fujitsu and Microsoft announce a significantK >         expansion of their partnership - Fujitsu an Itanium server maker.   N Yep, but Fujutsu hasn't bet its business on that IA64 thing. It does plemty of othe servers too.   H >         Oh - don't forget that Hitachi, Unisys, Dell and IBM will mostL >         likely have a fit when Itanium "goes away" as they too manufacture >         Itanium boxes.  N They won't have a fit. Dell doesn't want IA64, it has to have it, probably dueN to its relationship with Intel. Dell have stated many times that they are onlyK interested in high volume platforms where theyt can get good efficiency andd low cost for building/assembly.A  J The above companies see IA64 as a necessary evil to secure a good relationM with their their 8086 chip suppliers. Dell and IBM are certaintly not betting- their business on IA64.a  H Heck, even HP isn't betting its business on IA64 since their business isL primarily 8086 based, and they have the big printer business that subsidizesH the wintel area. Carly is very much a consumer oriented person. HP wantsG consumer product visibility, Carly doesn't want to be in the enterpriseoM obscurity because there isn't much limelight there to enhance the reflectionst on her hair.  L And apart from HP, who else has decided to port their proprietary OS to IA64 and dump other platforms ?  F Folks like Hitachi and Unisys who just do Unix don't really care aboutL platform switch since they can find a varsion of Unix that runs for whatever platform they choose.p   ------------------------------  # Date: Thu, 01 Jul 2004 06:57:00 GMTd/ From: JF Mezei <"jfmezei"@spamnot@teksavvy.com>bF Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <381a0949de8573364fe44b524775ffca@news.teranews.com>   Rob Young wrote:Q > > My guess is that 3 years from now, Intel may release an IA64 emulator runningpF > > on an 8086 (instead of the original plan to emulate 8086 on IA64). > I >         But that would be very difficult given that Intel is projectingW8 >         50-100% greater performance Itanium vs. Xeon.     Y Yeah, just liek Intel was projecting that Merced would have truly impressive performamce.e  B Fact is that AMD will force Intel to keep the 8086 way up there inK perfornmance, otherwise Intel will lose its bread and butter business. As a.D result, it is very very unlikely that the 8086 would have such a bad$ performance compared to other chips.  L And 3 years down the road, if AMD starts to sell 8086s that have whatever itN takes to build multi-CPUultra fast machines (SMP etc), then Intel will also beL forced to sell similar 8086s, and that will evaporate any advantage IA64 mayK have had in certain niches where IA64 had features that neither Intel's norj AMD's 8086 had.r   ------------------------------  % Date: Thu, 01 Jul 2004 01:35:05 -0400n( From: David Froble <davef@tsoft-inc.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <40E3A289.7020300@tsoft-inc.com>   JF Mezei wrote:M  ! > david20@alpha2.mdx.ac.uk wrote:h > L >>"Internally, Intel has basically given up hope on IPF becoming the defactoQ >>64-bit architecture until Tukwilla in 2007. From the specs being bandied about,fN >>that chip looks to be another marvel (pun intended) from the Alpha team, but2 >>between now and then, there is precious little." >> >  > N > IA64 may look much better in 3 years compared to IA64 today. Few people will > debate this. > L > The *REAL* question is whether IA64 will progress as fast as its competingL > chips such as Power, 8086 and even Sparc during that period. And one could> > argue that it needs to progress faster in order to catch up. > M > 3 years from now, how will IA64 perform compared to whatever Power offers 3> > years from now ? > G > Remember that it was those very Alpha developpers that gave all thosesP > presentations on how IA64 was a bad archictecture that would be very difficultN > to move as quickly as cleaner architectures. So no matter how good the alphaN > guys are, if they are tasked to help improve a bad architecture, there is noP > way that they can work the same miracles as they would have been able to do on > a nice clean architecture.    N With the recent cancellations of some projected chips/projects/whatever, it's Q possible that Intel is accepting that their design is a loser, and may be giving wQ the designers more latitude in what they come up with.  Might not be EPIC.  Hey,  + those cancellations have to mean something.e    ' > IA64 will NEVER be industry standard.t    L I used to feel this way.  Now I wonder a bit.  With the exception of IBM it Q seems nobody wants to be in the CPU business.  If Intel is the only game in town?   ) > That "just wait 3 years" statement fromsM > Intel is yet another "IA64 may not be impressive now, but wait X years, and39 > you'll see" statements. Heard those many times already.R    Q I agree with you on the 'just wait' garbage.  "Just wait until windows is ready" m	 and such.-    L > 3 years from now, the 8086 will probably become enterprise ready, at whichG > point HP will slowly and quietly start to migrate to it to reduce itsu: > dependance on the IA64 which will eventually be retired.    J Regardless of it's volume, x86 is garbage.  Surely we can hope for better.     Dave   -- u4 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, 1 Jul 2004 13:43:01 +0200  From: "Dr. Dweeb" <dr@dweeb.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <cc0tbr$mak$1@news.cybercity.dk>   JF Mezei" <"jfmezei wrote:! > david20@alpha2.mdx.ac.uk wrote:aE >> "Internally, Intel has basically given up hope on IPF becoming thelE >> defacto 64-bit architecture until Tukwilla in 2007. From the specsaA >> being bandied about, that chip looks to be another marvel (punrD >> intended) from the Alpha team, but between now and then, there is >> precious little." >' > B > IA64 may look much better in 3 years compared to IA64 today. Few > people will debate this. > B > The *REAL* question is whether IA64 will progress as fast as its@ > competing chips such as Power, 8086 and even Sparc during thatG > period. And one could argue that it needs to progress faster in order  > to catch up. >'D > 3 years from now, how will IA64 perform compared to whatever Power > offers 3 years from now ?  >tG > Remember that it was those very Alpha developpers that gave all those F > presentations on how IA64 was a bad archictecture that would be veryE > difficult to move as quickly as cleaner architectures. So no matter G > how good the alpha guys are, if they are tasked to help improve a badeG > architecture, there is no way that they can work the same miracles ase? > they would have been able to do on a nice clean architecture.s >r@ > IA64 will NEVER be industry standard. That "just wait 3 years"F > statement from Intel is yet another "IA64 may not be impressive now,F > but wait X years, and you'll see" statements. Heard those many times
 > already.  J Can anyone show me anywhere in writing where INTEL (not HP) have said thatH EPIC will become "industry standard", as distinct from a high end server# chip for specialised applications ?y   >hF > 3 years from now, the 8086 will probably become enterprise ready, atB > which point HP will slowly and quietly start to migrate to it toE > reduce its dependance on the IA64 which will eventually be retired.n   ------------------------------   Date: 1 Jul 2004 05:14:47 -0700t' From: icerq4a@spray.se (David Svensson)cF Subject: Re: Intel Itanium's very survival in doubt - inquirer article= Message-ID: <734da31c.0407010414.40dc7918@posting.google.com>   w JF Mezei <"jfmezei"@spamnot@teksavvy.com> wrote in message news:<ab9909d6c39f96583acb3ea53bf77f9a@news.teranews.com>...! > David Svensson wrote:!G > > I don't expect that. It has been obvious for atleast 4-5 years thatlI > > Itanium would not replace x86. Intel wanted a high-end chip with highe8 > > profit, otherwise they would have cancelled in 2001. > N > Not quite. Initially, IA64 was to have replaced the 8086 completely for bothC > desktop and server (which is one reason they spent so much effort 2 > incorporating an 8086 inside the the first IA64.  = When I watched Intel presentations in 1997/1998 there were no E sightings that Intel wanted to discontinue x86. IA64 was at that timeOF not planned to be a desktop CPU. There may have been hopes before that1 time that IA64 would dominate the desktop though.o  D About 8086 inside, "spent so much effort" is not correct. They couldE have spent a whole lot more time/money on doing it better, apparentlye* they didn't want to or were short of time.   > N > When they realised that IA64 was an uncompetitive architecture (cost/time toO > develop, heat generation, compiler complexity etc), Intel did admit that IA64 J > would not become industry standard (aka: would not replace the 8086). ToP > anyone without any financial ties to Intel, that was a clear message that IA64L > had little future and gave much more credibility to all the statements pre> > June 25 from Digital Alpha engineers on how flawed IA64 was.  ? I think you are confusing the IA64 architecture and the currenttC Itanium implementation. Yes, there have been problems, but the heate= generation and being "uncompetitive" are not tied to the IA64s
 architecture.e  C That the Alpha team people disliked IA64 was pretty understandable,rD they had a different view on how things should be done and they were competitors.  N > And not so long ago, someone here posted a link to some hour long video of aM > presentation by an ex Intel 8086 engineer. He also tended to agree with the6! > Alpha engineer's views on IA64.   F Yes, altough I think he is rather positive to Itanium considering that he is a x86 P6 architect.   I > Companies who have a financial stake in IA64 (HP, INTEL and a couple of-O > others) cannot publicly tell the truth since it would ruin their own companmyuP > if they admitted that they had made a wrong technological decision and bet theM > company of a failed architecture. So naturally, you'll continue to see spino, > from the likes of HP and Intel about IA64.  E The problem with IA64 has very little do with the architecture or howcD it performs. There is no major problem there. The problem is that it@ is a new archicture and it is in todays environment very hard toD introduce a new archicture. All the other current architecture would+ have exactly the same problems of adoption..  O > My guess is that 3 years from now, Intel may release an IA64 emulator runningmD > on an 8086 (instead of the original plan to emulate 8086 on IA64).  E There has been hints over time that Intel would make a CPU that could>C execute both x86 and IA64 code, but not through emulation on one ofq9 the other, but more like the current P4 style of decodingc
 instructions.-   ------------------------------   Date: 1 Jul 2004 06:51:27 -0700 ( From: bob@instantwhip.com (Bob Ceculski)F Subject: Re: Intel Itanium's very survival in doubt - inquirer article< Message-ID: <d7791aa1.0407010551.5112e25@posting.google.com>  \ David Froble <davef@tsoft-inc.com> wrote in message news:<40E3A289.7020300@tsoft-inc.com>... > > I > > Remember that it was those very Alpha developpers that gave all thoseoR > > presentations on how IA64 was a bad archictecture that would be very difficultP > > to move as quickly as cleaner architectures. So no matter how good the alphaP > > guys are, if they are tasked to help improve a bad architecture, there is noR > > way that they can work the same miracles as they would have been able to do on > > a nice clean architecture. >  > P > With the recent cancellations of some projected chips/projects/whatever, it's S > possible that Intel is accepting that their design is a loser, and may be giving hS > the designers more latitude in what they come up with.  Might not be EPIC.  Hey,  - > those cancellations have to mean something.- >  > ) > > IA64 will NEVER be industry standard.: >  > N > I used to feel this way.  Now I wonder a bit.  With the exception of IBM it S > seems nobody wants to be in the CPU business.  If Intel is the only game in town?k > + > > That "just wait 3 years" statement from O > > Intel is yet another "IA64 may not be impressive now, but wait X years, andd; > > you'll see" statements. Heard those many times already.o > S > I agree with you on the 'just wait' garbage.  "Just wait until windows is ready" n > and such.h > N > > 3 years from now, the 8086 will probably become enterprise ready, at whichI > > point HP will slowly and quietly start to migrate to it to reduce itse< > > dependance on the IA64 which will eventually be retired. > L > Regardless of it's volume, x86 is garbage.  Surely we can hope for better. >  > Dave  ; windoze already runs on alpha ... does that mean EV8 debuts . in 2007?  Maybe I was right after all Bill! :)   ------------------------------  $ Date: Thu, 1 Jul 2004 10:58:06 -0400# From: "John Smith" <a@nonymous.com>KF Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <8pidnYVCgsPiu3nd4p2dnA@igs.net>   David Froble wrote:. >  <major snip> > D > Regardless of it's volume, x86 is garbage.  Surely we can hope for	 > better.l    9 Unlikley as long as that's where Intel butters its bread.    ------------------------------  $ Date: Thu, 1 Jul 2004 11:10:47 -0400# From: "John Smith" <a@nonymous.com>oF Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <E4KdnWEfr6vktHndRVn-ug@igs.net>   David J Dachtera wrote:e > Dave Gudewicz wrote: >>F >> Our VMS Ambassador, fresh back from VMSland in Nashua, NH said this >> at our June LUG meeting:m >>A >> Nothing is finalized yet, but you'll be really, really, really G >> pleased with what Itanium VMS will cost.  I said: "you used really 3 ! >> times".  His answer: "I know".c >l > Well, FFO! >iE > Now, all they need to do is shrink-wrap it along with the licensingiE > forms and voila! VMS can be put on the computer store shelves alongt > side Micro$lop and Linux!r >o& > *SLAP* Wake up, DJ! You're dreaming!    E Right alongside the 'OpenVMS for Newbies' book we are going to write.t  K Chapter 1 - Just Call It VMS (it's been called that for over 25 years - whyw change now? 1 page)s= Chapter 2 - VMS vs. Windows and Unix/Linux (beginner version)i' Chapter 3 - Booting  For The First Timec, Chapter 4 - Installing the O/S (if you must)5 Chapter 5 - How Licences Work (really boring chapter)n" Chapter 6 - Basic System Managment) Chapter 7 - How 'Bout Those Applications?-   etc....a  * (c) 2004, John Smith. All Rights Reserved.   ------------------------------  $ Date: Thu, 1 Jul 2004 12:19:55 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <1cGdnc3uNb7upHnd4p2dnA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:Wx53FusOnG45@eisner.encompasserve.org...eK > In article <ab9909d6c39f96583acb3ea53bf77f9a@news.teranews.com>, JF Mezeii( <"jfmezei"@spamnot@teksavvy.com> writes: >qK > > Companies who have a financial stake in IA64 (HP, INTEL and a couple of H > > others) cannot publicly tell the truth since it would ruin their own companmyJ > > if they admitted that they had made a wrong technological decision and bet thetJ > > company of a failed architecture. So naturally, you'll continue to see spin. > > from the likes of HP and Intel about IA64. > > I > > My guess is that 3 years from now, Intel may release an IA64 emulatorl runningsF > > on an 8086 (instead of the original plan to emulate 8086 on IA64). >tA > But that would be very difficult given that Intel is projectingcA > 50-100% greater performance Itanium vs. Xeon.  Xeon64 certainlyt6 > won't be a candidate to run the much faster Itanium.  J You're confused as usual, Rob.  If you read the article which you yourselfF cited, it makes it clear that Itanic is not anticipated to have betterJ *per-core* performance than Xeon (even 3 years from now, and given Intel'sJ rather abysmal history of predicting relative Itanic performance one mightK take that with a large grain of salt) - it will just have more cores on the B chip, hence higher *aggregate* chip performance for those who have9 readily-partitionable loads suitable for multi-threading.n  K Many servers do run such loads.  But for single-thread loads, it's entirelyhG possible that Xeon could emulate Itanic with acceptable performance (at L least if Xeon's 64-bit performance is somewhere nearly as good as Opteron's,+ something which has yet to be ascertained).   F Given the relatively negligible market penetration that Itanic enjoys,J emulating the few applications that might not be at least equally happy toF run natively on AMD64 might be eminently feasible as an alternative to. continuing to pour money down the Itanic hole.   ...o  L > Intel says flat out that the goal for Itanium is for the family of serversD > based on it to use as many of the same components that there is no disparity inL > pricing. By 2007, Intel wants Itanium machines to have pricing parity, and toJ > have twice the cores on a die, twice the performance, and twice the bang for: > the buck.   I Of course, that projection doesn't take into account competitive pressure K from Opteron.  Whether Itanic systems in 2007 will be priced at parity withlK Xeon systems that have been subject to such Opteron pricing pressure is thei real question.   ...   ? > Hey... if nothing else it will put the remaining RISC CPUs iniC > a brutal position (Power + SPARC and maybe I'm being presumptuouse? > anticipating SPARC being "not canceled" in 3 years) with very > > high performance and much cheaper cost (versus Power/SPARC).  H Selling futures as usual, Rob.  IIRC Itanic was supposed to have put itsJ RISC competition in a brutal position some years ago, and when that didn'tJ happen it was predicted certainly to have done so by now.  Plus ca change, plus c'est la meme chose.Q   - bill   ------------------------------  $ Date: Thu, 1 Jul 2004 12:41:46 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <a4ydncw1CIUJo3ndRVn-vw@metrocast.net>  5 "David Froble" <davef@tsoft-inc.com> wrote in message & news:40E3A289.7020300@tsoft-inc.com...   ...   J > I used to feel this way.  Now I wonder a bit.  With the exception of IBM it/ > seems nobody wants to be in the CPU business.   K Sun clearly still does:  otherwise, under its current pressures it would be J heading full-tilt toward AMD64 rather than pressing forward on 3 differentE SPARC fronts (two internally for the future, plus one using Fujitsu's87 current - and eminently respectable - SPARC64 product).   % >  If Intel is the only game in town?n  G Let's not forget AMD, either.  So far, there's no significant area thataH Opteron doesn't address better than Itanic (save for the current lack ofJ large Opteron systems, something which at least Sun is working on and bothL IBM and Unisys could address quickly with variants of their 32-processor x86K platforms; Itanic also leads it in FP performance, but not in per-dollar orsI per-Watt performance, which are also significant metrics).  And while oneuJ can question whether AMD has the production capacity to drive Intel out ofG the x86 business, there's no quesiton whatsoever that it has sufficient C capacity to drive Intel out of the Itanic business (such as it is).h   ...   L > Regardless of it's volume, x86 is garbage.  Surely we can hope for better.  J While the x86 ISA carries a quarter-century's worth of historical baggage,I I'll suggest that it still manages to move it along right smartly (thoughmB competing with architectures which have had nowhere nearly as muchH development funding helps explain a lot of that).  Opteron's on-chip RASG features are quite respectable (Xeon's may be as well - I'm just not as L familiar with them), and the use of HT as the chip interconnect makes a wide1 variety of system configurations easy to achieve.   L So while the ISA may be ugly it gets the job done, and while desktop systemsG may cut a lot of quality corners it's entirely possible to build serveraL systems that can hold up their heads with the best of the RISC crowd.  Sure,K something better would be nice (and Alpha certainly offered it, though it'sCI much more debatable whether Itanic does, or even will in 2007), but there1H are at least some compensating advantages in having development that can) leverage commodity volumes to support it.8   x86 does not imply Windows.e   - bill   ------------------------------  % Date: Thu, 01 Jul 2004 14:02:16 +0800 , From: Paul Repacholi <prep@prep.synonet.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <871xjw6z9z.fsf@k9.prep.synonet.com>  - young_r@encompasserve.org (Rob Young) writes:   ; > 	So how soon before we read the above OEMs are abandoningw= > 	Itanium?  Sure... and we will hear about that soon, right?h  D Well, I don't know if you will, but I've read those reports already.  " Seen a M$ 64 bit roadmap recently?   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.o@                                              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, 01 Jul 2004 10:56:59 +0100 * From: Nic Clews <sendspamhere@[127.0.0.1]>3 Subject: Re: Memory test diags for Alphastation 255u' Message-ID: <cc0n9u$j27$1@lore.csc.com>    Z wrote: > < > I've got a AS 255 (OVMS 7.1-2) that's crashing weekly with= > Kernel Stack Invalid errors.  There's no crash dump to lookm? > at and bumping MIN_KSTAKPAGES from 4 to 8 made no difference.h > = > Firmware is old, latest patches are not installed, but this @ > was running fine a year ago.  And the application it's running > hasn't changed since then. >  > I suspect bad memory.d > 2 > What's the best way to test the system's memory?  	 Power on.   H If you were seeing memory errors, you'd likely see MACHINECHECK crashes.D VMs does a good job of maintaining data integrity, and in particularC it's memory structures, and distinguishing the difference between a-. software corruption and a hardware corruption.  F Yes, I'd advise you update the firmware, I have seen some cases where,E for an indeterminate reason, it was necessary to stop errors or other2H behaviour. And be aware that if the firmware is TOO old on a system, youC really need an original firmware disk, some early firmware on earlyc) systems just is not happy with CDR media.u  E Of course you may need to increase the kernel stack pages again. Some-F outside influences may potentially be noisy networks, depending on howH you are configured, you may be asking a lot of your system and it is not
 its fault. -- t? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesn nclews at csc dot como   ------------------------------  # Date: Thu, 01 Jul 2004 17:07:39 GMTd! From: Nigel Barker <nigel@hp.com>b" Subject: Re: OpenVMS .... no news?8 Message-ID: <00e8e01t97pqkjns6ok71rmp5em5hbs900@4ax.com>  N On Thu, 1 Jul 2004 00:22:34 -0400, "Bill Todd" <billtodd@metrocast.net> wrote:  I >Gee - I can so clearly remember the time when it was stated that the VMSCJ >head count would be doubled precisely to avoid any negative impact of theI >port on on-going development (such as it was - back in 2001 there was atrL >least a continuing pretense that reasonably robust development activity was >still on the agenda).  N You are wrong on this. Nobody ever promised to double the headcount of OpenVMSP Engineering. Mainly because there never was any need to double resources for theO Itanium port. This port is not like VAX to Alpha where basically the VMS sourcesO code was given over to a few hundred engineers who sat down for 2-3 years doingeM the port while another bunch of engineers got on with enhancing VAX/VMS. ThisbG time it is common source code. The number of engineers involved in workzN necessary to allow the port to go ahead was around 30-40. They spent all theirM time figuring how to boot etc & by the way updating & modernising some of thetO internals (like ELF image format). Once VMS had booted the work done on Alpha &CP the work done on Itanium is the same, mainly a question of conditionalising code? with a tiny fraction written specifically for the new platform.A  A >> http://h71000.www7.hp.com/openvms/roadmap/openvms_roadmaps.html >fL >My, what an interesting document this continues to be.  Double-speak at itsK >best.  For example, it's so encouraging to see that the VMS port to Itanic-L >is 'exceeding expectations', despite a projected production-quality releaseE >date that has now slipped to Q4 (which itself is still not the 'fullo9 >functionality' release:  that's 8.3, some time in 2005).e  N The production quality release has always been targeted for the second half of 2004.s   > in particular L >> read the notes for more detailed information about what new features turn >upP >> when. >PM >Hmmm.  Sometimes .ppt files have readable notes.  I tend to prefer less MSsyt6 >formats like .pdf myself, so I must have missed them.   <snip>  J >But, as I noted, I have not read the notes that you mentioned.  So please9 >feel free to inform us of the wonderful details therein.i  M The kind of level of detail on enhancements to OpenVMS is as in the paragraphnO below. I really urge you to actually read the notes accompanying the PowerpointbP presentation rather than rely on me regurgitating the details in this newsgroup.  E "In VMS 8.2 the OpenVMS C Run-Time Library will include the followingl
 enhancements:eK Implement new file Lock APIs: flockfile(), funlockfile() and ftrylockfile()o& statvfs() and fstavfs file system APIsP The stat structure will be enhanced to be standard compliant for ease of porting UNIX applications O fcntl():  This file control API has been enhanced to provide the ability to sete: and get file control flags via F_SETGL and F_GETFL optionsN pipe() enhanced to provide an optional stream oriented implementation for UNIX compatibility"       -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  $ Date: Thu, 1 Jul 2004 07:03:17 -0700# From: "Tom Linden" <tom@kednos.com>t& Subject: PK* variables for shared scsi9 Message-ID: <NDEMLKKEBOIFBMJLCECIGEMKDHAA.tom@kednos.com>o  8 Need some enlightenment on pk*0_disconnect and pk*0_fast   Have following config.  +            ____________LAN_________________r+           |        |        |             |e.        Node A   Node B   Node C  ...    Node K        XP1000   XP1000   XP1000c!        VMS7.3   VMS7.3-1 VMS7.3-2            |        |        |i           |  SCSI  |  BA356 |u           -------------------h           |        |        |a          SHDW X   SHDW Y   SHDW Z     Physically connected as follows   4              BA356            A             B      C5                 \            / \           / \    / \dC                  \__________/   \_________/   \__/   \__ Terminatort    < http://h71000.www7.hp.com/doc/732FINAL/6318/6318pro_021.html! Table 6.2 describes the following  pk*0_disconnecte  L Allows the target to disconnect from the SCSI bus while the target acts on aB command. When this parameter is set to 1, the target is allowed toK disconnect from the SCSI bus while processing a command. When the parameter I is set to 0, the target retains control of the SCSI bus while acting on a  command.    	 pk*0_fast   G Enables SCSI adapters to perform in fast SCSI mode. When this parameternF is set to 1, the default speed is set to fast mode; when the parameter) is 0, the default speed is standard mode.a    J Now the BA356 is constrained to 40MB even though the drives themselves are capable of 160.   L So my questions are (1) what is the best setting for these two variables andC (2) must they be the same on all the nodes that are scsi connected?R   Tomn --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------  $ Date: Thu, 1 Jul 2004 16:52:29 +0100* From: "Richard Brodie" <R.Brodie@rl.ac.uk>* Subject: Re: PK* variables for shared scsi+ Message-ID: <cc1bvu$ugm@newton.cc.rl.ac.uk>t  b "Tom Linden" <tom@kednos.com> wrote in message news:NDEMLKKEBOIFBMJLCECIGEMKDHAA.tom@kednos.com...  - With the usual disclaimers about free advice:p  : > Need some enlightenment on pk*0_disconnect and pk*0_fast  A Disconnect roughly means "call me back when you have a response".sE Whilst it might theoretically be faster with a single target disk notaF to disconnect, it's going to greatly impair the ability to overlap IOsB to multiple disks (actually thinking about it, it's going to break' command queueing to a single disk too).   ? Standard mode here means <= 5MHz; unless you have really messeds) up the configuration you don't want that.r  J > So my questions are (1) what is the best setting for these two variables  @ In almost all circumstances, 1. The exceptions are likely mostly historical.v  E > (2) must they be the same on all the nodes that are scsi connected?y No..   ------------------------------  $ Date: Thu, 1 Jul 2004 09:19:19 -0700# From: "Tom Linden" <tom@kednos.com> * Subject: RE: PK* variables for shared scsi9 Message-ID: <NDEMLKKEBOIFBMJLCECIEEMPDHAA.tom@kednos.com>n     -----Original Message-----1   From: Richard Brodie [mailto:R.Brodie@rl.ac.uk]-'   Sent: Thursday, July 01, 2004 8:52 AMr   To: Info-VAX@Mvb.Saic.Coms,   Subject: Re: PK* variables for shared scsi      0   "Tom Linden" <tom@kednos.com> wrote in message5   news:NDEMLKKEBOIFBMJLCECIGEMKDHAA.tom@kednos.com...D  /   With the usual disclaimers about free advice:   <   > Need some enlightenment on pk*0_disconnect and pk*0_fast  C   Disconnect roughly means "call me back when you have a response".vG   Whilst it might theoretically be faster with a single target disk notoH   to disconnect, it's going to greatly impair the ability to overlap IOsD   to multiple disks (actually thinking about it, it's going to break)   command queueing to a single disk too).   A   Standard mode here means <= 5MHz; unless you have really messedf+   up the configuration you don't want that.s  L   > So my questions are (1) what is the best setting for these two variables  B   In almost all circumstances, 1. The exceptions are likely mostly
   historical.-  G   > (2) must they be the same on all the nodes that are scsi connected?h   No.a  H When I checked, these were not defined, so what is the default, fast and disconnect?t     ---s(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------  $ Date: Thu, 1 Jul 2004 10:39:31 +03007 From: "Oleksii Krykun" <krikun@academy.kiev.ua.no.spam>  Subject: Secondary DNS problemS Message-ID: <1037270357C4D411A1C900A0C9D4BFCB0114593A@hqnts40div01.academy.kiev.ua>S  K I used my old VAX4000-200 as secondary DNS in our LAN about 7 years. NT 4.0A DNS server was primary.12 Now I've replaced MS DNS on NT server with BIND 9.3 On BIND named.conf there is allow-transfer for VAX.r! Event Log shows events like this:O  @ client 10.0.4.2#1166: transfer of 'BLA.BLA.BLA/IN': AXFR started   But on VMS side I see:   $ ucx sh host/nolocal 4 %SYSTEM-E-REJECT, connect to network object rejected& %UCX-W-NORECORD, Information not found4 -SYSTEM-F-REJECT, connect to network object rejected $t   UCX$BIND_STARTUP.LOG says:  9 UCX BIND Server Error message -- Wed Jun 30 13:34:14 2004e% secondary zone "'BLA.BLA.BLA" expiredn; UCX BIND Server Warning message -- Wed Jun 30 13:34:14 2004o, recvfrom: connect to network object rejected; UCX BIND Server Warning message -- Wed Jun 30 13:34:17 2004 < zoneref: Masters for secondary zone 'BLA.BLA.BLA unreachable9 UCX BIND Server Error message -- Wed Jun 30 13:34:24 2004 % secondary zone "'BLA.BLA.BLA" expiredt  L How to investigate this problem? I can't find any information about UCX BIND logging.   P.S.   $ ucx show version  @   DEC TCP/IP Services for OpenVMS VAX Version V3.2 - ECO Level 7,   on a VAX 4000-200 running OpenVMS V5.5-2H4  K Unfortunately I can not upgrade to newer version of TCP/IP on VMS because I , have not enough physical memory on VAX (16M)   ------------------------------  % Date: Thu, 01 Jul 2004 10:36:44 +0100 - From: John Laird <nospam@laird-towers.org.uk>d0 Subject: Re: slap in the face again... thanks HP8 Message-ID: <cfm7e0p31n1akur3m6msgicjfv979cm06t@4ax.com>  K On Thu, 01 Jul 2004 02:48:56 GMT, JF Mezei <"jfmezei"@spamnot@teksavvy.com>e wrote:  < >Does Windows now have the equivalent of standalone backup ?  J You are joking ;-)  MS seem to go out of their way to make it as difficultK as possible even to let 3rd party developers produce such solutions (doublyuL so if you have opted for ntfs partitions).  Their answer is: backup your ownF stuff and always be prepared to reinstall Windows (plus umpteen Gbs of? patches that you'd either forgotten you'd installed or they hadtI automagically done for you and you have to somehow reacquire).  Quite howeK you are supposed to cleanly separate "your* stuff from theirs given that sosJ much software is inclined to dump something in the main windows partition,@ no matter how carefully you try to arrange things, is not clear.  ; No o/s can call itself "serious" without such a tool, imho.-   --  6 Why can't you be a non-conformist like everyone else?    Mail john rather than nospam...u   ------------------------------  % Date: Thu, 01 Jul 2004 11:54:06 +0200g* From: Paul Sture <nospam@sture.homeip.net>0 Subject: Re: slap in the face again... thanks HP* Message-ID: <2ki59uF2j2qqU1@uni-berlin.de>   JF Mezei wrote:n > Paul Sture wrote:( > J >>But to bash you in not too rough a way, you should really count the costE >>of your wasted time and use that to justify getting a decent backup0 >>solution.f >a   [snip]   > P > One of the big problems (although I think that with XP, this has been solved),A > is that there is no real way in windows to do the equivalent ofhO > backup/image/ignore=interlock, so any back you make ends up missing any filestP > that were considered locked/opened at the time. And because the screen scroollE > quickly, you don't have a record of which files were NOT backed up.a >   G With NT 4.0 it was possible to create an alternative 'root' containing lH just enough to perform maintenance and backup operations. I assume that 9 possibility is still available in later Windows versions.a   > = > Does Windows now have the equivalent of standalone backup ?   G I am not familiar with the latest versions, but as Bill Todd mentioned u< in this thread, Partition Magic can do image backups. And at  + http://www.ultrabac.com/products/45pricing/i  F there is a range of solutions from single workstation image backup to # file by file server backups and DR.2   ------------------------------  # Date: Thu, 01 Jul 2004 11:23:57 GMTo" From:   VAXman-  @SendSpamHere.ORG0 Subject: Re: slap in the face again... thanks HP0 Message-ID: <00A342C4.D7BD887C@SendSpamHere.ORG>  r In article <519b60ffe8ea29e4dd0bd5aa359e3c43@news.teranews.com>, JF Mezei <"jfmezei"@spamnot@teksavvy.com> writes:" >VAXman-, @SendSpamHere.ORG wrote:I >> micro$hit organization).  The kids and wife used it for the most part.AJ >> First the monitor died in about 6 months (I leave my old trusty DEC VRCK >> and VRT on all the time.  This Gateway monitor was not on all that often J >> and it died off quickly).  Then the mouse decided to spring its left or8 >> rigth click button. The keyboard followed soon after. >>L >The important part of this was "the kids and wife used it".  Sorry, but theN >fact that it didn't last long make have far more to do with the kids using itB >than it coming from Dell, Gateway or whatever :-) :-) ;-) :-) :-)  J Wife uses these nasty boxes at work because of mahogany lined meeting roomJ martini guzzling management edicts.  She surfs and reads email.  As for myK kids, there are no games.  They use it to do school work because the school K has a similar group of mahogany lined meeting room martini guzzling manage- K ment edicts to force feed Micro$hit to the hapless dweebs under their tute-i lage.   J At least of my kids uses the crappy PeeCee terminal emulator to maintain aJ web site on my VMS machines.  Yes, he has to use EDT too because you can'tL seem to author an HTML page on a PeeCee and FTP it to a web server where it K will work-a-shit(tm).  He also maintains his growing prog collection on thenK PeeCee using Apple iTunes.  Good preparation for when this PeeCee meets its = demise with the snow plow and I supplant it with an Apple G5.t    K >You know, the human brain naturally/instinctively does get the fingers  to O >click much harder on the mouse thinking the phaser gun will fire faster/harder K >to kill the dangerous alien that is about to eat you.... It is only as yourO >mature that you succesfully train your brain that it doesn'T make a differencecK >if you click the mouse softly or hard when the time comes to kill off somed  >dangerous enemy on some CRT :-)  J Video games are played on the Nintendo box here; not the Wintendo box.  AtH least the only crashes on the regular game consoles occur in race games.  J FYI, I spent 3 hours and applied NUMEROUS Weendoze XP Regressional patchesK to try to get simple USB camera working.  It remains NON-functional on thisaJ piece of shit.  I plugged it into the Apple Powerbook (even though the boxI that contained this camera claims to be Weendoze numerous incestuous off-D. spring compliant) and it worked straight away.  K Also, on a "security note":  I wanted to regain my wireless bridge to I got K a wireless PCI card and installed it in this PeeCee.  My network SSID isn'tuK advertized and the communications encrypted via a 128bit passphrase.  AfterkJ I dicked with the card and software for about an hour and made one supportI call, I got it working.  Weendoze XP fires up and a little bubble pops upbK atop some icon of two little PeeCees on the bar at the bottom.  It says, to M this effect:  You are connected to netowrk "xyzzy" using 128 bit passphrase   G "there goes your security".  Billy and Co. will never get it will they?o   -- uB http://www.legacy-2000.com  for the *best* OpenVMS system securityC                             solutions that others only claim to be.  -- sK VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?" t   ------------------------------  % Date: Thu, 01 Jul 2004 10:18:48 -0700u# From: Joe Bloggs <JBloggs@acme.com>p0 Subject: Re: slap in the face again... thanks HP8 Message-ID: <qoh8e0l9i122t1pt548lgjqrqqvuokf3jq@4ax.com>  . On Thu, 01 Jul 2004 11:54:06 +0200, Paul Sture  <nospam@sture.homeip.net> wrote:    Q >> One of the big problems (although I think that with XP, this has been solved),rB >> is that there is no real way in windows to do the equivalent ofP >> backup/image/ignore=interlock, so any back you make ends up missing any filesQ >> that were considered locked/opened at the time. And because the screen scroolloF >> quickly, you don't have a record of which files were NOT backed up. >> s >aH >With NT 4.0 it was possible to create an alternative 'root' containing I >just enough to perform maintenance and backup operations. I assume that t: >possibility is still available in later Windows versions.  > My experience w/ NT4, W2K, then XP, that the chances of doing E reasonable image backups easily, has gotten getting worse and worse. u  6 Somewhere in the NT4/W2K/XP de-evolution, the ability D to easily rename a volume/partition (eg. from E:\ to C:\) was lost.   = At the same time, the number of *system* registry references e? populated w/ direct/hard-coded references to drive letters has   increased 10-fold, at least. o  ? Also, I found many instance of 3rd party softwar, and drivers,  B and often Microsoft s/w, that cannot be installed on any drive but C:\.    7 I had false hopes that some of the newer NTFS features  7 (junctions points, and the like) might lead to Windows 6F having a facility, at least remotely similar to VMS's logical tables,  if only for disk devices.p  ? What I used to do, in NT4, was boot a partition with a minimal pB NT Server installed, and create a mirror set, using the partition 1 I wanted to duplicate, and then break the mirror.l  B It used to be a fairly simple matter, to boot into the duplicated 5 partition, after doing some volume/partition renames.   = Nowadays, on  W2K, and XP, It's now longer a simple exercise.a   ------------------------------  # Date: Thu, 01 Jul 2004 14:37:03 GMTy& From: Jilly <jilly@clarityconnect.com>- Subject: Re: Split I/Os to contiguous file???o@ Message-ID: <06260dbd6d4715ed09ad28d5aa32f0b6@news.teranews.com>   Galen wrote:   > H > Is there some way to do this with Delta? I've been trying to no avail.# > All I get is something like this:n >  > $ ANA/SYSf: > SDA> !(Here i proceeded to get the device's UCB address: > FFFFFFFF810B05C0)n > ...m  > SDA> SPAWN RUN SYS$SHARE:DELTA > 810B06D8/  > Eh?2 > @ > Based on an older post to a different thread, I also tried the > following: >  > [Q > 1;Mt > 00000000 00000001  > 00010001:810B06D8/ > Eh?t > H > This is an ES40 running V7.3-2. I would also be willing to try it fromB > the system console if I could figure out how to access the right > location from there. >  > 00010001:810B06DBy   Tryd   RUN SYS$SHARE:DELTAi 00010001:1;m g10B6D8/     --  C Jilly - Working from Home in the Chemung River Valley - Waverly, NYsH       - jilly@clarityconnect.com                      - Brett Bodine fanH       - Mark.Jilson@hp.com                            - since 1975 or soH       - http://www.jilly.baka.com           - http://www.brettbodine.com   ------------------------------  # Date: Thu, 01 Jul 2004 17:48:32 GMTP& From: Jilly <jilly@clarityconnect.com>- Subject: Re: Split I/Os to contiguous file???t@ Message-ID: <169b5537945682f3f43daef90266cea0@news.teranews.com>   Jilly wrote:   > Galen wrote: >  >> nI >> Is there some way to do this with Delta? I've been trying to no avail.r$ >> All I get is something like this: >>   >> $ ANA/SYS; >> SDA> !(Here i proceeded to get the device's UCB address:p >> FFFFFFFF810B05C0) >> ...! >> SDA> SPAWN RUN SYS$SHARE:DELTA  >> 810B06D8/ >> Eh? >> iA >> Based on an older post to a different thread, I also tried thel
 >> following:r >> r >> [Qu >> 1;M >> 00000000 00000001 >> 00010001:810B06D8/. >> Eh? >> sI >> This is an ES40 running V7.3-2. I would also be willing to try it fromnC >> the system console if I could figure out how to access the righth >> location from there.i >> a >> 00010001:810B06DB >  > Tryl >  > RUN SYS$SHARE:DELTA6 > 00010001:1;m
 > g10B6D8/ >  >  Another one to try ist   RUN SYS$SHARE:DELTAP 00010001:1;M	 I810B6D8/t   -- sC Jilly - Working from Home in the Chemung River Valley - Waverly, NY0H       - jilly@clarityconnect.com                      - Brett Bodine fanH       - Mark.Jilson@hp.com                            - since 1975 or soH       - http://www.jilly.baka.com           - http://www.brettbodine.com   ------------------------------   Date: 1 Jul 2004 14:04:21 GMTe# From: spamcatcher@topazpartners.come; Subject: Re: VAX Hardware Support Announcement from NEMONIXa- Message-ID: <cc15l5$ad4$1@msunews.cl.msu.edu>u  < In comp.os.vms Bill Gunshannon <bill@gw5.cs.uofs.edu> wrote:0 : In article <cbuj2o$126k$1@msunews.cl.msu.edu>,. :        spamcatcher@topazpartners.com writes: :>   :> a2 :> Thought this might be of interest to the group: : B : It might also interest peolple here to know they have no problem: : SPAMing, probably with addresses they mined from USENET. :  : bill  I Bill, no intent to spam, and no e-mail mining I assure you--you must readbH this group through an e-mail gateway. I posted this to comp.sys.dec and F comp.os.vms myself because I thought the news would be of interest to H this audience. My header had the word "announcement" in it, and was veryK clear. If you're not interested in announcements, you can ignore it. NobodyoK mined any e-mail addresses! I hate that--that's why I protect my own e-mail L address, but feel free to flame me offline. Just replace the first dot with  an at sign.r  & - Todd (tvanhoosear.topazpartners.com)   ------------------------------  % Date: Thu, 01 Jul 2004 12:14:50 +0100y* From: Nic Clews <sendspamhere@[127.0.0.1]>: Subject: Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS' Message-ID: <cc0rrt$ki2$1@lore.csc.com>p   David J Dachtera wrote:o >  > "Alan E. Feldman" wrote: > >tH > > When is it appropriate to use the /WINDOWS qualifier for INIT or SETH > > VOLUME? If this affects performance, why isn't it in the Performance > > Manaual? >  > It isn't?  > H > Seriously - I'm sure there are references to other doc.'s in the GuideC > to Performance Mgt. The books try to be "one size fits all" not a-" > "cookbook" for high-performance. > J > There's a few tuning tricks that aren't in *ANY* of the doc.'s! Ya gotta0 > go digging for DECUS presentations on the web.  < http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_026.html   Section 9.2.3.  G from askq.compaq.com: tick high performance systems, use "INIT /WINDOWSt OPENVMS" as search  E [OpenVMS] What is the /WINDOWS Qualifier on INIT, MOUNT, SET VOLUME? -  C Dave is right, there's a wealth of information out there. Also some@G t-shirt* wearing specialists for hire, of which Dave does fit into thatu	 category.e  E * I don't mean he turns up in a t-shirt, I mean he's been there, seene> it, done it, and ready to let you benefit from his experience. -- V? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------   End of INFO-VAX 2004.361 ************************ said: "you used really 3 ! >> times".  His answer: "I know".c >l > Well, FFO! >iE > Now, all they need to do is shrink-wrap it along with the licensingiE > forms and voila! VMS can be put on the computer store shelves alongt > side Micro$lop and Linux!r >o& > *SLAP* Wake up, DJ! You're dreaming!    E Right alongside the 'OpenVMS for Newbies' book we are going to write.t  K Chapter 1 - Just Call It VMS (it's been called that 