1 INFO-VAX	Sat, 11 Nov 2006	Volume 2006 : Issue 620       Contents:= Re: Hobbyist License for VAX-VMS: producer=hp v producer=dec? = Re: Hobbyist License for VAX-VMS: producer=hp v producer=dec? = Re: Hobbyist License for VAX-VMS: producer=hp v producer=dec? C Re: How can one distinguish an IDE/ATA(PI) drive from a SCSI drive? P Re: Itanium console:bypass its interpretation of certain control characters char Re: Most "classic" VMS version Re: Most "classic" VMS version Re: Most "classic" VMS version Re: Most "classic" VMS version Re: Most "classic" VMS version Re: Most "classic" VMS version Re: Novice's questions Re: Novice's questions7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600  spring 2006 collection6 Re: writing fixed size records with one shorter record6 Re: writing fixed size records with one shorter record6 Re: writing fixed size records with one shorter record  F ----------------------------------------------------------------------    Date: 10 Nov 2006 14:17:33 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) F Subject: Re: Hobbyist License for VAX-VMS: producer=hp v producer=dec?3 Message-ID: <T9RYJL$PT9Gi@eisner.encompasserve.org>   j In article <MYudneWuO-R7BsnYnZ2dnUVZ8sydnZ2d@bt.com>, "Nick Glazzard" <nick.glazzard@speedsix.com> writes:5 > I'm sure I must have missed something here, but ...  > N > This morning I got new licenses for my VAX from the hobbyist site, that timeE > of year having come around again. Everything seemed to go fine with / > installing these new licenses. But I now get:  > @ > %LICENSE-E-NOAUTH, DEC VAX-VMS is not authorized on this node.      For VMS you may have to    2       LICENSE MODIFY VAX-VMS /INCLUDE=scsnodename   E    before the license will load.  All the other products may be hung      up on a lack of VMS license.    ------------------------------  # Date: Fri, 10 Nov 2006 23:08:07 GMT ) From: "John Vottero" <JVottero@mvpsi.com> F Subject: Re: Hobbyist License for VAX-VMS: producer=hp v producer=dec?> Message-ID: <rD75h.24408$TV3.15790@newssvr21.news.prodigy.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  1 news:bd68b$45550305$cef8887a$6754@TEKSAVVY.COM...  > Stephen Hoffman wrote:K >> AFAIK, licenses with a producer of HP won't work on most (all?) OpenVMS  M >> VAX versions, and there's no ECO to add this.  These licenses won't work,   >> in simplest terms.  >  > + > Would LICENCE LOAD  complain about this ?  > J > Or will they fail when VMS asks if it is authorized to run DEC/VAX-VMS ?  K LICENSE LOAD won't complain, it's a valid license but, the code is looking  F for a VAX-VMS license with a producer of DEC so it won't find a match.   ------------------------------  % Date: Fri, 10 Nov 2006 18:23:42 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>F Subject: Re: Hobbyist License for VAX-VMS: producer=hp v producer=dec?) Message-ID: <ej31lt$1i42$1@pyrite.mv.net>    JF Mezei wrote:  > Stephen Hoffman wrote:C >> AFAIK, licenses with a producer of HP won't work on most (all?)  I >> OpenVMS VAX versions, and there's no ECO to add this.  These licenses  ! >> won't work, in simplest terms.  >  > + > Would LICENCE LOAD  complain about this ? J > Or will they fail when VMS asks if it is authorized to run DEC/VAX-VMS ?  H    As implemented, the OpenVMS VAX license check looks for various PAKs G including for the VAX-VMS license from the producer DEC.  The (errant)  G hobbyist license that was received and loaded here is a valid license,  I but it might as well have been for the JF product from MEZEICORP; it and  C the rest of the PAKs (if any) in the LMF database do not match the  / license PAK that was requested by the software.   E    The (errant) license PAK here is (or should be) a perfectly valid  E license PAK, just not one for the DEC issuer and the VAX-VMS product.    ------------------------------  + Date: Fri, 10 Nov 2006 14:30:18 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)L Subject: Re: How can one distinguish an IDE/ATA(PI) drive from a SCSI drive?2 Message-ID: <06111014301890_2020028F@antinode.org>  8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>  8 > >    Currently cdrecord uses that annoying "dev=i,j,k" > K >    If you dig around in the source code, you'll find that the values are  I > mapped and re-assembled into an OpenVMS device specification deep down  0 > at the bottom of the cdrecord.exe source code.  A    That part's not so deep.  The scgo_isatapi() function is a bit % deeper, and that was causing trouble.   H >    Macro32 and Bliss tend to like the $V.  Macro32, Bliss and various F > other languages can and do use $M.  ($V is the bit offset.  $M is a K > bitmask.)  If you use the $V bit offset within your DCL, I'll assume you  H > are using a lexical function (eg: f$cvui) to extract the bit, or that E > you are using the $M value or a bit-shift of the $V value to get a  I > bitmask) and the .AND. operator.  (upon grok, do please ignore this --  H > but then, it's not often that an opportunity to mention f$cvui/f$cvsi  > comes up. :-)  )  F    Actually, I was lust looking at hex representation (using F$FAO()).  I >    What's additionally "fun" here is that the OpenVMS driver I/O paths  K > are (slightly) different for the IO$_DIAGNOSE paths.  IIRC, DN/USB works  J > like DQ/ATAPI here, and uses the same IO$_DIAGNOSE paths -- the biggest I > difference between DQ/ATAPI and DN/USB is that DN/USB does not provide   > timeouts.   E    So, I'll probably rig scgo_isatapi() to treat the DN guys the same E as the DQ guys.  I don't have the hardware to test it, but it'll look 
 plausible.  F > >    I'm not sure that I can actually avoid always having an "i,j,k"K > > mapping for devices, so now would probably be a good time to add a "DN"  > > mapping. > H >    The cdrecord.exe port that the HP folks provided includes mappings I > for these, and a command procedure wrapper.  The source code should be  G > on the Freeware.  (The mappings changed somewhere in the V8.* range,  H > too, IIRC -- the old DQ x,y,z code was bumped upwards somewhere along  > the line.) > F >    The command option parsing code within cdrecord.exe doesn't lend F > itself to fixing this, unfortunately.  Changes here are undoubtedly D > quite feasible, though the command-parsing support is non-trivial.  C    Actually, getting a normal device name to be accepted was no big D deal, but I missed getting the ATAPI property set properly, and that caused some trouble.  J >    There are up to four DQ devices around on various systems, and there ( > can be DQ/IDE and DN/USB PCI adapters.  H    I'll give it some thought, but my istant guess would be a change fromD the current 8-and-up = DQx to something like 8-15 = DQx, and 16-23 =E DNx.  My latest (VMS V8.2) SYS$MANAGER:CDRECORD.COM mentions "DQ" but > not "DN", so if that's in a newer one, I'd like to get a copy.  E >    I'd probably look to tweak the cdrecord.exe tool to implement a  J > vmsdev=ddcu: command option, were I going after this source code change.  G    Currently (in my stuff), it's just "dev=name", where "name" could be F "i,j,k", or "ddcu:", or a logical name, or whatever.  Worst case wouldC be to get the ALLDEVNAM and map it back to "i,j,k", but I'd like to  avoid that if I can.      Thanks for the info.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  # Date: Fri, 10 Nov 2006 19:38:23 GMT & From: John Reagan <john.reagan@hp.com>Y Subject: Re: Itanium console:bypass its interpretation of certain control characters char 0 Message-ID: <Py45h.2319$ua.995@news.cpqcorp.net>    VAXman- @SendSpamHere.ORG wrote:K > I have an application that I started on the Itanium after I logged in via K > the console.  I need to type a control-B to get its attention but this is K > the sequence used by the management processor to get one to its menu.  Is J > there something in the console menu I can set to change the default to a? > different sequence so that I can get out of this application?  >    Not that I know of.    --   John Reagan 5 HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Fri, 10 Nov 2006 13:21:42 -0600 / From: Chris Scheers <chris@applied-synergy.com> ' Subject: Re: Most "classic" VMS version / Message-ID: <4rk1pqFqpd3oU1@mid.individual.net>    JF Mezei wrote:  > Dave Froble wrote:J >>  My opinion is that V7.3 is the most capable.  Guess I'm just not into  >> antiques. >  > K > 7.3 marks a significant decision to not make a new release fully upwards  J > compatible since support for Display Postscript was removed between 7.2 	 > and 7.3   F Technically, I believe it was Motif which removed Display Postscript. I It may be possible to continue to use Display Postscript with 7.3 if you  , don't upgrade Motif.  I have not tried this.   --  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  B Voice: 817-237-3360            Internet: chris@applied-synergy.com    Fax: 817-237-3074   ------------------------------  % Date: Fri, 10 Nov 2006 13:21:47 -0600 / From: Chris Scheers <chris@applied-synergy.com> ' Subject: Re: Most "classic" VMS version / Message-ID: <4rk1ptFqpd3oU2@mid.individual.net>    Arne Vajhj wrote: > JF Mezei wrote: B >> Looking back at history, I would think that 5.5-2 was the most H >> significant release. It signaled the end of Digital. And it probably J >> happened at the peak ofthe VMS installed base.  And it is still widely  >> used today. >>F >> As I recall, it was also the last of the releases before the first  >> Alpha release.  > 5 > I think VMS Alpha 1.0 and 1.5 was same time as 5.5.  >  > Arne  I IIRC, Alpha 1.0 was based on the VAX 5.4 sources with bits of 6.0 thrown  = in.  "Parity" was somewhat achieved somewhere around VMS 6.2.    --  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  B Voice: 817-237-3360            Internet: chris@applied-synergy.com    Fax: 817-237-3074   ------------------------------  % Date: Fri, 10 Nov 2006 13:21:51 -0600 / From: Chris Scheers <chris@applied-synergy.com> ' Subject: Re: Most "classic" VMS version / Message-ID: <4rk1q1Fqpd3oU3@mid.individual.net>    prep@prep.synonet.com wrote:< > Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes: > F >>    The earliest distros were available on either magtape or on RX02B >> eight inch floppy or on a disk pack.  CDs arrived over a decade	 >> later.  > H > And RX50s. You have not lived until you have installed VMS onto a 8200F > from a LARGE pile of RX50s... It super sucks when this is onto a HSC9 > disk in a room of running machines, but the manager....   G One night I loaded VMS and Ada onto a MicroVAX II from RX50s.  I think   it was about 80-90 floppies.  G What really sucks is getting a parity error on a floppy 3/4 of the way  G into the installation and having to find another copy of the floppy to  G continue.  What amazed me was that I actually did find another one and  ' did not have to abort the installation.      --  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  B Voice: 817-237-3360            Internet: chris@applied-synergy.com    Fax: 817-237-3074   ------------------------------  % Date: Fri, 10 Nov 2006 21:35:02 +0100 3 From: Michael Unger <spam.to.unger@spamgourmet.com> ' Subject: Re: Most "classic" VMS version / Message-ID: <4rk684Frk9koU1@mid.individual.net>   & On 2006-11-10 01:58, "JF Mezei" wrote:   > [...]  > M > There is a document somwehere on the VMS web site that celebrates 25 years  N > of VMS. In it, it includes the many major kilometrestones for each release. @ > This may give you some ideas of where there was major changes.  8 <http://h71000.www7.hp.com/openvms/25th/index.html>, and@ <http://h71000.www7.hp.com/openvms/20th/vmsbook.pdf> as well ...   Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  % Date: Fri, 10 Nov 2006 22:55:09 +0100 - From: Marc Van Dyck <marc.vandyck@brutele.be> ' Subject: Re: Most "classic" VMS version 2 Message-ID: <mn.555f7d6b47402669.30579@brutele.be>  . prep@prep.synonet.com was thinking very hard :< > Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes: > F >>    The earliest distros were available on either magtape or on RX02B >> eight inch floppy or on a disk pack.  CDs arrived over a decade	 >> later.  > H > And RX50s. You have not lived until you have installed VMS onto a 8200F > from a LARGE pile of RX50s... It super sucks when this is onto a HSC9 > disk in a room of running machines, but the manager....   @ Yessss... last year, we cleaned-up our large fire-proof vault in> the building's basement, and I had the good surprise to find a@ complete MicroVMS+decnet distribution, on floppies, there. Don't< have any drive to read them back, but nice to have anyway...     --  
 Marc Van Dyck    ------------------------------  # Date: Fri, 10 Nov 2006 23:51:30 GMT % From: Rob Brown <mylastname@gmcl.com> ' Subject: Re: Most "classic" VMS version E Message-ID: <Pine.LNX.4.61.0611101650420.17018@localhost.localdomain>   $ On Fri, 10 Nov 2006, JF Mezei wrote:  G > Nop. Display Postscript was a X windows EXTENSION implemented at the   > DECW$SERVER level. > G > It was not removed by the Motif people. It was removed by Compaq who  ; > did not feel like continuing the relationship with Adobe.   $ On Fri, 10 Nov 2006, JF Mezei wrote:  F > Nop. Display Postscript was a X windows EXTENSION implemented at the > DECW$SERVER level. > F > It was not removed by the Motif people. It was removed by Compaq who; > did not feel like continuing the relationship with Adobe.   @ I don't think that matches what it says in the Release Notes for' DECWindows Motif 1.2-5.  There it says:   3          1.8 Display PostScript No Longer Supported   =          V1.2- Starting August 1, 1998, Compaq will no longer @          5     support Adobe Display PostScript software. Compaq:                is taking this action because Adobe Systems@                Incorporated is discontinuing support for Display=                PostScript. This action only affects the Adobe @                Display PostScript software, not the applications:                that make use of the software. For example,?                Bookreader will continue to be supported for all @                other types of source files, except Adobe Display                PostScript.  ?                However, for customer convenience, Adobe Display A                PostScript software will be supplied on an "as is" B                unsupported basis.  Compaq disclaims all warranties;                made with regard to Adobe Display PostScript <                software, including all implied warranties of+                merchantability and fitness.    - Rob      --    B Rob Brown                        b r o w n a t g m c l d o t c o m6 G. Michaels Consulting Ltd.      (780)438-9343 (voice)4 Edmonton                         (780)437-3367 (FAX)2                                   http://gmcl.com/   ------------------------------    Date: 10 Nov 2006 12:35:18 -0800 From: "MZN" <MikeZmn@gmail.com>  Subject: Re: Novice's questions C Message-ID: <1163190918.457138.197550@i42g2000cwa.googlegroups.com>   C OK, thanks, I received licenses for OpenVMS and Layered Products by D e-mail. But I don't know what to do with it. Entering by hands looksG very inconvenient. But theese filels on my look very similar to command A files on some (DCL) language. Let suppose that I'd like to use it  during OpenVMS installation.  < Another question. How I can obtain OpenVMS 8.3 (I have 8.2)?   Thanks,  Mike   ------------------------------  % Date: Fri, 10 Nov 2006 16:20:37 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> Subject: Re: Novice's questions ) Message-ID: <ej2qf5$1g10$1@pyrite.mv.net>   
 MZN wrote:E > OK, thanks, I received licenses for OpenVMS and Layered Products by F > e-mail. But I don't know what to do with it. Entering by hands looksI > very inconvenient. But theese filels on my look very similar to command C > files on some (DCL) language. Let suppose that I'd like to use it  > during OpenVMS installation.  H    If this is the typical hobbyist license, extract the contents of the E two mail messages into files with names such as PAKS_OPENVMS.COM and  I PAKS_PRODUCTS.COM, editing off any headers and any footers that the mail  F system may have added, and then log in as SYSTEM on the OPA0: console 0 device and issue two @ commands at the $ prompt:      $ @PAKS_OPENVMS.COM    $ @PAKS_PRODUCTS.COM   I    Since you may or may not have a way to load the files, you may end up  E entering the OpenVMS base and user licenses by hand, and the network  C license by hand (most folks usually pick IP for this task, and the  G license PAK name for that is UCX), and then configure and start the IP  D network and then copy over the rest of the licenses via FTP or such.  > > Another question. How I can obtain OpenVMS 8.3 (I have 8.2)?  D    The same path as is usual for hobbyists looking for products and H product versions other than what is on the hobbyist distro...  You need G to find somebody locally with the kit, and borrow it, or find somebody  I selling a kit and buy it, or find somebody with an extra kit and pay for   shipping...    ------------------------------  # Date: Fri, 10 Nov 2006 18:43:08 GMT ' From: Steve Thompson <smt@vgersoft.com> @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600C Message-ID: <Pine.LNX.4.58.0611101340080.11243@honker.vgersoft.com>   # On Fri, 10 Nov 2006, Syltrem wrote:   M > How can I compare the performance of an Alpha ES40 with 4-833Mhz CPUs to an ' > Integrity rx3600 with 2-1.4Ghz CPUs ?  > [...]   I My own workload is completely different (not Oracle), so this won't apply I to you directly. On total compute throughput, however, I would expect the H Alpha to be slightly quicker, although not by much (it has twice as many1 CPU's). The I/O subsystem may be the key for you.    -s   ------------------------------  % Date: Fri, 10 Nov 2006 14:03:30 -0500 * From: "Syltrem" <syltremzulu@videotron.ca>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx36000 Message-ID: <12l9j83j96tq9a5@corp.supernews.com>  5 "Steve Thompson" <smt@vgersoft.com> wrote in message  = news:Pine.LNX.4.58.0611101340080.11243@honker.vgersoft.com...  > % > On Fri, 10 Nov 2006, Syltrem wrote:  > L >> How can I compare the performance of an Alpha ES40 with 4-833Mhz CPUs to  >> an ( >> Integrity rx3600 with 2-1.4Ghz CPUs ? >> [...] > K > My own workload is completely different (not Oracle), so this won't apply K > to you directly. On total compute throughput, however, I would expect the J > Alpha to be slightly quicker, although not by much (it has twice as many3 > CPU's). The I/O subsystem may be the key for you.  >  > -s  F These IA64 CPUs are supposed to be faster, and they have 2 cores each.  9 I need hard numbers (operations per second, or something)    Thanks ! Syltrem    ------------------------------  % Date: Fri, 10 Nov 2006 15:08:50 -0500 * From: "Syltrem" <syltremzulu@videotron.ca>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx36000 Message-ID: <12l9n2j90618qe6@corp.supernews.com>  4 "John Reagan" <john.reagan@hp.com> wrote in message + news:pB45h.2320$ua.1729@news.cpqcorp.net...  > Syltrem wrote: >  >>I >> These IA64 CPUs are supposed to be faster, and they have 2 cores each.  > / > Faster than what?  Older Itaniums?  The ES40?  >  >>< >> I need hard numbers (operations per second, or something) >> > F > what kind of operations?  memory accesses?  IOs?  integer additions? > M > I can't give you hard numbers, but I would certainly expect the Itanium to  3 > be faster than your ES40 for an average workload.  >  > --  
 > John Reagan 7 > HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader  > Hewlett-Packard Company   I That server (the ES40 to be replaced by some Itanium box) hosts 6 Oracle  J databases of which 1 is heavily accessed, plus all clients (300) that run J different applications (mostly 4GL apps), some of which use RMS files and  others Oracle.I It also has Advanced Server (Pathworks) with 500 connections and 50 open  & files, and a dozen Progress databases." And also a few other minor things.   The MONITOR SYSTEM reports Processes - 450  CPU Busy (234) -- 4 CPUs Direct I/O Rate (3956) Buffered I/O Rate (2819)  K There is minimal pagefaulting but not much memory left (XFC cache 77MB and   Free List 18MB) . Those numbers are quite normal during daytime.   Syltrem    ------------------------------    Date: 10 Nov 2006 14:21:57 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx36003 Message-ID: <pGXIN2JuIXxf@eisner.encompasserve.org>   ] In article <12l9j83j96tq9a5@corp.supernews.com>, "Syltrem" <syltremzulu@videotron.ca> writes:  > H > These IA64 CPUs are supposed to be faster, and they have 2 cores each. > ; > I need hard numbers (operations per second, or something)   C    You can probably find some crude comparisons of Alphas to Alphas 9    somewhere, IA64 to IA64, disk to disk, bus to bus...     K    Try your application on one of HP's test drive machines then compensate  O    for the model/RAM/disk/bus ... differences and you've got a ballpark figure.       Your real results WILL vary.   H    Or you may be able to borrow or short term lease a system to get real    results.    ------------------------------  % Date: Fri, 10 Nov 2006 15:55:25 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600) Message-ID: <ej2ovr$1fh4$1@pyrite.mv.net>    Syltrem wrote:  K > That server (the ES40 to be replaced by some Itanium box) hosts 6 Oracle  L > databases of which 1 is heavily accessed, plus all clients (300) that run L > different applications (mostly 4GL apps), some of which use RMS files and  > others Oracle.  ;    A simple answer here is almost certainly a wrong answer.   I    Whether a move to OpenVMS I64 and an Integrity server will speed your  H operations, or hinder them, depends greatly on various factors and data  not yet in evidence.  I    At the core, the typical OpenVMS I64 configuration is faster than the  C typical OpenVMS Alpha AlphaServer configuration, and the Integrity  H rx3600 is a very nice and very fast box.  But whether it will be faster G for your specific installation and your specific applications is a far   more difficult question.  I    A tool like the very ancient "QUALIFY" might be nice, but it's not an   easy problem to solve.  D    The key consideration here involves what factor(s) are currently I limiting your performance, and whether (or not) an Integrity server will  E resolve these.  If the application environment is pounding on a disk  D spindle, for example, then even massive upgrades in processor speed * probably won't help aggregate performance.  K > It also has Advanced Server (Pathworks) with 500 connections and 50 open  ( > files, and a dozen Progress databases.  E    IIRC, the Advanced Server product isn't available on OpenVMS I64.  H The target Microsoft Windows SMB/CIFS server environment involves an HP H port of the Samba server and its accouterments, and this Samba SMB/CIFS  stuff is AFAIK in field test.   $ > And also a few other minor things. >  > The MONITOR SYSTEM reports > Processes - 450  > CPU Busy (234) -- 4 CPUs > Direct I/O Rate (3956) > Buffered I/O Rate (2819)  E    If you want an answer with a degree of certainty (rather than the  E guestimates that I or others can provide here), then I might suggest  A that there be a prototype attempted.  Use one or more of of your  H applications -- some sort of a representative sample -- and load it and H test it on the Test Drive system or equivalent HP prototype environment I to see how fast it goes.  I'd expect the server will PROBABLY be faster,  B though the actual observed aggregate performance could range from I GLACIAL to GONZO, depending on what performance limits exist within your   current configuration.  :-)   C    The other approach is to bring a local, borrowed or leased test  I system on-line, and use that to qualify and to stage the migration.  You  D or somewhat you designate will be tweaking and/or porting code here @ after all, and that's a task best done on a server reserved and ? dedicated for testing, for target practice and for porting and  C development; on a platform entirely disconnected from a production   server and its environment.   M > There is minimal pagefaulting but not much memory left (XFC cache 77MB and   > Free List 18MB) 0 > Those numbers are quite normal during daytime.  I    An XFC cache of 77 MB does not look to be a particularly large cache,  A and would look like a potential performance constraint.  Is this  G AlphaServer ES40 system already configured near or at the upper limits  H of its physical memory addressing?  I've seen single-user OpenVMS Alpha G workstations operating with half-gigabyte XFC caches.  Cache hit rates  H factor in here -- if your database doesn't use XFC, then having a large H cache doesn't matter.  But if there are applications that can or do use F the XFC (read) cache, then having an undersized cache forces disk I/O  for those read; cache misses.    ------------------------------  % Date: Fri, 10 Nov 2006 16:09:03 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600) Message-ID: <ej2ppf$1fn0$1@pyrite.mv.net>    Steve Thompson wrote: % > On Fri, 10 Nov 2006, Syltrem wrote:  > N >> How can I compare the performance of an Alpha ES40 with 4-833Mhz CPUs to an( >> Integrity rx3600 with 2-1.4Ghz CPUs ? >> [...] > K > My own workload is completely different (not Oracle), so this won't apply K > to you directly. On total compute throughput, however, I would expect the J > Alpha to be slightly quicker, although not by much (it has twice as many3 > CPU's). The I/O subsystem may be the key for you.   G    I inferred that Integrity rx3600 configuration to include two Intel  G Itanium 1.4 MHz processors, which is four cores.  Though you're right,  F that could certainly be read as one Itanium processor and two cores...  I    This whole "cores" stuff is, well, a somewhat bogus distinction.  The  E innards of the SMP implementation has never been highlighted to this  I degree before, and there have been cases where there were two processors  G on one board in the AlphaServer line, and two processors in one socket  G in the Integrity line.  Multicore has engineering and cost advantages;  C it's a way to provide SMP with lower hardware costs.  But it's SMP.   *    Hyperthreading, now that's different...   ------------------------------  % Date: Fri, 10 Nov 2006 16:18:43 -0500 * From: "Syltrem" <syltremzulu@videotron.ca>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx36000 Message-ID: <12l9r5knrr5iq07@corp.supernews.com>  F "Stephen Hoffman" <Hoff@HoffmanLabs-RemoveThis-.Org> wrote in message # news:ej2ovr$1fh4$1@pyrite.mv.net...  > Syltrem wrote: > E >   The key consideration here involves what factor(s) are currently  K > limiting your performance, and whether (or not) an Integrity server will  G > resolve these.  If the application environment is pounding on a disk  F > spindle, for example, then even massive upgrades in processor speed , > probably won't help aggregate performance. >   I It does not have enough memory (but can survive quite well). Having more  J would certainly help. It currently has 8GB. Disks are fine. Bottleneck is " mostly CPU speed during heavy use.    L >> It also has Advanced Server (Pathworks) with 500 connections and 50 open ) >> files, and a dozen Progress databases.  > J >   IIRC, the Advanced Server product isn't available on OpenVMS I64. The K > target Microsoft Windows SMB/CIFS server environment involves an HP port  K > of the Samba server and its accouterments, and this Samba SMB/CIFS stuff   > is AFAIK in field test.  >   M That's ok, we'll keep the Alpha around for some (long) time after installing   the Integrity.  F >   If you want an answer with a degree of certainty (rather than the L > guestimates that I or others can provide here), then I might suggest that > > there be a prototype attempted.  Use one or more of of your J > applications -- some sort of a representative sample -- and load it and M > test it on the Test Drive system or equivalent HP prototype environment to  H > see how fast it goes.  I'd expect the server will PROBABLY be faster, L > though the actual observed aggregate performance could range from GLACIAL K > to GONZO, depending on what performance limits exist within your current   > configuration.  :-)  >   K I'll see if that is feasible. Setting up a database on a remote machine is  K not easy and means a lot of GB to transfer even for a small portion of the   data.     K >   The other approach is to bring a local, borrowed or leased test system  G > on-line, and use that to qualify and to stage the migration.  You or  I > somewhat you designate will be tweaking and/or porting code here after  J > all, and that's a task best done on a server reserved and dedicated for E > testing, for target practice and for porting and development; on a  B > platform entirely disconnected from a production server and its  > environment. >    I'll look into this, too.   J >   An XFC cache of 77 MB does not look to be a particularly large cache, 9 > and would look like a potential performance constraint.   ( I would like the XFC to be larger but...L This machine has been pushed to its limit. That's why we want to change it, & but for what? That's the big question.J The new machine should be able to handle another 100 users and not suffer ' from usage peaks (to our normal limit).   H How does one usually proceed, when time comes to upgrade a server? It's J easier when you stay on the same platform but now, we have to switch from  Alpha to Itanium... H VAX to Alpha was quite simple too, probably most if not all Alphas were J faster than any model of VAX. The same is not true with Alpha and Itanium  but there is no guidelines.    Thanks for your thoughts Syltrem    ------------------------------    Date: 10 Nov 2006 13:24:22 -0800 From: twnews@kittles.com@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600C Message-ID: <1163193861.943851.318830@h48g2000cwc.googlegroups.com>    Stephen Hoffman wrote: > Syltrem wrote: > D >> That server (the ES40 to be replaced by some Itanium box) hosts 6D >> Oracle databases of which 1 is heavily accessed, plus all clientsI >> (300) that run different applications (mostly 4GL apps), some of which # >> use RMS files and others Oracle.  > < >   A simple answer here is almost certainly a wrong answer. > I >   Whether a move to OpenVMS I64 and an Integrity server will speed your I > operations, or hinder them, depends greatly on various factors and data  > not yet in evidence. > I >   At the core, the typical OpenVMS I64 configuration is faster than the D > typical OpenVMS Alpha AlphaServer configuration, and the IntegrityI > rx3600 is a very nice and very fast box.  But whether it will be faster H > for your specific installation and your specific applications is a far > more difficult question.  E Hoff finally starts to get to the core of your question.  The current D state of the art Integrity servers are on average just incrementallyB faster than the Alpha you describe.  The thing is that there is noG simple apples to apples comparison.  Different kinds of IO perform very C differently between these architectures.  Like many have said, your D mileage may very.  I am investigating similar questions to yours for= our site.  Our Alpha's are much older, so I know I will get a G performance boost, but it is unclear how much and I do not have time to  test drive at this point.   C The key, IMHO, is that you should not count on anything but a small B boost in going from your particular Alpha's to fairly cutting edgeF Integrity.  It just isn't that much faster.  On the other hand, if youG are CPU bound on your individual processes at all, it seems likely that G you would get a pretty good boost.  If you are IO bound and you are not ) upgrading your IO system, maybe not much.   E One thing to keep in mind is that while data takes up the same amount B of memory on these 2 systems, executables are around twice as big.B Since you seem to be some what limited by your current memory, you8 should definitely get more memory than the Alpha's have.  A Also keep in mind that the main thing you get from more expensive E Integrity models is not speed, but expandability.  If you can fit all C of the CPU, memory, and PCI cards into a model, then that server is E probably good enough for you.  The parts of your config that you list C look to me like you could get by with a 2620 (2 dual core = 4 CPU). 2 You would need to judge that based on all factors. > I >   A tool like the very ancient "QUALIFY" might be nice, but it's not an  > easy problem to solve. > D >   The key consideration here involves what factor(s) are currentlyJ > limiting your performance, and whether (or not) an Integrity server willF > resolve these.  If the application environment is pounding on a diskE > spindle, for example, then even massive upgrades in processor speed , > probably won't help aggregate performance. > F >> It also has Advanced Server (Pathworks) with 500 connections and 50. >> open files, and a dozen Progress databases. > I >   IIRC, the Advanced Server product isn't available on OpenVMS I64. The J > target Microsoft Windows SMB/CIFS server environment involves an HP portJ > of the Samba server and its accouterments, and this Samba SMB/CIFS stuff > is AFAIK in field test.   F No Advanced Server on I64.  CIFS is not due out until 2007.  As of nowD a migration tool from Advanced Server to CIFS is not promised in theG initial release.  Recreating 100's of shares could be very painful.  We E are looking at leaving a single Alpha in our new I64 cluster (planned F for next year) just to help with transitions and contingencies.  If weG don't need the Alpha, we will not include it, but until that is proven, . we will continue to plan on bring one forward.   Thomas Wirt  Operations Manager Kittle's Home Furnishings  > % >> And also a few other minor things.  >> >> The MONITOR SYSTEM reports  >> Processes - 450 >> CPU Busy (234) -- 4 CPUs  >> Direct I/O Rate (3956)  >> Buffered I/O Rate (2819)  > E >   If you want an answer with a degree of certainty (rather than the F > guestimates that I or others can provide here), then I might suggestB > that there be a prototype attempted.  Use one or more of of yourI > applications -- some sort of a representative sample -- and load it and I > test it on the Test Drive system or equivalent HP prototype environment J > to see how fast it goes.  I'd expect the server will PROBABLY be faster,C > though the actual observed aggregate performance could range from J > GLACIAL to GONZO, depending on what performance limits exist within your > current configuration.  :-)  > J >   The other approach is to bring a local, borrowed or leased test systemF > on-line, and use that to qualify and to stage the migration.  You orH > somewhat you designate will be tweaking and/or porting code here afterI > all, and that's a task best done on a server reserved and dedicated for D > testing, for target practice and for porting and development; on aA > platform entirely disconnected from a production server and its  > environment. > I >> There is minimal pagefaulting but not much memory left (XFC cache 77MB  >> and Free List 18MB)1 >> Those numbers are quite normal during daytime.  > I >   An XFC cache of 77 MB does not look to be a particularly large cache, B > and would look like a potential performance constraint.  Is thisH > AlphaServer ES40 system already configured near or at the upper limitsI > of its physical memory addressing?  I've seen single-user OpenVMS Alpha H > workstations operating with half-gigabyte XFC caches.  Cache hit ratesI > factor in here -- if your database doesn't use XFC, then having a large I > cache doesn't matter.  But if there are applications that can or do use G > the XFC (read) cache, then having an undersized cache forces disk I/O  > for those read; cache misses.    ------------------------------  % Date: Fri, 10 Nov 2006 16:28:10 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600) Message-ID: <ej2qt8$1g1s$1@pyrite.mv.net>    Syltrem wrote:  E > How does one usually proceed, when time comes to upgrade a server?    H    Within the same processor architecture, I tend to look at speeds and C feeds.  Within and across architectures, I look at benchmarks, and    preferably at my own benchmarks.  Q > It's easier when you stay on the same platform but now, we have to switch from   > Alpha to Itanium...   6    Did you look at a used (larger) AlphaServer system?  J > VAX to Alpha was quite simple too, probably most if not all Alphas were L > faster than any model of VAX. The same is not true with Alpha and Itanium  > but there is no guidelines.   A    Architectural migrations are not easy things for establishing  E guidelines or rules-of-thumb, whether VAX to Alpha, VAX to IA-64, or  * Alpha to IA-64.  Benchmark it, if you can.   ------------------------------    Date: 10 Nov 2006 13:38:00 -0800 From: twnews@kittles.com@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600C Message-ID: <1163194680.879479.256140@h54g2000cwb.googlegroups.com>    Stephen Hoffman wrote: > Syltrem wrote: > E >> How does one usually proceed, when time comes to upgrade a server?  > H >   Within the same processor architecture, I tend to look at speeds andD > feeds.  Within and across architectures, I look at benchmarks, and" > preferably at my own benchmarks. > E >> It's easier when you stay on the same platform but now, we have to " >> switch from Alpha to Itanium... > 7 >   Did you look at a used (larger) AlphaServer system?   E I did and found that TCO for the Integrity appears to be a lot lower. E For about the same upfront cash I can get what looks to be a slightly @ better server in I64 than Alpha (my mileage may very :) ).  I amF banking that despite some bad current trends and indications, VMS willF be around long enough that If I need to replace my whole cluster (onlyF 4 Alphas), then I might as well migrate to Integrity and hopefully not% need to migrate again for many years.   G Wow!  After ready my own words above, I am feeling like I must be quite  an optimist.  :)   Thomas Wirt  > E >> VAX to Alpha was quite simple too, probably most if not all Alphas I >> were faster than any model of VAX. The same is not true with Alpha and & >> Itanium but there is no guidelines. > A >   Architectural migrations are not easy things for establishing F > guidelines or rules-of-thumb, whether VAX to Alpha, VAX to IA-64, or, > Alpha to IA-64.  Benchmark it, if you can.   ------------------------------  % Date: Fri, 10 Nov 2006 17:20:54 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx36008 Message-ID: <583e2$4554fafb$cef8887a$19775@TEKSAVVY.COM>   A couple of general comments:   J If you must ask, and the answers are mostly "depends", then it means that= =20 C the performance cannot be that vastly superior on the IA64 machine.     J IA64, being EPIC, depends more on compiler logic than Alpha which has mor= e=20 optimisations done at run time.   H If you are doing SPEC benchmarks with predictable computing, then the=20J compiler can generate code that will run really fast on the IA64 thing. B= ut=20 J if your code is full if IFs , branches etc, the compiler won't relly be=20J able to make full use of IA64 because it cannot predict what can and cann= ot=20  be done on parralel.  J Also, IA64 seems to have a greater performance hit for unaligned memory=20, access. (someone can confirm or deny thing).  J What this means is that you might really want to ask Oracle/HP to provide= =20 9 you with real life Oracle benchmarks for the two systems.     J When you look at costs though, wouldn't it cost less to just upgrade your= =20  CPUs ?  F the HP web page for the ES series shows ES45 has EV68 processors at=20J 1250Mhz.   Any chance you might be able to upgrade the ES40 CPUs to have =   the newer 1250mhz ones ?  J If you can extend your Alphas for a couple more years, you would then hav= e=20J much greater visibility of what will happen to architectures.  Buying som= e=20J IA64 for a pilot project may be OK, but deploying it and making it disast= er=20 J tolerant in real life production is expensive, especially if it will be=20' declared "mature" in a couple of years.           4 En passant, tu devrais mettre =E0 jour ta signature:D ton site web est maintenant =E0  http://pages.videotron.com/syltrem/   ------------------------------   Date: 10 Nov 06 17:53:41 EST) From: cook@wvnvms.wvnet.edu (George Cook) @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600! Message-ID: <KFNU8f+dEYt4@wvnvms>   ] In article <12l9tmut7ooksad@corp.supernews.com>, "Syltrem" <syltremzulu@videotron.ca> writes: ( > <twnews@kittles.com> wrote in message ? > news:1163193861.943851.318830@h48g2000cwc.googlegroups.com...  >> Stephen Hoffman wrote:  >>> Syltrem wrote: >>>  >>H >> One thing to keep in mind is that while data takes up the same amountE >> of memory on these 2 systems, executables are around twice as big. E >> Since you seem to be some what limited by your current memory, you ; >> should definitely get more memory than the Alpha's have.  >  > Are you sure about this?8 > Images (.EXE) on Alpha are 2 times bigger than on VAX.N > But 64 bit against 64 bit, I would expect them to be the same size on Alpha  > and Itanium?  I The VMS Mosaic IA64 executable is twice the size of the Alpha executable.   F If I recall correctly, even the simplest IA64 instruction is 128 bits.E EPIC is/was a poorly thought out concept.  I still cannot believe the ? number of people who actually fell for all the hype or that any @ competent CPU designer actually thought it was a good idea.  TheA argument that all the problems with EPIC could/would be solved in - the compilers was absurd from the very start.      George Cook  WVNET      ------------------------------   Date: 10 Nov 2006 23:15:56 GMT/ From: Thierry Dussuet <thierry@dussuet.lugs.ch> @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx36001 Message-ID: <slrnela21c.1rlo.thierry@MARS.Family>    Heyo!   H On 2006-11-10, Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> wrote: > Steve Thompson wrote: & >> On Fri, 10 Nov 2006, Syltrem wrote: >>  O >>> How can I compare the performance of an Alpha ES40 with 4-833Mhz CPUs to an ) >>> Integrity rx3600 with 2-1.4Ghz CPUs ? 	 >>> [...]  >>  L >> My own workload is completely different (not Oracle), so this won't applyL >> to you directly. On total compute throughput, however, I would expect theK >> Alpha to be slightly quicker, although not by much (it has twice as many 4 >> CPU's). The I/O subsystem may be the key for you. > I >    I inferred that Integrity rx3600 configuration to include two Intel  I > Itanium 1.4 MHz processors, which is four cores.  Though you're right,     8086 after all? :-)    SCNR   Thierry    ------------------------------  % Date: Fri, 10 Nov 2006 18:35:13 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600) Message-ID: <ej32bg$1i9n$1@pyrite.mv.net>    Syltrem wrote:( > <twnews@kittles.com> wrote in message ? > news:1163193861.943851.318830@h48g2000cwc.googlegroups.com...  >> Stephen Hoffman wrote:  >>> Syltrem wrote: >>> H >> One thing to keep in mind is that while data takes up the same amountE >> of memory on these 2 systems, executables are around twice as big. E >> Since you seem to be some what limited by your current memory, you ; >> should definitely get more memory than the Alpha's have.  >  > Are you sure about this?8 > Images (.EXE) on Alpha are 2 times bigger than on VAX.N > But 64 bit against 64 bit, I would expect them to be the same size on Alpha  > and Itanium?    D    OpenVMS I64 image size increases of roughly 2x to 3x of those of I OpenVMS Alpha are not particularly unusual, though your mileage here may  H vary.    As an example of this image size increase, you can investigate D the image sizes for various tools found on the OpenVMS Freeware, or F various user-mode images common to both OpenVMS I64 and OpenVMS Alpha.  H    If you've not already found it (and you probably have...), there's a E manual on porting applications to OpenVMS I64 in the current OpenVMS  @ documentation set.  This has various details of what you should A consider, and what you should look for, and was written with the  G collected input of a number of folks that had performed one or more of  H these migrations to the OpenVMS I64 platform; it's can be a useful read.  I    There are also certainly folks around that have performed these sorts  H of platform and/or software migrations, and that potentially can assist F you in expediting this project to its resolution.  This if you'd like  some assistance, obviously.    ------------------------------  # Date: Fri, 10 Nov 2006 23:41:03 GMT ' From: Steve Thompson <smt@vgersoft.com> @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600C Message-ID: <Pine.LNX.4.58.0611101840130.29755@honker.vgersoft.com>   + On Fri, 10 Nov 2006, Stephen Hoffman wrote:    > Steve Thompson wrote: ' > > On Fri, 10 Nov 2006, Syltrem wrote:  > > P > >> How can I compare the performance of an Alpha ES40 with 4-833Mhz CPUs to an* > >> Integrity rx3600 with 2-1.4Ghz CPUs ?
 > >> [...] > > M > > My own workload is completely different (not Oracle), so this won't apply M > > to you directly. On total compute throughput, however, I would expect the L > > Alpha to be slightly quicker, although not by much (it has twice as many5 > > CPU's). The I/O subsystem may be the key for you.  > H >    I inferred that Integrity rx3600 configuration to include two IntelH > Itanium 1.4 MHz processors, which is four cores.  Though you're right,H > that could certainly be read as one Itanium processor and two cores...  ( Yeah, I read it as two cores total. Duh.   Steve    ------------------------------  % Date: Fri, 10 Nov 2006 19:17:57 -0500 0 From: Glenn and Mary Everhart <everhart@gce.com> Subject: spring 2006 collection & Message-ID: <455516B5.3090908@gce.com>  , This is a multi-part message in MIME format.& --------------060103030005000403040406; Content-Type: text/plain; charset=ISO-8859-1; format=flowed  Content-Transfer-Encoding: 7bit    All - O The Spring 2006 sigtape (well, CD) has been mailed to the US people at the top  K of the tree today. Contents are attached. (The tree list is also attached.)   F I will shortly send to those outside US (note BXA was on the US list).  8 If there are corrections or the like please let me know.  K Yeah, I know it's late in the year. I have a fall 2006 collection very well M along, and intend to get it out by end 2006. Of course if someone else wishes O to pick up the torch, I will send what I have. Whoever is running the SIG these  days really ought to decide.  N This publication has been continuously running since spring of 1979, not a badM record for a group like the VMS SIG. Shows there has been continuous interest O for a rather long time in writing new VMS software and sharing it. For this the ' credit and honor belong to the authors.   F If of course any media arrive broken or unreadable please let me know.   Glenn C. Everhart  Everhart@gce.com  & --------------060103030005000403040406! Content-Type: application/msword;   name="vmslt06atpe.doc" ! Content-Transfer-Encoding: base64  Content-Disposition: inline;  filename="vmslt06atpe.doc"   H Vk1TL0xUIFNwcmluZyAyMDA2IFNJRyBUYXBlcw0KLS0gIC0tIC0tLS0tLSAtLS0tIC0tLSAtH LS0tLQ0KDQpbdm1zbHQwNmEuLi5dIFRyZWUNCg0KWy5HQ0UuLi5dCUFuYWx5UmltIGlzIGEgH c3ByZWFkc2hlZXQgYW5kIERCTVMgdGhhdCBhcmUgaW50ZWdyYXRlZCwNCgkJCWRlc2lnbmVkH IGZvciB0ZXh0IGRpc3BsYXkgZGV2aWNlcy4gQWxsIHZlcnNpb25zIGFyZQ0KCQkJaGVyZSwgH dGhvdWdoIHRoZXkgbmVlZCB0byBiZSByZWNvbXBpbGVkIGZvciBuZXdlcg0KCQkJT1MgdmVyH c2lvbnMuIFZlcnNpb25zIGluY2x1ZGUgc29tZSBmb3IgbXNkb3MsIHVuaXgsDQoJCQl2bXMsH IHJzeCwgYW5kIGFtaWdhZG9zLiAgU2FmZXR5IC0gVGhpcyBpcyBhbg0KCQkJZWxhYm9yYXRlH IHNlY3VyaXR5IHBhY2thZ2UgZm9yIFZNUyB3aXRoIGFsbA0KCQkJZnVuY3Rpb25zIGV2ZXIgH d3JpdHRlbiBmb3IgaXQuIFNvbWUgc2VjdXJpdHkNCgkJCXJlbGF0ZWQgaWRlYSBwYXBlcnMgH cHJlc2VudCB0b28uDQpbLkdOVS4uLl0JUHJlc2VudCBhcmUgR251Y2xldXMsIGEgc2VjdXJlH IGVuY3J5cHRlZCBQMlAgc3lzdGVtLA0KCQkJR251bWVyaWMsIGEgc3ByZWFkc2hlZXQgKHZlH cnkgRXhjZWwgbGlrZSwgbW9yZQ0KCQkJYWNjdXJhdGUgYW5kIG1vcmUgZnVuY3Rpb25zKSBHH bnVuZXQsIGFub3RoZXIgUDJQDQoJCQlzeXN0ZW0sIGFuZCBsaWJnY3J5cHQNClsuTkVULi4uH XQlOZXQgaXRlbXM6IFRoaXMgaXMgbWF0ZXJpYWwgb2YgaW50ZXJlc3QgZnJvbSB0aGUgaW50H ZXJuZXQsDQoJCQlub3Qgc3BlY2lmaWNhbGx5IFZNUyByZWxhdGVkLiAgQW1vbmcgb3RoZXIgH dGhpbmdzOg0KCQkJQk9DSFMgaXMgYW4geDg2IHNvZnR3YXJlIGVtdWxhdG9yIEJPVEFOIGlzH IGEgYnVuY2gNCgkJCW9mIGNyeXB0byBjb2RlIGFuZCByb3V0aW5lcyBDUllQVE8gaXMgYSBsH b3Qgb2YgSmF2YQ0KCQkJY3J5cHRvIGNvZGUgRmlyZWJpcmQgaXMgYSBEQk1TIE1TT1JUIGlzH IGEgcG93ZXJmdWwNCgkJCXNvcnQgYWxnb3JpdGhtIFA3WklQIGlzIGEgY29tcHJlc3MvZGVjH b21wcmVzcw0KCQkJdXRpbGl0eSwgdmVyeSBoaWdoIGNvbXByZXNzaW9uIFJ1YnkgaXMgYSBsH YW5ndWFnZQ0KCQkJaW50ZXJwcmV0ZXIgV0lORSBpcyBhIHdpbmRvd3MgZW11bGF0b3INClsuH T0xEUlNYLi4uXQlaaXAgZmlsZSBvZiBzb21lIG9mIHRoZSBvbGQgUlNYIFNJRyBtYXRlcmlhH bCBvZiBoaXN0b3JpY2FsDQoJCQlhbmQgcGVyaGFwcyBwcmFjdGljYWwgaW50ZXJlc3QgYXMgH aXQgaXMgZ2V0dGluZw0KCQkJaGFyZCB0byBmaW5kLg0KWy5TQU1CQS4uLl0JTGF0ZXN0IFNhH bWJhIGtpdHMuIFNhbWJhIGFsbG93cyBvdGhlciBzeXN0ZW1zIChlLmcuIFZNUykgdG8NCgkJH CWFjY2VzcyBXaW5kb3dzIHR5cGUgZmlsZSBhbmQgcHJpbnQgc3RvcmVzIGFuZCBzZXJ2ZQ0KH CQkJZmlsZXMgYW5kIHByaW50ZXJzIHRvIFdpbmRvd3MNClsuVEsuLi5dCUh1bnRlciBHb2F0H bGV5IG1hdGVyaWFsOiAgVGhpcyBpcyBmcm9tIEh1bnRlcidzIG5ldA0KCQkJY29sbGVjdGlvH bnMuICBDU1ZTRUFSQ0guWklQOzEgICAgc2VhcmNoIGNvbW1hDQoJCQlzZXBhcmF0ZWQgdmFyH aWFibGUgZmlsZXMgRVNFVC5aSVA7MSAgICAgICAgIHNldA0KCQkJdmFyaW91cyBwcm9jZXNzH IGF0dHJpYnV0ZXMgbm8gU0VUIGNvbW1hbmQgZXhpc3RzDQoJCQlmb3IgRlRQX05FVy5aSVA7H MSAgICAgIGZpbmQgbmV3IG9yIGNoYW5nZWQgZmlsZXMgaW4NCgkJCWFuIGZ0cCBkaXJlY3RvH cnkgRlc4MF9ERUxUUkVFLlpJUDsxIGRlbGV0ZSB0cmVlIG9mDQoJCQlmaWxlcyBHQkxTRUNfH U0RBLlpJUDsxICAgc2hvdyBnbG9iYWwgc2VjdGlvbnMgaW4NCgkJCXNkYSBIR0ZUUC5aSVA7H MSAgICAgICAgZnRwIHNlcnZlciBmb3IgVk1TLCB3b3Jrcw0KCQkJYmV0dGVyIHdpdGggb3RoH ZXJzIHRoYW4gc3RkIG9uZSBKQVpaLVYyNkIuWklQOzENCgkJCW11c2ljIHByZyBMSVNURU4uH WklQOzEgICAgICAgbXVsdGljYXN0IG1lc3NhZ2UNCgkJCWxpc3RlbmVyIExOLlpJUDsxICAgH ICAgICAgICBsb2dpY2FsIG5hbWVzIHV0aWwNCgkJCUxOX1NEQS5aSVA7MSAgICAgICBsb2dpH Y2FsIG5hbWUgZGlzcGxheSBmb3Igc2RhDQoJCQlMTl9TREEwMTAuWklQOzEgICAgZGl0dG8gH TUJNT04uWklQOzEgICAgICAgIG1haWxib3gNCgkJCW1vbml0b3IgTUJNT04wMTAuWklQOzEgH ICAgIGRpdHRvIE1CVS5aSVA7MQ0KCQkJbWFpbGJveCB1dGlsaXR5IE1CVTAxNi5aSVA7MSAgH ICAgICBkaXR0byBNTUsuWklQOzENCgkJCW1ha2UgY2xvbmUgZm9yIFZNUy4gV29ya3MgYSBsH b3QgbGlrZSBNTVMgUEYuWklQOzENCgkJCXNob3dzIHVzZXJzIG9mIHBhZ2VmaWxlIFBGTE9BH RC1WTVMtS0VZLVNFVFVQLkZPUjsxDQoJCQlQRl9TREEuWklQOzEgICAgICAgc2hvd3MgcGFnH ZWZpbGUgUEZfU0RBMDExLlpJUDsxDQoJCQlkaXR0byBQV0FJVC5aSVA7MSAgICAgICAgcHJvH Y2VzcyB3YWl0IGFuYWx5emVyDQoJCQlQV0FJVF9TREEuWklQOzEgICAgZGl0dG8sIHNkYSBQH V0FJVF9TREEwMTAuWklQOzENCgkJCWRpdHRvIFJLLlpJUDsxIFJPU0VHQVJERU4tMjEuWklQH OzEgbXVzaWMgcHJvZ3JhbQ0KCQkJU0RMLTFfMl8xMS5aSVA7MSAgIHN5c3RlbSBzeW1ib2wgH ZGVmaW5pdGlvbg0KCQkJbGFuZ3VhZ2UgVElNSURJVFktMjAwMi1QQVRDSEVTLlpJUDsxIHNvH dW5kIHBhdGNoZXMNCgkJCWZvciB0aW1pZGl0eSBwcm9nIFRJTUlESVRZWFgtMjEwMC5aSVA7H MSBtdXNpYw0KCQkJcHJvZ3JhbSBWTVMtTUlESS5IVE1MOzEgVk1TLU1JRElfRklMRVMuRElSH OzENCgkJCVZNU0JBQ0tVUDQtMS0xLlpJUDsxIHJlYWRzIHZtcyBiYWNrdXAgdGFwZXMgaW4gH dW5peA0KCQkJV0FUQ0hFUi5aSVA7MSAgICAgIGlkbGUgdGVybWluYWwgbG9nb2ZmIG9yIHByH b3RlY3QNCgkJCVdYV0lORE9XU18xNjcuWklQOzEgd2luZG93cyBBUEkgZW11bGF0b3INCgkJH CVdYV0lORE9XU18xNjdfQVhQX09MQi5aSVA7MQ0KCQkJV1hXSU5ET1dTXzE2N19WQVhfT0xCH LlpJUDsxIFgxMVI1X1hBV19YTVUuWklQOzEgWA0KCQkJdXRpbHMgWklQLlpJUDsxICAgICAgH ICAgIG5ldyBaSVAgY29tcHJlc3MgdXRpbGl0eQ0KWy5WVS4uLl0JVk1TIHJlbGF0ZWQgdXRpH bGl0aWVzIGZyb20gbmV0OiBBbnRpd29yZCAgICAgICAgQ29udmVydCBtcw0KCQkJd29yZCBkH b2NzIHRvIG90aGVyIGZvcm1hdHMgbGlrZSB0ZXh0IEJMSVNTDQoJCQlCbGlzcyBjb21waWxlH ciBmb3IgRnJlZVZNUyAod2l0aCBGcmVlVk1TLCBWTVMgY2xvbmUNCgkJCWZvciB4ODYpIGNVH UkwgICAgICAgICAgICBmdHAgb3IgaHR0cCBjb3B5IHRvL2Zyb20NCgkJCVVSTCBCWklQMiAgH ICAgICAgICAgY29tcHJlc3MgdXRpbGl0eSwgaGlnaA0KCQkJZWZmaWNpZW5jeS4gIENEUlRPH T0xTICAgICAgICBNYWtlIENELVIgb3IgRFZELVIgb3INCgkJCURWRCtSIENNVUlQICAgICAgH ICAgICBUQ1AvSVAgc3VpdGUgZm9yIFZNUyAoVmF4KQ0KCQkJR05VUEcgICAgICAgICAgIEduH dSBQcml2YWN5IEd1YXJkLCBlbmNyeXB0cyBpbmZvDQoJCQlNVE9PbFMgICAgICAgICAgYWNjH ZXNzIHdpbmRvd3MgRkFUeHggb3IgbXNkb3MgZmlsZQ0KCQkJc3RydWN0dXJlcyBORURJVCAgH ICAgICAgICAgZWRpdG9yIEdIT1NUU0NSSVBUDQoJCQlQb3N0c2NyaXB0IGludGVycHJldGVyH LCBwcmludCAucHMgZmlsZXMgb3Igdmlldw0KCQkJKHd0aCBndikgSW1hZ2VtYWdpY2sgICAgH IEltYWdlIG1hbmlwdWxhdGlvbiBhbmQNCgkJCWZvcm1hdCB0cmFuc2xhdG9yIEpPSE4gICAgH ICAgICAgICBKb2huIHRoZSByaXBwZXIsDQoJCQlwYXNzd29yZCBndWVzc2VyLiAgTW9zYWljH ICAgICAgICAgIHdlYiBicm93c2VyLA0KCQkJZGVzY2VuZGVkIGZyb20gZmlyc3Qgc3VjaCwgH YnV0IGZvciBWTVMuICBPcGVuc3NsDQoJCQllbmNyeXB0aW9uIHJvdXRpbmVzLCBzdXBwb3J0H cyBodHRwcywgY2VydHMsIG1vcmUNCgkJCVB5dGhvbiAgICAgICAgICBsYW5ndWFnZSBpbnRlH cnByZXRlciwgbWFueSB1dGlscyBpbg0KCQkJaXQuICBNeVNRTCAgICAgICAgICAgREJNUyBzH dXBwb3J0aW5nIFNRTCBTaW1oDQoJCQllbXVsYXRvciBmb3IgbWFueSBwcm9jZXNzb3JzIGluH Y2x1ZGluZyBwZHAxMSwgdmF4LA0KCQkJcGRwMSwgbWFueSBtJCBOQ0hSRU0gZGlyICAgICAgH bWFueSBWTVMgdXRpbHMsDQoJCQl0aGluZ3MgbGlrZSB4cGFpbnQsIHRpZmYsIHNlZCwgeGF1H dG9sb2NrLCB6bGliLA0KCQkJc294LCBwbmdsaWIsIGZvbnRjb25maWcsIGdudXBsb3QsIGZyH ZWV0eXBlLCBib2NocywNCgkJCWdyYXBoaSQgYWJpbml0LiAgZm9udGZvcmdlICAgICAgIEZvH bnQNCgkJCWNyZWF0ZS9lZGl0L2luc3RhbGwgaHViZXIgZGlyICAgICAgIGdldGtleSwNCgkJH CWludmVydGVkIGluZGV4IGZhY2lsaXR5LCBzZW5kbWFpbCwgaW5pdCBjbGksIGxvdHMNCgkJH CW9mIHN0JCBzdWJyb3V0aW5lcywgdGNwaXAgZXhhbXBsZXMgYW5kIHV0aWxzLCBiYXNpYw0KH CQkJaW8gdmltICAgICAgICAgICAgIFZpIGVkaXRvciBsb29rYWxpa2Ugc3dpc2gNCgkJCXdlH YiBpbmRleGluZyBmYWNpbGl0eSB6aXAgICAgICAgICAgICAgYXJjaGl2aW5nDQoJCQl1dGlsH aXR5IHpsaWIgICAgICAgICAgICBjb21wcmVzcyB1dGlsLCBwcm9ncmFtbWFibGUNCgkJCWxpH YnJhcnkNCg0KDQpbLldXVy4uLl0JVGhpcyBhcmVhIGhhcyBXQVNEIChodHJvb3QpLCBhIHdlH YiBzZXJ2ZXIgZm9yIFZNUyBhbmQNCgkJCXZhcmlvdXMgdXRpbGl0aWVzIGFuZCBwbHVnaW5zH IGZvciBpdC4gTHlueCwgYSB0ZXh0DQoJCQlvbmx5IGJyb3dzZXIsIGlzIHByZXNlbnQgYWxzH by4gIFNveW1haWwgZ2l2ZXMgdm1zDQoJCQltYWlsIGFjY2VzcyBmcm9tIHdlYg0KDQoNCg==& --------------060103030005000403040406 Content-Type: text/plain;   name="tree05.txt" Content-Transfer-Encoding: 7bit  Content-Disposition: inline;  filename="tree05.txt"   VMS SIG Tapecopy Tree  2005 All:?    This is the tapecopy tree. To keep things simple and not too B hard for everyone, I am sending many copies of the sigtapes myselfC and am sending enough copies to those who agreed to make copies, so C that all you need to do is send a CD to each person assigned. Don't C bother if there is no address; those people should contact you with D one, or let me know a mailing address. Email and find address if youC can though, and if you are willing, and perhaps you can make copies  for the 2 or 3 such people.   >    If you have trouble with any of the CDs please let me know. Glenn Everhart 156 Clark Farm Rd  Smyrna, Delaware 19977 302 659 0460 everhart@gce.com. (work: 302 758 4925, glenn.everhart@chase.com)      , People Glenn Everhart will send sigtapes to:   PLJ@byron.ext.telia.se Peter Ljungberg  Box 8003 39008 KALMAR SWEDEN  
 Tim Shoppa 7328 Bradley Blvd. Bethesda. Md. 20817    shoppa@trailing-edge.com  
 Dr.Otto Titze 
 Kernphysik TU  Schlossgartenstrasse 9 D-64289 ? Darmstadt, Germany   (note: has new address; this still usable)  Otto Titze <Otto.titze@gmx.de>  ----------------------------  | Dr. Otto Titze             | | Im Gldenen Wingert 6a     |  | 64342 Seeheim-Jugenheim    | | T: 06257/8917,0170/5640647 | | M: otto.titze@gmx.de       |  ---------------------------- , "Dr. Otto Titze" <titze@ikp.tu-darmstadt.de>     Michel Smans IARC 150 Cours Albert Thomas 
 69372 Lyon Cedex 08 France   Peter Ljungberg  Box 8003 39008 Kalmar, Sweden PLJ@byron.ext.telia.se   Jeremy Begg  VSM Software Services Pty Ltd  P.O. Box 402 Walkerville SA 5081 	 AUSTRALIA  jeremy@vms.com.au    David L. Cathey  Montagar Software Concepts
 POB 260772 Plano, Texas 75026-0772   
 Mark Berryman  9659 Moorcroft Dr  Peyton, CO 80831 719 494 2195 mark.berryman@mvb.saic.com   Ales.Petan@turboinstitut.si 
 Ales Petan Novo polje, cesta VII/35 1000 Ljubljana	 Slovenija    Paul Repacholi 1 Crescent Rd  9257-1001 Kalamunda 6076 West Australia   Encompass US HQ  attn: Mary Ellen Smith 401 N. Michigan Ave., 22nd Fl. Chicago, Ill. 60611   ) Bureau of Export Admin, Dept. of Commerce " Washington DC 20230  exception TSU   Dr. Klaus Centmayer  Lehrstuhl fur Datenverarbeitung  Techniche Univ. Muenchen D-80290  Muenchen, Germany    Dick Munroe  Cottage Software works Inc PMB 361  464 Common St. Belmont, Mass. 02478  
 Verne Britton  System Support Group. West Va. Network for Educational Telecomputing 837 Chestnut Ridge Rd. Morgantown, W. Va. 26505   Dr. Stephen L. Arnold  2530 Targhee St.* Madison, Wis. 53711-5491     encompasserve 608 278 7700   Kenneth R. Farmer  710 Barrington Park Circle Kernersville NC 27284   - William Thomas (William.G.Thomas@sungard.com)    No address known.    Alan E. Frisbie  Flying Disk Systems, inc 4759 Round Top Drive Los Angeles, Calif. 90065  323 256 2575 Frisbie@flying-disk.com   # Steven Bitgood <steve@goodbits.com>  Steven Bitgood 1370 Stone Creek Lane #302 Charlottesville, VA  22902   Sherri A. Lyon 4000 N. Mingo Rd., MS 375  Tulsa, OK  74116   Sherri Lyon  EDS -- VMS Systems Programming MS 375 4000 N. Mingo Rd Tulsa, OK  74116 ( Phone:+1-918-939-5362  + mailto:Sherri.Lyon@eds.com  ! Wesley <wdunnahoo@mindspring.com>  Wesley Dunnahoo  4055 Frankford Rd apt 411  Dallas, TX 75287-6617  972 248 3783 (h)  ) Christopher Herrick <herriccp@us.ibm.com>        Pete Herrick       132 Tunison Road       New Brunswick, NJ 08901          (732) 392-3353 (W)       (732) 214-0689 (H)       (732) 816-4943 (C)         herriccp@us.ibm.com                Pete Herrick             VMS SA             IBM Global Services   0 juengst@moose.jlab.org (Henry G. Juengst, x6673) Dr. Henry G. Juengst 578 Ginger Trail, Apt. 206 Newport News, VA 23608-1727   : ----------------------------------------------------------) People to be supplied by Wesley Dunnahoo:     & "Frank Battat" <Frank@libertygold.com> Liberty Gold Fruit Co., Inc.     P.O. Box 2187,   South San Francisco, Ca. 94083   E "Czadowski, Gerard A (Gerry)" <Gerry.Czadowski@Nav-International.com>  Gerry Czadowski $ International Truck and Engine Corp. 5408 W. Eddy Street  Chicago, IL 60641   2 "Josef Derflinger" <derflinger@trueworldfoods.com>  >> derflinger@trueworldfoods.com >> true world foods  >> 3234 papetti plaza  >> Elizabeth, nj 07207 >>  ( "Carl Friedberg" <friedberg@exs.esb.com> Carl Friedberg carl@comets.com  www.comets.com    1 "Gelman, David" <david.gelman@icm-computer.co.uk>  David Gelman 5 Primley Park Garth Leeds, West Yorkshire  LS17 7LE United Kingdom  . Gary Gladstone <gary_gladstone@rocketmail.com> Gary Gladstone G-Squared Consulting, Inc  2712 Woodfern Ct Lake Ridge VA 22192-2042   301-763-8896 (work)   3 "Grist, Catherine" <Catherine.Grist@NA.SunChem.com>  Catherine Grist  Sun Chemical 135 West Lake Street Northlake, IL  60164   708/236-3659 708/562-7859 (fax)  " "jimgursha" <jgursha@sandisks.com>! PLease send me the CD. Jim Gursha  1735 York AVenue, Apt 31G  NY, NY 10128B ------------------------------------------------------------------( People to be supplied by Steven Bitgood:    & "Mike Jaycox" <JaycoxM@mh.state.oh.us> Michael Jaycox Ohio Dartment of Mental Health Office of Support Services 2150 W. Broad St.  Columbus, Ohio 43223( A Email:  jaycoxm@mhmail.mh.state.oh.us  ? Work Phone (614) 752-0195   & "Jay E. Morris" <morrisj@epsilon3.com>
 Jay E. Morris 
 9081 FM 78 Suite 102, PMB 139 Converse, TX  78109   + "Hittner, David T." <david.hittner@ngc.com>    David Hittner    Northrop Grumman   2555 University Blvd.    Fairborn, OH 45324    6 "Muehlbauer, Jeffrey" <jmuehlbauer@artisticcarton.com> Jeffrey J. Muehlbauer " Director, Information Technologies Artistic Carton Company  1975 Big Timber Road Elgin, Illinois  60123! Main:              (847) 741-0247 " Fax:                (847) 741-8529  Direct:           (847) 717-1950  Cell:             (630) 430-47561 E-Mail:           jmuehlbauer@artisticcarton.com    ( "Robert Novak" <Robert.Novak@bmcjax.com>	 Bob Novak  Team Lead - Technical Support  Howard Bldg, Suite 510 Baptist Medical Center 820 Prudential Drive Jacksonville, FL 32207  % "O'Connor, Marty" <MOConnor@DVFS.COM>  Marty O'Connor   Sr. Technical Architect ) Delaware Valley Financial Services, Inc.   300 Berwyn Park  Berwyn, Pa 19312 (610) 296-9600 x1223   MOConnor@DVFS.com     ! "Ray Peppo" <crpeppo@hotmail.com>  Systems Administrator, OpenVMS  P Systems                                                &nb! sp;                  Network Administration  Y Group                                                                                     Q CORESTAFF Services                                                         &nbs!  w 1775 St. James Place                                                                                                    # Suite 300                    &nbs!   Houston, Texas  R 77056                                                                         &n!    713-348-1431  + "JEFFREY D. SANDERS" <JDSANDER@sentara.com>  Jeffrey Sanders  Application Developer I  Sentara Healthcare 600 Gresham Dr	 Suite 306  Norfolk, VA 23507     A ----------------------------------------------------------------- % People to be supplied by Sherri Lyon:   $ Bert Twomey <bert.twomey@ca.ibm.com>
 Bert J Twomey  Advisor - Technical Srvcs  IBM Global Services  483 Bay Street, Floor 11NB Toronto, Ontario  M5G 2E1  Canada  3 Robert Underwood <Robert.Underwood@blockbuster.com>  Robert Underwood 3513 Concord Rd  Doylestown, PA  18901  Bob.Underwood@IEEE.org  * "Martin Vasas" <Martin.Vasas@unilever.com>I "martin.vasas.grd.chem@aya.yale.edu" <martin.vasas.grd.chem@aya.yale.edu>  Martin Vasas
 15 Lyda Drive  Milford CT 06460  : "Wilkinson, Douglas N" <douglas.n.wilkinson@citigroup.com> 		Doug Wilkinson 		5222 Buss Drive  		Emmaus, Pa 18049  , david w williams <david.w.williams@juno.com> David Williams 435 Matamoras Rd Halifax, PA 17032      + "Camaroto, Eddie" <eddie.camaroto@csfb.com>  Eddie Camaroto 10 North Woodland Avenue East Brunswick, NJ 08816-1616.   Eddie Camaroto Assistant Vice President Manager VMS systems - Americas- 1-609-243-0886<?xml:namespace prefix = o ns =    Brian Schenkenberger 14 Rutgers Rd. Jackson, NJ 08527  vaxman@tmesis.com   > --------------------------------------------------------------- People to be supplied by Christopher Herrick:    Warren Kahle <warren@kahle.com>  Warren Kahle
 4102 Ascot Ln  Houston TX 77092-8312   ) "Minotti, Dorothy W." <MinottiD@cofc.edu>  Dorothy W. Minotti College of Charleston  66 George Street Bell Bldg. # 510 Charleston, SC  29424   + "Viswasam, James" <James_Viswasam@mhhs.org>  James R Viswasam" Memorial Hermann Healthcare System" 9401 Southwest Freeeway, Suite 836 Houston, TX 77077  Ph: 713-448-5425   James Viswasam VMS Technical Services" Memorial Hermann Healthcare System   Tom_Wetty@vwr.com  Thomas Wetty 9 Freeport Road  New Castle,  DE  19720   Thomas Wetty Sr. Programmer/Analyst QSS Warehouse Systems  VWR, International& (610) 429-5523 , (484) 467-1661 (cell)     1 From: O'Connor, Marty [mailto:MOConnor@DVFS.COM]   Marty O'Connor Sr. Technical Architect ( Delaware Valley Financial Services, Inc. 300 Berwyn Park  Berwyn, Pa 19312 (610) 296-9600 x1223 MOConnor@DVFS.com   = ------------------------------------------------------------- ' People to be supplied by Henry Juengst:      "Grimme, Jon" <JGrimme@MSA.com> *         Management Science Associates, Inc         Jon Grimme, Sr. Eng.         6565 Penn Ave "         Pittsburgh, Pa. 15206-4490   Paul Horine <horine@us.ibm.com>  Paul Horine , Manager,  VMS DEC VAX /Alpha Systems Support 6300 Diagonal Highway   025T Boulder,  CO    80301     $ "Kaledas, Ronald" <RKaledas@dmc.org> Ron Kaledas  Detroit Medical Center 3663 Woodward, Fifth Floor Detroit, Mi  48201   A. Mahendra Rajah  Dept. Computing Services Univ. of Regina  Regina, Sask. s4s 0a2  Canada   jwhome@comcast.net Jerry Wojtak c/o Wojtak Consulting  208 South Harvey Ave.  Oak Park, IL  60302     - "James Cristofero" <jcristof@columbus.rr.com>  James Cristofero jcristof@columbus.rr.com   - From: Paul Horine [mailto:horine@US.IBM.COM]     Paul Horine , Manager,  VMS DEC VAX /Alpha Systems Support 6300 Diagonal Highway   025T Boulder,  CO    80301   8 Askins Lance Contr AEDC/ATA <Lance.Askins@arnold.af.mil> M. Lance Askins  Aerospace Testing Alliance 760 Fourth Street  Arnold AFB, TN 37389-6200 $ A Email:  Lance.Askins@arnold.af.mil ? Work Phone (931) 454-7173    james.lunde@aurora.org	 Jim Lunde  Aurora Health Care 3031 W Montana St  Heil Ctr - 2nd Flr Milwaukee, WI 53234-3910  	 Jim Lunde  Aurora Health Care Sr. Systems Software Engineer  (414) 389-2349  & Ted Medenblik <ted.medenblik@duke.edu>
 Ted Medenblik  4101 N. Roxboro Road Durham, NC 27704    
 Ted Medenblik   Duke Health Technology Solutions PRMO IT Division Duke University Health System  (919) 620-4987   michelle@popejoy-solutions.biz Michelle Popejoy Popejoy Solutions, Inc.  P.O. Box 754 Savona, NY 14879 (607) 738-9489   Marty Kuhrt  20 Castle Lane Oakland, CA, 94611 510 531 6624  ( --------------060103030005000403040406--   ------------------------------    Date: 10 Nov 2006 11:16:44 -0800< From: "Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com>? Subject: Re: writing fixed size records with one shorter record C Message-ID: <1163186204.399363.206230@k70g2000cwa.googlegroups.com>    Albrecht Schlosser wrote:   > Hein RMS van den Heuvel wrote: > > Albrecht Schlosser wrote: = > >  -->  FAT$V_RTYPE=FAT$C_UNDEFINED     FAB$B_RFM=FAB$C_UDF  > Q > I understand "FAB$B_RFM=FAB$C_UDF", but what does "FAT$V_RTYPE=FAT$C_UNDEFINED" : > mean? (guess: the same, but what language/tool/context?)  G Interesting you picked up on that! It was a deliberate cut & paste from  the SET FILE /ATTR help text. 2 The RFM=UDF referds to DCL dealing with those bits4 The FAB stuf is the RMS language as you surmised andG The FAT stuff refers to the ACP QIO interface to those same attributes.   F  > I think that I will give that a try. Just found a piece of my own C	 code that P > writes a (real fixed length) file with sys$put. Setting the correct attributes > should not be a big deal,   2 Correct. Coudl be done while initializing the FAB.  > > but I do hope that the resulting file would then be  usable.   That will be the big test.G Some standard tools ('search if I recall correctly') don't care to deal  with UDF files. D You can always SET FILE/ATT=(RFM=FIX,LRL=512,MRS=512) afterwards :-)   ------------------------------    Date: 10 Nov 2006 14:14:05 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ? Subject: Re: writing fixed size records with one shorter record 3 Message-ID: <7nhSt1NzlOdd@eisner.encompasserve.org>   m In article <u1fe24-4ud.ln1@news.hus-software.de>, Albrecht Schlosser <ajs567XNewsX-XNewsX@tiscali.de> writes: # > This is how the file gets opened:  > ! >          OPEN    (UNIT   = LUN, " >       *           FILE   = NAME,# >       *           TYPE   = 'NEW', + >       *           CARRIAGECONTROL='NONE', ) >       *           RECORDTYPE = 'FIXED', ! >       *           RECL   = 512, " >       *           ERR    = 2900) >   G    RECORDTYPE of FIXED and RECL of 512 for a formatted file means every     record _will_ be 512 bytes.  G    VMS can handle your needs as undefined record type.  I haven't tried G    it but HELP makes it look like specifying Fortran RECORDTYPE STREAM  J    may do what you want.  If not, I'd try using a USEROPEN routine before .    I'd bother doing all the I/O via RMS calls.   ------------------------------  % Date: Fri, 10 Nov 2006 16:51:37 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ? Subject: Re: writing fixed size records with one shorter record 7 Message-ID: <f03a3$45550275$cef8887a$6754@TEKSAVVY.COM>    Hein RMS van den Heuvel wrote:; > Well, it is not really a fixed length 512 file is it now? : > Just some tools seemed to find it handy to call it that.  G While I *understand* the above, in practice,  don't fixed length files  L still have a end-of-file offset for the last block ? If so, it should still B be possible to have the last record shorter then the fixed length.  ! An example ZIP file: DUMP/HEADER:         VAX-11 RMS attributes0          Record type:                      Fixed5          File organization:                Sequential ;          Record attributes:                <none specified> .          Record size:                      5120          Highest block:                    391040          End of file block:                39093.          End of file byte:                 426,          Bucket size:                      0,          Fixed control area size:          0.          Maximum record size:              512,          Default extension size:           0,          Global buffer count:              0,          Directory version limit:          0    + Note the end of file byte not being at 512.   9 (this was created with FTP and SET TYPE=IMAGE during FTP)     L It would *appear* to me that if you do not put the equivalent of ctx=rec as J record processing option,  you *should* be able to write raw data and the K system fills the blocks and when you close the file, it should set the end  * of file marker where you last write ended.   ------------------------------   End of INFO-VAX 2006.620 ************************