1 INFO-VAX	Thu, 09 Aug 2001	Volume 2001 : Issue 440       Contents:* Re: ACCVIO problem - any help appreciated.* Re: ACCVIO problem - any help appreciated. Re: Alpha-IA64 FAQ Article from Information week E Re: Automating MS Access with DCL code for a report run once a month. 6 RE: Backup disk on one system to tape drive on another6 Re: Backup disk on one system to tape drive on another6 Re: Backup disk on one system to tape drive on another6 Re: Backup disk on one system to tape drive on another. Re: Can queue manager handle 100.000 entries ?5 Re: DECwindows keyboard problem: <> keys do not work. 
 Flip-Chip" Re: Flip-Chip" Re: Flip-Chip" Re: Flip-Chip"% RE: fms - prototype definitions for C  Re: free software available  Re: free software available  Re: GEMBASE x OpenVMS 7.3  Re: HELP..VMSer in UNIX land HELP..VMSer in UNIX land/ Re: How to build a bootable media for a 11/780? 9 I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = RE: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel 1 RE: Installing V7.3 on Personal Workstation 500au ! Re: Lemmings, was Re: Move to Sun ! Re: Lemmings, was Re: Move to Sun ! Re: Lemmings, was Re: Move to Sun ! Re: Lemmings, was Re: Move to Sun ! Re: Lemmings, was Re: Move to Sun ! Re: Lemmings, was Re: Move to Sun  Linker-Warnings in VMS 7.3 Re: Microsoft and Code red Microsoft and CR Re: Microsoft and CR Re: Microsoft and CR Re: mount spare internal disk  Re: Move to Sun  Re: Move to Sun  Re: OpenVMS and IA64 pb dec
 Re: pb dec Re: PGP on VMS Re: Press Release , Re: Qume QTV-202 keyboard and Dec 3000/300LX! Re: Red Code: where are we going? ) Re: Shameless Grab; Was Re: uVAX 3100 M38 ) RE: Shameless Grab; Was Re: uVAX 3100 M38 3 Re: Source for non-standard DEC 15 Amp power cords? 3 Re: Source for non-standard DEC 15 Amp power cords? 4 Re: Suggested DCPS features (was OpenVMS  + Itanium)4 Re: Suggested DCPS features (was OpenVMS  + Itanium)4 Re: Suggested DCPS features (was OpenVMS  + Itanium)4 Re: Suggested DCPS features (was OpenVMS  + Itanium)$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64& Re: The VMS Opensource Porting Project" The VMS Opensource Porting Project Re: Third postcard from Sun  Re: Third postcard from Sun  Re: Third postcard from Sun  Re: Third postcard from Sun   Re: UNIX-cd product distribution% Re: Variable length records - example = Re: very nice message also room for feedback on this web site  Re: VMS 7.3 experiences? Re: VMS 7.3 experiences? Re: VMS 7.3 experiences?' VMS Seminar for "Experienced Beginners"  Re: vmstar questions Re: Vortex Server  We've launched TAPESYS v6.0 ; Re: You Get What You Pay For, a.k.a., There's No Free Lunch   F ----------------------------------------------------------------------  $ Date: Thu, 9 Aug 2001 09:03:14 -04000 From: "Syltrem" <syltrem@videotron.ca.spammenot>3 Subject: Re: ACCVIO problem - any help appreciated. 5 Message-ID: <EQvc7.51982$TW.262735@tor-nn1.netcom.ca>   A Your traceback info is missing the module name, line number, etc.   H Do you happen to have the source for this? The easiest would be to checkJ what exactly it is doing on the line that causes the error. The best is toD run it through debug, wait until it crashes and see where the PC is.  I Without the source code it may be hard to see what is going wrong, as you / don't know what operation is causing the error.    --   Syltrem ; http://pages.infinit.net/syltrem (OpenVMS related web site)     C "Rob Buxton" <rob.buxton@wcc.govt.nz> a crit dans le message news: $ 3b71a6c3.3428820@news.wcc.govt.nz... > Hi Folks,  > 9 > Spent a while on this and I'm getting a tad frustrated. G > We have a program that was working okay until I put a raft of patches  > onto our Production Alpha. > Patches were: 9 > DEC VMS AVAIL_MAN V2.0              Full LP     Install  > 05-AUG-2001 12:14:559 > DEC AXPVMS TCPIP_ECO V5.1-151       Patch       Install  > 05-AUG-2001 12:10:029 > DEC AXPVMS DNVOSIECO03 V7.2         Patch       Install  > 05-AUG-2001 12:03:469 > DEC AXPVMS VMS721_SHADOWING V6.0    Patch       Install  > 05-AUG-2001 12:00:509 > DEC AXPVMS VMS721_RENAME_OLD V1.0   Patch       Install  > 05-AUG-2001 11:59:379 > DEC AXPVMS VMS721_F11X V3.0         Patch       Install  > 05-AUG-2001 11:55:279 > DEC AXPVMS VMS721_RMS V2.0          Patch       Install  > 05-AUG-2001 11:48:579 > DEC AXPVMS VMS721_MANAGE V2.0       Patch       Install  > 05-AUG-2001 11:47:029 > DEC AXPVMS VMS721_AUDSRV V1.0       Patch       Install  > 05-AUG-2001 11:45:319 > DEC AXPVMS VMS721_SYS V10.0         Patch       Install  > 05-AUG-2001 11:34:409 > DEC AXPVMS VMS721_UPDATE V3.0       Patch       Install  > 05-AUG-2001 11:28:19 > A > These Patches were applied to our Development Alpha a few weeks 	 > before. F > So, on both Production and Development Alphas we're running the same% > version of VMS (7.2-1) and Patches. C > On Development the job runs fine, on Production it fails with the  > ACCVIO below.  >  > Print Date = 08-Aug-2001= > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual < > address=000000000057E000, PC=000000000011EB20, PS=0000001B1 > %TRACE-F-TRACEBACK, symbolic stack dump follows ; >   image    module    routine             line      rel PC  > abs PC > G > I've copied all of the data files it uses to a separate directory and ? > used local assigns to reference the data to ensure there's no H > different data. Still it fails on Production and works on Development. > < > The User Quotas are higher on Production than Development. > F > The run time also varies, the job should take about 7-8 minutes, butB > sometimes it fails immediately and other times after running for3 > several minutes (almost to the end but not quite)  > F > It also works on the VAX variant of the image against the same data. > F > Are there any SYSGEN Parameters that might influence this behaviour? > C > The main difference I can see is that on Production we use Volume H > shadowing and on Development we do not. I've tried moving all the dataH > to a non-shadowed disk but that still failed. Also moved it to a local  > disk to rule out mscp serving. > # > Further tests & checks I've done. ? > Checked the link dates of the image being run on Production &  > Development - it's the same B > Checked the dates on files in sys$library:, sys$loadable_images,H > sys$system to ensure that the order of patches hasn't left a different > image in place. D > Used SDA and Availability Manager to watch for quotas and to watchD > what files are held open and specifically ensure they're the same. > F > On Production, we have two similary configured Alphas, the job failsG > on both. On Development we have two Alphas, the second is on 7.3, the  > job works on both of these.  >  > Bewildered again!  >  > Rob. >    ------------------------------   Date: 9 Aug 2001 13:11:19 GMT 5 From: koehler@bessta.gsfc.nasa.aspm.gov (Bob Koehler) 3 Subject: Re: ACCVIO problem - any help appreciated. / Message-ID: <9ku25n$4ml$1@skates.gsfc.nasa.gov>   [ In article <3b71a6c3.3428820@news.wcc.govt.nz>, rob.buxton@wcc.govt.nz (Rob Buxton) writes:    >  >Print Date = 08-Aug-2001 < >%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual; >address=000000000057E000, PC=000000000011EB20, PS=0000001B 0 >%TRACE-F-TRACEBACK, symbolic stack dump follows: >  image    module    routine             line      rel PC >abs PC  >   ; >The User Quotas are higher on Production than Development.  >    > E >It also works on the VAX variant of the image against the same data.  > E >Are there any SYSGEN Parameters that might influence this behaviour?  >   H Possibly.  If there are unchecked malloc's in the code a SYSGEN parmeterF just might be making some malloc fail on one system that is working onJ another.  But the odds of getting 57E000 as the address I think are rather small.  H Get into the development environment and find out what's at 11EB20 (linkH map, then compiler listing with assembly language, make sure you use theD same link and compile commands except for adding maps and listings).  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = GSFC Code 582 Flight Software   | Federal Sector, Civil Group I                                 | please remove any ".aspm" when replying    ------------------------------  # Date: Thu, 09 Aug 2001 15:24:10 GMT + From: "Richard Tomkins" <tomkinsr@home.com>  Subject: Re: Alpha-IA64 FAQ < Message-ID: <uWxc7.21568$Ok5.3363250@news3.rdc1.on.home.com>  0 http://www.compaq.com/hpc/ref/ref_alpha_ia64.doc  : This document makes a strong case for the Alpha Processor.   rtt      Alpha and IA64 Executive Summary   I Applications have two types of parallelism: instruction-level parallelism F and thread-level parallelism.  Instruction-level parallelism enables a; processor to issue multiple instructions in the same cycle. J Instruction-level parallelism can be static (discovered by the compiler atC compile-time) or dynamic (discovered by the processor at run-time). E Thread-level parallelism enables a processor to run multiple threads, ( processes, or programs at the same time.  D An Alpha processor will exploit static and dynamic instruction-levelG parallelism with out-order execution, and thread-level parallelism with F simultaneous multithreading.  Out-of-order execution has a performanceK benefit of 1.5-2x over in-order execution.  Simultaneous multithreading has 1 benefit of 1.5-3x over single threaded execution.   J  An IA64 processor will only exploit static instruction-level parallelism.D It cannot take advantage of dynamic instruction-level parallelism orL thread-level parallelism.  IA64 defines a set of architectural extensions toG permit compilers to identify more instruction-level parallelism.  These J architectural extensions will make it very difficult for an IA64 processorB to implement out-of-order execution or simultaneous multithreadingA efficiently.  For most applications, the small benefit that these K architectural extensions give compilers does not equal the performance lost & by not using these dynamic techniques.  F Alpha will be superior to IA64 on commercial applications.  CommercialL applications are very sensitive to code size.  The IA64 instruction encodingF increases the code size of a program by at least 33%, and the compilerG techniques required by the IA64 introduce many additional instructions. F Commercial programs are difficult to analyze at compile-time, and IA64F cannot dynamically adjust to program behavior at run-time.  CommercialL programs have very low instruction-level parallelism, but they are typicallyK explicitly multithreaded.  Each thread is very sequential and includes long > delays waiting for memory.  The IA64 strategy of searching forA instruction-level parallelism cannot find the orders of magnitude D improvements available to Alpha through simultaneous multithreading.  G Alpha will be superior to IA64 in high performance technical computing. K Memory bandwidth and the scalability of the system limit the performance of J most high performance technical applications.  Future Alpha processors areL adding a low-latency, high-bandwidth memory interface on chip, together withI on-chip support for distributed shared memory.  The next generation Alpha K processors will have the fastest memory system in the industry.  Alpha will 6 be the leader in high performance technical computing.       1. Introduction   L Future Alpha processors will be developed around two architectural concepts:7 out-of-order execution and simultaneous multithreading.   K ? Out-of-order execution enables the processor to schedule the execution of F instructions in an order that maximizes program performance.  It has a2 proven benefit of 1.5-2x over in-order  execution.  K ? Simultaneous multithreading (SMT) enables multiple threads (or processes) K to run simultaneously on a single microprocessor.  Most server applications H are divided into multiple threads, and SMT permits these applications toJ take full advantage of the multiple execution units on the processor.  SMT7 has a benefit of 1.5-3x over single threaded execution.   I These two features permit an Alpha processor to exploit both thread-level K parallelism and instruction-level parallelism.  The processor can use these F two types of parallelism interchangeably, and dynamically adapt to the( varying requirements of the application.  E Intel has chosen a markedly different direction than Alpha.  Intel is L introducing a new 64-bit instruction set architecture called IA64. They haveL called the architecture EPIC, for Explicitly Parallel Instruction Computing,L but it is essentially a VLIW (Very Long Instruction Word) architecture.  TheB IA64 architecture is very similar to the Cydrome machine, a failedL minisupercomputer company of the 1980s.  The first implementation of IA64 is? called Merced, with a follow-on implementation called McKinley.   L With the IA64, Intel is focusing on a compiler-driven technology to increaseK instruction-level parallelism, and is ignoring other proven ways to improve E performance on large applications.  IA64 is developed for an in-order E execution model, with a set of new architectural extensions to permit @ compilers to identify more instruction-level parallelism.  TheseK architectural extensions will make it very difficult for IA64 processors to L implement out-of-order execution or simultaneous multithreading efficiently.L For most applications, the small benefit that these architectural extensionsK give compilers do not equal the performance lost by not using these dynamic  techniques.      2. Design Philosophy  ) IA64: a smart compiler and a dumb machine   J The IA64 design is a derivative of the VLIW machines designed by MultiflowI and Cydrome in the 1980s.  The key idea is a generalization of horizontal K microcode: in a wide instruction word the processor presents control of all C of the functional units to the compiler, and the compiler precisely H schedules where every operation, every register file read, every bypass,J will occur.  In effect, the compiler creates a record of execution for theG program, and the machine plays that record.  In the early VLIWs, if the E compiler made a mistake, the machine generated the wrong results; the K machine had no logic to check that registers were read in the correct order I or if resources were oversubscribed.  In more modern machines such as the E IA64 processors, the machine will run slowly (but correctly) when the  compiler is wrong.  F The IA64 design requires the compiler to predict at compile-time how aH program will behave.  Traditionally, VLIW-style machines have been builtG without caches and focused on loop-intensive, vectorizable code.  These I restrictions mean the memory latency is fixed and branch behavior is very D predictable at compile-time.  However, IA64 will be implemented as aG general-purpose processor, with a data cache, running a wide variety of I applications.  In most applications, the latency of a memory operation is L very difficult to predict; a cache-miss may have a latency that is 100 timesL longer than a cache hit.  Alpha's out-of-order design can dynamically adjustL to the cache pattern of the program; on an IA64 processor, when the compiler( makes a mistake, the machine will stall.  D Similarly, the IA64 design requires the compiler to move code acrossK branches to find parallelism.  However, this decision requires the compiler K to predict branch direction at compile-time.  This is very difficult to do, K and even with elaborate profile-feedback systems, where a program is run to I gather information about its behavior before it is compiled, compile-time K branch prediction rates are at best 85%. Without feedback, the compile-time J rates are much closer to 50%.  In contrast, hardware branch predictors areK 95-98% accurate.  An IA64 design will be executing unprofitable speculative 8 instructions 3-10x more frequently than an Alpha design.  E The IA64 is an architectural idea that was developed for vectorizableVJ programs.  Intel has tried to extend it to commercial applications, but it5 is fundamentally the wrong design for these problems.h    + Alpha: a smart compiler and a smart machinem  K An explicit goal in the development of the Alpha architecture was to enableeK innovative performance improvements in compilers, architecture, and circuitpL implementation.  We did not add features to the instruction set architectureI that make compiler improvements easy but hardware improvements difficult.hG In the early 1990s, we designed a VLIW version of Alpha similar to IA64rK [1,2,3,4,5,6].  During this process we discovered that most of the compiler G technology for a VLIW processor could equally well be applied to a RISC H processor, and that by avoiding IA64-style extensions to Alpha, we could) also implement an out-of-order processor.I  L Alpha is designed to exploit both compile-time and run-time information.  WeI agree with the IA64 designers that the compiler should create a record ofoH execution for a program.  However, we also recognized that the processorL will know at run-time additional information about a program's behavior, forH example, whether a memory reference is a cache miss and what direction aF branch executes.  Rather than stall the processor when the compiler isK wrong, we designed an out-of-order issue mechanism that allowed the machineeJ to adapt to the run-time behavior of the program.  In addition, a compilerE has a restricted view of the program and often cannot optimize acrossiI routine or module boundaries.  At run-time, an out-of-order processor cantF find parallelism across these boundaries.  Compiler technology must beJ combined with out-of-order execution to extract the most instruction-level parallelism from a program.l  A Simultaneous multithreading permits an Alpha processor to exploit0L thread-level parallelism in addition to instruction-level parallelism.  MostD commercial applications have very small amounts of instruction-levelK parallelism, but they are frequently composed of multiple parallel threads.eA SMT enables an Alpha processor to achieve large speedups on theseCJ applications.  SMT also permits the processor to exploit instruction-level' parallelism fully when it is available.   C Alpha is designed for a wide range of commercial applications.  ItstJ industry-leading memory bandwidth and high floating point performance will@ enable it to excel on scientific programs as well.  Simultaneous= multithreading is a natural extension of Alpha's out-of-orderlE implementation.  It is the most powerful mechanism for exploiting theo3 explicit parallelism in most application workloads..     3. Alpha features    Out-of-order execution  < Out-of-order execution is a combination of three techniques:  F ? Dynamic scheduling. The processor can reorder instructions to reduce processor stalls.e  B ? Register renaming.  The processor can rename registers to remove/ write-after-read and write-after-write hazards.4  I ? Branch prediction.  The processor can predict the direction of a branchb before the branch is executed.  F The basic organization of a processor is the fetch-execute cycle.  TheI processor fetches an instruction from the instruction cache, executes thehB instruction, updates the register file and memory, and retires theC instruction.  Pipelined systems overlap these stages for successiveuL instructions.  Out-of-order systems fetch multiple instructions into a queueK (or instruction window).  The processor can execute the instructions in therI window "out-of-order", but it must retire the instructions and make theirlH results visible in the register file and memory system in program order.F These concepts are best understood by looking at some simple examples.    A Dynamic scheduling.  Figure 1 presents a straight-line block of 4tI instructions, written in pseudo-code.  Consider executing this block on aeK 4-issue machine with a 3-cycle load latency on a cache hit.  On an in-order F pipeline, the sequence will take 7 cycles, assuming cache hits.  On anJ out-of-order pipeline, the processor will fetch all 4 instructions at onceI and notice that the second LOAD is independent of the first ADD.  It will6K move the second LOAD up to dual issue with the first, and the sequence will2 take 4 cycles.    &        in-order           out-of-order;   t1 = LOAD a0         0: t1 = LOAD a0      0: t1 = LOAD a0 9   t2 = ADD t1,1       1:                     t3 = LOAD a1 ,   t3 = LOAD a1        2:                  1:,   t4 = ADD t3,1       3: t2 = ADD t1,1    2::                          t3 = LOAD a1     3: t2 = ADD t1,1:                       4:                     t4 = ADD t3,1                       5:&                       6: t4 = ADD t3,1 Figure 1: Dynamic scheduling.5  H Of course, within a straight-line block of code, the compiler could (andK should) schedule the code, moving the second LOAD above the ADD, and givingn> the in-order machine the same performance as the out-of-order.  F There are two situations where the compiler and the in-order processorC cannot equal the out-of-order processor.  The first is dealing withtI operations of variable latency.  In the example above, assume each of theOF LOADs occasionally misses the cache and goes to memory, resulting in aK latency of 100 cycles or more.  The out-of-order machine will delay the ADD J that is dependent on the load, but it will continue fetching and executingK instructions that are not dependent on the LOAD.  The in-order machine will K stall at the ADD instruction, and will not execute any further instructionsfK until the LOAD completes, resulting in a 100-cycle stall for the processor.   I A second situation is dealing with memory aliasing.  If there was a STOREsH between the first ADD and the second LOAD, and the compiler cannot proveK that the LOAD always refers to a distinct location from the STORE, then thetK compiler cannot move the LOAD above the STORE.  In an out-of-order machine,gD the processor will know the addresses of the LOAD and the STORE, and7 determine if it is safe for them to issue out-of-order.a      F IA64 has introduced architectural support for speculative execution toK address the problems of variable latency and memory aliasing in an in-orderlJ processor.  However, this support is not as powerful a solution as dynamic scheduling.   H Register renaming.  Figure 2 presents a similar straight-line block of 4H instructions.  Note that the second LOAD reuses the same register as theJ first.  A compile-time scheduler for an in-order processor cannot move theL second LOAD above the preceding ADD, because the second LOAD would overwriteH the input of the ADD.  This is called a write-after-read hazard.  In theL out-of-order processor, the architectural registers are mapped into a largerJ physical register file, and the result of each instruction is written to aB distinct physical register.  This removes all write-after-read andL write-after-write hazards, and permits the processor to move the second LOAD above the ADD.  ?                            in-order                out-of-ordere?       t1 = LOAD a0      0: t1 = LOAD a0         0: p1 = LOAD a0s?       t2 = ADD t1,1     1:                         p3 = LOAD a162       t1 = LOAD a1      2:                      1:2       t1 = ADD t1,1     3: t2 = ADD t1,1        2:@                            t1 = LOAD a1         3: p2 = ADD p1,1@                         4:                         p4 = ADD p3,1                         5:(                         6: t1 = ADD t3,1     Figure 2: Register renaming.  H Of course, within a straight-line block of code, the compiler could (andE should) rename the architectural registers to permit the scheduler totI reorder the instructions.  This can typically be done unless the compilerhH has run out of architectural registers to allocate, or if there are someI required bindings of the registers. For example, at a procedure call, theh= calling standard requires the use of some specific registers.h  L IA64 has introduced a large number of registers to permit the compiler to doD aggressive renaming.  However, this register real estate can be moreK effectively used to hold a large physical register file for an out-of-ordero
 processor.  L Branch prediction.  Figure 3 presents a two-block sequence of code, where weL load and add a value, and then branch to L1.  Assume the branch is predictedG correctly.  On an in-order machine, this sequence takes 9 cycles.  Even G though the branch is predicted correctly, the in-order processor cannot-J issue the instructions after the branch until the branch is issued.  On anL out-of-order machine, the correct branch prediction permits the processor toL examine all 5 instructions at once, and dynamically schedule the second LOAD and ADD before the branch.  9                      in-order                out-of-ordert?       t1 = LOAD a0      0: t1 = LOAD a0         0: p1 = LOAD a0w?       t1 = ADD t1,1     1:                         p3 = LOAD a1d2       BEQ t1, L1        2:                      1:2                         3: t1 = ADD t1, 1       2:@       L1:               4: BEQ t1, L1           3: p2 = ADD p1,1@       t1 = LOAD a1      5: t1 = LOAD a1            p4 = ADD p3,1=       t1 = ADD  t1,1    6:                      4: BEQ p2, L1l                         7:(                         8: t1 = ADD t3,1     Figure 3:  Branch prediction  D A compiler technique called trace scheduling permits the compiler toK schedule all of the instructions along an execution trace as a single basicdJ block.  This would enable the compiler to schedule the second LOAD and ADDA in parallel with the first.  However, to perform this code motion L profitably, the compiler needs to be able to predict the branch correctly atL compile-time.  Without any additional knowledge of the program behavior, theI compiler will be wrong 50% of the time.  Even with run-time feedback, theaG compiler will at best be correct 85% of the time.  Good hardware branch-L predictors, which are used by an out-of-order machine, are correct 95-98% ofI the time.  The compiler's prediction will be wrong 3-10 times as often asuL the out-of-order processor, and the performance of the in-order machine will0 not be able to equal the out-of-order processor.  I If a compiler moves a load above a conditional branch, it must be careful L not to introduce an unwarranted exception, for the load will now be executedC when the program did not intend it to be.  IA64 has introduced somegK architectural features to address this problem. However, using this featureh0 will also increase the code size of the program.    L Predicting through a function call.  Figure 4 presents a 3-block sequence ofH code, where the first two blocks lead up to a function call.  Assume theI branch is predicted correctly.  In the in-order machine, this requires 11tH cycles.  In the out-of-order machine, the correct branch prediction willJ permit the processor to see the instructions on both sides of the functionJ call, and the processor can complete execution of the body of the function' before the BSR instruction is executed!n  <                         in-order                out-of-order?       t1 = LOAD a0      0: t1 = LOAD a0         0: p1 = LOAD a0i?       t1 = ADD t1,1     1:                         p3 = LOAD a1c2       BEQ t1, L1        2:                      1:2                         3: t1 = ADD t1, 1       2:@       L1:               4: BEQ t1, L1           3: p2 = ADD p1,1?       BSR foo           5: BSR foo                 p4 = ADD p3,f=                         6: t1 = LOAD a1         4: BEQ p2, L1e:       foo:              7:                      5: BSR foo6       t1 = LOAD a1      8:                      6: ret(       t1 = ADD t1,1     9: t1 = ADD t3,1       ret              10: ret- Figure 4:  Predicting through a function calll      K Of course, in a simple example like this, the compiler could simply in-lineiL the call itself, giving the in-order machine the same performance.  However,J inlining is often not a practical optimization, because the called routineB is too large or the routine body is not available to the compiler.  I In summary, the Alpha out-of-order design has several advantages over thee@ IA64 in-order design.  Alpha can adapt to memory references thatF occasionally miss in the cache, avoiding delays of 100 cycles or more.J Alpha can find parallelism when the architectural registers do not expressL it. And Alpha can find parallelism across branches and across function calls dynamically, at run-time.   K IA64 depends on compile-time predictions to obtain static instruction-levelnJ parallelism.  IA64 relies on the compiler to predict which loads will missL the cache, how memory operations alias with each other, and the direction ofH each branch.  If the compile-time predictions are correct, both IA64 andJ Alpha will perform well.  But when the compiler is wrong, the out-of-orderJ Alpha processor can adapt and continue to perform well.  The in-order IA64 will run slowly.     Simultaneous Multithreadinge  K Computer systems exploit two forms of parallelism: thread-level parallelismmH (TLP) and instruction-level parallelism (ILP).  Thread-level parallelismL enables a multiprocessor system to run multiple threads from an application,F or multiple independent programs, at the same time.  Instruction-levelJ parallelism enables a superscalar processor to issue multiple instructionsI in the same cycle.  Simultaneous multithreading (SMT) is a new technologyvK that permits a processor to exploit both TLP and ILP.  Multiple threads canfD run on an SMT processor, and the processor will dynamically allocateG resources between threads, enabling a processor to adapt to the varyingtH requirements of the workload.  Most server applications are divided intoK multiple threads, and SMT permits these applications to take full advantagey1 of the multiple execution units on the processor.h  B The unique advantage of an SMT processor is that it can use threadD level-parallelism and instruction-level parallelism interchangeably.B Multiple threads can run in parallel in the parallel portion of anK application; in the sequential portions, all of the processor resources can K be applied to a single thread.  Amdahl's law says that the performance of abB parallel application is limited by the amount of time spent in theG sequential portion; improving the performance of a parallel application G requires speedups in both the parallel and sequential portions.  An SMTr/ processor can effectively deliver this speedup.r  F The opportunity.  Alpha's out-of-order execution and IA64's explicitlyG parallel instruction computing both find parallelism at the instructionwL level.  They are both techniques for issuing multiple instructions per cycleL from a single thread.  The amount of potential instruction-level parallelismB is dependent on the program and varies greatly from application to application.  K Figure 5 presents a simple example with a large amount of instruction-levelnJ parallelism.  Assume we need to do 4 instructions of work for each elementH in array a, that the array is in the data cache, and that a load takes 3K cycles to return its value on a cache hit.  On a dual issue machine, we canlF load a future element of an array while we work on the current one andJ utilize the functional units effectively.  On a quad issue machine, we canL load two future elements while working on two current elements, and continue$ to use the machine very effectively.   for (i = 0; i < n; i++)c         work on a[i]           dual issue          ALU0        ALU1    0: LOAD a[i+1]      .s   1: work a[i]      work a[i]    2: work a[i]      work a[i]i   3: LOAD a[i+2]      .i   4: work a[i+1]    work a[i+1]    5: work a[i+1]    work a[i+1]w             quad issue  8        ALU0        ALU1              ALU2           ALU37   0: LOAD a[i+2]      .              LOAD a[i+3]      . ?   1: work a[i]      work a[i]        work a[i+1]    work a[i+1]c?   2: work a[i]      work a[i]        work a[i+1]    work a[i+1]e7   3: LOAD a[i+4]      .              LOAD a[i+5]      .w?   4: work a[i+2]    work a[i+2]      work a[i+3]    work a[i+3]r?   5: work a[i+2]    work a[i+2]      work a[i+3]    work a[i+3]l   Figure 5:  An array problem.    B Figure 6 presents a similar example with limited instruction-levelJ parallelism.  We have changed the data structure from an array to a linkedH list.  On a dual issue machine, we can load the next element of the listA while we work on the current one and utilize the functional unitsoI effectively.  However, on a quad issue machine, we can find no additionalnK parallelism.  We can only process one list element every three cycles, evenpD if we can parallelize the work on an element.  We cannot load futureK elements of the list until we have loaded the current one.  This limitation6H is fundamental to the example, and we cannot find more instruction-levelF parallelism without rewriting the program.  However, with simultaneousJ multithreading, we can use the unutilized functional units to run a second1 program, or another thread from the same program.g       while( a != 0)       work on node a       a = a->next              dual issue          ALU0        ALU1u   0: an = LOAD a->next   .   1: work a         work a   2: work a         work a   3: a = LOAD an->next   .   4: work an       work an   5: work an       work an             quad issue  8        ALU0           ALU1           ALU2           ALU37   0: an = LOAD a->next  .             .               .c:   1: work a          work a          work a         work a7   2:    .               .             .               .h7   3: a = LOAD an->next  .             .               .t;   4: work an        work an          work an        work an 7   5:    .               .             .               .e   Figure 6:  A list problem.  H Scientific applications typically use arrays as data structures and theyL have a large amount of instruction-level parallelism. Out-of-order issue andA explicitly parallel instruction computing will both perform well.rH Commercial applications typically use lists as data structures, and theyJ have much less instruction-level parallelism; often they average less thanF one instruction per cycle. Only a technique that exploits thread-levelG parallelism, such as simultaneous multithreading, can fully utilize thes" functional units of the processor.  J Simultaneous multithreading.  Simultaneous multithreading works by turning< thread-level parallelism into instruction-level parallelism.  K An Alpha out-of-order processor has an in-order instruction fetch mechanismoI and an out-of-order execution mechanism.  Instructions are fetched in theiH order that they appear in the program, and they are executed in an orderJ determined by the data dependencies between the instructions.  Between theJ fetch and execute portions of the machine is an issue queue.  Instructions? wait in the queue until they are ready to issue.  See Figure 7.o        H    [In-order fetch]  [Queue] [Out-or-order execution]  [In-order retire]    & Figure 7:  Alpha out-of-order pipeline      G SMT is implemented by enabling the fetch unit to fetch from a differentaJ thread every cycle.  The fetched instructions have their registers renamedK into a large physical register file, and then they are placed in the queue. G Due to the register renaming, instructions from multiple threads can beeH mixed in the queue.  The logic that determines whether an instruction isB ready to issue only examines physical registers, and it can selectK instructions from different threads in the same cycle.  In fact, it is verytF likely that instructions from different threads will issue in the same< cycle, for they will reference different physical registers.  J There is some minor bookkeeping required to keep track of the threads, butE the SMT can be implemented without any major changes to the processoreE pipeline, without an increase in the cycle time of the processor, ande7 without a significant increase in the size of the chip.-  L The processor dynamically adapts to the requirements of the threads with theL instruction fetch policy.  On a given cycle, we will fetch instructions fromJ the thread that has fewest instructions in-flight (i.e., instructions thatG have been fetched but not retired).  This prevents a single thread fromoL filling the instruction queue, and makes sure multiple threads are executingK at the same time, increasing the thread-level parallelism.  It also enablesnJ the thread with the most instruction-level parallelism at this time to use the machine effectively.         for each thread do       a = todo[tid]        while( a != 0)           work on node a           a = a->next     -                                Multiprocessor1<            processor 1                           processor 2L      ALU0  ALU1  ALU2  ALU3  ALU4 5 6  7       ALU0  ALU1  ALU2  ALU3 ALU4 5 6 7 L   0: LDan    .     .     .     .  . .  .       LDan    .     .     .    .  . . .fL   1: Wa     Wa     Wa    Wa    .  . .  .       Wa     Wa     Wa    Wa   .  . . .eL   2:  .      .     .     .     .  . .  .        .      .     .     .    .  . . .iL   3: LDa     .     .     .     .  . .  .       LDa     .     .     .    .  . . .cL   4: Wan   Wan    Wan    Wan   .  . .  .       Wan   Wan    Wan    Wan  .  . . .iL   5:  .      .     .     .                      .      .     .     .    .  . . .     0             Simultaneous multithreaded processor7      ALU0   ALU1   ALU2   ALU3   ALU4  ALU5  ALU6  ALU7m5   0: LDan0  LDan1  LDan2  LDan3   .     .     .     .t6   1: Wa0    Wa0    Wa0    Wa0    Wa1   Wa1   Wa1   Wa16   2: Wa2    Wa2    Wa2    Wa2    Wa3   Wa3   Wa3   Wa35   3: LDa0   LDan1  LDan2  LDan3   .     .     .     .i7   4: Wan0   Wan0   Wan0   Wan0   Wan1  Wan1  Wan1  Wan1f7   5: Wan2   Wan2   Wan2   Wan2   Wan3  Wan3  Wan3  Wan3l    ) Figure 8:  A multi-threaded list problem.eC Alternatives.  SMT can deliver more performance than a conventional E multiprocessor.  Consider a multithreaded version of the list programl? presented in Figure 8.  On two 8-issue processors arranged in apL multiprocessor systems, we will be able to process two list elements every 3L cycles.  On a single 8-issue SMT processor, with the capability of running 4J threads, we are able to process 4 list elements every 3 cycles.  With halfG the number of functional units, we can double the performance.  This isaL because the SMT machine can run more threads than the multiprocessor, and atJ the same time, offer each thread sufficient instruction-level parallelism.     4. IA64 features   IA64 basics   H The IA64 architecture introduces 64 bit addressing and a new instructionH set.  It also contains an IA32 mode; all IA64 processors will be able toH execute IA32 programs, though with disappointing performance.  IA64 is aK load/store architecture; memory can only be referenced by explicit load andfL store instructions.  All other instructions operate on registers.  There areF five register files: 128 64-bit integer registers, 128 82-bit floatingI register files, 64 1-bit predicate registers, 8 branch registers, and 128 G special purpose application registers. Each instruction typically has 2rG register inputs, 1 predicate input, and 1 output.  The instructions are-D gathered into 3 instruction bundles; the bundles are a mechanism for? expressing parallelism between instructions.  There is explicit F architectural support for speculative execution, predication, functionJ calls, and software pipelining.  We will consider these features in detail below.   Instruction format  L IA64 instructions are big.  3 instructions are packed into a 128-bit bundle;H each instruction is 41 bits, with a 5-bit template field to describe the* dependencies in the bundle.  See Figure 9.  G             127       .         87   86        .       46  45         .u
 5   4    .  0aK            [  instruction slot 2  |  instruction slot 1 |  instruction slot  0 | template ]7                       41b                           41bt 41b                 5b" Figure 9:  IA64 instruction format    * The larger instruction encoding is due to:  C ? Larger register files. A 128-entry register file requires a 7-bitgD identifier to select a register.  2 inputs specifiers and one output- specifier require 21 bits in the instruction.e  G ? Predication.  Each instruction requires 6-bit predicate specifier, top; select a predicate from a 64-entry predicate register file.n  L ? Explicit parallelism.  5 bits in each bundle are devoted to describing theJ dependencies within a bundle, or between bundles. The architecture permitsI the compiler to group multiple bundles together, and indicate that all ofhG the operations are data independent. The template bits indicate where a % block of independent operations ends.   @ Comparing the instruction encodings with Alpha, we see that IA64E instructions are 33% larger, based on their encoding alone.  An AlphanI instruction is 32 bits, and three instructions can be encoded in 96 bits. L The corresponding IA64 bundle is 128 bits.  Also, IA64 instructions can onlyJ be expressed in bundles of 3, and not all combinations of instructions areL allowed.  Some padding of bundles with no-ops is required.  In addition, allB the compiler techniques required for IA64 will increase code size.  I For important server applications such as on-line transaction processing, H code size has a first order effect on performance, and IA64 will be at a competitive disadvantage.B  F The instruction encoding permits VLIW-style parallelism.  For example,L Figure 10 shows the code for a simple loop that adds a constant to a vector,D with the loop unrolled by 2.  Each line in the figure is bundle of 3C instructions.  The double semicolon indicates the end of a group of H independent instructions.  Note that almost half of the instructions areJ NOPs due to restrictions on the placement of instructions in bundles.  ForC example, only one floating-point instruction can occur in a bundle.a  7     L1: LDFD f4 = [r5],8   LDFD f14 = [r15],8    NOP ;;l  4         NOP                FADD f7 = f4, f9      NOP7         NOP                FADD f17 = f14, f9    NOP ;;   ;         STFD [r6] = f7,8   STFD [r16] = f17,8   BR.cloop L1o  ! Figure 10:  A simple vector loop.8  E Unlike traditional VLIWs, IA64 is fully scoreboarded.  Bundles can betG chained together to indicate a sequence of data independent operations.aI However, the machine must check for dependencies between these sequences.eJ This removes much of the simplicity of the traditional VLIW.  In addition,2 IA64 must deal with the variable latency of loads.  J The ability to chain together bundles also permits the compiler to presentK an arbitrary amount of parallelism to the hardware.  This appears to removetJ one of the main weaknesses of a VLIW: that the code must be compiled for aJ specific width of machine.  However, it is clear for best performance, the( compiler must target a specific machine.L For example, consider the simple loop in Figure 10.  On a processor with twoJ memory units, a software-pipelined schedule can be written which maximizesI the use of these units.  But on a processor with 3 memory units, the loop E would need to be further unrolled; the current loop requires 4 memoryyJ references and a software pipelined schedule could only utilize the memoryB units 67% of the time.  The statically scheduled IA64 model cannot@ dynamically adjust to utilize the machine resources efficiently.   Large register files  K IA64 has large register files: 128 integer registers and 128 floating point G registers. Registers have two uses: to store data that is used multipleBG times for fast retrieval and to express the parallelism in the program.   F Large register files have a proven benefit in scientific programs; forL example, in blocked matrix solvers they can be used to hold a sub-array thatC is repeatedly referenced.  However for general integer programs andAI commercial servers, where data is less regularly structured and typicallyeI accessed indirectly through pointers, it is more difficult to use a large K register file effectively to hold commonly used data; in these applicationsrG the extra code space required to specify the register offsets the minora/ gains in using the register file to store data.o  I A processor with simultaneous multithreading presents the compiler with ahL full architectural register file for each thread.  It permits the programmerF to use a large number of registers to hold data without increasing the instruction size.d  I Registers are also required to express parallelism.  Every operation thataL produces a value requires a register specifier; in effect, it is the name ofC the value.  For example, to issue 8 operations per cycle requires 8s: destination registers.  If, on average, the result is readK 10 cycle later, 80 registers are required to express the computation. On aniF in-order machine such as IA64, architectural registers are required toI express this parallelism.  This is one of the reasons IA64 has introducedAF larger register files and paid the price of large instructions.  On anH out-of-order machine, the architectural registers are mapped into a muchI larger physical register file.  Physical registers can be used to expressrF the parallelism discovered by the dynamic scheduler; the architectural? register file and the instruction encoding do not need to grow.e     Predicationu  J Almost all IA64 instructions require a predicate register as an additionalF input.  The instruction is executed only if the predicate is true.  ToK support predication IA64 includes a powerful compare instruction to produceyG predicates, see Figure 11.  The compare instruction compares r1 and r2,sJ using a comparison given by crel (e.g., greater than).  In a typical case,G the result of the comparison is written to p1 and its complement to p2.wE This gives two predicates to control the two sides of an if-then-elsesI statement.  A number of other results are possible; this is controlled bya the ctype qualifier.      (qp)  CMP.crel.ctype p1,p2=r2,r3  $ Figure 11:  IA64 compare instruction  L Predication permits the compiler to remove a branch.  It is a generalizationK of the Alpha conditional move instruction (CMOV); in IA64 terminology, CMOVuL would be called a predicated move.  Figure 12 shows three ways to compute if (a) x = t+1.  7         Alpha               IA64                  Alphai<         BNE a,.+2           CMP.EQ p1,p2 = a,0    ADD t,1,x0=         ADD t,1,x       (p1)ADD x = 1,t           CMOV a,x0,xp5         (1)                 (2)                   (3)c. Figure 12:  Three ways to compute if (a) x=t+1    J In (1) we use a branch; in (2), the IA64 predication; and in (3) the AlphaK CMOV instruction.  For many common cases such as this one, the more generala+ IA64 predication does not improve the code.m  F Predication turns a control dependence into a data dependence.  In (1)A above, the ADD instruction is not dependent on the branch.  In an K out-of-order processor, when the branch is predicted correctly, the ADD mayoK issue before the branch.  In the predicated IA64 version, the ADD must wait5D for the comparison.  In many programs, particularly large commercialL applications, the computation of the branch conditions are the critical pathB of the computation.  Run-time branch prediction is extraordinarilyJ effective; 95-98% of branches are predicted correctly.  On an out-of-orderH machine, instructions can be issued before the branch that controls themJ resolves.  In an in-order machine, predicated instructions must wait untilF their predicate is evaluated.  This increases the critical path length through the program.  J Predication increases the instruction cache footprint of programs as well.J It requires the predicated instructions from both sides of an if-then-elseJ to be present in the instruction cache in order to execute either the thenG clause or the else clause.  For tight inner loops, predication may be aiJ reasonable decision, but for large loop-free programs such as databases orG operating systems, requiring both sides of an if-then-else clause to be H cache resident to execute only one of them will increase the instructionG cache footprint and lower performance.  Also, every IA64 instruction is J larger in order to contain the predicate specifier.  All code has a largerH instruction cache footprint to support the feature, even large loop-free: server applications where it cannot be profitably applied.  I Predication also prevents the full utilization of the functional units in.J the processor.  If both sides of an if-then-else are scheduled in the sameK straight-line code, only half of the functional units are effectively used;nI the results of the functional units with a false predicate are discarded.oL On a single-threaded processor such as IA64, this may seem like a reasonableB decision.  However, on simultaneous multithreaded processor, theseL functional units are a valuable resource that can be used by another thread.C Predication must be used judiciously, which Alpha can do with CMOV.t  J Predication cannot remove branches when they are function calls. Figure 13E shows an excerpt from the 022.li benchmark from SPECint95. The staticcJ probability of each branch is reported; there are two probabilities on twoE lines, because the C && operator is an implied branch.  This decisioneJ pattern is found in many commercial applications.  All of the branches areF highly biased, except for one, which decides whether to call evform orJ xlgetvalue.  However, predication cannot be effectively applied to the 32%G branch, because a transfer of control to one of the called functions is B required.  Note that this routine is an excellent candidate for anF out-of-order processor, because all of the branches (including the 32%K branch) can be effectively predicted by a run-time predictor, and processorAL can overlap the execution of either evform or xlgetvalue with the evaluation# of the branch conditions in xleval.    NODE *xleval(NODE *expr) {  7         if (--xlsample <= 0) ...               /* 1% */f  9         if (*++xltrace < TDEPTH)               /* 100% */h&             trace_stack[xltrace]=expr;  A         if (expr && expr->n_type==LIST)        /* 99.9%, 32.0% */t              expr = evform(expr);A         else if (expr && expr->n_type==SYM)    /* 99.9%, 99.9% */s$             expr = xlgetvalue(expr);           --xltrace;           return(expr);n     }n  J Figure 13:  Xleval routine from 022.li in SPECint95, annotated with static branch probabilities.u    G Extensive predication makes it impractical to implement an out-of-orderiH version of IA64.  In the example in Figure 14, the ADD in line [d] readsG either the value of x created by the MOV instruction in line [b] or theo< value created by the predicated ADD instruction in line [c].  (               CMP.EQ p1,p2 = a,0     [a](               MOV x = 1              [b](          (p1) ADD x = 1,t            [c](               ADD y = x,1            [d]  K Figure 14:  Predication makes it impractical to implement out-of-order IA64   F In an out-of-order processor, each instruction that writes a result isI assigned a new physical register.  In Figure 14, assume the MOV in line bhK writes physical register xv1 and the ADD in line c writes physical registeroK xv2.  The ADD in line d will read physical register xv2, independent of thefL value of the predicate p1.  For the predicated instruction to work correctlyK in an out-of-order processor, the instruction must either write a new valuepH to this physical register, or pass along the old value.  In essence, the? predicated instruction must behave like the C select operation.n            xv2 = p1 ? add 1,t : xv1  C This requirement adds an additional input to all of the potentiallyoK predicated instructions.  It will increase the size of the front-end of thea processor pipeline by 50%.   Control speculation   F Control speculation refers to the compiler moving instructions above aL branch.  This permits long latency operations such as cache-missing loads toK begin earlier in the program.  Consider the possible translations of if (a)eC x = *b + 1 given in Figure 15.  Column 1 presents a straightforwarduH translation of the statement.  The other columns present versions of the- code where the LDL is moved above the branch.          if (a) x=*b+1e  @     Alpha             IA64               Alpha             AlphaF                       LD4.S t=[b]        LDL t,(b)         LDL r31,(b)>                       ...                ...               ...D                       CMP.EQ p1,p2=a,0   BNE a,.+3         BNE a,.+2C     BNE a,.+2    (p2) BR .+2             CMP ER,EXC,t0     LDL t,*blD     LDL t,(b)         CHK.s t            BNE t0, fixup     ADD t,1,x2     ADD t,1,x         ADD x=1,t          ADD t,1,x  >     (1)               (2)                (3)               (4)    2 Figure 15:  Possible translations of if (a) = *b+1  D Note that when an instruction is moved above a branch, it may now beI executed when it should not be.  In the original program, the instruction D would only be executed when control reached the block containing theH instruction, its home block.  The transformed program should continue toG execute as if the instruction was still in its home block, but with the 9 performance advantage of issuing the instruction earlier.   J The compiler must be careful about the side effects the instruction has onJ registers, memory, and exceptions.  For registers, the compiler can simplyL ignore the written register if the program branches away from the home blockK of the load.  Memory side effects can be avoided by not speculating stores.sL Avoiding exceptions requires more support. Consider, in Figure 15, if both aK and b are zero.  If we move the load above the branch, we will get a memory I exception for dereferencing location zero; if we do not move the load, we3 will branch around it.  D To address this problem, IA64 has introduced two new instructions: aK speculative load and a speculation check.  On an exception, the speculativeWK load sets a 65th bit in the result register and ignores the exception.  ThesH check instruction checks the 65th bit of the register, and if it is set,G signals the exception.  This permits the exception to be deferred untilrI control reaches the home block of the load, or dismissed if control neverwE reaches this block.  Column 2 in Figure 15 illustrates the use of the8J speculative load (indicated by the .s qualifier) and the speculative check (CHK.s) instructions.e  L For Alpha, we have implemented a similar system in software [5]. SpeculativeJ loads are identified using a PC-map.  When a speculative load generates anK exception, the system software sets an assigned bit in a reserved exceptionuL register and returns; this corresponds to setting the 65th bit in the resultF register in the IA64 design.  In the home block, a traditional compareK instruction checks if the bit corresponding to this speculative load is setpK in the exception register and branches to a handler if necessary.  Column 3e0 in Figure 15 illustrates the use of this scheme.  E We have done extensive experimentation with software-directed controlsL speculation.  We have discovered that an out-of-order processor with a largeL instruction window can find most of the instruction-level parallelism in theE program if all memory references are cache hits; the problem is cache J misses.  An attractive solution to improving instruction-level parallelismL in programs is to use prefetching.  We can ensure a reference is a cache hitK by prefetching it.  A prefetch cannot generate an exception, so there is no K need for a checking instruction in the home block.  In addition, a prefetch K will fetch a 64-byte cache line; multiple prefetches to the same cache line K can be merged into a single instruction.  And a prefetch does not require atE register to hold a result; register pressure is reduced.  In summary,eH prefetching on an out-of-order processor provides all of the benefits ofK control speculation with fewer instructions, and thus a smaller instruction K cache footprint.  Prefetching directly attacks memory latency, which is one : of the major limits to high instruction-level parallelism.  F Compilation techniques for exploiting control speculation require codeB duplication.  Superblocks (or hyperblocks) must be built to createJ straight-line paths through the code [7,8].  Figure 16 shows a simple flowH graph where each Bn represents a basic block, and the edges are possibleE control flow between the blocks.  Assume the frequently traveled pathcF through the graph is B0-B1-B3-B5-B6.  To isolate this path for controlJ speculation, the superblock algorithm will create copies of blocks B3, B5,H and B6.  If all blocks are the same size, this is a 30% increase in codeL size.  This increase is on top of the 33% code size increase due to the IA64A instruction encoding.  IA64 will not be competitive on commercialsF applications, where code size has a first order effect on performance.  &                 B0                  B0'                /  \                 | \,+               B1  B2                B1  -B2n+                \  /                 |     |c+                 B3                  B3   B3 ,                /  \                 | \ /  \.               B4  B5                B5 B4   B5,                \  /                 |   \  /+                 B6                  B6   B6r  -               flow graph           superblocke    ; Figure 16:  Forming superblock for hot path B0-B1-B3-B5-B6.v         Data speculation  F Data speculation refers to the compiler moving a load above a possiblyE conflicting store.  Often in programs with pointers, distinct pointeruL references rarely point to the same memory location, but the compiler cannotJ prove this.  The IA64 provides some architectural support to permit a loadI to move above a store, and then, after the store occurs, check if the twod pointers overlapped.  E Figure 17 illustrates the problem.  To improve the performance of theaI program, we would like to schedule the potential cache-missing load of *qsK above the store to *p.  IA64 introduces two new instructions to do this: anoI advanced load and a checking load; we can see their use in column 2.  The;J advanced load (indicated by the .a qualifier) will both perform a load andH create an entry in an advanced load table (ALAT). Every store in an IA64G will check its address with the ALAT and clear any matching entry.  ThenJ checking load (indicated by the .c qualifier) will check the ALAT.  If theB entry for the matching advanced load remains in the table, then noL intervening store to the same address has occurred, and the checking load isH performed.  If the entry for the matching advanced load has been removedH from the table, the store to the same address may have occurred, and theK checking load reissues the load. The same effect can be created on Alpha byfL explicitly checking if the two pointers are equal; see column 3 on Figure c.L If the two pointers are aligned, then we do not need to replay the load, butH can move the value of the store to the destination register of the load.    
        *p = x          y = *q  =         Alpha           IA64            Alpha           Alphao  C                         LD8.a y=[q]     LDQ y,(q)       LDL r31,(q) ;                         ...             ...             ...tA         STQ x, (p)      ST8 [p]=x       STQ x,(p)       STQ x,(p)eA         LDQ y, (q)      LD8.c y=[q]     CMPEQ x,y,t     LDQ y,(q)d4                                         CMOVNE t,x,y  ;         (1)             (2)             (3)             (4)t  J Figure 17:  Possible translations of a store to *p followed by a load from *q.r      E We invented a similar address-checking technique when Alpha was firstsI designed [1].  However, we determined that this problem is best solved bytJ the processor.  At run-time, we know the pointer values and can track whenJ conflicts occur and how they vary over time.  A run-time predictor [9] canL accurately predict which loads and stores conflict; it permits the processorG to freely reorder the references that are unlikely to conflict.  We can L achieve better performance than IA64, because our run-time predictor enablesL us to determine more accurately when it is profitable to move a load above aG store.  And we will not require any extra checking instructions, so ouri, instruction cache footprint will be smaller.  G In cases where the load from *q frequently misses the cache, it will belJ beneficial to add a prefetch instruction, as shown in column 4, Figure 17.     Function calls  L IA64 has added register windows, similar to those in the SPARC architecture,J to support function calls.  The 128-entry general-purpose register file isH partitioned into a 32 entry global file and a 96 entry stacked file.  OnI entry to a procedure, an ALLOC instruction is executed that creates a newlJ register stack frame of up to 96 entries; on return, the caller's registerE stack frame is restored.  It appears to the compiler that there is aneL unlimited stack of physical registers.  Of course, there is a bounded numberJ of physical registers on the processor, and they are written out to memoryG as necessary by a register stack engine (RSE), without explicit programo
 intervention.t  I It is ironic that in an architecture designed to give compiler control oftH the processor, the compiler is not given control of saving and restoringJ registers.  This is one area where compiler technology has a proven recordK of success [10].  Only a handful of registers need to be saved and restored K across a procedure call, and the saves and restores can typically be placedaJ at locations where they do not conflict with the other computation.  On anJ IA64, the register save engine may be triggered at any time.  Also note itI will save all registers, not simply those that are live across a function L call; much of the saving and restoring done by the register save engine will be unnecessary.t  H To make effective use of the register stack, an IA64 implementation willJ need to have a large on-chip physical register file that can hold multipleL register frames.  The register file is one of the most valuable resources onE the chip; it must be carefully designed to deliver fast, multi-portedsI access.  However, on an IA64, most of the physical register file will siteI idle, since only one window on the register file can be open.  In effect,mK the register file is a staging buffer for saving and restoring registers tosI memory.  Contrast this with a multi-threaded, out-of-order machine, where L all the physical registers are available to the current computation, and the3 very expensive structure is usually fully utilized.a     Software pipelining   J  IA64 has added significant architectural support for software pipelining.G IA64 has introduced rotating register files and implicit predication to(B minimize the code size in a software-pipelined loop.  This is bestK understood by looking at an example. In Figure 18 we present simple loop toc add a constant to a vector.n  E Figure 18, part 2, indicates how a single iteration of the loop wouldeH execute on a simple machine with 3 cycle cache-hit latency and a 3 cycleJ floating latency, assuming the arrays are in the data cache.  If we assumeK this machine can issue a load, a store, and a floating-point operation in arJ cycle, we would like to execute an iteration of this loop every cycle.  ToI avoid register conflicts, this requires a three-cycle kernel, as shown inoG part 3.  To simplify the exposition, we do not show any loop control orlJ address arithmetic, and we use the Alpha instruction set.  The three-cycleC kernel is the body of a loop, and it will iterate until the loop isnI complete.  Note that the LDT f0, 0(r16) in the first cycle is consumed byh7 the ADD f0, f30, f16 in the next iteration of the loop.o  K This kernel runs the simple machine at peak rate, but we need to be able tohJ enter it and exit it.  We create a prolog to initiate all the computationsG that must be in-flight to enter the kernel at the top, and we create anhF epilog to complete the computations in flight when we finally exit the kernel at the bottom.e  @ Note that the code has increased in size 9 times from the simple0 LDT/ADDT/STT that is the basic body of the loop.    1. simple loopc        DO i = 1,nm         A(i) = T+B(i)r            2. basic loop schedulee%                                 cyclen"         LDT   f0, 0(r16)         0"         .                        1"         .                        2"         ADDT  f0, f30, f16       3"         .                        4"         .                        5"         STT   f16, 0(r17)        6              3. software pipelined kernelh  G         STT  f16, 0(r17)        ADDT  f0,f30,f16        LDT  f0, 0(r16)tG         STT  f17, 8(r17)        ADDT  f1,f30,f17        LDT  f1, 8(r16)nG         STT  f18,16(r17)        ADDT  f2,f30,f18        LDT  f2,16(r16)d        !    4. loop with prolog and epilogI
        prologeG                                                         LDT  f0, 0(r16)rG                                                         LDT  f1, 8(r16) G                                                         LDT  f2,16(r16)   G                                 ADDT  f0,f30,f16        LDT  f0, 0(r16) G                                 ADDT  f1,f30,f17        LDT  f1, 8(r16)9G                                 ADDT  f2,f30,f18        LDT  f2,16(r16)b  
        kernel   G         STT  f16, 0(r17)        ADDT  f0,f30,f16        LDT  f0, 0(r16)tG         STT  f17, 8(r17)        ADDT  f1,f30,f17        LDT  f1, 8(r16)iG         STT  f18,16(r17)        ADDT  f2,f30,f18        LDT  f2,16(r16)e  
        epilog H                                 STT  f16, 0(r17)        ADDT  f0,f30,f16H                                 STT  f17, 8(r17)        ADDT  f1,f30,f17H                                 STT  f18,16(r17)        ADDT  f2,f30,f18  H                                                         STT  f16, 0(r17)H                                                         STT  f17, 8(r17)H                                                         ST  Tf18,16(r17)( Figure 18:  A software-pipelined kernel.    G To address this code growth, IA64 has added two features.  The first is(H rotating registers.  The kernel of the loop has three copies of the sameI code, with different register identifiers.  By rotating the register file.L each iteration of the loop, so that f32 in the current iteration will be f35J in three iterations, we can write the kernel in a single copy.  The secondD feature is rotating predicates.  Note that the prolog and epilog areH identical to the main kernel, except that certain operations are droppedB out.  On an IA64, we can achieve this same effect dynamically withL predication.  For example, in the prolog, we start with the full kernel, butG only enable the LDTs, then the LDTs and the ADDTs, and then finally theeI entire kernel.  When we are done with the main body of the loop, we enter I the epilog by first turning off the LDTs, then turning off the ADDTs, and " finally the STTs, and we are done.  J The code growth savings are considerable.  However, software pipelining isK most applicable to high performance technical computing. These applicationsdE are dominated by high trip-count loops, and even with very large looppH unrolling, the instruction cache miss rate is not significant. IA64 willH have smaller code than Alpha for these scientific loops, but it will not affect performance.a  J For commercial applications with low trip count loops, software pipeliningD is not the best solution.  A low trip count loop will be dynamicallyE unrolled in the instruction window of an out-of-order processor.  TherJ processor will reorder the code, adjusting to dynamic events such as cache7 misses, which are difficult to predict at compile-time.v     Instructions  L Though most of the IA64 instructions are RISC-style, there are a few notable exceptions.r  C No displacements.  The basic IA64 addressing mode is a base address H contained in a register.  A surprising weakness is that the base addressK cannot be modified by a displacement when calculating a virtual address.  AoL base-update mode does permit a displacement to be added to the base registerI after the virtual address has been computed.  This forces an unattractiveoE tradeoff when accessing multiple fields off of the same base pointer.oK Either a register must be dedicated to computing each field address, or onerB addressing register can be used with base-update addressing, which2 introduces a data dependency between the accesses.  J Figure 19 presents sequences for loading multiple fields from a structure,H as may happen in a large commercial application.  In column 1, the AlphaL sequence incorporates the appropriate offsets from p as displacements in theL load instruction and no additional address arithmetic is required.  Column 2I presents the parallel IA64 code, where two explicit ADD4 instructions are L required to compute the addresses of the fields before loading them.  ColumnI 3 presents the sequential IA64 code, where the second LD8 is dependent onvG the first LD8, and must issue in the following cycle.  The IA64 code is I 33-66% larger than the Alpha sequence.  The IA64 architecture is not wellcA suited to the addressing requirements of commercial applications.n  % new_salary = p->salary + p->increase;t  (         Alpha                       IA64  =         LDQ t0, s(p)       ADD4 a0=p,s            ADD4 a0=p,sr@         LDQ t1, i(p)       ADD4 a1=p,i            LD8  t0=[a0],i>         ADDQ t0,t1,ns      LD8  t0=[a0]           LD8  t1=[a0]?                            LD8  t1=[a]            ADD8 ns=t0,t1s(                            ADD8 ns=t0,t1  5         (1)                (2)                    (3)d  6 Figure 19:  Addressing a structure with displacements.    I CISC instructions.  The pipeline for a modern RISC processor is optimized C for writing one register per instruction.  IA64 has introduced manyeJ instructions where a single instruction may require more than one registerJ write.  As mentioned above, the base register in a memory reference can beK updated after the memory reference occurs by adding a register or immediate K to the base address.  An IA64 load may write two registers: the destination E register of the load and the base register.  Two register writes will,I complicate a pipeline optimized for writing one register per instruction. K It may also require an additional write port to the register file to handlee! a worst case that rarely happens.r  F To support software pipelining, IA64 has introduced a very complicatedK branch instruction.  The loop branch instruction reads and writes 3 specialaK application registers (the rotating register base, the loop counter and theiB epilog counter), writes predicate register 63, and updates the PC.F Implementing this instruction will complicate a pipeline optimized forD writing one register per instruction.  It is also tailored to a veryJ specific style of software pipelining and cannot be used by compilers that support a different model.       4. Application performance  D In developing the Alpha architecture, we focus on the performance ofE general-purpose code, on high-performance technical computing, and on.F commercial server applications.  Of course, application performance is@ determined by the computer system, not the microprocessor alone.  J To improve system performance, we are incorporating some additional system" functionality on to the processor.    K ? Low-latency, high-bandwidth memory interface.  The microprocessor core isoH increasing in speed relative to memory.  The major bottleneck in systemsH performance is the memory interface. Future Alpha systems will bring theI board-level cache and the memory controller on-chip, to reduce latency ton! memory and to increase bandwidth.d  K ? Distributed shared memory (DSM).  Bus-based multiprocessor systems do not I scale well; in the near future, the memory requests of a single processordK will exhaust the capacity of the system bus.  Future multiprocessor systems D will require distributed shared memory, with local memories for eachF processor and point-to-point connections between processors and remoteH memory.  Future Alpha processors will directly support this organization  with on-chip network interfaces.     General purpose code    6                                      SPECint   speedup6                                      ------    -------*     in-order     Mips R5000  180MHz   4.823     out-of-order Mips R10000 180MHz   8.59     1.78     *     in-order     Pentium    200MHz    5.473     out-of-order PentiumPro 200MHz    8.09     1.48b      *     in-order     Alpha 21164 600MHz   19.33     out-of-order Alpha 21264 575MHz   30.3     1.57B    I Figure 20:  SPECint comparison of in-order and out-of-order processors ath the same cycle time.  K Out-of-order execution is the most effective way to improve the performanceaF of general purpose code.  General purpose codes are those that are notL highly parallel and do not put extraordinary demands on the memory system ofC the processor; they are exemplified by the SPEC integer benchmarks.fL Out-of-order execution was implemented in a number of microprocessors in theI past 5 years, and we can examine the benefit by examining the performance E improvement in comparing the performance of in-order and out-of-order J implementations of the same instruction set architecture.  We can see thatK at the same cycle time, we typically see a performance improvement of 1.5x.       $ High Performance Technical Computing  K Highly parallel, bandwidth intensive programs characterize high performancefL technical computing (HPTC).  There is a large amount of parallelism, both atI the instruction-level and at the thread-level. This applications map welle, onto a simultaneous multithreaded processor.  G The performance of HPTC applications is typically limited by the memorynL bandwidth of the system.  Most large applications require loading one doubleD precision floating point number from memory for each flop; this is 8A bytes/flop.  The SPECfp95 benchmarks are smaller versions of HPTC I applications.  Performance studies on previous Alpha implementations havepK shown SPECfp95 benchmarks spend 50% of their time stalled waiting on a datawI cache miss [11].  Essentially no time is spent waiting for an instructiona cache miss.s  K The next generation Alpha processors will have the fastest memory system ine: the industry.  We will be the leaders in HPTC performance.     Server applications   I Server applications such as online-transaction processing and web servingnB are large multithreaded programs.  They have very small amounts ofJ instruction-level parallelism; on the most aggressive superscalar machinesL they typically execute less than one instruction per cycle.  However, serverK applications perform well on multiprocessor platforms, and they are ideallyr2 suited for a simultaneous multithreaded processor.  J As an example of a server application, we will consider online-transactionJ processing.  This application has a number of distinctive characteristics:  G ? No loops.  Our studies of databases have shown that almost 70% of thetL run-time is spent in procedures with loops that iterate less than 2 times onL average, and that nearly all run-time is spent in procedures with loops thatJ iterate less than 16 times [12].  An insignificant amount of time is spent5 in procedures containing loops with high trip counts.   K ? Large routines with many branches.  Almost all the run-time in a database L is spent in routines with more than 16 distinct branches, and more than halfL the time is spent in routines with more than 128 branches [12].  Even thoughC there are many branches, they are well suited for a hardware branchuI predictor.  Our studies have shown that the number of mispredicts runningrA TPC-C is less than the average for the SPECint95 benchmarks [11].   D ? Large memory footprint.  Transaction processing has a large memoryE footprint, exceeding the size of on-chip caches and large board level J caches.  For TPC-C, the overall cache miss rate is three times the averageL of the SPECint95 benchmarks, and more than twice the average of the SPECfp95I benchmarks.  The instruction cache miss rate is four times the average ofoJ the SPECint benchmarks, and 10 times the average of the SPECfp benchmarks.F The board level cache miss rate is 10 times the average of the SPECintD benchmarks, and 1.5 times the average of the SPECfp benchmarks [11].      E On an earlier Alpha system, the processor was stalled 80% of the time L running TPC, while delivering industry-leading performance [11].  To improveG performance, we are designing future Alpha systems to do the following:   F Reduce the instruction cache footprint.  The major goal when compilingC databases is to reduce the size of the instruction cache footprint.eI Improving code quality to generate fewer instructions is important.  Code L layout techniques that rearrange the instructions in the application to makeH the more frequent path sequential will effectively pack each cache blockJ with useful instructions.  This packing improves performance by up to 30%.  J The basic instruction encoding of IA64 increases the code size by 33%.  In9 addition, the techniques that IA64 introduces to increasesH instruction-level-parallelism (speculation and predication) increase theG instruction cache footprint. Speculation requires that additional checkaJ instructions be introduced on the frequent path for each speculative chainG of operations; large amounts of code must be introduced to recover fromsI mis-speculation; and in addition, large amounts of code must be copied to.G form superblocks. Predication requires that both sides of a conditionaloG branch must be in the instruction cache. Alpha's out-of-order executiontD techniques are a much better method for increasing instruction-level? parallelism without increasing the instruction cache footprint.n  D Also note that the special IA64 instructions introduced for softwareK pipelining loops is not applicable to transaction processing, for there aree no frequently executed loops.   K Tolerate cache misses.  With out-of-order execution, an Alpha processor cantK adapt to a data cache miss; only the instructions that are dependent on therD missing reference are delayed.  In an in-order processor, all of theK instructions after the first instruction dependent on the missing references are delayed.  G The IA64 strategy for tolerating cache misses is to attempt to guess ateL compile-time what references will miss, and to schedule speculative loads toG issue the references early.  This approach has three drawbacks.  First, A in-line checks and compensation code are required; the additionalhI instruction cache misses due to these instructions may outweigh any gainspK due to issuing the load early.  Additionally, often the address computation6E of the load is on the critical path, and the load cannot be scheduled E earlier.  And finally, in a program like transaction processing, with(K irregular data structures, it is very difficult for the compiler to predictoI which reference will miss.  The out-of-order processor, at run-time, will 5 have this information to guide its dynamic scheduler.h  K Increase effective pin bandwidth.  To increase the effective pin bandwidth,cI we are moving the board level cache on to the chip. The interface betweenrH the processor and the board-level cache is the most frequently traversedI interface in today's systems.  By moving the cache on to the chip, we caniF introduce a much higher bandwidth, lower latency interface between theI processor and the cache.  At the same time, we will make the cache highlyt6 associative, effectively removing all conflict misses.  F In addition, we are adding a direct RAMbus memory controller on to theE processor.  RAMbus offers four times the effective pin bandwidth of atE conventional SDRAM memory system.  Future Alpha systems will have the0A highest bandwidth, lowest latency memory systems in the industry.t  K Merced will not have an on-chip level 2 cache.  Neither Merced nor McKinleyt, will have an on-chip memory controller [13].  J Increase processor-to-processor bandwidth.  The scaling of current systemsH running transaction processing is limited by the bandwidth of the systemJ bus.  In particular, communication of shared data is a bottleneck.  FutureB Alpha systems will replace the system bus with many point-to-point> connections.  This will remove the system bus as a bottleneck.  J Neither Merced nor McKinley will have an on-chip support for a distributed shared memory [13].1  E Simultaneous multithreading.  Transaction processing is an explicitly D parallel program with very low functional unit utilization; detailedC simulations [14] have shown that a speedup of 3x is achievable with0B simultaneous multithreading.  This remarkable result is due to twoJ phenomena.  Even though the threads are not running in lock step, they areJ all running the same code, and by constructive interference, the effectiveC instruction cache miss rate of the program is reduced by 30%.  With H appropriate support from the operating system, multithreading introducesL very few conflict misses into the data references, and the latency toleranceE inherent in SMT permits the extra data cache misses introduced by the J multiple threads to have a minimal effect on processor performance.  For aG processor with sufficient memory bandwidth, such as the next generation J Alpha, simultaneous multithreading can effectively exploit the parallelism in transaction processing.  D IA64 does not include simultaneous multithreading.  Each thread in aJ transaction-processing program is very sequential and includes long delaysI waiting for memory.  The IA64 strategy of searching for instruction-levelDF parallelism cannot find the orders of magnitude improvements available$ through simultaneous multithreading.  F In summary, future Alpha systems will directly address the performanceL bottlenecks in transaction processing.  We expect the transaction processingK throughput of an Alpha processor to increase by a factor of 10 from today'sTH 21264 to an 8-wide 21464 with simultaneous multithreading: a factor of 2L from improved instruction-level parallelism, a factor of 2 from thread-levelL parallelism, and a factor of 2.5 from improvements in process technology and cycle time.   I In contrast, the new technologies Intel has developed for IA64 are a pooreK fit for the transaction processing.  Their new instruction set architecture.F increases the code size of a program by at least 33%, and the compilerG techniques required to increase instruction-level parallelism introduce G additional instructions.  IA64 does not have techniques for dynamically L tolerating cache misses or memory latency.  In fact, the IA64 techniques forD tolerating memory latency create additional instructions, which willK increase the instruction cache miss rate, which, in turn, will increase thesL memory system delays.  Merced will add no features to increase effective pin8 bandwidth, and no IA64 processor is planning to increaseI processor-to-processor interconnect bandwidth. And most importantly, IA64fF does not include simultaneous multithreading.  IA64 is only focused onE increasing instruction-level parallelism, and IA64 processors have noeK techniques to effectively exploit the parallelism in an explicitly parallele1 program.  Figure 21 highlights these differences.o  B                                  Merced   21364   McKinley   21464@     small icache footprint         no      yes      no       yes  @     dynamically tolerate           no      yes      no       yes      cache missesa       increase pin bandwidth@      . on-chip L2 cache            no      yes      yes      yes@      . on-chip memory controller   no      yes      no       yes  @     increase processor-to-         no      yes      no       yes      processor bandwidth  @     simultaneous multithreading    no      no       no       yes? Figure 21:  Features for supporting high performance commercialo
 applications.l    
 5. Conclusionn  C An Alpha processor will be able to exploit static instruction-leveldD parallelism (discovered by the compiler at compile-time) and dynamicL instruction-level parallelism (discovered by the processor at run-time).  AnD IA64 processor will only be able to exploit static instruction-level parallelism.  J An Alpha processor can take advantage of the excellent compiler technologyH developed for IA64 and other VLIW processors; much of this technology isI already implemented in the Alpha compilers.  However, the Alpha compilers G will be able to use these optimizations much more judiciously, avoidingsH excessive code growth, because the Alpha out-of-order processor can also3 discover instruction-level parallelism at run-time.   G An Alpha processor will be able to adapt to dynamic program behavior at,G run-time.  An IA64 processor will not.  An Alpha processor can adapt toaJ memory references that miss in the cache, avoiding delays of 100 cycles orA more.  An IA64 processor will stall.  An Alpha processor can findiK instruction-level parallelism when the compiler does not express it. And anoI Alpha processor can find instruction-level parallelism at run-time acrossc5 branches, function calls, and compilation boundaries.   H An Alpha processor will be able to exploit thread-level parallelism.  AnD IA64 processor will not.   Most server applications are divided intoL multiple threads, and simultaneous multithreading permits these applicationsL to take full advantage of the multiple execution units on the processor.  AnF Alpha processor can use thread-level parallelism and instruction-levelJ parallelism interchangeably, adjusting to the behavior of the application.E Amdahl's law says that high performance requires speedups in both theDK sequential and the explicitly parallel portions of an application; an Alpha % processor can deliver these speedups.i  C An Alpha processor will deliver the highest memory bandwidth in theiJ industry, and systems built out of Alpha processors will lead the industry( in high performance technical computing.  E An Alpha processor will significantly outperform an IA64 processor onaB commercial applications.  Alpha processors have addressed the mainG requirements of commercial applications: reducing the instruction cachenD footprint, tolerating unpredictable cache misses, increasing the pin< bandwidth, and exploiting explicit thread-level parallelism.H IA64 processors are not well designed for commercial applications.  TheyD require a large instruction cache footprint; they cannot dynamicallyH tolerate cache misses; and they cannot exploit thread-level parallelism.  < In the important server markets, Alpha will outperform IA64. BibliographyL 1. McKeen, Adler,  Emer,  Lowney,  Nix, Sager.  "Mechanism for enforcing the= correct order of instruction execution," US patent 5,420,990.,E 2. McKeen, Adler, Emer, Lowney, Nix, Sager. "Apparatus and method for6E speculatively executing instructions in a computer system," US patent 
 5,421,022.E 3. McKeen, Adler, Emer, Lowney, Nix, Sager. "Method and apparatus fortL propagating exception conditions of a computer system," US patent 5,428,807.D 4. Adler, Lowney, Hobbs. "Software mechanism for accurately handlingJ exceptions generated by instructions scheduled speculatively due to branch" elimination," US patent 5,627,981.C 5. Adler, Lowney, Hobbs. Software mechanism for accurately handlingoH exceptions generated by speculatively scheduled instructions," US patent
 5,634,023.D 6. Cohn, Adler, Lowney.  "Software mechanism for reducing exceptionsH generated by speculatively scheduled instructions," US patent 5,901,308.I 7. W. Hwu , et al., "The Superblock:  An Effective Technique for VLIW andgH Superscalar Compilation",  The Journal of Supercomputing ,7(1/2):229-248 (1993).mJ 8. S. Mahlke, et al., "Effective compiler support for predicated executionA using the hyperblock," in Proc. of the 25th Annual Intl. Symp. on  Microarchitecture, Dec. 1992.iJ 9. G. Chrysos, et al., "Memory Dependence Prediction using Store Sets," inI Proc. 25th International Symposium on Computer Architecture, pp. 142-153,e Barcelona, Spain, June, 1998.eE 10. D. Wall, "Register Windows vs. Register Allocation," in Proc. ACM H SIGPLAN Conf. on Programming Language Design and Implementation '88, pp. 67-78, Atlanta, GA, June 1988.K 11. Z. Cvetanovic, et al., "AlphaServer 4100 Performance Characterization," + Digital Technical Journal, 8(4):3-20, 1996. E 12. R. Cohn, et al., "Optimizing Alpha Executables on Windows NT withp5  Spike,"  Digital Technical Journal, 9(4):3-20, 1997.-I 13. L. Gwennap.  Intel's Merced and IA-64: Technology and Market Forecast1+ 1999 Edition.  MicroDesign Resources, 1999.PC 14. J. Lo, et al., "An Analysis of Database Workload Performance on C Simultaneous Multithreaded Processors," in Proc. 25th InternationalfL Symposium on Computer Architecture, pp. 39-50, Barcelona, Spain, June, 1998.   ------------------------------  $ Date: Thu, 9 Aug 2001 09:44:36 -04002 From: "Sue Skonetski" <susan.skonetski@compaq.com>& Subject: Article from Information week2 Message-ID: <Cswc7.732$Yx2.18032@news.cpqcorp.net>  5 http://www.informationweek.com/story/IWK20010808S0007   +                   Wednesday, August 8, 2001x  )                    OpenVMS Is Flying Highu  D                    When Compaq recently cancelled long-term plans to7                    develop the Alpha chip, the high-RASnJ                    (reliability/availability/serviceability) system seemed inH                    jeopardy. Now, it's become a big part of the national"                    defense system.  E                    Thanks to Compaq, American ground troops will soonoJ                    be 10 times more effective on the battlefield. G.I. JoeH                    will have a friendly bird overhead--a bird based on aA                    Boeing 707 that was once a commercial or cargoeF                    plane--taking snapshots of multiple layers of earthF                    and instantly passing the data to ground troops whoF                    would then move in with deadly accuracy. Each BlockE                    20 E-8C Joint Strategic Target Attack Radar System D                    (J-Stars) plane is loaded with two Compaq servers@                    and 18 workstations, all based on the OpenVMS$                    operating system.  H                    Brig. Gen. Jeff Riemer, program executive officer forD                    command and control and combat support systems atF                    the U.S. Air Force, made sure his planes could swapF                    computer systems if necessary, without ripping themJ                    apart. But since he took delivery of the first Block 20E                    J-Star earlier this week, he's too busy noting howaK                    efficient, powerful, and cost effective the systems are.oA                    "There's 10 times the acceleration in how fastnK                    information is relayed to the war fighter," says Riemer.l  =                    In addition, two servers replace 10 in theaH                    predecessor, the Block 10, which also has a different@                    operating system inside from EMC Corp.'s Data@                    General division, when DG was its own systemsE                    company. The OpenVMS will start three times fasternG                    and reboot twice as fast. Moreover, the new plane isdJ                    $20 million cheaper than the Block 10. It's part of theB                    military's commitment to use standard computingG                    systems. Before, the military built its own systems.w?                    "Over a 20-year span, we expect to save $800e)                    million," says Riemer.r  C                    To be part of the J-Stars program, Compaq had tonA                    build in specialized military availability and  reliability.H                    Features include climate control, power conditioning,?                    and shock resistance. Dr. Dale Burton, VP ofEK                    engineering and logistics for air-to-ground surveillance D                    and battle management systems at J-Stars designerD                    Northrop Grumman Integrated Systems in Melbourne,H                    Fla., says the greatest benefit of OpenVMS inside theJ                    plane is the software itself. "We can walk in, yank outA                    these 19-inch computers, and replace them withsH                    Wildfire [Compaq's newest high-end server] in a day,"I                    says Burton. "The foot stomp is the fact that we don't E                    have to rewrite software during upgrades." He saysrD                    rewriting the weapons system app would take threeB                    years and cost hundreds of millions of dollars.  D                    Rich Marcello, general manager and VP of Compaq'sD                    high-performance systems division, says there areC                    450,000 OpenVMS systems running worldwide-it's aqF                    $3 billion business for Compaq, and OpenVMS will beG                    ported to Intel's Itanium processor in 2003. BesideseD                    military and government, Marcello says OpenVMS is>                    doing well in some financial, hospital, and<                    telecommunications markets. "We have manyD                    commitment letters out to support OpenVMS through?                    2011," says Marcello, "and we even have somei/                    government pacts past 2015.".  #                    -- Martin Garveyh    '                       Back to NewsFlashe  +                       Send Us Your Feedbackn  %                       Top of the Pagee   ------------------------------  $ Date: Thu, 9 Aug 2001 09:06:21 -04000 From: "Syltrem" <syltrem@videotron.ca.spammenot>N Subject: Re: Automating MS Access with DCL code for a report run once a month.5 Message-ID: <yTvc7.51983$TW.262697@tor-nn1.netcom.ca>a   Windoze has a scheduler.F You could produce the file on the VMS box in time for when the windozeH scheduler starts your ms-access job that requires the file. If required,? write a little .BAT file that would FTP the file on the peecee.o   --   Syltrem ; http://pages.infinit.net/syltrem (OpenVMS related web site)m    @ "Sue Pedersen" <pedersen@lcms.org> a crit dans le message news:* 000201c11f60$9c133330$c408040a@lcms.org... > Hi,d >nH > I'm not sure where to start with this project.  A colleage is taking a fileF > from our VAX system and making a report with Access once a month.  A request L > has been made to automate this process to happen on the 3rd of each month.L > I'm assuming I need to put this into the scheduler but I'm not sure how toK > get a report to run in Access from a DCL program.  Could you give me someF > pointers?? >h > Thank you, > Sue Pedersen > pedersen@lcms.orgo >h   ------------------------------  $ Date: Thu, 9 Aug 2001 07:33:46 -0400+ From: "Main, Kerry" <Kerry.Main@compaq.com>l? Subject: RE: Backup disk on one system to tape drive on anotherlR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D55FB9@kaoexc01.americas.cpqcorp.net>   Robert,p  I >> 4. Software Partners has/had a remote tape product called Thruway if IpJ remember correctly.  It made remote tape drives appear local.  When I lastH used it, it needed DECnet, but I suspect it can also use tcpip by now.>>   Fyi -eD http://www.sp32.com/products/index.php (Software Partners Home Page)1 Click on "Thruway" for the following description:   I "THRUway, The OpenVMS Remote Device Access System, bridges the gap from arF remote VAX or AXP to a central VAX or AXP, simplifies file access, andL provides easy and safe management of remote data from the main site. THRUwayH does this by, among other things, making clustered tape drives appear asH local drives to remote users, and by making remote disk drives appear as local drives. "w   And from the "Features" icon -1 - THRUway works with TCP/IP and DECnet networks. o   Regards,  
 Kerry Main Senior Consultanto Compaq Canada Corp.r Professional Services  Voice: 613-592-46600 Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----B From: rdeininger@mindspring.com [mailto:rdeininger@mindspring.com] Sent: August 8, 2001 11:14 AMo To: Info-VAX@Mvb.Saic.Come? Subject: Re: Backup disk on one system to tape drive on anothern    D In article <0a51ntomma024eopujfq7mq8did1ig10in@4ax.com>, Mark Hemker <hemker@home.com> wrote:  F > I am trying to figure out a way to backup the disks on one system toF > the tape drive on another system.  Both system are running VMS 7.2-1F > and TCP/IP Services 5.0a.  The system with the tape drive has DECNETF > Phase IV installed and configured but the system with the disks doesF > not.  If necessary, I could install DECNET on the other system.  TheG > systems cannot be clustered so I can't use TMSCP.  I am wanting to be1E > able to perform image backups as if the tape drive were attached tol
 > the system.h   Possibilities:  D 1. Install and configure DECnet on the second node.  If you have the5 licenses, this is likely the fastest and easiest way.   J 2. Configure an NFS server on the node with the disks, NFS mount the disks on the node with the tape.  I 3. Temporarily cluster the systems, just for the duration of the backup. sI (The node with disks you want to back up could be a satellite of the noden$ with the tape drive, or vice-versa.)  F 4. Software Partners has/had a remote tape product called Thruway if IJ remember correctly.  It made remote tape drives appear local.  When I lastF used it, it needed DECnet, but I suspect it can also use tcpip by now.  = BTW, you should seriously consider upgrading TCP/IP to V 5.1.n   -- A Robert Deininger rdeininger@mindspring.comn   ------------------------------  # Date: Thu, 09 Aug 2001 00:40:19 GMTn# From: Mark Hemker <hemker@home.com>e? Subject: Re: Backup disk on one system to tape drive on anothera8 Message-ID: <ptm3nt0r80ksk2985dltnslj7f5j4psu4d@4ax.com>  F Thanks for all of the suggestions.  I started to play with NFS, but itD is totally new to me and I was hoping to avoid having to learn about; it.  I am going to look into it some more based on people'sg? suggestions.  I am also going to look into some of the softwareaE mentioned.  Unfortunately, Multinet is not an option on these systemsoF for political reasons.  Thanks for the help and if anyone has any more ideas, please let me know.   Thanks,  Mark Hemkerm  E On Wed, 08 Aug 2001 11:14:20 -0400, rdeininger@mindspring.com (Robertw Deininger) wrote:   E >In article <0a51ntomma024eopujfq7mq8did1ig10in@4ax.com>, Mark HemkerT ><hemker@home.com> wrote:c >eG >> I am trying to figure out a way to backup the disks on one system topG >> the tape drive on another system.  Both system are running VMS 7.2-1dG >> and TCP/IP Services 5.0a.  The system with the tape drive has DECNETaG >> Phase IV installed and configured but the system with the disks doesiG >> not.  If necessary, I could install DECNET on the other system.  The H >> systems cannot be clustered so I can't use TMSCP.  I am wanting to beF >> able to perform image backups as if the tape drive were attached to >> the system. >d >Possibilities:4 >oE >1. Install and configure DECnet on the second node.  If you have thed6 >licenses, this is likely the fastest and easiest way. >aK >2. Configure an NFS server on the node with the disks, NFS mount the disksp >on the node with the tape.r >aJ >3. Temporarily cluster the systems, just for the duration of the backup. J >(The node with disks you want to back up could be a satellite of the node% >with the tape drive, or vice-versa.)c >lG >4. Software Partners has/had a remote tape product called Thruway if IyK >remember correctly.  It made remote tape drives appear local.  When I lastcG >used it, it needed DECnet, but I suspect it can also use tcpip by now.  > > >BTW, you should seriously consider upgrading TCP/IP to V 5.1.   ------------------------------  $ Date: Thu, 9 Aug 2001 12:42:33 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>i? Subject: Re: Backup disk on one system to tape drive on anothere$ Message-ID: <3b72bdda$1@news.si.com>   >Possibilities:o >pE >1. Install and configure DECnet on the second node.  If you have thee6 >licenses, this is likely the fastest and easiest way.  G Sorry, but that won't help.  You can't reference remote tape drives viasJ DECnet with the BACKUP command.  The only time BACKUP allows a remote fileK specification is when you're referring to an on-disk saveset.  They alreadyrK said they don't have enough disk space for an on-disk saveset that can thena be COPYed to the remote device.   J There might be another DECnet-based solution, however.  Years ago, someoneK posted a task-to-task example of writing a saveset to a remote system, withl; the DECnet task on that system actually doing the tape I/O.- --A Brian Tillman                   Internet: tillman_brian at si.com-A Smiths Aerospace                          tillman at swdev.si.coma= 3290 Patterson Ave. SE, MS      Addresses modified to preventa< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------   Date: 9 Aug 2001 02:50:43 GMT ) From: leslie@clio.rice.edu (Jerry Leslie)e? Subject: Re: Backup disk on one system to tape drive on anothere' Message-ID: <9kstq3$4ue$1@joe.rice.edu>i  3 Robert Deininger (rdeininger@mindspring.com) wrote:e :rH : 4. Software Partners has/had a remote tape product called Thruway if IL : remember correctly.  It made remote tape drives appear local.  When I lastH : used it, it needed DECnet, but I suspect it can also use tcpip by now.   Yes, as of THRUway 3.0...i  4   http://www.sp32.com/press/releases/nr_9_24_96.html-   Release of THRUway with Support for TCP/IPl   --Jerry Leslie   ------------------------------  $ Date: Thu, 9 Aug 2001 12:12:35 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>a7 Subject: Re: Can queue manager handle 100.000 entries ? $ Message-ID: <3b72b6d4$1@news.si.com>  G >We are considering using SMTP to send bills to customers (no spam mail F >!). This could amount to sending about 100,000 e-mail messages from aG >batch run. Since every e-mail message is placed in a TCPIP$SMTP queue,wD >and handled by the queue manager, I wonder if the queue manager canG >handle so many entries without serious effects on the speed. I seem toi? >remember from a very long time ago that very long queues wouldr) >dramaticaly slow down the queue manager.g  K If you're worried about queue manager performance, get an SMTP package thato; doesn't use the queue manager.  MadGoat's MX comes to mind.h --A Brian Tillman                   Internet: tillman_brian at si.comyA Smiths Aerospace                          tillman at swdev.si.coml= 3290 Patterson Ave. SE, MS      Addresses modified to preventm< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  + Date: Thu, 09 Aug 2001 07:48:54 -0500 (CDT)S5 From: "John E. Malmberg" <malmberg@Encompasserve.org>n> Subject: Re: DECwindows keyboard problem: <> keys do not work.I Message-ID: <Pine.PMDF.4.21L.0108090743310.7134-100000@Encompasserve.org>g  / The behavior is controlled by OPTIONS->KEYBOARDS   [ ] Comma Key sends , <r   Then apply the change.  C After which you can save the change using the Options pulldown menus again.  E Or if you know the resource name, you can edit the DECW$TERMINAL*.DATl  file that your DECterm is using.   -Johnc wb8tyw@qsl.network Personal Opinion Only    ------------------------------  % Date: Thu, 09 Aug 2001 10:04:32 -0600r% From: Dan O'Reilly <dano@process.com>c Subject: Flip-Chip"aB Message-ID: <5.1.0.14.2.20010809100323.00ab6e70@ntbsod.psccos.com>  7  From a Compaq announcement I received via email today:e  I "Focal Point --> Compaq announces the latest Intel(r) Pentium(r) III Flip/D Chip PGA processors at 1.26 GHz and 521K cache for ProLiant industry standard servers."  K Didn't DEC own the "Flip Chip" trademark for PDP-8's?  I suppose it doesn'tr= matter too much, and maybe this is just dating me...<grin>...n     ------I +-------------------------------+---------------------------------------+AI | Dan O'Reilly                  |                                       |eI | Principal Engineer            |  "Why should I care about posterity?  |oI | Process Software              |   What's posterity ever done for me?" |uI | http://www.process.com        |                    -- Groucho Marx    |rI +-------------------------------+---------------------------------------+l   ------------------------------  % Date: Fri, 10 Aug 2001 00:24:21 +0800h- From: David B Sneddon <dbsneddon@bigpond.com>p Subject: Re: Flip-Chip"6A Message-ID: <5.1.0.14.0.20010810002330.009f96e0@mail.bigpond.com>u  . At 10:04 AM 9/08/01 -0600, Dan O'Reilly wrote:8 > From a Compaq announcement I received via email today: >PJ >"Focal Point --> Compaq announces the latest Intel(r) Pentium(r) III FlipE >Chip PGA processors at 1.26 GHz and 521K cache for ProLiant industry- >standard servers."A >2L >Didn't DEC own the "Flip Chip" trademark for PDP-8's?  I suppose it doesn't> >matter too much, and maybe this is just dating me...<grin>... >n >. >------eJ >+-------------------------------+---------------------------------------+J >| Dan O'Reilly                  |                                       |J >| Principal Engineer            |  "Why should I care about posterity?  |J >| Process Software              |   What's posterity ever done for me?" |J >| http://www.process.com        |                    -- Groucho Marx    |J >+-------------------------------+---------------------------------------+  & I have some "Flip chips" for PDP-11's. Am I as old as you?i       Regards, Dave.s --  I David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.com I Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/ I DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm I "Life is what happens to you while you're busy making other plans" Lennon    ------------------------------  $ Date: Thu, 9 Aug 2001 13:24:52 -0300+ From: <fabio_compaq@ep-bc.petrobras.com.br>a Subject: Re: Flip-Chip" L Message-ID: <OF80BDD8D4.D390D1B1-ON03256AA3.005A07F5@ep-bc.petrobras.com.br>  & Don't be so "connected" to the past...  3 May we use the XT or AT  acronym for a new device ?    RegardsV   F=E1bio Cardoso         H                                                                        =            =20H                     "Dan                                               =            =20H                     O'Reilly"            Para:   Info-VAX@Mvb.Saic.Com =            =20H                     <dano@process        cc:                           =            =20H                     .com>                Assunto:     Flip-Chip"       =            =20H                                                                        =            =20H                     09/08/2001                                         =            =20H                     13:04                                              =            =20H                     Responder a                                        =            =20H                     "Dan                                               =            =20H                     O'Reilly"                                          =            =20H                                                                        =            =20H                                                                        =            =20        7  From a Compaq announcement I received via email today:g  H "Focal Point --> Compaq announces the latest Intel(r) Pentium(r) III Fl= ipD Chip PGA processors at 1.26 GHz and 521K cache for ProLiant industry standard servers."  H Didn't DEC own the "Flip Chip" trademark for PDP-8's?  I suppose it doe= sn't= matter too much, and maybe this is just dating me...<grin>...l     ------H +-------------------------------+--------------------------------------= -+H | Dan O'Reilly                  |                                      =  |H | Principal Engineer            |  "Why should I care about posterity? =  |H | Process Software              |   What's posterity ever done for me?"=  |H | http://www.process.com        |                    -- Groucho Marx   =  |H +-------------------------------+--------------------------------------= -+       =o   ------------------------------  $ Date: Thu, 9 Aug 2001 13:02:51 -0400 From: William_Bochnik@acml.com Subject: Re: Flip-Chip"l> Message-ID: <OF6C34FC23.C9B42B04-ON85256AA3.005D7E32@acml.com>  ; as long as the old acronym has fallen out of use - the term > clustering used for the horrible Microsoft "barely better than- failover" system versus VMS comes to mind :-)s  : oh, and I heard some grumblings about the term VMS used by- Nintendo (or was it Sony for Playstation)....           H                                                                        =(                                      =20H                     fabio_compaq@ep-bc.petrob                          =(                                      =20H                     ras.com.br                               To:  Info-=( VAX@Mvb.Saic.Com                     =20H                                                              cc:       =(                                      =20H                     08/09/2001 12:24 PM              Subject:     Re: F=( lip-Chip"                            =20H                                                                        =(                                      =20H                                                                        =(                                      =20        & Don't be so "connected" to the past...  3 May we use the XT or AT  acronym for a new device ?-   Regards    F=E1bio Cardoso2                             "Dan.                     O'Reilly"            Para: Info-VAX@Mvb.Saic.Comi,                     <dano@process        cc:@                     .com>                Assunto:     Flip-Chip"                     09/08/2001                     13:04n                     Responder au                     "Dan                     O'Reilly"r        7  From a Compaq announcement I received via email today:   @ "Focal Point --> Compaq announces the latest Intel(r) Pentium(r) III Flip; Chip PGA processors at 1.26 GHz and 521K cache for ProLiantn industry standard servers."  @ Didn't DEC own the "Flip Chip" trademark for PDP-8's?  I suppose
 it doesn't= matter too much, and maybe this is just dating me...<grin>...s     ------H +-------------------------------+--------------------------------------= -+! | Dan O'Reilly                  |  |e; | Principal Engineer            |  "Why should I care aboutl
 posterity?  |s> | Process Software              |   What's posterity ever done
 for me?" |? | http://www.process.com        |                    -- Grouchoe	 Marx    |.H +-------------------------------+--------------------------------------= -+                  F ______________________________________________________________________;  The information contained in this transmission may containF@ privileged and confidential information and is intended only forA the use of the person(s) name above.  If you are not the intendedi= recipient, or an employee or agent responsible for deliveringc3 this message to the intended recipient, any review,s@ dissemination, distribution or duplication of this communication? is strictly prohibited.  If you are not the intended recipient,uA please contact the sender immediately by reply e-mail and destroye$ all copies of the original message.=   ------------------------------   Date: 8 Aug 2001 17:40:12 -0500a9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)a. Subject: RE: fms - prototype definitions for C3 Message-ID: <I9ehezSV$wbA@eisner.encompasserve.org>s  | In article <F5949552111A66489D2D578D92B36972059976@reoexc04.emea.cpqcorp.net>, "Pye, Graham" <Graham.Pye@compaq.com> writes:  M > So, here's an extract from the original SDL file, in case that's any use toiG > you. I expect some of the lines will wrap in unhelpful places. I also5K > apologise to other readers if this posting ends up too long. I'm sure youaJ > realise that this doesn't come with any guarantees, support, or anything > much else either :-) > 2 > Graham Pye (Part of the group that owns FMS now)  F That's good.  Is there any possibility of putting that long SDL sourceH into wider distribution.  For instance, in any future FMS-for-IA64 kit ?  E Well, I know the answer is yes, there is a possibility, but please doeD consider it.  We all get the SDL compiler on the Freeware.  There isE always the possibility someone might want to call FMS from a language  not yet invented.i   ------------------------------   Date: 9 Aug 2001 01:00:07 -0700f* From: polato@igi.pd.cnr.it (Sandro Polato)$ Subject: Re: free software available= Message-ID: <2af2b3d8.0108090000.23dc56b3@posting.google.com>   + >While I am pleased by this generous offer, C >I am confused by this message.  Is this available at the events ori3 >by download at the url provided or either or both.e  3 At this time MenuFinder is available by download at.) http://www.itre.com/mf/download_axp.html.h   >How should one proceed?  F Simply download the kit and compile the form to receive via e-mail the unlimited activating key.u@ In the form you have to specify the OpenVMS event (CETS, DiamondF Forum, Compaq local country meeting, Decus, ..) where you were present	 or intendd to partecipate.o  A > They wanted me to include the software in my freeware archives,i@ > but I declined to do so because it's not really freeware (it's3 > one free license, but there's a cost for more).  l   There is a misunderstand.gA MenuFinder for VAX (at the current version) is, and will ever be,. really freeware. In fact :; - no license fees are required for installing and using it k  - no activating key is required # - no user registration is required aF - there are no limit on the number of systems where you can install it> So, MenuFinder for VAX is a real and unconditioned gift to VAX	 communityuD Now it is also included in the OpenVMS Freeware CD - and I challengeF you to convince Hoff to include in the CD a non real freeware tool ...  C Instead, you can have only one really free and unlimited MenuFinder.D for Alpha licence if you partecipate at one OpenVMS Event. And, yes,5 you have to pay (very little) for more Alpha licence.nE I think this is better then "try and buy" policy because it is a "get $ and use it forever for free" policy.< For more information go to http://www.itre.com/mf/faq.html .   > That's not aC > criticism of they're giving it away---I think that's great.  It'seE > just not something that I felt I could put in my freeware archives.t  ? Hunter, I hope you decide to include MenuFinder for VAX in yourMB freeware archive. No one had installation problems and, for what I  know, many are happy to use it !  
 Sandro Polatod mfinfo@itre.comi   ------------------------------  $ Date: Thu, 9 Aug 2001 12:32:04 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> $ Subject: Re: free software available$ Message-ID: <3b72bb65$1@news.si.com>  F >Is this available at the events or by download at the url provided or either or both.g  I It would appear from a quick visit to the named site that the license forhF the software is available from the given URL, not the software itself. --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.coma= 3290 Patterson Ave. SE, MS      Addresses modified to preventt< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Thu, 09 Aug 2001 12:58:50 +0200o+ From: Maarten van Tilburg <mtilburg@wxs.nl>t" Subject: Re: GEMBASE x OpenVMS 7.3% Message-ID: <3B726CEA.59C40B2@wxs.nl>s  * fabio_compaq@ep-bc.petrobras.com.br wrote: > M > Who is using  GEMBASE ? I am planning to upgrade my systems to OpenVMS 7.3.l > when I have window time. > M > I would like to know what GEMBASE version is compatible wih OVMS 7.3 and if  > you- > have considerations. > . > Actually I have GEMBASE 6.0 running OVMS 7.2 > 	 > Regardsh >  > Fbio Cardosou >   E We are using it. We tried to get that information, from their reply :b   <quote>'H No version of Gembase has been tested and certified to work with OpenVMS? 7.3.  However, this is not to say that Gembase 6.1.5A (with thet	 mandatory G patch applied) will not work in an OpenVMS 7.3 environment.  Many otheraF factors including, your database engine and version, IP protocol stack andr version are all factors.   </quote>  4 More information should be obtained on their website http://www.rossinc.com   Maarteni   ------------------------------  % Date: Wed, 08 Aug 2001 23:36:38 +0100t4 From: John Laird <john@laird-towers.freeserve.co.uk>% Subject: Re: HELP..VMSer in UNIX land.8 Message-ID: <0jf3nt0o6u99b456dtpusadqjmqtqtl4n2@4ax.com>  E On Tue, 07 Aug 2001 18:05:35 -0400, rdeininger@mindspring.com (Robertv Deininger) wrote:   < >In article <3B7048A3.96D63AED@softapp.com>, Fletcher Hearns ><hearns@softapp.com> wrote: >c
 >> Hello all,- >> -> >> I have a question for all you VMSers now working with UNIX. >> i; >> I have a text file that I need to modify.  I need to addy >> something toe7 >> the beginning and something to the end of each line. 
 >> Basically:r >> i >> "This is line 1"  becomes >> "ABC This is line 1 XYZ"h >>' >On VMS or Unix, I would do it with vi:f >  >:1,$s/.*/ABC & XYZ/ > " >One command, that's all it takes.  F Blech.  SOS used to be able to do this in its sleep long before anyone2 ported vi or sed or awk or other unix-isms to VMS.  H Hey Hoff - any chance of dropping some of the compatibility mode sources) onto the next Freeware release ?   :-))))-     	John- -- -
 John Laird Yezerski Roper Ltd   ------------------------------  % Date: Thu, 09 Aug 2001 12:51:57 +0100c/ From: Nigel Arnot <sysmgr@maxwell.ph.kcl.ac.uk>0! Subject: HELP..VMSer in UNIX land$7 Message-ID: <00A0045A.8951A530.14@maxwell.ph.kcl.ac.uk>b  C Use gawk or awk, which is available on all platoforms including VMSu where I learnt it!   In Linux-land:  2 gawk '// {print "ABC " $0 " XYZ"}' infile >outfile   	Yours,e
 		Nigel Arnotd- 		NRA@MAXWELL.PH.KCL.AC.UK                   n  7 		"In the beginning there was nothing, which exploded."n       > Hello all, > = > I have a question for all you VMSers now working with UNIX.r > : > I have a text file that I need to modify.  I need to add > something to6 > the beginning and something to the end of each line. > Basically: >  > "This is line 1"  becomesd > "ABC This is line 1 XYZ" > 4 > I can think of several way to do this on VMS using= > either a DCL command procedure or and editor invoked with aP> > command procedure.  But I am having trouble figuring out how; > to do this on UNIX (Tru64). I have looked at both SED and 7 > AWK and made some headway. Using SED I can figure out-2 > how to add the ABC to each line but not the XYZ. >   > Any help would be appreciated. >  >  > -- > Fletcher Hearnse > President/Consultant	 > S*A*I*Lb > 2828 Brian Ct. > Ellicott City MD 21043 > 410-465-2391 > hearns@softapp.com >  >  >    ------------------------------  $ Date: Thu, 9 Aug 2001 11:24:51 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>c8 Subject: Re: How to build a bootable media for a 11/780?$ Message-ID: <3b72aba4$1@news.si.com>  J >AFAIK, the only large VAX systems that can boot from InfoServer are those	 that were < >released about the same time as (or later than) InfoServer.  & Thanks, Hoff, for setting me straight. --A Brian Tillman                   Internet: tillman_brian at si.comhA Smiths Aerospace                          tillman at swdev.si.com.= 3290 Patterson Ave. SE, MS      Addresses modified to prevente< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  $ Date: Wed, 8 Aug 2001 14:09:38 -04002 From: "Sue Skonetski" <susan.skonetski@compaq.com>B Subject: I just have to post this - and apoligse later Alpha/Intel2 Message-ID: <6ffc7.720$Yx2.18248@news.cpqcorp.net>   Dear Newsgroup,-  K Ok folks here goes.  For all the people that have sent me mail (flame mail) L and posted responses about the death of Alpha  I am going to give a personalF opinion and ask a few questions and if you want to blast me go for it.  D In all reasonableness did you think that the Alpha Chip was going toJ continue forever?  We upgraded from PDP's to VAXes to Alpha and now we areL upgrading again.  Not only are we upgrading but we gave several years noticeL for your planning purposes.  VMS is committed to continue development on theL GS and the next Alpha system and to move onto the Intel platform.  We have aH number of engineers in VMS (around 400) and are hiring some more for the porting project.  J We still have customers that are being supported using PDP's and VAXes whoD will continue to have their systems supported. Alpha systems will beJ supported into the next decade and longer under support contracts.  Please7 tell me where else you can get this kind of commitment.    So from my opinion       We are porting VMSB     And in case you did not know majority of the worlds major chip manufacturers use VMS-2     Alpha Systems will be supported for many years8     Compaq gave plenty of lead time vs. a 9 month windowK     This was not a Compaq (Houston) directive but a technical decision made ! by Alpha engineers that you know.n=     Engineering is more excited than they have been in years. J     I think that this will give VMS exposure in markets where we could not  go and a good business decision.*     There is plenty of work for all of us.  " Folks what is the real issue here?   Suei   ------------------------------  % Date: Thu, 09 Aug 2001 13:40:36 -0400d- From: JF Mezei <jfmezei.spamnot@videotron.ca>bF Subject: Re: I just have to post this - and apoligse later Alpha/Intel, Message-ID: <3B72CB10.4248EA6D@videotron.ca>   Sue Skonetski wrote:H > opinion and ask a few questions and if you want to blast me go for it.   Well, you asked for it !    F > In all reasonableness did you think that the Alpha Chip was going to > continue forever?D  L No, but what Compaq did was akin to killing your 18 year old son because youK know he will eventually die so you might as well kill him right away. Alpha  had a lot of life left into it.   : >  We upgraded from PDP's to VAXes to Alpha and now we are > upgrading again.    K Sue,  serious customers do not see this as an upgrade. For one thing, Alpha H had a quality image that Intel doesn't have. Secondly, even Compaq's ownE documents show that Alpha had technical superiority against Intel. So ( customers do not see this as an upgrade.  I What Compaq is doing, prior to killing its 18 year old son, is to give it J hormones that stop its growth at age 15, meanwhile, its fat and slow IntelL rival will continue to grow and will one day be stronger/faster than Alpha. R But that is an artificial means of portraying the Intel chip as superior to Alpha.  < > Not only are we upgrading but we gave several years notice > for your planning purposes.   K HOW this was announced has much more to do with the distrust of Compaq than L the actual switch to the inferior IA64. The main thrust behind this move wasJ cost cutting (remember the 180 day plan) by streamlining product lines andL eliminating redundant products by focusing on a single platform. Nothing wasL said about choosing a better platform for VMS. As a matter of fact, the portK of VMS was just a "by the way" issue, and not part of the main announcementtc which concerned the 180 day restructurting and purchasing of new companies for sofftware/solutions.e  N So to some, Compaq conveniently exchanged technology that it does not considerM strategic for money which will allow Compaq to do something which is feels istG strategic. And if Alpha, which was so closely associated with VMS isn't-M considered strategic and dumped so unceremoniously, how can anyone trust thataN Compaq won't do the same to VMS whenever it gets an offer that gives it enough. cash to invest in some profitable NT venture ?  M And what was it that Compaq said to its few "key" customers it visited on the E day of the alpha murder that Compaq can't say to the general public ?   L > We still have customers that are being supported using PDP's and VAXes who1 > will continue to have their systems supported. -  N Consider the de-support of certain recent storageworks products, and the aboveH starts to be on shakey ground. I have not seen any commitment to new VMSH released on VAX-VMS for instance. For all we know, 7.3 might be the lastN version.  Would it be the end of the world if it were ? no. But frank and openM discussion from Compaq would go a long way towards helping Compaq rebuild theb trust that customers lost. t   >Alpha systems will beL > supported into the next decade and longer under support contracts.  Please9 > tell me where else you can get this kind of commitment.   L The word commitment from Compaq is meaningless. Compaq broke its commitmentsK to Alpha without warning just because Intel gave it the opportunity to stop D competing against Intel/Microsoft. The minute VMS gets in the way ofN Microsoft, I have no reason to beleive that Compaq would fight to preserve VMSK and give a kick in Gate's ass instead of licking it so clean that it shines16 (Something which Compaq is so good at doing to Gates).  D >     And in case you did not know majority of the worlds major chip > manufacturers use VMS   K Oh, come on. How many systems does this represent ? 10 ? 50 ? How useful is L this to a customer who would like to have the acrobat document reader on his3 VMS workstation ? Or a modern version of netscape ?   M >     This was not a Compaq (Houston) directive but a technical decision mades# > by Alpha engineers that you know.   J Sue, this statement kills credibility. It becomes very clear that you haveK been assimilated by the borg and must now tow the party line. Read your own K web site and you will see that Alpha had lots of technical superiority over 
 Intel's IA64.   ? >     Engineering is more excited than they have been in years.   M Well, that is because they know that VMS won't be killed until 2004 at least. N But are they truly excited to port what will be a "stable" product, as opposed2 to focusing on improving VMS for those 3-4 years ?  L >     I think that this will give VMS exposure in markets where we could not" > go and a good business decision.  N No, Sue. Compaq has had MANY MANY MANY opportunities to give VMS some exposureJ and always chose to exclude VMS.  Just because the chip is changed doesn'tE magically make Compaq decide to make VMS compete head to head against * competing products such as Microsoft's NT.  N Just the other day, I saw a PR release from Compaq extoling the virtues of itsM NT proliant servers and how they were outperforming Unix systems. Why not let-N Microsoft do its own markerting and concetrate on your own products instead ofH insisting on licking Bill Gates' derrire at every opportunity you see ?  $ > Folks what is the real issue here?   Distrust of Compaq.t   ------------------------------  $ Date: Thu, 9 Aug 2001 12:30:37 -0500+ From: Christopher Smith <csmith@amdocs.com>eF Subject: RE: I just have to post this - and apoligse later Alpha/IntelL Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DAF6@cmiexch1.cmi.itds.com>   > -----Original Message-----9 > From: Sue Skonetski [mailto:susan.skonetski@compaq.com]o  ? > and posted responses about the death of Alpha  I am going to y > give a personaleH > opinion and ask a few questions and if you want to blast me go for it.   Heh. :)e  I I thought maybe I should reply to this.  I'm certainly not the one makingKI all the noise, but I have my own problems with the decision, and I'm suree4 some other people have the same ones to an extent.    F > In all reasonableness did you think that the Alpha Chip was going to> > continue forever?  We upgraded from PDP's to VAXes to Alpha   G Forever, no -- until, say, 2010, I'd say that's reasonably possible.  IeD don't honestly have a problem, though with replacing Alpha early and upgrading, though.   > and now we are: > upgrading again.  Not only are we upgrading but we gave   J I would begin my argument at this point.  It seems to me that in replacingI Alpha with an Intel-designed chip, Compaq is taking a big step forward iniH terms of accessibility, and then turning around and running the opposite; direction until they're out of breath in technical terms ;)e  " Upgrade isn't how I'd describe it.   [snip]   >     We are porting VMSD >     And in case you did not know majority of the worlds major chip > manufacturers use VMSM4 >     Alpha Systems will be supported for many years: >     Compaq gave plenty of lead time vs. a 9 month window@ >     This was not a Compaq (Houston) directive but a technical  > decision madeg# > by Alpha engineers that you know.o? >     Engineering is more excited than they have been in years. @ >     I think that this will give VMS exposure in markets where  > we could not" > go and a good business decision., >     There is plenty of work for all of us.  J This is all great news.  Add this to the fact that VMS may be available on0 notebooks again (*hint*), and it's great news.    E On the other hand, I can't help but think that there must be a betterrE solution than to use Itanic.  Add that to the PR disaster that CompaqoK created when they announced that they were going to drop Alpha before -- oriK was it simultaneously -- the announcement of the port, and you've certainly  got room for an argument.e  $ > Folks what is the real issue here?  J So personally, I'm not blind to the possible benefits, but I'm wary of the down-side.    G I think part of the issue is that Compaq doesn't realize that it hasn'tIJ acquired the trust of its VMS customers yet.  It's sad, but Digital reallyL jerked people around for quite a while, and the effects are still lingering.K Compaq probably could have handled the situation this way, if the customersfL trusted them well enough, but that's just not the case yet.  I hope that theG trust will broaden upon successful completion of the port.  Until then,tK Compaq should act like it has to prove itself to the customers, because I'my afraid it really does.     Regards,   Chris       ! Christopher Smith, Perl Developerp Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");y 'd  y   ------------------------------  % Date: Thu, 09 Aug 2001 14:23:55 -0300o) From: fabio_compaq@ep-bc.petrobras.com.br/F Subject: Re: I just have to post this - and apoligse later Alpha/IntelL Message-ID: <OF33AD65E2.F0F1ECF5-ON03256AA3.005DC672@ep-bc.petrobras.com.br>  E In my personal opinion ... and very personal opinion ... analogy ....o  K OpenVMS is a Porsche ! ! !   Unix is a Mustang ! ! ! Windows NT is a Beetlet ! ! !w   What I am trying to say is:   I OpenVMS is a high quality product, which have specialized personal takingh care of it, G so it is expensive to mantain running. It is not a "massive production"m system.cK For me it is one of the 7 wonderfuls of the technology world. For others ith is anl antique OS.v  H Like the Porsches, it dont need to be fixed everytime, so it is the best quality of this OSA (availability).   Ex. Petrobras have hundreds of OpenVMS machinesl (VAX/Alpha) running G Control Systems's VXL in the oil rigs and refinaries. The company stilli trusting in OVMS for industrial automation.  J But, the accessories (Softwares) are becoming rare for the customers.  The motors (Alpha)J are expensive to build, and people prefer to buy a "Mustang" (Intel/Sparc) which can give the samesK results, even with diferent Horse Power (the car runs). Ex. Petrobras  willh port all the Oracle RDB0J databases to SAP / Oracle in Sun Solaris. If we had SAP under OpenVMS ....  H Alpha is a 64 bit processor. Who have other ? Itanium will be ready in a few years with OpenVMSI ported, but I dont know how many applications will be ported. The natural7 way is to port lessiE applications than VAX to Alpha. And do you know a new product lauchedl specifically for OpenVMS in the past two years ?n  J I think Intel should be worried  to develop a 128 bit processor.  If there is a 64, why reinvent ?a   Regards.   FC                X                                                                                         X                     "Sue Skonetski"                                                     X                     <susan.skonetski@c        Para:   Info-VAX@Mvb.Saic.Com             X                     ompaq.com>                cc:                                       X                                               Assunto:     I just have to post this -   X                     08/08/2001 15:09          and apoligse later Alpha/Intel            X                     Responder a "Sue                                                    X                     Skonetski"                                                          X                                                                                         X                                                                                                  Dear Newsgroup,I  K Ok folks here goes.  For all the people that have sent me mail (flame mail)eC and posted responses about the death of Alpha  I am going to give at personalF opinion and ask a few questions and if you want to blast me go for it.  D In all reasonableness did you think that the Alpha Chip was going toJ continue forever?  We upgraded from PDP's to VAXes to Alpha and now we areE upgrading again.  Not only are we upgrading but we gave several years  noticeH for your planning purposes.  VMS is committed to continue development on theyJ GS and the next Alpha system and to move onto the Intel platform.  We have aaH number of engineers in VMS (around 400) and are hiring some more for the porting project.  J We still have customers that are being supported using PDP's and VAXes whoD will continue to have their systems supported. Alpha systems will beJ supported into the next decade and longer under support contracts.  Please7 tell me where else you can get this kind of commitment.    So from my opinion       We are porting VMSB     And in case you did not know majority of the worlds major chip manufacturers use VMS 2     Alpha Systems will be supported for many years8     Compaq gave plenty of lead time vs. a 9 month windowK     This was not a Compaq (Houston) directive but a technical decision made ! by Alpha engineers that you know. =     Engineering is more excited than they have been in years.dJ     I think that this will give VMS exposure in markets where we could not  go and a good business decision.*     There is plenty of work for all of us.  " Folks what is the real issue here?   Suev   ------------------------------  $ Date: Thu, 9 Aug 2001 12:46:53 -04003 From: "Pohl, Kathy" <Kathy.Pohl@itec.mail.suny.edu>t: Subject: RE: Installing V7.3 on Personal Workstation 500auI Message-ID: <0B41ACBECF83734D98ABC83DD8E097E15DE6ED@cipher.itec.suny.edu>p  J This message is in MIME format. Since your mail reader does not understand< this format, some or all of this message may not be legible.  ' ------_=_NextPart_001_01C120F2.E4DFEF20  Content-Type: text/plain;- 	charset="iso-8859-1"9   	2# 	>On 8 Aug 2001, John Santos wrote:m 	>C 	>Can you clarify: Are you booting the VMS installation CD (i.e. ato thee> 	>start of the installation process) or have you done that and	 installednD 	>VMS on a target disk (presumably DKB0:) and are now trying to boot therA 	>target disk for the 1st time?  In other words, is DKB0: your CDs drive  	>or your new system disk?   	Hi,  ? 	I was booting from the VMS installation CD at the start of thes installation' 	process.  I have solved the problem.  .  C 	I didn't realize that this system already had UNIX installed and Ir had toC 	set the os_type to VMS.  However, I now have a different question.o	 Hopefullye? 	a little easier:  After halting the system and getting the >>>a
 prompt, what 2E 	are the commands I can type in at this point?  I have typed in Help,  but I D 	would also like to know if these commands are documented somewhere. And is4 	there a way to see which dev is the internal drive?   	Thanks, 	Kathy   -----Original Message-----' From: John Santos [mailto:JOHN@egh.com]r( Sent: Wednesday, August 08, 2001 6:08 PM To: Info-VAX@Mvb.Saic.Comn: Subject: Re: Installing V7.3 on Personal Workstation 500au     On 8 Aug 2001, Rob Young wrote:o  @ > "Pohl, Kathy" <Kathy.Pohl@itec.mail.suny.edu> wrote in messageC news:<0B41ACBECF83734D98ABC83DD8E097E1C4A7@cipher.itec.suny.edu>...o > > Hi,e > > E > > 	I am trying to install OpenVMS Alpha V7.3 on my Digital personalV > > workstation 500au.I > > 	I boot it using the command >>> boot dkb0 .  It starts to boot and In > > get the message:I > > 	"OpenVMS Alpha Operating System, Version V7.3" and then it hangs.  Ie > > have updatedD > > 	the firmware already.  I have read all the installation doc and" > > can't seem to get beyond this. > > 	What next?e > >  > C > The upgrade went smoothly?  Assuming that... try booting SYSBOOT:r > $ > >>> boot -fl root,flags  boot_dev: > 
 > by example:d >  > >>> boot -fl 0,1 dkb0: >  > SYSBOOT> SET WRITESYSPARAMS 0  > SYSBOOT> SET STARTUP_P1 "MIN"j > SYSBOOT> CONTINUEa > F > When you get in, comment out your TCP/IP startup and go back and tryK > a complete boot.  If using Multinet, you have to get to 4.3 , can't speakw > for the other packages.i >  > Rob   E Can you clarify: Are you booting the VMS installation CD (i.e. at theeF start of the installation process) or have you done that and installedF VMS on a target disk (presumably DKB0:) and are now trying to boot theE target disk for the 1st time?  In other words, is DKB0: your CD drive  or your new system disk?  B If you are booting the CD, then it is probably a CD drive problem.E Is it a DEC/Compaq CD drive or 3rd party?  (What does >>> show devicecA show for it?)  If 3rd-party, is it a drive that is known to work?e? See the FAQ and search the history of this newsgroup and/or ask:D here for requirements and other peoples experiences with this drive.A If 3rd-party, is it configured correctly?  (VMS requires it to beoF set to 512-byte block size.  Some drives can't be set this way, others< have a jumper.  There are probably other requirements, too.)  @ If the CD is known to be a supported model, is it an IDE or SCSI? drive?  Some (all?) IDE drives require an auxiliary boot floppyrB containing the drivers to boot from CD for some or all versions of VMS.  ? If all the above checks out, boot into SYSBOOT as Rob suggestedg and see what happens.   ; If the problem is booting your target system disk after theu= install, then also try booting into SYSBOOT as Rob suggested.S   HTHt   -- o John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539  ' ------_=_NextPart_001_01C120F2.E4DFEF20o Content-Type: text/html; 	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printableo  1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">  <HTML> <HEAD>9 <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =t charset=3Diso-8859-1">@ <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 5.5.2653.12"> @ <TITLE>RE: Installing V7.3 on Personal Workstation 500au</TITLE> </HEAD>a <BODY>  0 <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20H <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt;On 8 =# Aug 2001, John Santos wrote:</FONT>e6 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT = SIZE=3D2>&gt;</FONT>G <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt;Can =s? you clarify: Are you booting the VMS installation CD (i.e. at =t
 the</FONT>I <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt;start =aG of the installation process) or have you done that and installed</FONT>aG <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt;VMS = @ on a target disk (presumably DKB0:) and are now trying to boot =
 the</FONT>6 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =E SIZE=3D2>&gt;target disk for the 1st time?&nbsp; In other words, is =a DKB0: your CD drive</FONT>F <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt;or = your new system disk?</FONT> </P>  G <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Hi,</FONT>  </P>  D <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I was =: booting from the VMS installation CD at the start of the = installation</FONT>y6 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =@ SIZE=3D2>process.&nbsp; I have solved the problem.&nbsp; </FONT> </P>  G <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I didn't =tG realize that this system already had UNIX installed and I had to</FONT>nG <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>set the =qG os_type to VMS.&nbsp; However, I now have a different question.&nbsp; =o Hopefully</FONT>H <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a little =E easier:&nbsp; After halting the system and getting the &gt;&gt;&gt; =  prompt, what </FONT>G <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>are the =oI commands I can type in at this point?&nbsp; I have typed in Help, but I =  </FONT> E <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>would =II also like to know if these commands are documented somewhere.&nbsp; And =e	 is</FONT>GG <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>there a =h2 way to see which dev is the internal drive?</FONT> </P>  5 <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =a SIZE=3D2>Thanks,</FONT>h6 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT = SIZE=3D2>Kathy</FONT>s </P>  3 <P><FONT SIZE=3D2>-----Original Message-----</FONT>a* <BR><FONT SIZE=3D2>From: John Santos [<A =< HREF=3D"mailto:JOHN@egh.com">mailto:JOHN@egh.com</A>]</FONT>B <BR><FONT SIZE=3D2>Sent: Wednesday, August 08, 2001 6:08 PM</FONT>3 <BR><FONT SIZE=3D2>To: Info-VAX@Mvb.Saic.Com</FONT>II <BR><FONT SIZE=3D2>Subject: Re: Installing V7.3 on Personal Workstation =o 500au</FONT> </P> <BR>  8 <P><FONT SIZE=3D2>On 8 Aug 2001, Rob Young wrote:</FONT> </P>  0 <P><FONT SIZE=3D2>&gt; &quot;Pohl, Kathy&quot; =8 &lt;Kathy.Pohl@itec.mail.suny.edu&gt; wrote in message =I news:&lt;0B41ACBECF83734D98ABC83DD8E097E1C4A7@cipher.itec.suny.edu&gt;..=t </FONT></P>h  & <P><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>$ <BR><FONT SIZE=3D2>&gt; &gt; </FONT>H <BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; I am trying to install =0 OpenVMS Alpha V7.3 on my Digital personal</FONT>6 <BR><FONT SIZE=3D2>&gt; &gt; workstation 500au.</FONT>E <BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; I boot it using the =cE command &gt;&gt;&gt; boot dkb0 .&nbsp; It starts to boot and I</FONT>l4 <BR><FONT SIZE=3D2>&gt; &gt; get the message:</FONT>E <BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; &quot;OpenVMS Alpha =dF Operating System, Version V7.3&quot; and then it hangs.&nbsp; I</FONT>0 <BR><FONT SIZE=3D2>&gt; &gt; have updated</FONT>> <BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; the firmware => already.&nbsp; I have read all the installation doc and</FONT>B <BR><FONT SIZE=3D2>&gt; &gt; can't seem to get beyond this.</FONT>A <BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; What next?</FONT>-$ <BR><FONT SIZE=3D2>&gt; &gt; </FONT> <BR><FONT SIZE=3D2>&gt; </FONT>tC <BR><FONT SIZE=3D2>&gt; The upgrade went smoothly?&nbsp; Assuming =p# that... try booting SYSBOOT:</FONT>  <BR><FONT SIZE=3D2>&gt; </FONT>1@ <BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt; boot -fl root,flags&nbsp; = boot_dev:</FONT> <BR><FONT SIZE=3D2>&gt; </FONT>c* <BR><FONT SIZE=3D2>&gt; by example:</FONT> <BR><FONT SIZE=3D2>&gt; </FONT>i> <BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt; boot -fl 0,1 dkb0:</FONT> <BR><FONT SIZE=3D2>&gt; </FONT>:? <BR><FONT SIZE=3D2>&gt; SYSBOOT&gt; SET WRITESYSPARAMS 0</FONT>t4 <BR><FONT SIZE=3D2>&gt; SYSBOOT&gt; SET STARTUP_P1 = &quot;MIN&quot;</FONT>3 <BR><FONT SIZE=3D2>&gt; SYSBOOT&gt; CONTINUE</FONT>  <BR><FONT SIZE=3D2>&gt; </FONT>lB <BR><FONT SIZE=3D2>&gt; When you get in, comment out your TCP/IP =" startup and go back and try</FONT>G <BR><FONT SIZE=3D2>&gt; a complete boot.&nbsp; If using Multinet, you =y' have to get to 4.3 , can't speak</FONT>b6 <BR><FONT SIZE=3D2>&gt; for the other packages.</FONT> <BR><FONT SIZE=3D2>&gt; </FONT>r" <BR><FONT SIZE=3D2>&gt; Rob</FONT> </P>  I <P><FONT SIZE=3D2>Can you clarify: Are you booting the VMS installation =n CD (i.e. at the</FONT>H <BR><FONT SIZE=3D2>start of the installation process) or have you done = that and installed</FONT>iH <BR><FONT SIZE=3D2>VMS on a target disk (presumably DKB0:) and are now = trying to boot the</FONT>pH <BR><FONT SIZE=3D2>target disk for the 1st time?&nbsp; In other words, = is DKB0: your CD drive</FONT>w2 <BR><FONT SIZE=3D2>or your new system disk?</FONT> </P>  G <P><FONT SIZE=3D2>If you are booting the CD, then it is probably a CD =  drive problem.</FONT> D <BR><FONT SIZE=3D2>Is it a DEC/Compaq CD drive or 3rd party?&nbsp; =* (What does &gt;&gt;&gt; show device</FONT>I <BR><FONT SIZE=3D2>show for it?)&nbsp; If 3rd-party, is it a drive that =b is known to work?</FONT>I <BR><FONT SIZE=3D2>See the FAQ and search the history of this newsgroup =o and/or ask</FONT>sH <BR><FONT SIZE=3D2>here for requirements and other peoples experiences = with this drive.</FONT>eI <BR><FONT SIZE=3D2>If 3rd-party, is it configured correctly?&nbsp; (VMS =t requires it to be</FONT>H <BR><FONT SIZE=3D2>set to 512-byte block size.&nbsp; Some drives can't = be set this way, others</FONT>B <BR><FONT SIZE=3D2>have a jumper.&nbsp; There are probably other = requirements, too.)</FONT> </P>  H <P><FONT SIZE=3D2>If the CD is known to be a supported model, is it an = IDE or SCSI</FONT>C <BR><FONT SIZE=3D2>drive?&nbsp; Some (all?) IDE drives require an =m auxiliary boot floppy</FONT>G <BR><FONT SIZE=3D2>containing the drivers to boot from CD for some or =t all versions of</FONT> <BR><FONT SIZE=3D2>VMS.</FONT> </P>  I <P><FONT SIZE=3D2>If all the above checks out, boot into SYSBOOT as Rob =d suggested</FONT>/ <BR><FONT SIZE=3D2>and see what happens.</FONT>o </P>  E <P><FONT SIZE=3D2>If the problem is booting your target system disk =m after the</FONT>G <BR><FONT SIZE=3D2>install, then also try booting into SYSBOOT as Rob =u suggested.</FONT>  </P>   <P><FONT SIZE=3D2>HTH</FONT> </P>   <P><FONT SIZE=3D2>-- </FONT>% <BR><FONT SIZE=3D2>John Santos</FONT> : <BR><FONT SIZE=3D2>Evans Griffiths &amp; Hart, Inc.</FONT>. <BR><FONT SIZE=3D2>781-861-0670 ext 539</FONT> </P>   </BODY>  </HTML>\) ------_=_NextPart_001_01C120F2.E4DFEF20--\   ------------------------------   Date: 9 Aug 2001 05:02:34 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)s* Subject: Re: Lemmings, was Re: Move to Sun3 Message-ID: <g5IvMVtse8Xd@eisner.encompasserve.org>3   In article <y44rrhipny.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:2 > "Duane Sand" <duane.sand@mindspring.com> writes: > O >> "Waiting" until 2004?  I'm sure the VMS devel team doesn't feel it that way!dF >> It will likely be very challenging for them to meet that optimistic >> schedule. > P > Well, that's almost 2.5 years from now. How long did it take until VMS/AXP 1.0O > was available? The changes required were much larger than those for IA64 willeP > be. And a lot of the tools on the IA64 platform already exist, compared to the > initial situation on Alpha.b  G The first fully-functional Alpha VMS was V6.1 - V1.0 and V1.5 were justmG for "early adopters".  Certainly that makes the total time on VMS aboutV 5 years.   ------------------------------  # Date: Thu, 09 Aug 2001 02:43:58 GMTe. From: "Duane Sand" <duane.sand@mindspring.com>* Subject: Re: Lemmings, was Re: Move to Sun? Message-ID: <ONmc7.42841$Kd7.26395702@news1.rdc1.sfba.home.com>    "JF Mezei" wrote:o > ...eL > What I do find quite odd though is that Compaq would supposedly wait untilL > 2004 before making VMS on IA64 commercially available even though it might runsG > on IA64 beforehand. A conspiracy theorist might see this as a way for  CompaqJ > to delay any support commitment on VMS-IA64 as long as possible and keep thet1 > VMS customers on Alpha as long as possible. ...k  L "Waiting" until 2004?  I'm sure the VMS devel team doesn't feel it that way!C It will likely be very challenging for them to meet that optimisticf	 schedule.a= They are just now getting started in working out requirements @ and understanding the chip.  Designing won't be real for months.E Staffing won't be adequate for months.  Probably nothing IPF-specific ; can be done in the OS until various GEM-based compilers fors> IPF support the needed language dialects and emit stable code.; That's an entirely different compiler back end than Intel's 4 "Electron" compiler being used by most IPF  vendors.> The initial compiler work will likely require at least a year.> In parallel with that, whatever VAX and Alpha binary emulationH tools are needed, will likely take at least a year before first internal use.  E After all the hardware and all the software are functionally complete D and seemingly stable, there will likely need to be about a full yearD of internal "alpha" and "beta" full-system testing before the result= is stable enough to be shipped to even adventurous customers.   7 If none of that work were needed and VMS & its customerl3 software base could indeed be immediately ported asa5 easily & quickly as Tru64 or Linux, there still wouldoH be little point in sell those boxes immediately.  It's not until Intel's> 3rd generation IPF chip design and future chip fab technology,3 that IPF's clock rate and resulting performance aren: roadmapped to be compelling better than EV7x will achieve.7 A VMS-on-McKinley product would only be bought in small - numbers, as a kick-the-tires demo experiment.n  4 VMS ISVs might like that extra time with demo boxes.7 But I doubt that the port of VMS can be completed early 5 enough to beat the McKinley follow-on chip to market.S  (   -- Duane Sand, not speaking for Compaq   ------------------------------    Date: 09 Aug 2001 10:49:21 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e* Subject: Re: Lemmings, was Re: Move to SunH Message-ID: <y44rrhipny.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  0 "Duane Sand" <duane.sand@mindspring.com> writes:  N > "Waiting" until 2004?  I'm sure the VMS devel team doesn't feel it that way!E > It will likely be very challenging for them to meet that optimisticb > schedule.o  N Well, that's almost 2.5 years from now. How long did it take until VMS/AXP 1.0M was available? The changes required were much larger than those for IA64 willgN be. And a lot of the tools on the IA64 platform already exist, compared to the initial situation on Alpha.    	Jan   ------------------------------    Date: 09 Aug 2001 10:53:17 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> * Subject: Re: Lemmings, was Re: Move to SunH Message-ID: <y41ymliphe.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:s  O > > As long as Compaq was supporting and further developing Alpha, you could beEL > > sure they would also be supporting and further developing Tru64 and VMS,= > > because without them Alpha would loose its raison d'etre.  > 	 > Agreed.y > M > > indeed takes that long) "VMS and Tru64 sales have subsided to just 5% of aN > > their former glory [surprise, surprise!], we will therefore now move them > > > to maintenance mode and desupport them in a year's time."  > N > I disagree.  Consider that Compaq did not give away EV7 team right away.  AsM > long as EV7 team is working for Compaq on the last Alpha, then it is a fair>N > bet that Compaq won't go out and put VMS in maintenance mode. If Compaq wereL > to kill EV7 and let the employees go to Intel as the deal stipulates, then) > yeah, what you say would likely happen.   M EV6 will be end-of-life pretty soon now. If Compaq had killed EV7 as well, itUL would have been clear they had surrendered that market along with VMS, Tru64K and NSK to their competitors. Keeping at least EV7 was the aboslute minimum 1 required to keep those alive for the time being. a   	Jan   ------------------------------    Date: 09 Aug 2001 14:14:36 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>a* Subject: Re: Lemmings, was Re: Move to SunH Message-ID: <y4d765h1lf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:o  I > The first fully-functional Alpha VMS was V6.1 - V1.0 and V1.5 were justnI > for "early adopters".  Certainly that makes the total time on VMS about@
 > 5 years.  , I think we're talking "early adopters" here.   	Jan   ------------------------------  % Date: Thu, 09 Aug 2001 13:08:53 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>a* Subject: Re: Lemmings, was Re: Move to Sun, Message-ID: <3B72C3A4.489AEF07@videotron.ca>   Jan Vorbrueggen wrote:. > I think we're talking "early adopters" here.    K Back in the early Alpha days, the VMS market wasn't completely dead yet. So.G there were probably enough VMS machines around to make "early adopters"tK possible. As I recall, VMS 1,.0 on Alpha was missing the new queue manager,.H but had the old queue manager, so it was still functional. What else was	 missing ?d    N However, when you look at today's VMS installed base, with Compaq's philosophyL that there are only very large VMS shops with mission critical systems left,0 are there going to be that many early adopters ?  K What I do see though is the need for Compaq to release VMS on IA64 ASAP nottL for customers, but for the few large ISVs that count so that by the time VMSE is ready for prime time, there will be applications available for it.d  N Unless, of course, Compaq decides to emulate what Apple did for its transitionK from 68k to PowerPC and include an automatically triggered , transparent to L user, executable translator that will run Alpha and VAX executables on IA64,E at which point, you can start to migrate from day one and just have ahK performance hit until the native version of the software becomes available.k   ------------------------------   Date: 9 Aug 2001 06:44:15 -0700a9 From: lzoedv@cretschmar-logistik.de (M.Eismann&W.Richard)n# Subject: Linker-Warnings in VMS 7.3s= Message-ID: <6d280ea8.0108090544.4ea05304@posting.google.com>b   Hello to all OpenVMS-Friends!t  P After we had upgraded from OpenVMS V7.1-1H1 to V7.3 on a Test-Alphaserver we hadG compiled our applications without any errors! But now (after successfulrB compilation) we get link-warnings with unresolved message-numbers:& %LINK-W-NOMSG, Message number 0064A120& %LINK-W-NOMSG, Message number 0064A128& %LINK-W-NOMSG, Message number 0064A130& %LINK-W-NOMSG, Message number 0064A128  . Before above upgrade no link-warnings occured!  # An analyze/image of link.exe shows:b(         Image Identification Information  "                 image name: "LINK"3                 image file identification: "A12-03"NB                 image file build identification: "X913-0060000000"7                 link date/time: 22-MAR-2001 12:52:30.00o/                 linker identification: "A11-50"E  $ Does anybody have an idea or a hint?  	 greetingse martin eismann,/ cretschmar logistik gmbh duesseldorf, germany   ------------------------------   Date: 7 Aug 2001 15:52:08 -0000T3 From: Doc.Cypher <doc_cypher@redneck.gacracker.org>u# Subject: Re: Microsoft and Code redp5 Message-ID: <20010807155208.5938.qmail@gacracker.org>s  " -----BEGIN PGP SIGNED MESSAGE-----  C On Mon, 06 Aug 2001, JF Mezei <jfmezei.spamnot@videotron.ca> wrote:n   [SNIP]  M >Could this be the achile's heel that starts to bring down Microsoft, or willsO >corporations ignore this major flaw and continue to blindly bet their businessV >on Microsoft stuff ?. > C >What will it take for corporations to wake up from their MicrosoftSM >trans/brainwashing and realise that they shouldn't be betting their businesss >on MS software ?>  E In the case of the Code Red worm, the fault could be said to lie withaJ customers. This is because M$ had issued a patch for the expoit a month orH two ago. Of course, you can always blame M$ for failing to have adequateC quality management and testing of their product in the first place.v     Doc. - -- s6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.netp   -----BEGIN PGP SIGNATURE-----/ Version: 2.6.2  @ iQEVAwUBO28hcsriC3SGiziTAQFeWAf9Gdo8nogeU54IEoALm0sbp/Egq41B8WvE@ iKvnCJxr9OU1q7kApQnxoJJOyGq+ZKAGSye29tr+EtXZse8oS7xJ1EtQMxs8kuPe@ EtUqQKiG4rVGAIuuZRKssTBRGhCequPD8gWx5ZqKVZ14nHct8bFVRkcMKcU3ZGKT@ JyivZxSjkMdwTe9Gc6G9Nb5r/EhsnoC0Ja2GRo5w/pkCJcBK9qp7Pfs9s8a8qHqI@ zbTpEFrRhpZ+a02V7wU3Cs+UkeIk3E1QuDgpMh/kns7C++I7ywqlWCMoiMmlxk8x8 pJOBUveIq5TOQ23/enc1ewcKkeiqqfycRIkuOT6xbwALck/uUIZyfA== =1uuG  -----END PGP SIGNATURE-----n   ------------------------------  % Date: Thu, 09 Aug 2001 19:17:40 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.auv Subject: Microsoft and CRp5 Message-ID: <01K6XW3QI536003O4B@tgmail.tg.nsw.gov.au>s  K Shi(r)t (there is no other word!!! -- but I thought I should write it like m that.)  B I sent the following as part of the thread that writes CR in full.   >Hey, whoa.s >n >Isn't this OT for c.o.v.? > P >In the last hour, I have received over 30 messages on this subject.  What am I A >going to get overnight (Australian) whilst you guys are at work?o > K >I am not a BG fan, and I don't use anything Micro$haft.  I'm on VMS boxen.e >s8 >I know we love to gloat over inferior systems, but hey. >TP >[Out of 36 messages, in the past hour, one was from Jack Peacock: Move to Sun, F >one was on PGP and one personal one from my son.  The rest were ....] >O >Regards, Paddyn [rest of sig elided]  4 I get back from our own new wonderful virus rubbish:    E >From:	TGMAIL::IN%"MAILsweeper@tg.nsw.gov.au"  9-AUG-2001 18:44:55.91:$ >To:	IN%"obrien@gecko.tg.nsw.gov.au" >CC:	oL >Subj:	RE:Re: Microsoft and C* r* Trapped [Thought I should change that too] >,O >The above mesage has been trapped by the Transgrid virus scanner as contaning F1 >a possible virus.  Please contact the recipient.a  O Does this mean we can no longer discuss or include any "sensitive" word in our YN mail?  This is big brother gone insane.  My mail is all plain text from a VMS  box.  L I remember a mail from a Mr. Dicks had similar problems a while back.  What D happens with all those people who use the shortened form of Richard?  L Mr Gates inability to sell a secure operating system whilst taking over the ' world has sparked this ultra stupidity.m  1 I am so passed off that I would like to say duck.l   Regards, Paddy   ------------------------------  % Date: Thu, 09 Aug 2001 19:30:47 +0010&% From: paddy.o'brien@zzz.tg.nsw.gov.aus Subject: Re: Microsoft and CR;5 Message-ID: <01K6XWK06OCY003O5X@tgmail.tg.nsw.gov.au>>   I wrote, with snips:  ( Part of my love letter from MAILsweeper:  O >The above mesage has been trapped by the Transgrid virus scanner as contaning 3            ^^^^^^h1 >a possible virus.  Please contact the recipient.h  C And I've just noticed that they cannot even bladdy spell correctly.    Regards, Paddy   ------------------------------  % Date: Thu, 09 Aug 2001 13:07:08 +02002, From: Didier Morandi <Didier.Morandi@gmx.ch> Subject: Re: Microsoft and CR;& Message-ID: <3B726EDC.163461F8@gmx.ch>  & paddy.o'brien@zzz.tg.nsw.gov.au wrote:  P > Does this mean we can no longer discuss or include any "sensitive" word in our) > mail?  This is big brother gone insane.:  H The problem, here, Paddy, is that the behaviour we are experimenting (?)3 is perhaps the expectation the virus author(s) had:B   1. be in the News (glory)c   2. bother everyone (revenge?)p  # 3. hurt a max (insane satisfaction)O  & and maybe, suddenly, THE solution ($$)  = This reminds me Robert Ludlum's last book: "The Hades Factor">   D.   ------------------------------  $ Date: Thu, 9 Aug 2001 12:27:39 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>B& Subject: Re: mount spare internal disk$ Message-ID: <3b72ba5c$1@news.si.com>  H >For example if  I need to mount the disk named $1$dke100 as local disk, >which are the steps ?   To mount it system-wide, use  & $ mount/system $1$dke100: dke100slabel  ! To mount it for your process, uset   $ mount $1$dke100: dks100slabel&  8 where "dke100slabel" is the volume label for the device. -- TA Brian Tillman                   Internet: tillman_brian at si.comaA Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to prevents< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Thu, 09 Aug 2001 04:03:46 GMTt* From: cjt & trefoil <cheljuba@prodigy.net> Subject: Re: Move to Sun* Message-ID: <3B720BFA.F0D1C81@prodigy.net>   Arne Vajhj wrote: > 
 <snip> The > statementCG > above could be referring to the fact that SUN is not selling hardware2 > based on Intel chips.i >  > Arne   Are AMD chips close enough?t   ------------------------------  % Date: Thu, 09 Aug 2001 10:23:06 +0200t= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>I Subject: Re: Move to Sun) Message-ID: <3B72486A.38374C86@gtech.com>r   cjt & trefoil wrote: > Arne Vajhj wrote: > <snip> The
 > > statementpI > > above could be referring to the fact that SUN is not selling hardwaret > > based on Intel chips.; > >  > > Arne >  > Are AMD chips close enough?3   Yes.  ( Are SUN selling PC's with AMD chips in ?   Arne   ------------------------------  $ Date: Wed, 8 Aug 2001 10:10:10 -0400- From: "www.islandco.com" <sales@islandco.com>N Subject: Re: OpenVMS and IA64f/ Message-ID: <tn2hkh3pfhs944@news.supernews.com>n   Yep   E Let's keep backing up to 30 year old technology  floppies and tapes !qB What is the average age of the VMS development engineers, anyway ?   DT    F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:wMkL2B2t3PMu@eisner.encompasserve.org...>G > In article <200108080549.HAA15196@sinet1.fom.fgan.de>, Rudolf Wingert> <win@fom.fgan.de> writes:e
 > > Hello, > >OG > > OpenVMS on IA64 would be the chance for a full support of USB(2). It hope. E > > Also that we get a system integrated CD-RW and DVD-Rw capability.  >oH > I do not see how IA64 would change the CD situation.  There will be noH > different drives available on the market for IA64 than for Alpha.  VMSE > Development has not seen it appropriate to provide CD-R directly on>B > VMS, and the input to that decision should be the same for IA64.   ------------------------------  # Date: Thu, 09 Aug 2001 11:15:00 GMT- From: "-[Gj]-" <gjai@free.fr>3 Subject: pb deci2 Message-ID: <Uguc7.321$802.12301@nnrp1.proxad.net>   errorR! ??    003    3        qdz    0096e help me  i'm speak french serch doc in french3 thanks search info dec/linuxm1 i've decserver 5000/240 and i search all infos !!r error:
 3/misc/kbd ?STF (4: Ln#0 Kbd self test)   3/misc/mouse ?STF (4: Ln#1 Pntr self test)n   bye.   ------------------------------  % Date: Thu, 09 Aug 2001 17:30:03 +0200s, From: Didier Morandi <Didier.Morandi@gmx.ch> Subject: Re: pb dech& Message-ID: <3B72AC7B.5044FE26@gmx.ch>   "-[Gj]-" wrote:a >  > errorr# > ??    003    3        qdz    0096l	 > help me0 > i'm speak french > serch doc in frenche > thanks > search info dec/linuxl3 > i've decserver 5000/240 and i search all infos !!  > error: > 3/misc/kbd > ?STF (4: Ln#0 Kbd self test) >  > 3/misc/mouse > ?STF (4: Ln#1 Pntr self test). >  > byed  ( Explique-toi et je traduirai en english.* (explain in French, then I will translate)   D.   ------------------------------   Date: 7 Aug 2001 14:32:40 -0000:3 From: Doc.Cypher <doc_cypher@redneck.gacracker.org>. Subject: Re: PGP on VMSg5 Message-ID: <20010807143240.4660.qmail@gacracker.org>3  " -----BEGIN PGP SIGNED MESSAGE-----  < On Mon, 06 Aug 2001, "john nixon" <jnixon@cfl.rr.com> wrote:M >I have been asked if we can load PGP on VAX or Alpha VMS.  My first responsecI >was "what is PGP" (duh).  The answer I recieved is "Pretty Good Privacy"a >encryption. > K >Does anyone know anything about this?  (Am I the only that doesn't?) Is it  >available or useful on VMS?  A PGP for VMS can be found at http://www.pl.pgpi.org/platforms/vms/   F Unfortunately, this is version 2.6.3i and no later versions exist. (If< anyone knows of one and where it can be found, let me know!)  K This means that you will be restricted to the RSA algorithm and IDEA cyphernF with MD5 for signatures. (What is often referred to as "legacy" keys).     Doc. - -- e6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.netn   -----BEGIN PGP SIGNATURE-----d Version: 2.6.2  @ iQEVAwUBO28hcsriC3SGiziTAQFDtAf+PGHBhCm8tVYDJmTNpehemMnnKK/zaGWK@ HCz/CVYa3Ge8kWtRcA3VBslJZs01yxQN6nbq07GXEb33+AVqTyRmIs7dABXLKXPX@ N7TZzj5uyt/cHgyl5RzkriX8WjifR5NI0QeFIhZvhNxVDLpKIrRu8+w/F/VDKS5g@ 5tQ1MgR7wyaChymgVlhfy8wlRYZ6UXXeTGm/i9h2PugyIcIxpXpI4b0bwpMfmCEU@ csP7VbbIzpYUUogd+Zv623sEFvaLKDDDTme2mV9xiFAIch069SQWjXwpX45JWsq48 u+K7XYhzmEHsDJ3p04GBjt00Ri6ss7SsY9vlpIySs9ZQHetY8PqBzA== =Cmbkl -----END PGP SIGNATURE-----e   ------------------------------  % Date: Thu, 09 Aug 2001 13:44:15 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>i Subject: Re: Press Release, Message-ID: <3B72CBEB.A18D6334@videotron.ca>   Sue Skonetski wrote:N > Compaq Federal LLC. "And we're equally pleased that more and more governmentJ > agencies are turning to Compaq whether they need the mobility of an iPACM > Pocket PC, Evo desktops or laptop units, Compaq Pro-Liant industry-standardt; > services or a total services-led IT enterprise solution."r  K Another example. Why does Compaq take every opportunity to feature its iPAQeK and Proliant stuff in every press release, even those that should have beenxM dedicated to VMS, but never features VMS in any other type of public exposure J such as press releases about Proliant contracts, finincial statements, and Capellas interviews on CNN ?      L > Earlier this year, the U.S. Postal Service signed an agreement with CompaqJ > to make Presario Internet PCs and a variety of Internet services optionsD > available at discounts to more than 800,000 post office employees.  F > In April, Compaq was awarded a $30 million contract to update 32,000L > computers in the Social Security Administration in 1,000 service locations$ > across the country in five months.   Again, more PC drivel.   ------------------------------  % Date: Wed, 08 Aug 2001 23:10:24 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)5 Subject: Re: Qume QTV-202 keyboard and Dec 3000/300LXsL Message-ID: <rdeininger-0808012310250001@user-2iveb8l.dialup.mindspring.com>  M In article <3B71BE2A.2184B53E@iname.com>, Mark <espexplorer@iname.com> wrote:a  J > Does anyone happen to know if the Qume QVT-202 keyboard can be used withE > the DCE 3000/300LX?  I guess my real question is whether or not the.C > QVT-202 is compatable with the Digital LK201 and LK401 keyboards.i  # I have NO idea about this keyboard.n  J But any of the DEC LK201/LK401 keyboards with the correct connector shouldG work.  You also need a somewhat funky cable to connect the keyboard and J mouse to the system.  These items are usually available at ebay for cheap.   -- a Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Thu, 09 Aug 2001 13:11:36 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca>m* Subject: Re: Red Code: where are we going?, Message-ID: <3B72C446.9F7D9D24@videotron.ca>   "Doc.Cypher" wrote: F > According to the following article at Zdnet, the estimated number of5 > infected machines is probably in excess of 400,000.n  = > How many of those Windoze users will actually have backups?m    M How many of these windows users actually realise that they have been infected H and that their PC is constantly spewing out requests to connect to everyL possible IP ? Seems that the system does crash now and then due to the worm,N but to a windows user, that is a normal occurance and therefore does not raise any suspicions.t   ------------------------------  % Date: Thu, 09 Aug 2001 10:34:50 -0400o; From: Robert DiRosario <robert.j.dirosario.1@gsfc.nasa.gov>n2 Subject: Re: Shameless Grab; Was Re: uVAX 3100 M38- Message-ID: <3B729F8A.D343F764@gsfc.nasa.gov>u  F > I'm fairly certain that the uVAX uses the same internal cable as the VAXStation.:H The only difference between a VAXStation 3100 and a MicroVAX 3100 is theJ VAXStation has a frame buffer (video)  board.  Remove the frame buffer, orF disable it with the switch on the rear of the system, and it becomes a	 MicroVAX.o    
 Doc wrote:  L > On 8 Aug 2001 19:29:20 -0700, Phil Mendelsohn <mend0070@tc.umn.edu> wrote:1 > > Hi,  setup follows, with question at the end:- > >-J > > I'm salvaging a pallet of surplus uVAXen 3100's, Storage Expansion, anH > > InfoServer, some DECstations (now mostly parts, where applicable  --J > > i.e. drives), and some VT1300s.  This is hobbyist; it happened largelyG > > due to a little creativity in rearranging a crowded basement and anh > > understanding wife.s > >o > > Phil Mendelsohn. >h > Phil,pL >  I can't help you with the error codes, except to tell you that my VS 3100K > m38 sits on the "...B" diagnostic for about a minute. I think that's just G > an indication that it has a, ahem, "lot" of RAM. Mine is running 20M. F >  The main reason for my followup is that I'm looking for an internalI > harddisk cable. I'm fairly certain that the uVAX uses the same internale > cable as the VAXStation.H >  If you end up with spare parts, and want to sell a cable, I'd like to > have one.e >S
 >  Thanks, >   Doc Shipleym   ------------------------------  $ Date: Thu, 9 Aug 2001 13:42:16 -0500* From: WILLIAM WEBB <WWEBB1@email.usps.gov>2 Subject: RE: Shameless Grab; Was Re: uVAX 3100 M38- Message-ID: <0033000031817087000002L072*@MHS>i   =0AShameless plug:  0 VAXstation 3100 Model 76 User's Guide online at:. www.whiteice.com/~williamwebb/intro/DOC-i.html   WWWebb     > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ) > Sent: Thursday, August 09, 2001 1:15 PMiF > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET4 > Subject: RE: Shameless Grab; Was Re: uVAX 3100 M38 >v >eH > > I'm fairly certain that the uVAX uses the same internal cable as th= e.
 > VAXStation. > > The only difference between a VAXStation 3100 and a MicroVAX
 > 3100 is then; > VAXStation has a frame buffer (video)  board.  Remove then > frame buffer, orH > disable it with the switch on the rear of the system, and it becomes = au > MicroVAX.o >w >e > Doc wrote: >i1 > > On 8 Aug 2001 19:29:20 -0700, Phil Mendelsohna > <mend0070@tc.umn.edu> wrote:3 > > > Hi,  setup follows, with question at the end:m > > >4> > > > I'm salvaging a pallet of surplus uVAXen 3100's, Storage > Expansion, ani; > > > InfoServer, some DECstations (now mostly parts, where  > applicable  --; > > > i.e. drives), and some VT1300s.  This is hobbyist; it  > happened largely9 > > > due to a little creativity in rearranging a crowdedi > basement and an3 > > > understanding wife.  > > >d > > > Phil Mendelsohn2 > >0	 > > Phil, > > >  I can't help you with the error codes, except to tell you > that my VS 3100 ; > > m38 sits on the "...B" diagnostic for about a minute. Is > think that's just-< > > an indication that it has a, ahem, "lot" of RAM. Mine is > running 20M.H > >  The main reason for my followup is that I'm looking for an interna= lp= > > harddisk cable. I'm fairly certain that the uVAX uses the- > same internal  > > cable as the VAXStation.> > >  If you end up with spare parts, and want to sell a cable,
 > I'd like to 
 > > have one.  > >t > >  Thanks, > >   Doc Shipleyt >=   ------------------------------   Date: 9 Aug 01 12:28:33 GMTd- From: jason@azure.dstc.edu.au (jason andrade) < Subject: Re: Source for non-standard DEC 15 Amp power cords?) Message-ID: <jason.997360113@dstc.edu.au>   2 "P. Thompson" <thompson-nospam@new.rr.com> writes:    H >Cisco routers and some HP9000 8xx's have this "DEC" "nonstandard" power >cord as well.    D it depends - if you just want to test something, you could be reallyD careful with a stanley knife and butcher a normal power cord to fit.  * i've done this without very many problems.  = otherwise you could either talk to people like islandco whicht: might have a stock of them, or get a part number and start
 googling..   -jason   ------------------------------  # Date: Thu, 09 Aug 2001 08:02:49 GMT60 From: "P. Thompson" <thompson-nospam@new.rr.com>< Subject: Re: Source for non-standard DEC 15 Amp power cords?J Message-ID: <Pine.LNX.4.33.0108090301110.13264-100000@malacandra.localnet>  G Cisco routers and some HP9000 8xx's have this "DEC" "nonstandard" power8
 cord as well.p  $ On Wed, 8 Aug 2001, Ben Myers wrote:  G > Heat up your VAX enough and maybe it could boil water.  :)   Not good1 > for the VAX, tho... Ben Myersn > D > On Wed, 08 Aug 2001 18:18:04 +0100, ChrisQ <quattro@aerosys.co.uk> > wrote: >d > >Robert DiRosario wrote: > >>K > >> Where can I get the non-standard 15 Amp 120V power cords that DEC usedsK > >> on things like the VAX 4000 systems in the BA-440 enclosure or the DECe > >> Alpha 3000/900? > >l
 > >Robert, > > U > >I think what you want is the IEC "hot condition" plug lead set. These are like the Z > >standard IEC plugs, but have a notch along the length of the flat side and are rated at6 > >10a, not 5 as per the standard un-notched cord set. > > S > >Here in europe they are fitted to electric kettles etc, which is probably no usek) > >whatsoever if you are in the US ;-)...  > >e > >Chris   ------------------------------  . Date: Thu, 9 Aug 2001 08:11:24 +0200 (MET DST)& From: Rudolf Wingert <win@fom.fgan.de>= Subject: Re: Suggested DCPS features (was OpenVMS  + Itanium)e6 Message-ID: <200108090611.IAA18461@sinet1.fom.fgan.de>   Hello,   Brian Tillman did write:   >>>.H That's been available since DECwindows first came out.  It's the "print"I widget.  Just click on any DECwindows "File" menu and you'll see it.  YoueL can specify anything there that the PRINT command supports, including any of4 the /PARAMETERS that any specific symbiont supports. <<<r  F Does this tool show all the features of the printer or can you select,D what you want regardsless of the printer options? Also, what's aboutI printer features such as the highresolution option of LN20, not supportedhH via DCPS. A GUI like the Windows GUI, which list all the printer optionsG is much better, then we do have just. Once (years ago) VMS was a leaderrG OS with a lot of modern features (such as Async. Interrupts). Now it issH a little bit behind. Good tools we see on UNIX or Wintel at first. Under' VMS we will see them never or too late.-   Regards Rudolf Wingert   ------------------------------  % Date: Wed, 08 Aug 2001 17:46:12 -0500o/ From: Chris Scheers <chris@applied-synergy.com>a= Subject: Re: Suggested DCPS features (was OpenVMS  + Itanium)e3 Message-ID: <3B71C134.8A78BD46@applied-synergy.com>t   Brian Tillman wrote: > N > >It should be possible to use the printer feature in the normal way via DCPSM > >for the Guru's or people who knows all the printer features. For all otherr> > >(normal users), there should be a GUI like the windows GUI. > J > That's been available since DECwindows first came out.  It's the "print"K > widget.  Just click on any DECwindows "File" menu and you'll see it.  You N > can specify anything there that the PRINT command supports, including any of6 > the /PARAMETERS that any specific symbiont supports.   Well, sorta.  H The last time I checked, the print widget was still a Motif 1.0 widget. > It was not upgraded to later versions of Motif.  This makes itD "interesting" to use the widget within a larger application specific2 widget that uses Motif 1.1 or Motif 1.2 semantics.  D There are also some callbacks that are missing from the widget which would enhance its usability.  F Also, the print widget doesn't have any knowledge of printer types, soF it can't present useful printer specific information, e.g., paper tray existance or names.r  G -----------------------------------------------------------------------o$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com o   Fax: 817-237-3074    ------------------------------  $ Date: Thu, 9 Aug 2001 12:25:37 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>t= Subject: Re: Suggested DCPS features (was OpenVMS  + Itanium)l" Message-ID: <3b72b9e2@news.si.com>  G >Does this tool show all the features of the printer or can you select,E2 >what you want regardsless of the printer options?  K If you can do it from the PRINT command, you can do it from the Motif print  widget.  I already said that.  --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.comn= 3290 Patterson Ave. SE, MS      Addresses modified to preventt< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Thu, 09 Aug 2001 13:00:00 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>0= Subject: Re: Suggested DCPS features (was OpenVMS  + Itanium)e, Message-ID: <3B72C18F.CB653D03@videotron.ca>   Rudolf Wingert wrote:hH > Does this tool show all the features of the printer or can you select,4 > what you want regardsless of the printer options?   I Here is another question. When a PC is connected to VMS via Pathworks (or G whatever the name is this week), does the PC have access to the printer M information and PPDs, or must it assume a generic printer is connected at the0 other end of the print queue ?  G With the little product known as "DECPRINT Postscript to Sixel printingtM utility", there were logical names associated with each print queue to defineoK the type of printer that was hooked to it, so that DECprint would know whatl4 sort of resolution to use when generating the sixel.  
 for instance:e; PSPRINT$MATRIX_DEVICE_TYPE "LA75"  for queue named "MATRIX"r  M Perhaps DCPS could automatically define logicals to indicate the type/name ofRJ printer, as well as another logical that points to the PPD file associated with that printer.  I This would at least make it possible for the applications that need to it  access the information.R   ------------------------------  # Date: Thu, 09 Aug 2001 10:30:38 GMT.& From: "Ken Farmer" <kfarmer@tru64.org>- Subject: Re: Terry Shannon Tech Talk on Tru64 @ Message-ID: <iDtc7.107157$TM5.15799642@typhoon.southeast.rr.com>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messageeF news:rdeininger-0808012318320001@user-2iveb8l.dialup.mindspring.com...? > In article <2de05464.0108081502.56624985@posting.google.com>, 6 > utlonghornsrule@yahoo.com (Newbie JrSysAdmin) wrote: >R > > ">% > > > Copyright 2001 Terry C. Shannon : > > > Not affiliated with ... Compaq Computer Corporation. > >iH > > lackey, do you even know what a good hotel room in anaheim costs, or5 > > did your "non-affiliate" take care of it for you?( >L8 > What's happened to people's manners in this newsgroup? >- > -- > Robert Deininger > rdeininger@mindspring.comr    F Plus he's/she's hiding in the shadows behind some alias.  Come out Jr.   -- Ken Farmer, kfarmer@tru64.orge Tru64.org, http://www.tru64.org3 Tru64.org Newsletter: < http://www2.tru64.org/pages.php?page=Newsletter-Registration   ------------------------------  % Date: Wed, 08 Aug 2001 23:18:30 -0400s2 From: rdeininger@mindspring.com (Robert Deininger)- Subject: Re: Terry Shannon Tech Talk on Tru64nL Message-ID: <rdeininger-0808012318320001@user-2iveb8l.dialup.mindspring.com>  = In article <2de05464.0108081502.56624985@posting.google.com>,-4 utlonghornsrule@yahoo.com (Newbie JrSysAdmin) wrote:   > "> r# > > Copyright 2001 Terry C. Shannon 8 > > Not affiliated with ... Compaq Computer Corporation. > F > lackey, do you even know what a good hotel room in anaheim costs, or3 > did your "non-affiliate" take care of it for you?h  6 What's happened to people's manners in this newsgroup?   -- r Robert Deininger rdeininger@mindspring.come   ------------------------------   Date: 9 Aug 2001 15:19:01 -0000e4 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>- Subject: Re: Terry Shannon Tech Talk on Tru64 6 Message-ID: <20010809151901.22298.qmail@nym.alias.net>  " -----BEGIN PGP SIGNED MESSAGE-----  C On 8 Aug 2001, utlonghornsrule@yahoo.com (Newbie JrSysAdmin) wrote:r >"> " >> Copyright 2001 Terry C. Shannon7 >> Not affiliated with ... Compaq Computer Corporation.  >AE >lackey, do you even know what a good hotel room in anaheim costs, ory2 >did your "non-affiliate" take care of it for you?  ; Does Enron Corp know that you make abusive posts on usenet?   7 Google offers no protection against things like this...P  M http://visualroute.ipartners.pl:81/?go=192.152.140.9&submit=VisualRoute+TraceD     Doc. - -- G6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.netg   -----BEGIN PGP SIGNATURE-----e Version: 2.6.2  @ iQEVAwUBO3HEcsriC3SGiziTAQFYvAf+LQBOf2+e44cv0+NozgO+R//3YLk3MVHF@ rjlzzDgF4C5MrYoD2GTnLE2DBSyUiVmXjzWLZun9D/DfXsfe26D29NG71QR7oWP9@ rLMG9ZkV6mwROERKm+I9v102Qp7eE9ID9KcQFfasGFq2LjcDan8PpIHrpkV6rVTE@ I7VSjXnHwspqoOHB166t5XJNpgxqh5zsns+SA58xNPUUCrAjtDr7qWjnM+Wi9WP0@ Havd2ZZujui/10GrweNp3Vde2HwzY05UTCY8NEh1TK1/o7oq6hUY4vzq+hmGB88H8 xcisSVD9pETjuQSnQlrB9hpQdJhPzAeidbSh8qzUUSjZA3Yd/fb2Xg== =EWWct -----END PGP SIGNATURE-----d   ------------------------------  % Date: Thu, 09 Aug 2001 09:52:07 -0500g0 From: Patrick Spinler <spinler.patrick@mayo.edu>/ Subject: Re: The VMS Opensource Porting Projectm( Message-ID: <3B72A397.E046F631@mayo.edu>  ' One request and one bit of information:l  F My request is that you place the sources somewhere where the communityE (me, for example :-) ) can easily access and review them, even duringhG the middle of the actual porting.  It'd be a lot easier to make helpfuleA suggestions to your students if we can see what they're doing.  Io: suggest using sourceforge with their anonymous cvs access.  E My other thought is to recommend the people who frequent the vms-perleE mailing list (vms-perl-request@lists.perl.org) as folks with a lot ofeF knowledge of porting big unixy applications (perl) to vms.  Approached@ nicely, I'm certain many of them would be willing to help answer specific questions.0   Good luck !  -- Pat   Bill Gunshannon wrote: > F > It looks like this project, which saw much discussion here, is goingG > to go forward afterall.  I am writing up project proposals right now. G > For a start I am looking at finding students willing to try ports of: 	 >   PDKSH:D >   XRN (based onthe most current Unix sources as suggested by Hoff); >   LYX (a word processor like program that uses Tex/Latex)c > G > Any other suggestions, as we still have a lot of students who haven'toK > picked a project yet??  (not Emacs, these are undergrads, not prodigies.)  > I > And, on another note, I am trying to gather sources of information theycG > are likely to need.  In the heat of the last discussion a book named,aF > "UNIX OpenVMS Compatibility book" was mentioned.  Does anyone have aD > copy of this book they would be willing to send me??  (Hoff, is itI > perhaps available from Compaq??)  Are there any other books that peoplelJ > could send here that I could put into the department library for the useL > of students doing these ports??  Anybody have URLs of sites with info that > might prove usefull??f > H > I am really getting psyched about this now and plan to do everything IH > can to make it not only be a success this semester, but hopefully makeH > it generate the kind of projects the students want so that more can beF > done every year. There is also a possibility of this leading to someG > grad school projects which could tackle the larger packages.  It willr* > all depend on how it goes this semester. >  > 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>   -- -?       This message does not represent the policies or positionse1 	     of the Mayo Foundation or its subsidiaries. 3   Patrick Spinler			email:	Spinler.Patrick@Mayo.EDUe'   Mayo Foundation			phone:	507/284-9485v   ------------------------------   Date: 9 Aug 2001 14:37:12 GMTl1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) + Subject: The VMS Opensource Porting Project , Message-ID: <9ku76o$2ggt$1@info.cs.uofs.edu>  D It looks like this project, which saw much discussion here, is goingE to go forward afterall.  I am writing up project proposals right now.2E For a start I am looking at finding students willing to try ports of:i   PDKSHfB   XRN (based onthe most current Unix sources as suggested by Hoff)9   LYX (a word processor like program that uses Tex/Latex)e  E Any other suggestions, as we still have a lot of students who haven'tdI picked a project yet??  (not Emacs, these are undergrads, not prodigies.)o  G And, on another note, I am trying to gather sources of information theyaE are likely to need.  In the heat of the last discussion a book named, D "UNIX OpenVMS Compatibility book" was mentioned.  Does anyone have aB copy of this book they would be willing to send me??  (Hoff, is itG perhaps available from Compaq??)  Are there any other books that people H could send here that I could put into the department library for the useJ of students doing these ports??  Anybody have URLs of sites with info that might prove usefull??o  F I am really getting psyched about this now and plan to do everything IF can to make it not only be a success this semester, but hopefully makeF it generate the kind of projects the students want so that more can beD done every year. There is also a possibility of this leading to someE grad school projects which could tackle the larger packages.  It willp( all depend on how it goes this semester.   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>   c   ------------------------------  % Date: Thu, 09 Aug 2001 10:15:14 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> $ Subject: Re: Third postcard from Sun) Message-ID: <3B724692.9DFF150E@gtech.com>    Bill Todd wrote:9 > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message $ > news:3B710FB0.86713E3@gtech.com...F > > My guess would be that most posters has not explicit stated any of > > theese.o > > K > > If someone says "I would like to see VMS on Intel" it is pretty open tomE > > be interpreted as "add" or "replace" depending on what the readert
 > > wants. > M > I think not.  Virtually every request for VMS on Intel was for VMS on IA32,aJ > which I doubt anyone believes would be a suitable replacement for VMS on > Alpha.  " You do not see it the Compaq way !   1) Customers want VMS on IA-32 2) IA-32 can not replace Alpha< 3) Compaq do not want to spend money on both IA-32 and Alpha# 4) Intel say "IA-64 replaces IA-32"h& 5) Intel say "IA-64 can replace Alpha" 6) Compaq ....  ? You may disagree on several of their assumptions, but obviously38 Compaq makes decisions based on what they think is true.   Arne   ------------------------------  % Date: Thu, 09 Aug 2001 10:20:18 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>l$ Subject: Re: Third postcard from Sun) Message-ID: <3B7247C2.65965467@gtech.com>u   Bill Todd wrote:H > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:xI3TUzd2W+hp@eisner.encompasserve.org...a > > Or what Compaq can afford. > K > Given what dropping Alpha is likely to cost Compaq over the 3 years or so L > before the port generates a single penny of compensating revenue (not thatM > even at that point the compensation will likely be anything like complete), I > the course upon which Compaq has embarked just about has to be the mostaH > expensive course it possibly could have chosen (at least compared withG > alternatives such as maintaining the status quo and its stable profit H > stream, or doing that plus really starting to market and develop AlphaE > products, especially VMS, so as to grow that profit stream - which,tL > incidentally, would have made *adding* IA64 support to VMS fit right in as  > part of that growth strategy).   I agree on that.  @ The way the decision was made and the way it was announced was a disaster for the VMS market.  A But I think it has to do with the "PC mentality". In the PC worldd> it is good to make bold modes and make incompatible technology= switches if it makes good PR. VMS customers on the other side ; are more like IBM customers. They want smooth evolution and0 emphasizes compatibility.e   Arne   ------------------------------  % Date: Thu, 09 Aug 2001 12:43:20 +0100,( From: Nic Clews <sendspamhere@127.0.0.1>$ Subject: Re: Third postcard from Sun( Message-ID: <3B727758.B2642BA@127.0.0.1>   unix wrote:  > H > I have learned that Compaq is nearing their last Alpha series and willJ > change to Intel Titanium.  Not sure what they will call the server.  The1 > last Alpha series is on the assembly bench now.   E I only just read this. I'll refrain from using an expletive, but youra& statement is wrong, in  many respects.  G Please provide a reference (name/phone number/website) for the "...haveo" learned that Compaq..." statement.  H I can categorically, even as a "mere customer", tell you that the 'last'B Alphaservers are not on the "assembly bench now", and you ought to? familiarise yourself with the 1 GHz EV6 and future EV7 systems.9  H I'd personally be very worried if I depended on decisions you make based; on what little information you're prepared to make them on.e   -- g( Regards, Nic Clews CSC Computer Sciences nclews at csc dot coma   ------------------------------    Date: 09 Aug 2001 09:25:46 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>F$ Subject: Re: Third postcard from SunH Message-ID: <y48zgtd79g.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:s  I > That one-time 'wad of cash' would have to be at least in the $5 billionyK > range to be anywhere nearly large enough to compensate for taking a majoroM > hit in the well over $1 billion in lost annual Alpha-related *profit* (even L > with the current anemic marketing efforts - and a good deal more if CompaqF > had decided to try to make Alpha the centerpiece it deserved to be).  M BTW, from that DFWLUG event in March, there was a presentation by a guy namedbK Colarusso. It contained a pie chart stating the revenue of NSK ($2B), Tru64e: ($3B) and VMS ($4B), as well as ISSG ($4B as well, IIRC).    	Jan   ------------------------------  $ Date: Thu, 9 Aug 2001 12:30:14 -0400; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>D) Subject: Re: UNIX-cd product distributions$ Message-ID: <3b72baf7$1@news.si.com>  1 First, do not post HTML to the comp.os.vms group.b  E >HAve    compaq/dec software product library and documentation libraytL product distribution cd's fot the last seversl years for Unix >and True 64 -1 free if anyone interested email me cleaning house   I Of course, you realize it is illegal, based on the license agreement your", company signed, to give these to anyone, no? --A Brian Tillman                   Internet: tillman_brian at si.comaA Smiths Aerospace                          tillman at swdev.si.comh= 3290 Patterson Ave. SE, MS      Addresses modified to preventt< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Thu, 09 Aug 2001 13:30:00 +0200c+ From: Andreas Nastke <nastke@gdp-group.com>a. Subject: Re: Variable length records - example- Message-ID: <3B727438.5745A31F@gdp-group.com>t   the following works for me:   : 	fopen(outfilename, "w", "rfm=var", "rat=cr", "mrs=32000")     Luke Tucker schrieb: > A > I've been scouring the internet in search of a basic example of-G > setting up a variable length record file using FAB$B_RFM = FAB$C_VAR.cD > I am working on a system (written in c) which currently uses fixedH > length records that contain an array of parameters. Each record is setF > up with a fixed array with the maximum number of parameters in each.F > This wastes a huge amount of space so I want to change the system toF > work with variable length records. The old fixed length record files# > are not required to be converted.e > 9 > Can anyone point me in the direction of a good example?s >  > Thanks >  > Luke   ------------------------------  $ Date: Wed, 8 Aug 2001 09:24:44 -04005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> F Subject: Re: very nice message also room for feedback on this web site2 Message-ID: <mXac7.711$Yx2.18032@news.cpqcorp.net>  G Let me clarify things a bit.  OpenVMS has been involved with the JSTARS J program since about 1990.  Originally it was deployed on militarized AlphaI workstations and VAX servers.  The announcement from Northrop/Grumman was,K the delivery of the first "upgraded" aircraft, which uses ES40's to replace < all of the VAX and Alpha systems from the original aircraft.  K The JSTARS aircraft was used in desert storm (stormin Norman used a blow upsF of a JSTARS screen to show the battlefield).  It is highly successful,G really cool, and aside from some of the signal aquisition stuff, is VMSi) based - including the graphical displays.o  G The story here is the delivery of the first retrofitted aircraft to therF government, and the continued - and expanding - role of OpenVMS in theL military and civilian government (both US and foreign).  The actual hardwareK is just a part of the story.  When we add IPF as a new OpenVMS platform, wemI expect this to continue - it is OpenVMS by-and-large, which is what sellss these systems.   ------------------------------  $ Date: Thu, 9 Aug 2001 11:36:05 -0500  From: norm.raphael@jamesbury.com! Subject: Re: VMS 7.3 experiences?r4 Message-ID: <C2256AA3.005AF90D.00@jklh22.valmet.com>  I Given the messages in this tread and the need to upgrade to support fibree channel,J I am beginning to conclude that V7.2-1 for VAX and Alpha would be the best choiceK over V7.3 for VAX and Alpha.  This is a production cluster and I sense thatR	 there are- still unplumbed risks in V7.3.  + Anyone care to argue (in the formal sense).e   -Norme        / djesys.nospam@fsi.net on 08/07/2001 09:05:39 PM6  ' Please respond to djesys.nospam@fsi.nett   To:   Info-VAX@mvb.saic.comb cc:e" Subject:  Re: VMS 7.3 experiences?         Mark Daniel wrote: >nD > "Beware the Ides of XFC" lest your RMS integrity die an unpleasant > death. > [snip]: > Moral of the story; at least wait for Service Pack 1 ;^)  C Now you know why I refer to "General Availability" as "Gamma Test".C   -- David J. Dachterai dba DJE Systemso http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/s   ------------------------------   Date: 9 Aug 2001 12:56:37 GMT ) From: leslie@clio.rice.edu (Jerry Leslie) ! Subject: Re: VMS 7.3 experiences?i' Message-ID: <9ku1a5$792$1@joe.rice.edu>l  0 Mark Daniel (mark.daniel@wasd.vsm.com.au) wrote:; : YMMV?  (sorry, I always hate to admit being monolingual).. :, Your Mileage May Vary    ------------------------------  $ Date: Thu, 9 Aug 2001 13:46:09 -0300+ From: <fabio_compaq@ep-bc.petrobras.com.br> ! Subject: Re: VMS 7.3 experiences?0L Message-ID: <OF1AF44D29.AB69DCCD-ON03256AA3.005BC878@ep-bc.petrobras.com.br>   Wow !c  K I am planning to migrate to OpenVMS 7.3 as soon as possible (for me betweenm 2-3 months).I I have two Alpha 4100 5/600 (non clustered). Did anyone  have problems ino similar systems ?NB But there is a homologated version to work with EMC Symmetix (OVMS 7.2-1H1). This is thed fresh one !p  I PS: I received the "Sun Box" with OpenVMS manuals this week, but, withouto the CD-ROMs.J People from Compaq Brazil said to me that someone at the airport liked the "wallet" ..... Incredible no ?    Regards    FC        V                                                                                       V                     norm.raphael@jam                                                  V                     esbury.com              Para:   Info-VAX@Mvb.Saic.Com             V                                             cc:                                       V                     09/08/2001 13:36        Assunto:     Re: VMS 7.3 experiences?     V                     Responder a                                                       V                     norm.raphael                                                      V                                                                                       V                                                                                                   I Given the messages in this tread and the need to upgrade to support fibree channel,J I am beginning to conclude that V7.2-1 for VAX and Alpha would be the best choiceK over V7.3 for VAX and Alpha.  This is a production cluster and I sense thatO	 there areo still unplumbed risks in V7.3.  + Anyone care to argue (in the formal sense).W   -NormZ        / djesys.nospam@fsi.net on 08/07/2001 09:05:39 PME  ' Please respond to djesys.nospam@fsi.netP   To:   Info-VAX@mvb.saic.comu cc:0" Subject:  Re: VMS 7.3 experiences?         Mark Daniel wrote: >nD > "Beware the Ides of XFC" lest your RMS integrity die an unpleasant > death. > [snip]: > Moral of the story; at least wait for Service Pack 1 ;^)  C Now you know why I refer to "General Availability" as "Gamma Test".e   -- David J. Dachterar dba DJE SystemsD http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/p   ------------------------------  # Date: Thu, 09 Aug 2001 05:53:08 GMTn, From: "Laurie Knepper" <lknepper@cfl.rr.com>0 Subject: VMS Seminar for "Experienced Beginners"= Message-ID: <8zpc7.12706$eg1.3057584@typhoon.tampabay.rr.com>s  L New to VMS?  If any of you visiting this newsgroup are VMS beginners but areI experienced in other operating systems,  there's a seminar coming up in apE couple of weeks that may be of interest to you.  We're having a 2-daytE pre-symposium "bootcamp" seminar on September 8-9 in conjunction withaL CETS2001 (the Compaq Enterprise Technical Symposium) in Anaheim, California,L titled "OpenVMS Systems Management 101 Bootcamp: An Intro for the Windows NT / UNIX Administrator."  J Abstract:  This bootcamp provides computer professionals familiar with theJ Windows NT or UNIX operating systems a tour of OpenVMS and OpenVMS systemsC management. By comparing and contrasting OpenVMS to the NT and UNIXsL operating systems, seasoned professionals will apply their current knowledgeH of concepts and strategies to learn the specifics of OpenVMS. DiscussionL includes user interface topics (commands and special functions, editors, theL user process), directory navigation and file manipulation, system managementI utilities, networking options, memory organization and management, systemhF processes and operations, resource management, print and batch queues,K security considerations, and clustering. Although an OpenVMS system manageroL cannot be completely "trained" in two days, attendees are exposed to the allK the primary planning and operational aspects of OpenVMS systems management,tI and provided with guidelines and rules-of-thumb to get started. AttendeesoG learn the topic areas in which they need to concentrate their continuednH study, and how to take advantage of the vast resources available to help7 them expand their OpenVMS systems management knowledge.t  K The prerequisite is systems management/administration experience in Windowse NT or UNIX operating systems.i  K To register for this bootcamp seminar or for the CETS2001 conference (whichgF will have many sessions and workshops dealing with VMS in introductory1 through advanced levels), visit www.cets2001.com.m   ------------------------------  % Date: Wed, 08 Aug 2001 21:37:34 -0500n1 From: "David J. Dachtera" <djesys.nospam@fsi.net>y Subject: Re: vmstar questionse' Message-ID: <3B71F76E.7B74BF79@fsi.net>l  ! jamese@beast.dtsw.army.mil wrote:d > E > "John McDen" <jj@jj.moc> wrote on Wed, 8 Aug 2001 11:52:58 -0400 ino" > <9krnl9$nge$1@bob.news.rcn.net>: > : > > Could somebody tell me what does this errors in vmstar > > means, I really don't- > > understand what this means.  > >0 > > 1. tar: error in SYS$PARSE.n > > 2. *** skipped  $2$DUA8:% > > [ARCHIVE.ACADDBA.ABFS]10056.OBJ;1n > >     *** unsupported format.g > ' > From the VMS TAR 3.3-9 AAAREADME.TXT:p >  >     Restrictions >     ------------ > K >     Because of diffrences in the Un*x and VMS filesystems, some files may G >     fail to be correctly transferred to/from the tarfile. This can beS >     caused by: > M >     - VMS strong file typing: VMSTAR can only safely tranfer back and forthpK >     VMS "text" files (rfm=vfc or stream_lf with rat=cr) or VMS fixed size G >     record, 512 bytes/record, rat=none files (e.g. .EXE image files).nL >     VMSTAR will skip other file types (this includes .OBJ, they *can't* beD >     archived.  Library files may work, but be cautious with them).  C .%LB files, like .ZIPs and .EXEs, are Fixed-512 and should not be ao problem.   --   David J. Dachteras dba DJE Systemsb http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------   Date: 8 Aug 2001 18:01:42 -0500y9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: Re: Vortex Server3 Message-ID: <qUDVdDMCIrSe@eisner.encompasserve.org>e  h In article <000001c12050$1e0c9c60$100a640a@Patrick.fsc.com.fj>, A Bonaveidogo <Asena@fsc.com.fj> writes:. > This is a multi-part message in MIME format. > - > ------=_NextPart_000_0001_01C120B4.B3417C60T > Content-Type: text/plain;  > 	charset="iso-8859-1"d! > Content-Transfer-Encoding: 7bit  > J > We're using Vortex Server to get data from VMS to Linux.  Can it be used > for Windows? >  n+ > Any idea/suggestions will be appreciated.   < My suggestion would be to avoid posting MIME to comp.os.vms.   ------------------------------  $ Date: Thu, 9 Aug 2001 10:56:51 -0400= From: "Technical Support" <Tech_Support@SoftwarePartners.com>-$ Subject: We've launched TAPESYS v6.0! Message-ID: <3b723268$1@aerostar>o  J I don't mean to spam one of my favorite news groups.  I just thought thereL might be some TAPESYS users out there who would be interested in V6.0.  I amJ particularly proud of the new communications transports that are supportedK such as icc and tcpip.  The database has been revamped and made more objecteK oriented.  Lots of other nice stuff as well, including a simplified install H and automated backup load balancing across drives.  The next phase is to implement a web gui.   Dave  H Software Partners, Inc. is pleased to announce the launch of the TAPESYSJ V6.0 field test. This program makes the first release candidate of TAPESYSI V6.0, as well as that of JB V4.0, available to the public for free 60-dayoL trial. TAPESYS, the OpenVMS Tape Management System, is the premier automatedI tape backup solution for today's enterprise OpenVMS environments. JB, thehJ OpenVMS Jukebox Manager, provides OpenVMS with robust robotic tape library control and media management.s  I Please visit the Software Partners web site to register and download your " free 60-day trial of TAPESYS V6.0.  #     http://www.SoftwarePartners.com0  J For more information about TAPESYS, please visit Software Partners product information page.   8     http://www.SoftwarePartners.com/products/tapesys_vms  % New features in TAPESYS V6.0 include:l  '     VMSINSTAL software installation kite  2     Automated conversion and configuration utility  ?     Improved linking procedures for VAX and ALPHA architecturesk  (     More efficient reformatted databases  H     Communication between internal TAPESYS processes over TCP/IP and ICC( (InterCluster Communication), as well as
     DECnet  C     Integration of our JB database into the master TAPESYS database   2     Improved control of Media Management reporting  F     A new database field to improve management of offsite tape storage  I     A restructuring of the startup procedures for more efficient linking,l+ easier software maintenance and management.a  K     Many new parameters in SETUP.PAR and SETUP_SHIPPED_VERSION.PAR to allowi" better control of features, report     printing and communication  K     Integration of VMS Backup and RMU backup utilities into one easy to usen utility template  1     Improved compatibility with Multi-version RMUe  7     Compatibility with the latest changes to VMS Backupt  L     System backup history files have been reformatted for compatibility with ODS5 filenames  I     A daily checking procedure to ensure that ALL of your disks are beinge	 backed upt       Improved backup scheduling  A     A revamped menu-driven system backup (SBK) template generator   '     Improved diagnostic output controlss  K     New option for a centralized license key directory allowing one license7+ key for multiple Software Partners products     New features in JB V4.0 include:  I     Ability to use the TAPESYS database, its own native database, or botht	 databasesc  E     Automated initialization of volumes in a specified range of slots   J     Automated addition of volumes to the JB native database or the TAPESYS+ database with labels derived from barcodes.p  D     Ability to update a volume's jukebox association on JB CONFIGURE, commands, automating migration of tapes from     jukebox to jukebox  *     JB is now completely written in DEC C.       Improved error handlingc  7     Improved load and eject door and port compatibilityH       New key system  8     New SET JUKEBOX command to modify the jukebox record  <     Improved timing logic for dismounting volumes from drive  )     Vastly improved barcode reading logicC  <     Vastly improved JB CONFIGURE logic for jukebox inventory  :     Improved performance through improved database locking  0     Ability to define allocation order of drives  J     Expanded compatibility with SCSI-2/SCSI-3 and MRU-controlled jukeboxes   ------------------------------  # Date: Thu, 09 Aug 2001 17:21:46 GMTd4 From: LESLIE@209-16-45-102.insync.net (Jerry Leslie)D Subject: Re: You Get What You Pay For, a.k.a., There's No Free Lunch) Message-ID: <KEzc7.5686$%L5.81544@insync>n  & Bill Todd (billtodd@foo.mv.com) wrote: : 8 : "Jerry Leslie" <leslie@clio.rice.edu> wrote in message# : news:9knnao$3n0$1@joe.rice.edu... 4 : > David J. Dachtera (djesys.nospam@fsi.net) wrote:M : > : I get that here on OSR2. I'll leave come back in a couple of hours, tryML : > : open Eudora, Netscape or whatever, and it'll just hang. When I finallyM : > : do get a response to the three-fingered-salute, it says that the system G : > : is dangerously low on resources (whatever TF *THAT*'s supposed toa
 : > : mean!).2 : >2  : > : Micro$hit - Gotta love it! : >lB : > "You're riding with Microsoft, the Firestone of the Internet!" : F : Hardly fair to Firestone, since only a miniscule percentage of their : products are defective.  : F True, perhaps "Yugo" would be better, or some other problematic autos.  H However, the general public would probably take that as a compliment to J Firestone, since they only see the Microsoft ads with the servers humming  away with no one in sight.  E If they happen to work with Microsoft products, they assume that all - software has similar defects.    ------------------------------   End of INFO-VAX 2001.440 ************************