INFO-VAX Thu, 26 Apr 2007 Volume 2007 : Issue 228 Contents: Re: C++ Garbage Collector on VMS? Re: C++ Garbage Collector on VMS? Re: C++ Garbage Collector on VMS? Re: dtlogin and $HOME/.dtsession equivalents? Re: dtlogin and $HOME/.dtsession equivalents? Re: If you live in California, get out now! (Part 2) Re: If you live in California, get out now! (Part 2) Re: Itanium Performance tools Re: Itanium Performance tools Re: Itanium Performance tools Re: Itanium Performance tools Re: Itanium Performance tools Re: Itanium Performance tools Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers Re: Medical software vendor says it won't support OS on Itanium-based servers se Re: Medical software vendor says it won't support OS on Itanium-based servers se Re: Medical software vendor says it won't support OS on Itanium-based servers se Re: Neocons destroying America Re: Neocons destroying America Re: Neocons destroying America Re: Neocons destroying America (was: Democrats destroying America) Re: OpenVMS Boot Camp Confusion Re: OpenVMS Boot Camp Confusion Re: Set terminal/inquire in SYLOGIN Re: Set terminal/inquire in SYLOGIN Re: Set terminal/inquire in SYLOGIN Re: Set terminal/inquire in SYLOGIN Re: Set terminal/inquire in SYLOGIN Re: VMS Alpha to Itanium port Re: VMS Alpha to Itanium port ---------------------------------------------------------------------- Date: Thu, 26 Apr 2007 08:08:27 -0600 From: "Michael D. Ober" Subject: Re: C++ Garbage Collector on VMS? Message-ID: <4630b25c$1$501$815e3792@news.qwest.net> "sol gongola" wrote in message news:gC2Wh.5$lm5.1@newsfe12.lga... > Arne Vajhøj wrote: >> Tom Linden wrote: >>> On Wed, 18 Apr 2007 17:18:57 -0700, Arne Vajhøj wrote: >>>> Tom Linden wrote: >>>>> I believe the first use of ref counts was in a paper by Freiburghouse >>>>> on >>>>> the Multics PL/I compiler, ca. 1967. Of course, it didn't have many >>>>> leaks :-) >>>> >>>> If it only uses reference counting it will be definition >>>> have memory leaks. >>> >>> You have a different paradigm in mind, I will find link and post it. >>> This was for a compiler, not interpreter so different rules. When >>> refernece count drops to 0 memory is freed >> >> Yes. >> >> But what does it do when object A point to object B and object B >> points to object A, but nothing else point to A and B ? >> >> Arne > > If nothing points to A or B than both A and B are considered free > and should be garbage collected. > > Otherwise the garbage collection algorithm should be building a map > of referenced items and detect the loop. Depending on the needs of > the application, the loop would either tell the garbage collector that > it should stop the current link thread or it would tell the garbage > collector that there is a problem in the link structure. You just described a basic mark/sweep/compact GC. This is, unfortunately, the only known way a GC can be designed to avoid the self-referencing issue of A -> B and B -> A. The drawback to all current mark/sweep/compact GC is that it must stop all program execution threads to do the mark/sweep/compact processing. This is true for Java and .NET as well as Smalltalk, Lisp, etc. Mike. ------------------------------ Date: Thu, 26 Apr 2007 07:33:23 -0700 From: "Tom Linden" Subject: Re: C++ Garbage Collector on VMS? Message-ID: On Thu, 26 Apr 2007 06:39:38 -0700, Michael D. Ober wrote: > > "Tom Linden" wrote in message > news:op.trc7mhxatte90l@hyrrokkin... >>>>> Actually, no. Many times you allocate memory but don't really know >>>>> when >>>>> the >>>>> last reference to it is released. This happens when a routine >>>>> allocates >>>>> memory and then returns that memory as part of it's result. >>>> >>>> Why can't the caller free the memory? >>> >>> What happens when the caller allocates memory for a node in a b-tree >>> and >>> then adds the node to the b-tree? This is a very, very simple example >>> of >>> why memory management without a garbage collector is prone to leaks and >>> dangling pointers. >> >> I give, what happens and why? >>> >>> Mike. >>> > > Very simply the code that allocates the node doesn't control when it will > get used. If during processing of the tree, a reference to the node is > created and handled by a different thread but the primary thread (the one > processing the tree) deletes the node from the tree and then deallocates > the > memory, the second thread that is handling the actual node processing > will > either crash or have to handle a dangling pointer situation (the original > node is gone and possible overwritten). Before you say this doesn't > happen, > it does. I have a program that for performance reasons has split the > actual > node processing apart from the node creation. The node creator creates > nodes about 10 times as fast as they can be processed and puts them in a > queue to be processed by another thread. I did this because there is a > limited time window in which to gather the information required for the > data > collection, but the processing of the data can take as long as > required. On > top of this, there is a final pass that cleans up the target data area > and > it depends on the existence of the nodes created during data gathering. > Thus there are two threads, running asynchronously that require the > nodes be > available. The order of node handling is non-deterministic, making it > extremely difficult to predict when a node is no longer required. > Having a > Garbage Collector is the only real way to do this without cluttering the > program with memory management code. But presumably, once you have processed the node you could free it? Otherwise how do you know when to run the garbage collector? > > Mike. > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Thu, 26 Apr 2007 10:54:22 -0600 From: "Michael D. Ober" Subject: Re: C++ Garbage Collector on VMS? Message-ID: <4630d93b$0$497$815e3792@news.qwest.net> "sol gongola" wrote in message news:ve3Yh.276$fG7.70@newsfe12.lga... > Michael D. Ober wrote: >> "sol gongola" wrote in message >> news:cLoVh.1$vp2.0@newsfe12.lga... >>> Of course, your lisp machine is probably being designed to not have a >>> maximum memory limitation. That complicates things. The original lisp >>> died when you ran out of memory. >>> >> >> This is what led to the creation of the first garbage collector. >> >> Mike Ober. > > It died when the GC couldn't recover enough memory to continue :) > What I meant was that the available list structure space was specified > in the program source as a contiguous block of memory (early 1960's OS). > Still will - running out of address space is a guaranteed way of killing an application that isn't coded to handle this situation. > I don't know what it does today but I would assume that when it ran out > of memory, it would request another block of memory for the OS and > include that in its available list space. The GC algorithm would be > a little more complicated to handle the non-contiguous memory areas. > > In any case, the GC is not part of the system OS but part of the > application design. MS Research, among others, is working on OS's that handle garbage collection system wide. Obviously these probably won't be real-time systems. Cleaning up leftover resources from applications is not an easy task, and it's even harder to do while the applications are still running. Mike. ------------------------------ Date: 26 Apr 2007 03:19:08 -0700 From: "Bart.Zorn@gmail.com" Subject: Re: dtlogin and $HOME/.dtsession equivalents? Message-ID: <1177582748.054015.58980@t39g2000prd.googlegroups.com> Somewhere in your startup procedures you should call SYS$STARTUP:DECW $STARTUP.COM, most likely from SYS$MANAGER:SYSTARTUP_VMS.COM. The first time you are probably prompted to run AUTOGEN, but once you are past that you shou get the CDE login screen. Once CDE is running, you are on your own. Most VMS diehards do not know very much about the inner workings of CDE. Our VMS intuition does not work there! HTH, Bart Zorn On Apr 26, 12:10 am, Marcin 'Rambo' Roguski wrote: > So I'm having fun with 7.3-1 on my DEC2000/300, but I have a little > question. I managed to customize startup scripts to do my biddings, > but I'm still missing motif (cde) login screen, and can't get > commands to be executed at session start (I only found a way to do > it in DECwindows, by modifying templates)- most notably setting > root window background, but also I'd like to start some gizmos, > like cpu load etc... > > So like in the title, what's the VMS name for dtlogin app, and where > can I put my "user session" scripts? > > Rambo ------------------------------ Date: Thu, 26 Apr 2007 13:36:21 +0200 From: Marcin 'Rambo' Roguski Subject: Re: dtlogin and $HOME/.dtsession equivalents? Message-ID: <20070426133621.72e57e65.m_roguski@yahoo.com> On 26 Apr 2007 03:19:08 -0700 "Bart.Zorn@gmail.com" wrote: > Somewhere in your startup procedures you should call SYS$STARTUP:DECW > $STARTUP.COM, most likely from SYS$MANAGER:SYSTARTUP_VMS.COM. [...] > not know very much about the inner workings of CDE. Our VMS intuition > does not work there! Too bad, because that's where I got :) Yup, Decw$startup is, as name suggests, DECwindows inner guts. I guess the only way to find out is to read all the files and find out... ------------------------------ Date: 26 Apr 2007 05:47:03 -0700 From: genius@marblecliff.com Subject: Re: If you live in California, get out now! (Part 2) Message-ID: <1177591623.475424.197550@u32g2000prd.googlegroups.com> On Apr 25, 1:51 am, "Rudolf Wingert" wrote: > Hello, > > Genius wrotes: > > > > and you will not be in this world when Christ returns if you are not saved > .. you will be in hell ... only those saved will come back and rule with > God on this earth for 1000 years, then God will create a new earth and those > not found in the book of life will be sent to the lake of fire FOREVER .. > <<< > > Don't be afraid. Genius did not read the Wholy Bible in all details. This > 1000 years will be a presentation of Gods idea of life. Every body will see > how good it is. After that every body will get a second chance to accept > Gods law. there are NO second chances ... only the saints return with Christ and rule with Him in His kingdom for 1000 years, then the final judgement and those whose name are not found written in the book of life are cast into the lake of fire ... which book of revelation are you reading? ------------------------------ Date: Thu, 26 Apr 2007 08:49:44 -0700 From: David Mathog Subject: Re: If you live in California, get out now! (Part 2) Message-ID: genius@marblecliff.com wrote: > there are NO second chances ... only the saints return > with Christ and rule with Him in His kingdom for 1000 > years, then the final judgement and those whose name > are not found written in the book of life are cast into the > lake of fire ... Thorazine ------------------------------ Date: 26 Apr 2007 06:27:33 -0700 From: kenneth.randell@verizon.net Subject: Re: Itanium Performance tools Message-ID: <1177594053.712152.199570@n15g2000prd.googlegroups.com> On Apr 26, 5:01 am, "pin...@gmail.com" wrote: > I'm trying to get greater speeds from our VMS application running on > Itanium. I've had moderate success going from using the lock manager > (sys$enqw) to using spinning bitlocks, but feel there is more to be > gained in other areas too. However, PCA does not have system service > analysis implemented on Itanium and when I use PCA to analyse > processor time in functions, 90% is spent in "SYSTEM$SPACE", which > doesn't tell me a great deal. > > So, does anyone have any recommendations/suggestions on application > performance analysis tools that work on Itanium, please? I'm using VMS > v8.3 (ia64) with PCA v4.9. How about using SDA extensions ??? $ MCR SDA * SDA> PRF LOAD Others may be of interest -- IO, SPL, LCK, etc. depending on what exactly you are looking for ------------------------------ Date: Thu, 26 Apr 2007 15:38:27 +0200 From: Jur van der Burg <"vdburg at hotmail dot com"> Subject: Re: Itanium Performance tools Message-ID: <4630ab8d$0$331$e4fe514c@news.xs4all.nl> Don't forget the FLT alignment fault SDA extension (since V8.3 (or was it 8.2?)). Jur. pinton@gmail.com wrote, On 26-4-2007 11:01: > I'm trying to get greater speeds from our VMS application running on > Itanium. I've had moderate success going from using the lock manager > (sys$enqw) to using spinning bitlocks, but feel there is more to be > gained in other areas too. However, PCA does not have system service > analysis implemented on Itanium and when I use PCA to analyse > processor time in functions, 90% is spent in "SYSTEM$SPACE", which > doesn't tell me a great deal. > > So, does anyone have any recommendations/suggestions on application > performance analysis tools that work on Itanium, please? I'm using VMS > v8.3 (ia64) with PCA v4.9. > ------------------------------ Date: 26 Apr 2007 06:59:49 -0700 From: Ian Miller Subject: Re: Itanium Performance tools Message-ID: <1177595989.131003.168370@s33g2000prh.googlegroups.com> You could look at system service logging http://h71000.www7.hp.com/doc/82FINAL/6549/6549pro_043.html#sys_svc_logging but the best win is usually fixing any unaligned data accesses you have. Do MONITOR ALIGN to see the system wide rate and if it goes up when running your application then use the use the Alignment fault utility to trace them. http://h71000.www7.hp.com/doc/82FINAL/6549/6549pro_030.html#sda_flt ------------------------------ Date: Thu, 26 Apr 2007 11:29:52 -0400 From: John Reagan Subject: Re: Itanium Performance tools Message-ID: Mark Daniel wrote: > HP rx2600 (900MHz/1.5MB) OpenVMS I64 V8.3 > > CUR AVE MIN MAX > > Kernel Fault Rate 1.33 1554.95 1.33 5007.02 > Exec Fault Rate 0.00 0.00 0.00 0.00 > Super Fault Rate 0.00 0.00 0.00 0.00 > User Fault Rate 0.00 1116.18 0.00 3642.80 > > Total Fault Rate 1.33 2671.14 1.33 8553.53 > > I just ran a user mode (only) application (WASD) in serveral different > activities (main image only - no other process(es) involved), exercised > from another system using Apache Bench. Kernel mode faults were > consistently higher than user mode. Super and exec modes consistently > zero (even though RMS calls featured in at least some of the activity). > > What can be inferred from such a snapshot? > > Why not MONITOR ALIGN on Alpha where such issues have been emphasized > from the beginning? > > TIA. 1) Some application is generating alignment faults. 2) Some piece of kernel code is also generating alignment faults. Could be OpenVMS itself (I would call that a bug that we need to fix once we identify the guilty party); could be some piece of your application if you have kernel code. 3) On Alpha, alignment faults are fixed up quickly by the PAL code. Since the PAL code understands the page table entries and has direct access to the machine below OpenVMS, it can quickly fix up the alignment fault and make sure that no other CPU is in the middle of deleting the address space at the same time. On I64 however, all that happens is that the chip interrupts OpenVMS. The OS has to go take some some spinlocks, etc. to prevent other CPUs from playing with the memory in question while the alignment fault is fixed up. On Alpha, an alignment fault might cost 100 instructions give or take. On I64, it could be 10,000 to 15,000 instructions give or take (my SWAG, not really measured with any level of confidence). So you can do things like: 1) Use the SDA FLT extension to figure out which process/image is faulting along with PC values. Using those, plus .MAPs, and .LISs files , you can go back to the source. 2) PCA will collect fault data and plot it for you. 3) The debugger lets you say SET BREAK/UNALIGNED so it will stop at alignment faults. 4) You can call things like SYS$PERM_REPORT_ALIGN_FAULT which will generate messages to SYS$OUTPUT for alignment faults. It is process-wide and will survive image rundown. You have to call SYS$PERM_DIS_ALIGN_FAULT_REPORT (don't get me started on the confusing naming scheme) to turn them off. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: 26 Apr 2007 10:32:43 -0700 From: Bob Gezelter Subject: Re: Itanium Performance tools Message-ID: <1177608763.880761.293040@r30g2000prh.googlegroups.com> On Apr 26, 4:01 am, "pin...@gmail.com" wrote: > I'm trying to get greater speeds from our VMS application running on > Itanium. I've had moderate success going from using the lock manager > (sys$enqw) to using spinning bitlocks, but feel there is more to be > gained in other areas too. However, PCA does not have system service > analysis implemented on Itanium and when I use PCA to analyse > processor time in functions, 90% is spent in "SYSTEM$SPACE", which > doesn't tell me a great deal. > > So, does anyone have any recommendations/suggestions on application > performance analysis tools that work on Itanium, please? I'm using VMS > v8.3 (ia64) with PCA v4.9. I concur with John and the others, alignment faults are a BIG penalty on IA64 and should be completely eligible for removal. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Fri, 27 Apr 2007 04:01:28 +0930 From: Mark Daniel Subject: Re: Itanium Performance tools Message-ID: <1331oltn07hsbbb@corp.supernews.com> John Reagan wrote: > Mark Daniel wrote: > >> HP rx2600 (900MHz/1.5MB) OpenVMS I64 V8.3 >> >> CUR AVE MIN MAX >> >> Kernel Fault Rate 1.33 1554.95 1.33 5007.02 >> Exec Fault Rate 0.00 0.00 0.00 0.00 >> Super Fault Rate 0.00 0.00 0.00 0.00 >> User Fault Rate 0.00 1116.18 0.00 3642.80 >> >> Total Fault Rate 1.33 2671.14 1.33 8553.53 >> >> I just ran a user mode (only) application (WASD) in serveral different >> activities (main image only - no other process(es) involved), >> exercised from another system using Apache Bench. Kernel mode faults >> were consistently higher than user mode. Super and exec modes >> consistently zero (even though RMS calls featured in at least some of >> the activity). >> >> What can be inferred from such a snapshot? >> >> Why not MONITOR ALIGN on Alpha where such issues have been emphasized >> from the beginning? >> >> TIA. > > > 1) Some application is generating alignment faults. > > 2) Some piece of kernel code is also generating alignment faults. Could > be OpenVMS itself (I would call that a bug that we need to fix once we > identify the guilty party); could be some piece of your application if > you have kernel code. No elevated modes, all user. > 3) On Alpha, alignment faults are fixed up quickly by the PAL code. > Since the PAL code understands the page table entries and has direct > access to the machine below OpenVMS, it can quickly fix up the alignment > fault and make sure that no other CPU is in the middle of deleting the > address space at the same time. On I64 however, all that happens is > that the chip interrupts OpenVMS. The OS has to go take some some > spinlocks, etc. to prevent other CPUs from playing with the memory in > question while the alignment fault is fixed up. On Alpha, an alignment > fault might cost 100 instructions give or take. On I64, it could be > 10,000 to 15,000 instructions give or take (my SWAG, not really measured > with any level of confidence). Orders of magnitude at any rate. > So you can do things like: > > 1) Use the SDA FLT extension to figure out which process/image is > faulting along with PC values. Using those, plus .MAPs, and .LISs files > , you can go back to the source. Application mainly doing network and file I/O, along with some internal processing. Approx two minutes duration. SDA> LOAD FLT SDA> FLT START TRACE [do some processing] SDA> FLT STOP TRACE SDA> FTL SHOW TRACE /SUMM Edited results ... Exception PC Count Exception PC 00000000.00147CB0 20520 SDA$SHARE+00147CB0 SDA$SHARE 00000000.00147990 19980 SDA$SHARE+00147990 00000000.001A61D0 9810 SDA$SHARE+001A61D0 00000000.001AB2F0 2978 SDA$SHARE+001AB2F0 00000000.001AB2F1 2978 SDA$SHARE+001AB2F1 00000000.001AB2A0 2161 SDA$SHARE+001AB2A0 00000000.001AB2C0 2161 SDA$SHARE+001AB2C0 00000000.001AB420 2117 SDA$SHARE+001AB420 FFFFFFFF.8049E180 1147 EXE_STD$CARRIAGE_C+00AC0 IO_ROUTINES FFFFFFFF.8049E170 1146 EXE_STD$CARRIAGE_C+00AB0 00000000.0009F580 1140 SDA$SHARE+9F580 SDA$SHARE 00000000.001D6FB1 984 SDA$SHARE+001D6FB1 00000000.001D8410 940 SDA$SHARE+001D8410 00000000.0009F530 760 SDA$SHARE+9F530 00000000.0009F550 760 SDA$SHARE+9F550 00000000.0009F7A0 760 SDA$SHARE+9F7A0 FFFFFFFF.8045A460 700 IOC_STD$SIMREQCOM_C+00910 IO_ROUTINES FFFFFFFF.8045A480 700 IOC_STD$SIMREQCOM_C+00930 FFFFFFFF.804B2D30 600 IO_ROUTINES+94B30 00000000.00142510 590 SDA$SHARE+00142510 SDA$SHARE FFFFFFFF.804B2ED0 500 IO_ROUTINES+94CD0 IO_ROUTINES 00000000.002EE950 497 SDA$SHARE+002EE950 SDA$SHARE FFFFFFFF.804B3D60 400 IO_ROUTINES+95B60 IO_ROUTINES 00000000.001D7081 376 SDA$SHARE+001D7081 SDA$SHARE 00000000.001D7210 376 SDA$SHARE+001D7210 00000000.002EF020 365 SDA$SHARE+002EF020 00000000.002EF020 365 SDA$SHARE+002EF020 8< snip 32 similar entries 8< FFFFFFFF.80141770 6 EXE$PRIMITIVE_FORK_C+00070 SYSTEM_PRIMITIVES_MIN FFFFFFFF.80141771 6 EXE$PRIMITIVE_FORK_C+00071 FFFFFFFF.80142A40 6 EXE_STD$IOFORK_CPU_C+00B60 FFFFFFFF.80142A50 6 EXE_STD$IOFORK_CPU_C+00B70 FFFFFFFF.805B2D51 2 PROCESS_MANAGEMENT+A1E51 PROCESS_MANAGEMENT FFFFFFFF.805B2DB1 2 PROCESS_MANAGEMENT+A1EB1 FFFFFFFF.805B4C90 2 PROCESS_MANAGEMENT+A3D90 FFFFFFFF.805B6B20 2 PROCESS_MANAGEMENT+A5C20 FFFFFFFF.805B19F0 1 PROCESS_MANAGEMENT+A0AF0 FFFFFFFF.805B1A70 1 PROCESS_MANAGEMENT+A0B70 8< snip 16 similar entries 8< Can this be understood in general terms (without needing to be an internals specialist)? > 2) PCA will collect fault data and plot it for you. > > 3) The debugger lets you say SET BREAK/UNALIGNED so it will stop at > alignment faults. > > 4) You can call things like SYS$PERM_REPORT_ALIGN_FAULT which will > generate messages to SYS$OUTPUT for alignment faults. It is > process-wide and will survive image rundown. You have to call > SYS$PERM_DIS_ALIGN_FAULT_REPORT (don't get me started on the confusing > naming scheme) to turn them off. Thanks for the useful explanations. -- So it goes. [Kurt Vonnegut; Slaughterhouse-Five] ------------------------------ Date: 26 Apr 2007 03:11:32 -0700 From: etmsreec@yahoo.co.uk Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: <1177582292.496009.145510@c18g2000prb.googlegroups.com> VMS isn't on a dead end platform. Integrity servers are cheaper than Alpha and they cost less to license and have an easier licensing model than AlphaServers. I can now get a low end Integrity server that's functional (though not fully populated) for less than =A310000. The equivalent Alpha would be twice that price. Steve On 25 Apr, 04:44, JF Mezei wrote: > David J Dachtera wrote: > >> Medical software vendor says it won't support OS on Itanium-based serv= ers > > I am currently having to visit a hospital a lot. And I can tell you that > there is still a HUGE potential market for computerising hospital records. > > Amazing how an IT person notices inefficiencies in a hospital and how > stuff would be better if properly moved to computers. Consider just a > case of a patient moving from a few days stay at emergency ward to a > proper room upstairs. Change of doctor, change of nursing staff. And the > experience of the ER nurses with that patient is essentially lost and > the family is the one who ends up transfering the experience/knowledge > to the new staff. And that is within the same hospital. > > Also, admissions had access to family records and contact numbers, but > the nursing staff didn't since they don't have access to those computers. > > And the next step is inter-hospital/clinic records access. So when a > patient is in hospital with high blood pressure as one of the problem > areas, the doctors there don't immediatly have access to all the blood > pressure readings done in the past elsewhere to provide a baseline of > what is "normal" for that person without other infections etc etc. > > Now, since VMS is on a dead-end platform, it becomes really hard to > pitch a VMS based solution for such a great potential customer that > really needs it. Especially right after the health care system in quebec > suffered a big virus in its windows IT systems. If VMS were on a viable > platform today, they could/should pitch it to the quebec government. But > HP probably knows very well that it is pointless to try to pitch some > IA64 stuff. HP knows IA64 is a liability, and its refusal to admit it > will cost it its enterprise customer base as well a growth potential in > areas where it would be se easy to make huge sales. ------------------------------ Date: 26 Apr 2007 03:29:09 -0700 From: Andrew Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: <1177583349.584409.191080@c18g2000prb.googlegroups.com> On 25 Apr, 02:45, David J Dachtera wrote: > Neil Rieck wrote: > > > Some of you may already be aware of this news item. > > > OpenVMS Apps Face Uncertain Migration Path > > Medical software vendor says it won't support OS on Itanium-based servers > >http://www.computerworld.com/action/article.do?command=viewArticleBas... > > I posted this comment in the article's forum: > > ISV Market Confusion? > Submitted by David Dachtera on April 24, 2007 - 07:59. > > The statement attributed to Mike Nill, that Cerner is looking for strong > movement toward OpenVMS-I64 in the market-at-large echoes comments to me > from an executive at another ISV in the healthcare sector. To me this > indicates that the ISVs are confused about where their market is found. > > To my mind, it would make more sense to first seek direction from the > existing installed base which, so far - based on my participation in > other discussion groups - is over-whelmingly pro-OpenVMS and shows > little or no indication of a desire among the installed base to migrate > to another platform, along with all the costs (hardware/software > replacement, migration, retraining, etc.) and business disruption that > brings with it. > > The only indication I've seen so far of a desire among the installed > base to migrate to another platform seems to come from those sites which > are already max.'ing out 16- and 32-CPU Alpha GS1280s. For such sites, > I64 SuperDomes just won't cut it. > > Information is freely available on the 'net showing that I64 SuperDomes > are almost 50% slower at memory access than Alpha GS1280s. Thus, with > the end of Alpha, HP has nothing competitive to offer in the Enterprise > computing space. > If you wanted to buy a system that is closest to the GS1280 in terms of Memory Bandwidth then the Sun M series boxes would be the most likely choice. BTW I am joking. In reality the SuperDome memory bandwidth is probably not a constraining issue for applications like Cerner which do require good memory bandwidth but not the full capacity of a SuperDome. It is highly likely that current Cerner customers if they are maxing out GS1280's are doing so because they are running out of CPU capacity, the 1.3Ghz CPU's in the GS1280 are no longer very competitive in terms of Integer performance, as an example the latest Itaniums are at least 2x as fast. > I've also been told by the ISVs that HP has come to them - at the > prompting of the OpenVMS user base - pushing Itanium and UX, not > OpenVMS. The trouble there is that since HP has nothing competitive to > offer in the Enterprise computing space as we just saw HP becomes "just > another UN*X vendor" with nothing to differentiate them in the market. > > Thus, the incentive to stay with HP is greatly diminished, given that > offerings from other vendors outperform Alpha EV7z by almost three to > one, while I64 SuperDomes cannot out-perform Alpha EV7z. > In pure memory bandwidth terms the SuperDomes do not outperform the GS1280, however the Itaniums do provide more Interger and FP performance than the EV7z . Regards Andrew Harrison > The market-at-large is not as quick on the uptake of Itanium as with > "x86-64" from both Intel and AMD. So, a strong movement toward > OpenVMS-I64 in the market-at-large is not likely to materialize anytime > soon. This affords the ISVs a chance to cut costs by dropping a platform > viewed by the industry as declining. > > HP's on-going refusal to market their own product (OpenVMS) virtually > assures the outcome we are now seeing. > > -- > David J Dachtera > dba DJE Systemshttp://www.djesys.com/ > > Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/ > > Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/ > > Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/ ------------------------------ Date: 26 Apr 2007 03:44:01 -0700 From: etmsreec@yahoo.co.uk Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: <1177581403.283677.55510@r30g2000prh.googlegroups.com> VMS isn't on a dead end platform. Integrity servers are cheaper than Alpha and they cost less to license and have an easier licensing model than AlphaServers. I can now get a low end Integrity server that's functional (though not fully populated) for less than =A310000. The equivalent Alpha would be twice that price. Steve On 25 Apr, 04:44, JF Mezei wrote: > David J Dachtera wrote: > >> Medical software vendor says it won't support OS on Itanium-based serv= ers > > I am currently having to visit a hospital a lot. And I can tell you that > there is still a HUGE potential market for computerising hospital records. > > Amazing how an IT person notices inefficiencies in a hospital and how > stuff would be better if properly moved to computers. Consider just a > case of a patient moving from a few days stay at emergency ward to a > proper room upstairs. Change of doctor, change of nursing staff. And the > experience of the ER nurses with that patient is essentially lost and > the family is the one who ends up transfering the experience/knowledge > to the new staff. And that is within the same hospital. > > Also, admissions had access to family records and contact numbers, but > the nursing staff didn't since they don't have access to those computers. > > And the next step is inter-hospital/clinic records access. So when a > patient is in hospital with high blood pressure as one of the problem > areas, the doctors there don't immediatly have access to all the blood > pressure readings done in the past elsewhere to provide a baseline of > what is "normal" for that person without other infections etc etc. > > Now, since VMS is on a dead-end platform, it becomes really hard to > pitch a VMS based solution for such a great potential customer that > really needs it. Especially right after the health care system in quebec > suffered a big virus in its windows IT systems. If VMS were on a viable > platform today, they could/should pitch it to the quebec government. But > HP probably knows very well that it is pointless to try to pitch some > IA64 stuff. HP knows IA64 is a liability, and its refusal to admit it > will cost it its enterprise customer base as well a growth potential in > areas where it would be se easy to make huge sales. ------------------------------ Date: 26 Apr 2007 15:34:09 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: <4630c671$1@news.langstoeger.at> In article <1177583349.584409.191080@c18g2000prb.googlegroups.com>, Andrew writes: >In reality the SuperDome memory bandwidth is probably not a >constraining issue for applications like Cerner which do require good >memory bandwidth but not the full capacity of a SuperDome. > >It is highly likely that current Cerner customers if they are maxing >out GS1280's are doing so because they are running out of CPU >capacity, the 1.3Ghz CPU's in the GS1280 are no longer very >competitive in terms of Integer performance, as an example the latest >Itaniums are at least 2x as fast. What I've been told is, that the CPUs are NOT (yet) maxed out, but the alignment fault penalties on the Itanics are killing (CERNER and others). So, it is (still) a memory issue (and the Alpha is still better there). So, statement vs. statement. What is real? -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Thu, 26 Apr 2007 06:40:59 -0700 From: "Tom Linden" Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: On Thu, 26 Apr 2007 06:34:09 -0700, Peter 'EPLAN' LANGSTOeGER wrote: > In article <1177583349.584409.191080@c18g2000prb.googlegroups.com>, > Andrew writes: >> In reality the SuperDome memory bandwidth is probably not a >> constraining issue for applications like Cerner which do require good >> memory bandwidth but not the full capacity of a SuperDome. >> >> It is highly likely that current Cerner customers if they are maxing >> out GS1280's are doing so because they are running out of CPU >> capacity, the 1.3Ghz CPU's in the GS1280 are no longer very >> competitive in terms of Integer performance, as an example the latest >> Itaniums are at least 2x as fast. > > What I've been told is, that the CPUs are NOT (yet) maxed out, but the > alignment fault penalties on the Itanics are killing (CERNER and others). > So, it is (still) a memory issue (and the Alpha is still better there). > > So, statement vs. statement. What is real? > Well that gives credence to the AIX rumour, since Power is essentially byte adressable with one tick penalty for unaligned access, IIRC. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: 26 Apr 2007 08:12:05 -0700 From: BaxterD@tessco.com Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: <1177600325.627335.279090@r3g2000prh.googlegroups.com> On Apr 26, 7:24 am, Neil Rieck wrote: > > If it is true that Cerner is moving to AIX, I'll bet a week's pay that > IBM is behind the scenes with free stuff to sweeten the deal. > > Neil Rieck > Kitchener/Waterloo/Cambridge, > Ontario, Canada.http://www3.sympatico.ca/n.rieck/- Hide quoted text - > ------------------------------ Date: 26 Apr 2007 08:20:32 -0700 From: BaxterD@tessco.com Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: <1177600832.580077.191040@o40g2000prh.googlegroups.com> >On Apr 26, 7:24 am, Neil Rieck wrote: > >If it is true that Cerner is moving to AIX, I'll bet a week's pay that >IBM is behind the scenes with free stuff to sweeten the deal. > >Neil Rieck >Kitchener/Waterloo/Cambridge, >Ontario, Canada. Cerner has had, and has been marketing, an AIX version of their software for ~10 years. The real issue which HP is ignoring (apparently) is that I would expect most OpenVMS clients, if forced to move, would clearly choose AIX over HPUX, simply because it has been out there long enough for a history to exist. I am pretty sure that there is still no "production-ready" version of Cerner's Millennium product to run on HPUX (you are at liberty to decide for yourselves what "Production-ready" means to you). HP seems to thing that OpenVMS loyalty translates into "HP" loyalty. I think they are in for a shocker. Dave. ------------------------------ Date: 26 Apr 2007 10:26:20 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: In article <4630c671$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) writes: > What I've been told is, that the CPUs are NOT (yet) maxed out, but the > alignment fault penalties on the Itanics are killing (CERNER and others). > So, it is (still) a memory issue (and the Alpha is still better there). No, it is a software flaw. The software from Alpha was not adequately converted to Itanium. Converting to a new architecture involves making changes required by the new architecture. In the case of Itanium that means avoiding alignment faults. > So, statement vs. statement. What is real? It sound like Cerner (if they understand the situation) has decided not to put the effort into converting their software. Whether that is because it requires changes to Oracle Classic or to VMS compilers is not clear. ------------------------------ Date: Thu, 26 Apr 2007 08:15:30 -0700 From: "Tom Linden" Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers Message-ID: On Thu, 26 Apr 2007 08:26:20 -0700, Larry Kilgallen wrote: > In article <4630c671$1@news.langstoeger.at>, peter@langstoeger.at (Peter > 'EPLAN' LANGSTOeGER) writes: > >> What I've been told is, that the CPUs are NOT (yet) maxed out, but the >> alignment fault penalties on the Itanics are killing (CERNER and >> others). >> So, it is (still) a memory issue (and the Alpha is still better there). > > No, it is a software flaw. The software from Alpha was not adequately > converted to Itanium. Converting to a new architecture involves making > changes required by the new architecture. In the case of Itanium that > means avoiding alignment faults. I would argue that it is a design flaw of the cpu. > >> So, statement vs. statement. What is real? > > It sound like Cerner (if they understand the situation) has decided > not to put the effort into converting their software. Whether that > is because it requires changes to Oracle Classic or to VMS compilers > is not clear. Is their code written in Cobol? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Thu, 26 Apr 2007 10:33:13 -0500 From: Dave Harrold Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers se Message-ID: <59bv1mF2k6k0sU1@mid.individual.net> Peter 'EPLAN' LANGSTOeGER wrote: > In article <1177583349.584409.191080@c18g2000prb.googlegroups.com>, Andrew writes: >> In reality the SuperDome memory bandwidth is probably not a >> constraining issue for applications like Cerner which do require good >> memory bandwidth but not the full capacity of a SuperDome. >> >> It is highly likely that current Cerner customers if they are maxing >> out GS1280's are doing so because they are running out of CPU >> capacity, the 1.3Ghz CPU's in the GS1280 are no longer very >> competitive in terms of Integer performance, as an example the latest >> Itaniums are at least 2x as fast. > > What I've been told is, that the CPUs are NOT (yet) maxed out, but the > alignment fault penalties on the Itanics are killing (CERNER and others). > So, it is (still) a memory issue (and the Alpha is still better there). > > So, statement vs. statement. What is real? > We'll never know. Cerner will not run in an Integrity server environment to be able to do the comparison. Benchmark numbers (for whatever they are worth) seem to suggest that a 32 core Integrity server will perform as well as or better than a 32 CPU GS1280 in the environment. Currently, that's nothing to get too excited about, but as Integrity is going forward and AlphaServers are not.... Dave Harrold -- Dave Harrold, Lead Software Systems Engineer Aurora Health Care 3031 W. Montana Street Milwaukee, WI 53215 Phone: (414) 647-6204 FAX: (414) 647-4999 Email: David.Harrold@aurora.org http://www.AuroraHealthCare.org ------------------------------ Date: Thu, 26 Apr 2007 11:33:10 -0400 From: John Reagan Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers se Message-ID: Peter 'EPLAN' LANGSTOeGER wrote: > > > What I've been told is, that the CPUs are NOT (yet) maxed out, but the > alignment fault penalties on the Itanics are killing (CERNER and others). > So, it is (still) a memory issue (and the Alpha is still better there). > > You can compile C code with /ASSUME=NOALIGNED_OBJECTS. That should get rid of many alignment faults in C code that assumes it can take any random address and stuff it into a "pointer to int". You'll lose a little performance when the pointer is actually aligned (4 or 5 instructions per access vs 1 instruction per access), but you'll avoid the HUGE overhead of taking the alignment fault. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Thu, 26 Apr 2007 10:37:09 -0500 From: Dave Harrold Subject: Re: Medical software vendor says it won't support OS on Itanium-based servers se Message-ID: <59bv92F2l2e7oU1@mid.individual.net> Neil Rieck wrote: > > If it is true that Cerner is moving to AIX, I'll bet a week's pay that > IBM is behind the scenes with free stuff to sweeten the deal. > Not exactly true. Cerner wants the VMS customers to move to HP-UX. However, a lot of VMS customers are taking this opportunity to look at AIX as they, most probably, have AIX in house already, but not HP-UX. (At least according to the few customers I've talked to). Dave Harrold -- Dave Harrold, Lead Software Systems Engineer Aurora Health Care 3031 W. Montana Street Milwaukee, WI 53215 Phone: (414) 647-6204 FAX: (414) 647-4999 Email: David.Harrold@aurora.org http://www.AuroraHealthCare.org ------------------------------ Date: 26 Apr 2007 01:38:02 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Neocons destroying America Message-ID: <6eTLqzrvnPzt@eisner.encompasserve.org> In article , Dirk Munk writes: > No wonder. Rumsfeld & Cheney c.s. do know how to destroy things with Please do not feed off-topic posts. ------------------------------ Date: Thu, 26 Apr 2007 07:46:06 -0400 From: "Richard B. Gilbert" Subject: Re: Neocons destroying America Message-ID: <463090FE.2090700@comcast.net> Dirk Munk wrote: > Neil Rieck wrote: > >> According to this recent PBS program, the total cost of the war has >> already exceeded US$1 Trillion Dollars. > > > No wonder. Rumsfeld & Cheney c.s. do know how to destroy things with > bombs etc., but they haven't got a clue about rebuilding. If only a > fraction of that US1$ Trillion had been spend on rebuilding the > infrastructure (water & electricity for instance), things might have > been quite different. I seem to recall that the army tried to restore electric power, water, etc, only to find that as fast as they fixed things, people would sabotage the water pumps, steal the carburators off the generators, etc. The invasion was a clueless thing to do and done, of course, cluelessly! What else would you expect from Dubyah and Rummy? I'm sorry I voted for him. My only excuse is that the alternative seemed worse! ------------------------------ Date: 26 Apr 2007 08:30:45 -0700 From: AEF Subject: Re: Neocons destroying America Message-ID: <1177601445.636056.151410@c18g2000prb.googlegroups.com> On Apr 26, 7:46 am, "Richard B. Gilbert" wrote: > Dirk Munk wrote: > > Neil Rieck wrote: > > >> According to this recent PBS program, the total cost of the war has > >> already exceeded US$1 Trillion Dollars. > > > No wonder. Rumsfeld & Cheney c.s. do know how to destroy things with > > bombs etc., but they haven't got a clue about rebuilding. If only a > > fraction of that US1$ Trillion had been spend on rebuilding the > > infrastructure (water & electricity for instance), things might have > > been quite different. > > > > I seem to recall that the army tried to restore electric power, water, > etc, only to find that as fast as they fixed things, people would > sabotage the water pumps, steal the carburators off the generators, etc. It is usually much easier to destroy something than to build it because doesn't really matter exactly how many pieces you blow it up into or what their trajectories are. This is, of course, is a big advantage for the insurgents. [...] AEF ------------------------------ Date: 26 Apr 2007 01:37:20 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Neocons destroying America (was: Democrats destroying America) Message-ID: <3DR1CINaRePT@eisner.encompasserve.org> Is their main weapon off-topic posts ? In article <46300497$0$16292$88260bb3@free.teranews.com>, "Neil Rieck" writes: > According to this recent PBS program, the total cost of the war has already ------------------------------ Date: 26 Apr 2007 06:57:49 -0700 From: Ian Miller Subject: Re: OpenVMS Boot Camp Confusion Message-ID: <1177595869.019148.179430@r35g2000prh.googlegroups.com> http://www.openvmsplanet.org/index.php?s=&c=75&d=&e=&f=&g=&a=1353&w=2 "HP Educational is retiring OpenVMS Bootcamp training. PARSEC Group's last training will be May 14, 2007 for the two week intensive training session - guaranteed to be held." ------------------------------ Date: Thu, 26 Apr 2007 14:08:40 GMT From: Curtis Rempel Subject: Re: OpenVMS Boot Camp Confusion Message-ID: David J Dachtera wrote: > Neil Rieck wrote: >> >> There's a rumour going around about up-and-coming HP "OpenVMS Boot Camp" >> being the last one. >> >> As far as I can tell this is not true but a course by the same name is >> being dropped by Parsec. Don't confuse the two - the HP boot camp course is a 10 day VMS training class offering from HP and Parsec: http://www.hp.com/education/courses/u3585s.html I've taught U3585S and it's nothing like what Sue's boot camp is all about. Now if I could only find the time to make it to Sue's boot camp :-( [ snip ] ------------------------------ Date: 26 Apr 2007 07:32:09 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Set terminal/inquire in SYLOGIN Message-ID: In article <170bb$462fc9e1$cef8887a$3075@TEKSAVVY.COM>, JF Mezei writes: > Bob Koehler wrote: >> when the template tried to pick up the terminal width from the >> UCB's buffer size. >> >> That doesn't always work and the resulting "set terminal" command >> does always clear the screen, wiping out SYS$WELCOME before it can >> be read. >> > That is because some task force formed by a subcommitee working under a > committee of VMS management decided to do a > $SET TERM/INQUIRE/PAGE=xx/WIDTH=xx > /page and /width are nice things to have, if we could get them without clearing the screen then at least they wouldn't cause a problem even though they don't always work. As it is the problem is more painfull than the lack of the times they do work. ------------------------------ Date: 26 Apr 2007 07:36:22 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Set terminal/inquire in SYLOGIN Message-ID: In article , Tad Winters writes: > > I believe it's caused by setting the width. Note that the screen clears even when the width setting is already correct. Typically I log on with a width of 80, the default terminal characteristic is 80, and the /width=80 clears the screen. I thought about looking to see if the width was not changing and leaving out /width in those cases, but since all my users tend to log in with 80 and I have DCL keypad keys defined to quickly change the width it never seemed worth the effort. ------------------------------ Date: 26 Apr 2007 07:38:25 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Set terminal/inquire in SYLOGIN Message-ID: <1BzuzCEUc5$Y@eisner.encompasserve.org> In article <4630084E.4E2EA25C@spam.comcast.net>, David J Dachtera writes: > > I prefer SET TERM/INQ/LINE, and I add /OVER where the TTY default > characteristics have /INSERT set by default (*VERY* irritating!). > I never change the default /over at a system-wide level, but I find it irritating and always change it to /insert in my login.com . I think when people log into VMS it should behave as documented and if I have a different preference that should only affect me. ------------------------------ Date: Thu, 26 Apr 2007 16:36:32 GMT From: Tad Winters Subject: Re: Set terminal/inquire in SYLOGIN Message-ID: koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote in news:lawwDA6myWt0@eisner.encompasserve.org: > In article , Tad > Winters writes: >> >> I believe it's caused by setting the width. > > Note that the screen clears even when the width setting is already > correct. Typically I log on with a width of 80, the default > terminal characteristic is 80, and the /width=80 clears the screen. > > I thought about looking to see if the width was not changing and > leaving out /width in those cases, but since all my users tend to > log in with 80 and I have DCL keypad keys defined to quickly change > the width it never seemed worth the effort. > I believe it's a function of the terminal itself. When it receives the sequence for setting 80 column mode: CSI ? 3 l or 132 column mode: CSI ? 3 h it clears the screen. It's probably been maintained by newer terminals and emulators because the early terminals had that behavior. I'd guess the original terminals were like that for technical/economic reasons. If the Wyse terminals can make that optional, others could as well. If it was an option in any of the terminal emulators I've used, I would have set it. ------------------------------ Date: 26 Apr 2007 09:57:27 -0700 From: tom Subject: Re: Set terminal/inquire in SYLOGIN Message-ID: <1177606647.542395.284420@n15g2000prd.googlegroups.com> On Apr 26, 2:59 am, p...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote: > In article <1177533706.797613.147...@o40g2000prh.googlegroups.com>, tom writes: > > >That means DEC_CRT, Advanced video, etc. doesn't get set. > > Why don't you have a look into SYSGEN (TTY_DEFCHAR and TTY_DEFCHAR2)? > > -- > Peter "EPLAN" LANGSTOEGER > Network and OpenVMS system specialist > E-mail p...@langstoeger.at > A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist Thanks for all the replies. I think I'll just comment out the ourter IF statement, and comment out the /PAGE= and /WIDTH qualifiers. I think that does what I want. ------------------------------ Date: 26 Apr 2007 07:28:02 -0700 From: twnews@kittles.com Subject: Re: VMS Alpha to Itanium port Message-ID: <1177597682.341922.205720@u32g2000prd.googlegroups.com> Chris Townley wrote: > Just suddenly had the concept of porting a legacy in house application > from Alpha to Integrity given to me. > > Currently running VMS 6.2 on Alpha - application consists of some 3500 > modules Basic, with a smattering of C and macro code. This is an > application I know well, and have been maintaining/developing for some > years. However the oprogrammingh tyeam that took it in-house some 12 > years ago is now just me. > > I wont even look at the macro - if it doesnt run out of the box, I > rewrite as required, and there is nothing fancy in the C > > However the main area will be the basic. Has anyone any ideas what > issues are likely? > > TIA > -- > Chris > We just completed porting a huge Basic code base from Alpha to Integrity. Dozens of different programmers have worked on this code over the years, so it had may styles and flavors. The porting effort took around 80 man hours. Not too bad. The code has currently only been ported at the compile, link, and run level. We have not done extensive system testing yet as this was an exploratory port. The 80 hours does not include the time we spent setting up our operating environment (RDB, startup files, logicals, ...). I am sure that after testing we will find a few things to fix, but almost all of our code compiled and linked without change. Thomas Wirt Director of IS Kittle's Home Furnishings Indianapolis, IN ------------------------------ Date: 26 Apr 2007 07:28:44 -0700 From: twnews@kittles.com Subject: Re: VMS Alpha to Itanium port Message-ID: <1177597724.148214.295860@r30g2000prh.googlegroups.com> Chris Townley wrote: > Just suddenly had the concept of porting a legacy in house application > from Alpha to Integrity given to me. > > Currently running VMS 6.2 on Alpha - application consists of some 3500 > modules Basic, with a smattering of C and macro code. This is an > application I know well, and have been maintaining/developing for some > years. However the oprogrammingh tyeam that took it in-house some 12 > years ago is now just me. > > I wont even look at the macro - if it doesnt run out of the box, I > rewrite as required, and there is nothing fancy in the C > > However the main area will be the basic. Has anyone any ideas what > issues are likely? > > TIA > -- > Chris > We just completed porting a huge Basic code base from Alpha to Integrity. Dozens of different programmers have worked on this code over the years, so it had may styles and flavors. The porting effort took around 80 man hours. Not too bad. The code has currently only been ported at the compile, link, and run level. We have not done extensive system testing yet as this was an exploratory port. The 80 hours does not include the time we spent setting up our operating environment (RDB, startup files, logicals, ...). I am sure that after testing we will find a few things to fix, but almost all of our code compiled and linked without change. Thomas Wirt Director of IS Kittle's Home Furnishings Indianapolis, IN ------------------------------ End of INFO-VAX 2007.228 ************************