INFO-VAX Mon, 30 Apr 2007 Volume 2007 : Issue 235 Contents: Re: C++ Garbage Collector on VMS? Re: C++ Garbage Collector on VMS? Re: C++ Garbage Collector on VMS? Re: C++ Garbage Collector on VMS? CHILL Re: CHILL Re: Integrity Pearl Re: Integrity Pearl Re: Integrity Pearl Re: Integrity Pearl Re: Neocons destroying America Paul BEAUDOIN/MDBK/HSBC is out of the office. Re: SNMP agent VAXStation 3100 M38 Re: VMS on a Multia--disk images? ---------------------------------------------------------------------- Date: Sun, 29 Apr 2007 20:21:02 GMT From: "Michael D. Ober" Subject: Re: C++ Garbage Collector on VMS? Message-ID: "Mark Daniel" wrote in message news:1339l9ffq5g0r1f@corp.supernews.com... > Michael D. Ober wrote: >> "Main, Kerry" wrote in message >> news:FA60F2C4B72A584DBFC6091F6A2B8684022F2EDC@tayexc19.americas.cpqcorp.net... >> >> >>>-----Original Message----- >>>From: Michael D. Ober [mailto:"obermd."@.alum.mit.edu.nospam] >>>Sent: April 28, 2007 5:23 PM >>>To: Info-VAX@Mvb.Saic.Com >>>Subject: Re: C++ Garbage Collector on VMS? >>> >>> >> >> >> >> [snip ...] >> >> >> >>>>You didn't answer my first question, which was... >>>>But presumably, once you have processed the node you could free it? >>>> >>>> >>> >>>Actually, since I have to process each node multiple times and they >>>are >>>being processed by different threads, I don't really know ahead of >>>time when >>>the node will be available for reclamation. Even the number of times >>>each >>>node is processed is indeterminate - anywhere from 2 to 52 times per >>>node. >>>When each thread is done with the node, it simply removes it from it's >>>local >>>processing queue. Yes, I could reference count the node as I add and >>>remove >>>it to and from the trees and queues used by the program, but this >>>would >>>clutter the code with memory management features. Even the basic GC I >>>described can handle this better and with less chance of error. >>> >>> >>>>>Mike. >>>>> >> >> >>>Mike, >> >> >>>Something I would like to understand - how did programmers deal with all >>>of this memory reclamation with traditional languages before OO styles >>>of programming were introduced? >> >> >> They did it themselves. Having had to do memory management myself in >> non-GC environments, I can tell you that manual memory management >> increases the time to complete a program as well as the (dramatically) >> complexity of the code. >> >> >>>It seems to me (but willing to be corrected), that all of these GC >>>discussions started when J2EE and .Net OO paradigms were being >>>introduced. >> >> >> GC languages have been around since the late 60s or early 70s. However, >> it wasn't until Java that a fully GC language became popular. Dartmouth >> BASIC had a simple GC for string variables. >> >> >>>I guess I am still grappling to understand why an application needs to >>>worry about memory management in a virtual memory OS design. I can >>>understand this in the case whereby perhaps an OS does not provide >>>virtual memory capabilities, but memory management seems to me the dept >>>of the OS. >> >> >> VMS is the only OS that actually has primitives for OS level memory >> management for an application. Examples of these primitives are the >> LIB$ calls. Now look at the market size for VMS - tiny >> compared to Unix/Linux, Windows, and Mac. Given this reality in the >> market place, programmers have had to worry about memory management >> issues. > > It's interesting that you mention this Michael. > > The WASD server > > http://wasd.vsm.com.au/ > > uses these routines, in part, to address that very issue - having to clean > up memory that has been allocated in an *indeterminate* fashion during > processing. Without it WASD would have needed to explicitly keep track of > every byte allocated (so-to-speak) to ensure that for a long-lived > application like a server, memory did not leak too badly. > > Instead, it uses a number of different VM zones with tailored > characteristics established using LIB$CREATE_VM_ZONE to manage heaps > associated with various activities of the server proper; dynamic strings, > file/data cache, internal data structures, etc. > > However where this really produces dividends is with the independent zone > created for each individual request thread (*not* POSIX threads) that is > initiated (and there can be hundreds of these concurrently). The server > can LIB$GET_VM against each associated zone as the request threads demand > dynamic memory during processing and then in the final stages of request > rundown LIB$DELETE_VM_ZONE to return all those sundry memory chunks to the > process as a single operation. > > This simple and efficient application-level VM management, along with the > routine internal VM zone structure integrity checking (which occasionally > has shown up related bugs in WASD), is an excellent facility! Even very > busy WASD server processes, e.g. Uni Malaga > > http://wasd.vsm.com.au/ht_root/other/can_wasd_handle_the_load.html > > stay up for months, obviously without suffering significant or even > noticable memory leaks, largely due to the utility and integrity of the > LIB$*VM* routines. > > UMA WASD has just recently hit 67 days of uptime (not a record), 89M > requests and 1.02TB traffic; on an average weekday it handles some 1.5M > requests and 18GB data. > > See section "Memory Management" in: > > http://wasd.vsm.com.au/ht_root/src/httpd/readmore.txt > > while the code itself can be found at: > > http://wasd.vsm.com.au/ht_root/src/httpd/vm.c > Note that the WASD server is built on top of the VMS memory management subsystem. As I said, no other OS has OS level GC. Combine this with the tiny VMS market share and you have applications having to do their own memory management. Mike. ------------------------------ Date: Sun, 29 Apr 2007 17:18:55 -0400 From: Bill Todd Subject: Re: C++ Garbage Collector on VMS? Message-ID: Michael D. Ober wrote: ... > VMS is the only OS that actually has primitives for OS level memory > management for an application. Examples of these primitives are the > LIB$ calls. Now look at the market size for VMS - tiny > compared to Unix/Linux, Windows, and Mac. Given this reality in the market > place, programmers have had to worry about memory management issues. A quick look at the LIB$ VM routines suggests that they don't do anything in the way of GC: they just seem to allow the application to break up its dynamic virtual memory use into multiple heaps and exercise some degree of control over how those heaps are managed (perhaps complete control if it chooses to provide the internal heap-management routines itself). But that doesn't relieve the programmer of deallocation responsibility (nor does it eliminate the potential for memory leaks): it just potentially makes heap management more efficient. VMS is certainly not "the only OS that actually has" such primitives. Windows applications have been able to create and use multiple heaps since NT. Even NT heaps used internal allocation-size hierarchies and IIRC look-aside lists for small (often fixed-size) allocations. Win2K and later descendants provide explicit use of the latter (plus other mechanisms) at least for kernel development (though now that I look around they may not have introduced them for application-level heap management). XP introduced the 'low fragmentation heap' for smallish application-level allocations of variable size without requiring explicit definition of multiple lookaside lists. In a more recent post you suggest that VMS *does* provide real GC inside the functions you mentioned earlier (which would seem to be others than the ones I glanced at): if so, then the above comments do not apply, but it would be nice to see a more thorough description of what those GC facilities do. - bill ------------------------------ Date: Mon, 30 Apr 2007 01:35:47 GMT From: "Michael D. Ober" Subject: Re: C++ Garbage Collector on VMS? Message-ID: "Bill Todd" wrote in message news:VLedncNAi-RZlqjbnZ2dnUVZ_oCmnZ2d@metrocastcablevision.com... > Michael D. Ober wrote: > > ... > >> VMS is the only OS that actually has primitives for OS level memory >> management for an application. Examples of these primitives are the >> LIB$ calls. Now look at the market size for VMS - tiny >> compared to Unix/Linux, Windows, and Mac. Given this reality in the >> market place, programmers have had to worry about memory management >> issues. > > A quick look at the LIB$ VM routines suggests that they don't do anything > in the way of GC: they just seem to allow the application to break up its > dynamic virtual memory use into multiple heaps and exercise some degree of > control over how those heaps are managed (perhaps complete control if it > chooses to provide the internal heap-management routines itself). > > But that doesn't relieve the programmer of deallocation responsibility > (nor does it eliminate the potential for memory leaks): it just > potentially makes heap management more efficient. That's unfortunate. > > VMS is certainly not "the only OS that actually has" such primitives. > Windows applications have been able to create and use multiple heaps since > NT. Even NT heaps used internal allocation-size hierarchies and IIRC > look-aside lists for small (often fixed-size) allocations. Win2K and > later descendants provide explicit use of the latter (plus other > mechanisms) at least for kernel development (though now that I look around > they may not have introduced them for application-level heap management). > XP introduced the 'low fragmentation heap' for smallish application-level > allocations of variable size without requiring explicit definition of > multiple lookaside lists. What Windows has had since version 1.0 is the ability for a process to request memory from the system. This memory is added to the process working set and then only reclaimed by Windows when either the process explicitely returns the exact same memory to the system or when the process exits for any reason. XP's "low fragmentation heap" is simply a heap that the OS allocates to the process but never really gives the process the handle to. However, even this heap can fragment and require reallocation because it is not GC'd. > > In a more recent post you suggest that VMS *does* provide real GC inside > the functions you mentioned earlier (which would seem to be others than > the ones I glanced at): if so, then the above comments do not apply, but > it would be nice to see a more thorough description of what those GC > facilities do. > > - bill The VMS calls for tree and node allocation are either working from local process memory, in which case process level GC is still needed, or they are working from OS level memory and adding and removing that memory to the process, in which case the OS must perform some level of GC for the process or it will run out of address space. By the way, the way most OS's do process level GC is by clearing out the page tables and putting those pages back on the master available page table. Mike. Mike. ------------------------------ Date: Mon, 30 Apr 2007 12:06:58 +0800 From: "Richard Maher" Subject: Re: C++ Garbage Collector on VMS? Message-ID: Hi, > > Application A does not care much about whether application B releases > memory to the heap because the programmer put in delete/free calls or > because the runtime environment provides GC. Related to this, and Kerry's "server consolidation" advocacy, is there a Global Heap for every GC and every language that can be running on a server OS? Are there universal OO (de)allocation algorithms/APIs that allow *any* off-the-shelf GC to plug-in and clean-up after Java? Can different applications written Java and C++ (and any other object instantiator) share the same Heap and GC on the same server? It would seem less than optimal for a Java app to have a 2gigabyte heap with it's own resource hungry GC and a seperate 4gigabyte heap for the C++ applications and their own GC and then have Heap-Java maxing out during o/night processing while the Heap-C++ is 90% free, but surely it would be an absolute triumph for cross architecture standardization if it were otherwise? And what about all of the "free" memory in the OS that hasn't been artificially fenced off? Are CPU Class Schedulers also popular on OO systems? VMS does have the Reserved Memory Registry but each reservation is expected to run around 100% most of the time (else make it smaller :-) "I want 1 gig for that database and 4 gig for that database and then autogen so the OS knows how much real memory it has.". Does Windows/Unix know to re-tune/adjust when a given GC has taken a huge chunk of memory? Alternatively, do GCs only cordon off page file quota and *not* physical memory? I am also not suggesting that Rdb or RMS uses lib$*_vm for EXEC heap allocation (although I've said (proved?) before that with minor RTL modifications there is no reason why this should not be the case) but if you're not using a layered software architecture such as that commonly found on VMS where each layer adheres to the uniform heap conventions, then aren't you constraining your servers to hosting only homogenous software? Cheers Richard Maher PS. Slightly related, is a recent performance problem with the freeing of WebBrowser DOM memory via JavaScript. If I had 3000 que entries in my Select List and wanted to free them up before performing the next query then it would take Internet Explorer ~20secs (almost all CPU) just to perform 3000x selectList.remove(n)! People told me not to do the removes but rather just set the Array.length to zero so I did that with no change in performance :-( Then a smart guy called RobG from comp.lang.javascript told me to do a "shallow" clone of the DOM node for the Select List (similar to the following) and now it flies: - selectRef.size = 1; selectClone = selectRef.cloneNode(false); lovHdr = document.getElementById('lovHdr'); hdrClone = lovHdr.cloneNode(true); selectClone.appendChild(hdrClone); selectRef.parentNode.replaceChild(selectClone, selectRef); selectRef = document.getJobs.jobList; The things you have to do to keep this stuff happy eh? Yeah, it does it all for you. . . "Arne Vajhøj" wrote in message news:4634d35b$0$90270$14726298@news.sunsite.dk... > Main, Kerry wrote: > > Something I would like to understand - how did programmers deal with all > > of this memory reclamation with traditional languages before OO styles > > of programming were introduced? > > Languages without dynamic memory allocation: no problems. > > languages with dynamic memory allocation: long debugging sessions to > find the memory leaks, operational procedures to restart the server > every night if the memory leak was not found etc.. > > > It seems to me (but willing to be corrected), that all of these GC > > discussions started when J2EE and .Net OO paradigms were being > > introduced. > > GC is older than those. But it has become mainstream with those. > > > I guess I am still grappling to understand why an application needs to > > worry about memory management in a virtual memory OS design. I can > > understand this in the case whereby perhaps an OS does not provide > > virtual memory capabilities, but memory management seems to me the dept > > of the OS. > > It has nothing to do with the OS. At least not in any real world system. > > The way it works for both non GC and GC languages is: > > * runtime environment allocates memory from the OS > * the app allocates memory from the runtime environment > > GC or non GC is about the last bullet - not about the first bullet. > > > What happens when you start virtualizing the application that depends on > > GC under such environments like VMware (e.g. Windows/Linux) or when you > > start application stacking with other app's on the same system (e.g. > > OpenVMS)? > > Nothing in particular. > > Application A does not care much about whether application B releases > memory to the heap because the programmer put in delete/free calls or > because the runtime environment provides GC. > > Arne ------------------------------ Date: Sun, 29 Apr 2007 11:43:03 -0700 From: "Tom Linden" Subject: CHILL Message-ID: Whatever happened to the CHILL compiler for the VAX? ------------------------------ Date: Sun, 29 Apr 2007 15:21:31 -0400 From: JF Mezei Subject: Re: CHILL Message-ID: <7e311$4634f087$cef8887a$16497@TEKSAVVY.COM> Tom Linden wrote: > Whatever happened to the CHILL compiler for the VAX? Can't resist... It vanished due to global warming. ------------------------------ Date: Sun, 29 Apr 2007 18:30:49 GMT From: "Malcolm Dunnett" Subject: Re: Integrity Pearl Message-ID: "Sue" wrote in message news:1177800020.796953.35930@e65g2000hsc.googlegroups.com... | Dear Newsgroup, | | | Enclosed please find a pearl that I think you may find very useful, | this is some of the OpenVMS on Integrity Servers information that I | thought you would find useful. If you will please note the "with | thanks from openvms.org" you will see several new ports to OpenVMS on | IPF. It's interesting to juxtapose the "good news" about VMS on Itanium with the comments in the "medical software vendor" thread about HP refusing to license GEM to Kednos so that they can port their PL/I compiler to Itanium and the reported impending loss of a couple of large customers (especially when Kednos claims they'd be doing all the work). There are also some interesting allegations there about VMS ISVs who've been approached by HP to port their products to HPUX on Itanium, but not to VMS. ------------------------------ Date: 29 Apr 2007 14:21:30 -0700 From: Sue Subject: Re: Integrity Pearl Message-ID: <1177881690.059117.66480@p77g2000hsh.googlegroups.com> On Apr 29, 2:30 pm, "Malcolm Dunnett" wrote: > "Sue" wrote in message > > news:1177800020.796953.35930@e65g2000hsc.googlegroups.com... > | Dear Newsgroup, > | > | > | Enclosed please find a pearl that I think you may find very useful, > | this is some of the OpenVMS on Integrity Servers information that I > | thought you would find useful. If you will please note the "with > | thanks from openvms.org" you will see several new ports to OpenVMS on > | IPF. > > It's interesting to juxtapose the "good news" about VMS on > Itanium with the comments in the "medical software vendor" thread > about HP refusing to license GEM to Kednos so that they can port > their PL/I compiler to Itanium and the reported impending loss of > a couple of large customers (especially when Kednos claims they'd > be doing all the work). There are also some interesting allegations > there about VMS ISVs who've been approached by HP to port their > products to HPUX on Itanium, but not to VMS. I can not affect what companies do, I have very little influence I am just trying to help where I can. The computer world article regarding Cerner said that they were waiting for customers to send feedback regarding porting to VMS on Integrity, I have provided folks on my email list the names of who to send their cards and letters to. But I am not going to stop sending out information waiting for a particular vendor. I have a job to do. Sue ------------------------------ Date: Sun, 29 Apr 2007 18:04:45 -0400 From: Bill Todd Subject: Re: Integrity Pearl Message-ID: Sue wrote: > On Apr 29, 2:30 pm, "Malcolm Dunnett" > wrote: >> "Sue" wrote in message >> >> news:1177800020.796953.35930@e65g2000hsc.googlegroups.com... >> | Dear Newsgroup, >> | >> | >> | Enclosed please find a pearl that I think you may find very useful, >> | this is some of the OpenVMS on Integrity Servers information that I >> | thought you would find useful. If you will please note the "with >> | thanks from openvms.org" you will see several new ports to OpenVMS on >> | IPF. >> >> It's interesting to juxtapose the "good news" about VMS on >> Itanium with the comments in the "medical software vendor" thread >> about HP refusing to license GEM to Kednos so that they can port >> their PL/I compiler to Itanium and the reported impending loss of >> a couple of large customers (especially when Kednos claims they'd >> be doing all the work). There are also some interesting allegations >> there about VMS ISVs who've been approached by HP to port their >> products to HPUX on Itanium, but not to VMS. > > I can not affect what companies do, I have very little influence I am > just trying to help where I can. I don't think anyone here has any doubts about your dedication, Sue. But if that dedication can't translate into positive action on HP's part, then pointing out their conflicting behavior is also appropriate. It is also sad to see someone so dedicated to a company (or at least to one product of that company) which may quite possibly casually discard her without a moment's notice. Perhaps there really is hope for VMS that you can see and we cannot. If so, it will almost certainly be because of people like you. If not, try not to let your dedication leave you unprepared for what may occur. - bill ------------------------------ Date: Mon, 30 Apr 2007 00:28:56 GMT From: "Malcolm Dunnett" Subject: Re: Integrity Pearl Message-ID: "Sue" wrote in message news:1177881690.059117.66480@p77g2000hsh.googlegroups.com... | I can not affect what companies do, I have very little influence I am | just trying to help where I can. | The computer world article regarding Cerner said that they were | waiting for customers to send feedback regarding porting to VMS on | Integrity, I have provided folks on my email list the names of who to | send their cards and letters to. But I am not going to stop sending | out information waiting for a particular vendor. I have a job to do. Please understand I meant no criticism of the news you sent out, it's vital to show the positive things and I love reading about them and I think you're the best thing for VMS that HP has. I'm just saddened when I hear allegations of HP deliberately driving business away by stonewalling a partner and a couple of large customers (I'm referring to Tom's notes about the PL/I compiler and how VW and FIAT won't buy VMS (or HP) if they can't get PL/I for VMS on Itanium and how HP is refusing his company access to the GEM backend for Itanium that he needs so that he can release said PL/I compiler). The other comments in the thread about HP pushing HP-UX over VMS are equally disturbing - they remind me all too much of the "VMS is dead - migrate to TRU64 Unix" that we used to hear from DEC (look how that all turned out in the end). It's just unfortunate that while there are wonderful people like Sue trying to promote VMS she, and other's like her, seem to be getting sabotaged by other forces within HP. ------------------------------ Date: Mon, 30 Apr 2007 04:27:10 GMT From: CJT Subject: Re: Neocons destroying America Message-ID: <46357053.4030808@prodigy.net> Bill Todd wrote: > Glenn Everhart wrote: > >> Larry Kilgallen wrote: >> >>> 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. >> >> What makes you think George Bush is a conservative? > > > Since the word 'conservative' does not appear in the > immediately-preceding three posts in this sub-thread, I'm wondering > whether this was a subtle attempt at off-sub-topic irony on your part. > > But indeed, Dubya is nothing remotely resembling a traditional > conservative: 'neo'-conservatives have given traditional conservatives > an undeserved black eye (and stomach pains to boot in many cases). > > - bill That said, Dubya IS representative of the Republican Party. In many ways, the Democrats are more conservative (particularly fiscally). -- The e-mail address in our reply-to line is reversed in an attempt to minimize spam. Our true address is of the form che...@prodigy.net. ------------------------------ Date: Mon, 30 Apr 2007 05:05:32 +0100 From: paul.beaudoin@hsbc.com Subject: Paul BEAUDOIN/MDBK/HSBC is out of the office. Message-ID: I will be out of the office starting 30/04/2007 and will not return until 02/05/2007. If urgent please call on 07778 033532 . ----------------------------------------- SAVE PAPER - THINK BEFORE YOU PRINT! This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions. ------------------------------ Date: Sun, 29 Apr 2007 21:25:31 -0500 From: David J Dachtera Subject: Re: SNMP agent Message-ID: <4635539B.7F68090C@spam.comcast.net> apogeusistemas@gmail.com wrote: > > Hi: > Is there any snmp agent to VAX?VMS 5.5-2 ? > > Thanks. Try asking over on vmsnet.networks.tcp-ip.multinet. The reply is cross-posted for your convenience. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://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: 29 Apr 2007 17:35:04 -0700 From: a.drew7@gmail.com Subject: VAXStation 3100 M38 Message-ID: <1177893304.763387.229150@n59g2000hsh.googlegroups.com> I've got a Vaxstation 3100 model 38 that I'm trying to get working. It booted into VMS twice since I acquired it, but a week later it refused to start up. Without a monitor, I can only access it through the serial printer port and a terminal emulator. This is the only output I can get from it:    KA42-B V1.5 ?h?,?...E...D...C...B According to the manual for the Model 76, B is the Memory power-up self-test. I don't know if that is any different for the Model 38. I've left it there for over an hour with no change. The diagnostic lights are lit up like this: 1001 1011 Any ideas? Am I the proud owner of a VAX-shaped paperweight? Thanks, Andrew ------------------------------ Date: 29 Apr 2007 20:19:08 -0700 From: John Subject: Re: VMS on a Multia--disk images? Message-ID: <1177903148.003564.141830@y5g2000hsa.googlegroups.com> On Apr 29, 12:41 pm, Uusim=E4ki wrote: > John wrote: > > On Apr 28, 5:03 am, Uusim=E4ki wrote: > >> You'll find the Multia firmware which is needed for running VMS on a > >> Multia on the VMS Freeware 5.0 CD's or on the 'net at: > > >>http://h71000.www7.hp.com/freeware/freeware50/multia/ > > >> There are also installation instructions. > >> I have managed to install VMS V7.2 out-of-the-box and upgrade to V7.3-2 > >> with some tweaking. It runs fine but slow, as anyone can imagine. > > >> If you plan to use DECwindows, it's best to install at least 128MB of > >> RAM or if you can find 64MB SIMM's, use them. > > >> Don't put a very new disk drive inside the box or you run into trouble > >> with overheating. The original < 1GB disks drives don't produce too mu= ch > >> heat, but a 72GB 15k drive will melt the box. > >> A very nice storage solution for Multia is a BA353 (the pizzabox with a > >> CD drive, one or two disk drives and possibly a (DAT) tape drive. All > >> the 1.6" StorageWorks SBB's will fit into the BA353. You can find a > >> BA353 on Ebay for $10 or less. If you are lucky, it is fully equipped. > > >> I think it would be the best solution to get a bootable installation-C= D, > >> which has the Multia-specific drivers included. I might be able to bui= ld > >> one and send it to you. > > >> Kari > > > At this time, I do not have access to a VMS machine with a floppy. Is > > there a way to write the things you linked from a Linux or Windows > > machine? > > > A bootable install-cd would be nice, if you could build one for me. > > I'm going to try and find an appropriate SCSI CD-ROM drive to slap in. > > If I were to get such a bootable install-cd with Multia drivers, I > > would still need to upgrade the firmware, right? > > Thanks > > > John > > Well, this is a problem, because you need a VMS machine with a floppy > drive to write the files to it. > I'm not aware of any method how to write a VMS backup save set to a > floppy using Linux or Windows. > > I'll make a bootable installation CD and make a copy of the floppy which > you need for the firmware upgrade. Some other Multia-VMS hobbyist might > be interested in those also. > > I'll let you know by email when it is ready. > > Yes, you have to upgrade the firmware to run VMS on Multia, because VMS > will not work with the other firmware versions. The firmware on the > floppy is specially built just for this reason. Thank you very much! I look forward to experimenting with this some more. John ------------------------------ End of INFO-VAX 2007.235 ************************