1 INFO-VAX	Mon, 12 Jun 2006	Volume 2006 : Issue 324       Contents:' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron # Re: New HP web based email package!  Process Software RSA Support0 Rdb, standard vs. multiversion and link problems= Re: Upward Compatibility (was: Re: Results of my straw poll.) = Re: Upward Compatibility (was: Re: Results of my straw poll.) = Re: Upward Compatibility (was: Re: Results of my straw poll.)   F ----------------------------------------------------------------------  # Date: Sun, 11 Jun 2006 19:03:52 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>0 Subject: Re: Cost of used alphas vs 8086+charron1 Message-ID: <sOZig.1744$i44.791@news.cpqcorp.net>    Dave Froble wrote:  H > Has Charon-VAX ever run on an 8086?  I doubt it.  First you'd have to   > find an 8086 still being used.    E    In furtherance of that statement, the Intel 8086 is 1970s-vintage  J 16-bit technology -- it's about the same vintage as the first VAX systems.  E    If the intent of the thread here was to refer to IA-32 with EM64T  D (eg: to Intel IA-32e 64-bit operations), or to the AMD AMD64 64-bit F equivalent, then there is some room for discussion and for comparison.  F    As for Intel 8086, if an operating system provides for it, you can D apparently subset your way down into 8086 compatibility within most I (all?) current IA-32-class processors, to allow an processor environment  E reportedly capable of executing thirty year old code, also obviously  C assuming the requisite thirty year old run-time APIs are available.    ------------------------------  % Date: Sun, 11 Jun 2006 16:33:41 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: Cost of used alphas vs 8086+charron, Message-ID: <448C7E1D.56C8E9AC@teksavvy.com>   Hoff Hoffman wrote: F >    In furtherance of that statement, the Intel 8086 is 1970s-vintageL > 16-bit technology -- it's about the same vintage as the first VAX systems.    E Digital named its architecture "VAX", stuck with that name throughout C the life of the architecture, and then gave specific name to chips.   A Intel has not named the architecture that was begun with the 8086 H (perhaps because it knew it was a mere toy controller and never expectedC it to last so long). And it has changed the product name many times  based on the "chip du jour".  H The "8086" is the root of that architecture and  unambiguously refers to that family.  H When you say "Cadillac" today, do you refer to the very first car calledG "Cadillac" or do you refer to today's product lineup where Cadillac has  become a family of products ?     F >    If the intent of the thread here was to refer to IA-32 with EM64T  F This is much longer than just 8086. (am still awaiting confirmation of bribes to use X86 :-)   E Also, IA-32 is not commonly used. And it is ambiguous since Intel has G multiple 32 bit architectrures (it inherited the StrongArm from DEC and / either uses it or developped its own for PDAs.)   E In the context of VMS, it is a given that VMS is a 64 bit OS and that B when it is upgraded from that IA64 thing, it should go to the trueG industry standard commodity architecture that began as the 8086. And it D is a given that the 64 bit version of the 8086 will be the target ofD such as port, not the 16 bit with 8 bit bus original toy controller.  G And because ethe 8086 architecture comes from multiple competitors, you G cannot use trademarked names such as Pentium, Xeon or Opteron to denote D the architecture. Those are "volatile" names that refer to a currentC instantiation of the architecture from a specific vendor. And those > trademarks are dropped when a new brand-du-jour is introduced.  H When VMS starts to be commercialised on the 8086s, it is a given that itC will require a modern 64 bit instantiation of the 8086 and probably H additional requirements (EFI based booting environment, specific bus andG driver platforms etc). But it will still be running on the arhcitecture  whose name started as "8086".    ------------------------------  % Date: Sun, 11 Jun 2006 15:46:22 -0700 # From: "Tom Linden" <tom@kednos.com> 0 Subject: Re: Cost of used alphas vs 8086+charron) Message-ID: <op.taz6vkr2zgicya@hyrrokkin>   I On Sun, 11 Jun 2006 12:03:52 -0700, Hoff Hoffman <hoff-remove-this@hp.co=  m>  =    wrote:  H >   In furtherance of that statement, the Intel 8086 is 1970s-vintage  =  F > 16-bit technology -- it's about the same vintage as the first VAX  =  
 > systems. > F Give yourself credit, where credit is due.  8086 was an accumulator  =   architecure I with an ad hoc set of registers, VAX was a general register machine with=   aI symmetric, orthogonal instruction set.  8086 architecture was obolete 10=   G years before it was introduced.  Prime was the last good accumulator  =    architectureB that I can think of, and they offered a re-micro-coded version,  =   architecture not
 unlike VAX   ------------------------------  % Date: Sun, 11 Jun 2006 23:31:47 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: Cost of used alphas vs 8086+charron9 Message-ID: <SoydnYrksMeSQhHZnZ2dnUVZ_oKdnZ2d@libcom.com>    Wilm Boerhout wrote:) > Dave Froble wrote on 11-6-2006 17:30...  >> Wilm Boerhout wrote: + >>> Dave Froble wrote on 10-6-2006 19:31...  >>> 3 >>>> The slowest Alpha is much faster than an 8086!  >>>>' >>>> You're both being subverted by JF.  >>>>3 >>>> Perhaps you wish to discuss x86-64, or AMD-64?  >>>  >>> ???  >>> B >>> We're discussing CHARON-VAX on Intel vs. CHARON-VAX on Alpha, H >>> starting from JF's question about CHARON-AXP on 8086. Are you still  >>> with us? >>> 	 >>> /Wilm  >>I >> Has Charon-VAX ever run on an 8086?  I doubt it.  First you'd have to  ! >> find an 8086 still being used.  > K > C'mon Dave, read up on your threads. I use "8086" (in quotes) the way JF  K >  did/does. CHARON-VAX runs on modern Intel and (better still) on AMD, as  G > well as on Alpha. CHARON-AXP runs on Intel (64 bits) and AMD (ditto,   > also preferred). >  > /Wilm   ? Yes, and I'm on a mission to get JF to stop using that product  F designation, and to get others to stop being 'infected' by that usage.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 11 Jun 2006 23:39:15 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: Cost of used alphas vs 8086+charron, Message-ID: <448CE1C0.F13C5F9D@teksavvy.com>   Dave Froble wrote:@ > Yes, and I'm on a mission to get JF to stop using that productH > designation, and to get others to stop being 'infected' by that usage.  H When one considers the potential of someone paying me to stop using thatF designation, I have no incentive to stop on my own :-) :-) :-) :-) :-) ;-) :-)     A now, I promise this: when the port of VMS to the 8086 is formally E announced, I will abide by whatever designation HP chooses to use for $ that industry standard architecture.  G So, if you are unwilling to send me regular supply of chocolate bars to E get me to stop using the "8086" term, then write nice letters to Hurd ; asking him to make public the port of VMS to the 8086 ASAP.    ------------------------------    Date: 11 Jun 2006 18:12:59 -0700) From: "Sue" <susan_skonetski@hotmail.com> , Subject: Re: New HP web based email package!C Message-ID: <1150074779.599633.175810@h76g2000cwa.googlegroups.com>   F And yes it was a 17 year old (my daughter) creating the email accountsD its that easy, also to delete and modify.  It was easy enough that ID could teach her in less than five minutes.  It is really a wonderfulC tool.  I have some admin privs and you could teach someone that has  only had windows experience.   Sue     
 Sue wrote:I > Bob I would be interested in your feedback on trysecuresverer I have an H > account so send me mail. %%%mamavms@trysecureserver.com take out the %H > signs in case you are wondering I did not pick the username but I like > it.  >  > Anyone else as well. >  > sue  >  >  > bob@instantwhip.com wrote:  > > https://trysecureserver.com/   ------------------------------  % Date: Sun, 11 Jun 2006 15:55:44 -0400 & From: "Hal Kuff" <halkuff@verizon.net>% Subject: Process Software RSA Support 1 Message-ID: <4z_ig.111404$aD6.91097@newsfe16.lga>    Hi,   D    We are looking for folks that have bought Process Software's RSA L support... We would like to get it going on our site and are trying to find F out what one gets for the 200/user fee... an rsa license? Or just the / ability to use the loginout code for one user?     ------------------------------    Date: 11 Jun 2006 12:24:42 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>9 Subject: Rdb, standard vs. multiversion and link problems C Message-ID: <1150053882.798728.215050@m38g2000cwc.googlegroups.com>   C We've got an alpha going in to replace a VAX system running MANMAN. D The Alpha has VMS V7.3-2 (fully ECO'd), DBMS V7.123, Rdb V7.143, andF CDD V7.0a (7.0.1), which are the versions we have media available fromD Oracle for this system; all those versions are supposed to be OK for= MANMAN V11.4 usage and are part of the same Oracle media kit.   D Apparently the Rdb V7.1 kits are all "Multiversion", and you have toG fall back to V7.0 to get a standard single version kit.  The problem is C that MANMAN had hardcoded paths for linking, created in dynamically G built OPT files... so it will link SYS$LIBRARY:SQL$USER instead of just A SQL$USER, so the logicals set up by RDB$SETVER.COM don't properly > direct to the included SQL$USER71.OLB file, and the link fail.  D I really don't want to make changes to MANMAN command procedures.  ID also don't want to try 'manually' converting this Rdb release into aD 'standard' one by renaming (or rather copying ) images. The Rdb docsD really don't provide any useful info, at least in the install guide,B release notes, beyond a warning about layered products doing image anlysis to check versions.  F So are there any options short of trying to get my hands on a V7.0.x.x standard Rdb kit?   F Once thats done I can try to find out why the bloody linker can't findB DBMSHR.EXE even though its in the right place, and all appropriateF logicals and setups are identical to both the original VAX and another' working (bult older versioned) Alpha.      Rich   ------------------------------  # Date: Sun, 11 Jun 2006 18:54:23 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>F Subject: Re: Upward Compatibility (was: Re: Results of my straw poll.)1 Message-ID: <zFZig.1743$b%3.874@news.cpqcorp.net>    Michael Kraemer wrote: > Richard B. Gilbert schrieb:  >> Michael Kraemer wrote: > >>> "Traditionaly, VMS was famous for compatibility. It is our> >>> experience that this is no longer true. We find that every= >>> new release of anything (e.g. Fortran compiler, C, socket = >>> libraries, VMS itself) breaks something. We spend alot of D >>> time coping with this and it is getting increasingly difficult." >>> (as of Oct-1994).  >>G >> I find the above a little puzzling.  It has been my experience over  A >> many years that applications that stick to the documented and  I >> supported interfaces work without problems on newer versions of VMS.   F >> Can you provide examples of things that broke while using only the ' >> documented and supported interfaces?   H    That you and most other folks haven't noticed bodes well, of course. F   It is and continues to be a goal of OpenVMS Engineering to maintain / the upward-compatibility of images and of APIs.   F    As for specific cases were compatibility was broken, Adobe Display ? Postscript is a salient example.  That support was removed for  = contractual reasons, as has been stated on various occasions.   @    The BACKUP shareable image API, during the interval when the E maintainers hadn't realized the requirement to preserve the constant  I values (oops) and when the API definitions were also located outside the  ) purview of the symbolic constant scanner.   G    There have been select (few) other examples where compatibility was  4 problematic, and once in a while there's been a bug.  I    More subtly, there are also cases where the underlying "standard" API  H definitions are moving targets, and don't maintain compatibility within E the required design -- where supporting the newer edition of the API  G means breaking compatibility.  (There was an interface specification I  C was chasing a while back, for instance, and it regularly underwent  H incompatible changes.)  The C header files and the X Windows APIs go to I some length to avoid breaking application compatibility, even though the  < interfaces and the interface definitions are moving targets.  I    Again, the intent and the goal of engineering is to make incompatible  H change very rare, both at the source level (when porting, for instance, D to subsequent platforms) and binary compatibility when upgrading or  applying ECOs.   ------------------------------  % Date: Sun, 11 Jun 2006 15:36:56 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> F Subject: Re: Upward Compatibility (was: Re: Results of my straw poll.), Message-ID: <448C70D7.7A57B0EA@teksavvy.com>   Hoff Hoffman wrote: H >    There have been select (few) other examples where compatibility was6 > problematic, and once in a while there's been a bug.    H I think TPU/EVE also changed. ALLIN1 uses callable TPU. And upgrading toD 7.2 broke that and ALLIN1 was no longer able to call TPU, even afterF relinking the ALLIN1 image against thew new shareable images. It couldG be that there was undocumented kludge used by ALLIN1. (newer version of  A1 fixed that problem)   (this was on vax).   ------------------------------  # Date: Sun, 11 Jun 2006 22:46:58 GMT + From: "Villy Madsen" <Villy.Madsen@shaw.ca> F Subject: Re: Upward Compatibility (was: Re: Results of my straw poll.)+ Message-ID: <C31jg.10971$Mn5.5843@pd7tw3no>    I remember - many years ago   E I had written a fortran application running on a mainframe - an early ) incarnation of MVS (or perhaps even SVS).   L The application used a relatively unused feature that allowed the program toL trap the error that occurred when a user would enter an alpha when a numericK was used (what do you mean that you want interactive IO) - what do you mean > you don't want the app to crash when it encounters bad data ??  H Anyway - by a matter of trial and error - and it worked great until theyJ upgraded the fortran compiler - I think it was 4G - but it was a long time ago.   Anyway - the apps broke.  L I went down and pounded on the desk of the support analyst (I still remember his name for some reason) H until he quietly and without emotion point out that I had done somethingL incorrectly, (the documentation for the feature in the new version was a lot better than in the old).  I anyway - redfaced, I went back and rewrote the code (which ended up being I used until the need for it disappeared some 15 years later (the telephone E switch that it developed traffic tables for went the way of the dodo)   L Of course, there are many applications (esp for web apps) that appear to useJ "undocumented features". They are the ones that break when you apply a new
 patch.....   Villy    ------------------------------   End of INFO-VAX 2006.324 ************************                                                                                                                                                                                                                                                  eÑ$]C95I w9]Dv䛭^W__kNU>S( ND48Lqr? *blrJ40}ys=o$sj?SvmMfUEo@6eg%{yf%&\>Ru)6@k
gADvVe
 'l4!8PXw&Is8XT#ҪC4!	>
11qdtqəF18U!9~MYćy4 هDɋϮ
Pά2ɭĿgǋ0n݄pzЂ :6unQr=kZ3|q|9Q(!AP2xCɉ|M3|ە.~,'G.`6͐Օ*=$*goeHŕ 2 ijRo{|7E