INFO-VAX Wed, 25 Jun 2008 Volume 2008 : Issue 353 Contents: Re: Book "OpenVMS for Unix Users" Re: Book "OpenVMS for Unix Users" Re: Book: "Writing for the Reader" by John O'Rourke Re: Book: "Writing for the Reader" by John O'Rourke Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: How to transfer complete disk images without using tape Re: On the fly PCSI install needs to update text file on target system systemsys Re: On the fly PCSI install needs to update text file on target system systemsys Re: On the fly PCSI install needs to update text file on target system systemsys Re: On the fly PCSI install needs to update text file on target system systemsys Re: On the fly PCSI install needs to update text file on target system Re: On the fly PCSI install needs to update text file on target system Re: On the fly PCSI install needs to update text file on target system systemsys OT: Tru64 booting Re: OT: Tru64 booting Re: OT: Tru64 booting Re: Tru64 file system source code now open source Re: Tru64 file system source code now open source Re: Virtualized VMS in clusters (general questions) ---------------------------------------------------------------------- Date: Wed, 25 Jun 2008 02:41:33 -0700 (PDT) From: IanMiller Subject: Re: Book "OpenVMS for Unix Users" Message-ID: <48f9a5a0-d77a-416b-af78-35cdf5e97b21@a1g2000hsb.googlegroups.com> On 23 Jun, 16:37, Ralf Folkerts wrote: > Hi, > > while searching for Books that might help me getting into OpenVMS I > found the abovementioned Book "OpenVMS for Unix Users" (ISBN: > 1555583253) from Digital Press. > > However, I was unable to locate a Copy or find a Review. I searched > Alibris and the Sites mentioned in the OpenVMS-FAQ (inkl. elsevier) > amongst googling for it. > > Does anyone have a hint where that book might be available? Or could > anyone either recommend or disadvice that Book? I have been using Unix > (and FreeBSD and Linux) for many years now, so I hope that this book > might help me getting onto track faster... > > Cheers, > _ralf_ In the VMS documentation (http://www.hp.com/go/openvms/doc) the HP OpenVMS Programming Concepts Manual is well worth a read http://h71000.www7.hp.com/doc/82FINAL/5841/5841PRO.HTML ------------------------------ Date: Wed, 25 Jun 2008 18:42:32 +0200 From: Ralf Folkerts Subject: Re: Book "OpenVMS for Unix Users" Message-ID: IanMiller schrieb: [...] > In the VMS documentation (http://www.hp.com/go/openvms/doc) the HP > OpenVMS Programming Concepts Manual is well worth a read > http://h71000.www7.hp.com/doc/82FINAL/5841/5841PRO.HTML Hi Ian, thanks for the Hint! I just downloaded them as PDF so I can read Offline (...however, I think it might be better to read the OpenVMS User's Guide first, then maybe the System Managers Manuals and the continue into Programming... Seems I'll not have a shortage of to-be-read Literature in the near future ;-) Cheers, _ralf_ ------------------------------ Date: 25 Jun 2008 15:41:04 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Book: "Writing for the Reader" by John O'Rourke Message-ID: <6cf78fF3ed75tU1@mid.individual.net> In article <85e5$4861c4da$4c0aab67$960@teksavvy.com>, "John Smith" writes: > If you have a PC or Mac, the Fujitsu ScanSnap S500 or S510 does fantastic > job of double-sided scanning and OCR to .pdf at up to 18 pages/minute. > Resulting .pdf is fully searchable. Runs about $350 with a full Adobe > Acrobat license & OCR software. > > I'm currently scanning old reports I wrote originally on dedicated Wang word > processing machine - still have the 8" floppies but nothing to read them on, > so scanning is the answer. > John, What do you know about the format of those disks? I hae the ability to read Single, Double and Quad density 8" floppies. I have no experience with WANG so I don't know if they did anything "unique" with their floppies (like Apple did with 5.25" floppies). I won't be home till late August but I would be willing to help if I can. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 25 Jun 2008 17:01:58 GMT From: VMS is Virus Free Subject: Re: Book: "Writing for the Reader" by John O'Rourke Message-ID: <9cu4641usedh6tki30a89jrs7jaivgj7av@4ax.com> On Wed, 25 Jun 2008 00:13:03 -0400, "John Smith" wrote: >If you have a PC or Mac, the Fujitsu ScanSnap S500 or S510 does fantastic >job of double-sided scanning and OCR to .pdf at up to 18 pages/minute. >Resulting .pdf is fully searchable. Runs about $350 with a full Adobe >Acrobat license & OCR software. > >I'm currently scanning old reports I wrote originally on dedicated Wang word >processing machine - still have the 8" floppies but nothing to read them on, >so scanning is the answer. > >It even does scanning of tabular data (printed in 6-7 pt. type) into Excel >with perfect accuracy if the scan speed is reduced to about 6 ppm. > >Highly recommended. > > I have a high-end HP scanner with ADF at home with OCR software that does a pretty good job of automatically rotating pages to rightside up, then converting all the scanned pages to readable text with original layout in a Word doc. It would not take long to scan the book and convert if you wouldn't mind parting with it for a week or so. ------------------------------ Date: Wed, 25 Jun 2008 06:02:20 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: How to transfer complete disk images without using tape Message-ID: In article , marlow.andrew@googlemail.com writes: > I am considering how to move a system from an old 4100 to an ES45. Build a cluster, mount all disks on all nodes, and use BACKUP. ------------------------------ Date: Wed, 25 Jun 2008 04:50:25 -0700 (PDT) From: marlow.andrew@googlemail.com Subject: Re: How to transfer complete disk images without using tape Message-ID: <1cc9e4f6-3c14-418b-bca8-f4348c676965@b1g2000hsg.googlegroups.com> JF Mezei wrote: > If you can hook an ethernet cable between the two, you can then make > transfers via: > > -DECNET > You can copy individual files, or send a saveset across ethernet and > unpack it at other end. No. I need to copy 150 GB of data as a set of disk images. One by one file transfers just doesn't cut it. > > -MSCP (would technically require clustering licence). The licensing issue rules it out. > > -FTP or KERMIT See reply for DECNET. > I would not recomment NFS because you get into a lot of reliability > issue sas well as preserving file attributes. Fair enough. ------------------------------ Date: Wed, 25 Jun 2008 04:52:04 -0700 (PDT) From: marlow.andrew@googlemail.com Subject: Re: How to transfer complete disk images without using tape Message-ID: etmsr...@yahoo.co.uk wrote: > On 24 Jun, 10:43, marlow.and...@googlemail.com wrote: > > I am considering how to move a system from an old 4100 to an ES45. The > > 4100 has a disk array with several large disks giving a total capacity > > of around 150 GB. This all has to be transferred to the ES45s. > You don't actually say whether you need disk contents or actually a > disk image. I am not sure that it matters. People on the project talk about transferring a disk image but this may just be loose terminology. > Also, we're assuming that it's an AlphaServer 4100 ? yes. ------------------------------ Date: Wed, 25 Jun 2008 04:56:38 -0700 (PDT) From: marlow.andrew@googlemail.com Subject: Re: How to transfer complete disk images without using tape Message-ID: Jim Mehlhop wrote: > Best solution is definitely high speed ethernet (Gigabit prefered) > clustered and running Volume shadowing, so there is no downtime on the data. The 4100 system does not need to be available to users at the time. So I suggested temporarily unplugging a cable from one of the NICs and plugging in a gigabit hub to connect the 2 machines together. But I wasn't sure what sw to use to do the transfer. Obviously things like FTP are out. I don't know about volume shadowing, I am not a VMS person. -Andrew ------------------------------ Date: Wed, 25 Jun 2008 05:02:46 -0700 (PDT) From: marlow.andrew@googlemail.com Subject: Re: How to transfer complete disk images without using tape Message-ID: <37f448f4-918e-485f-9e8b-f1d0897912a1@y21g2000hsf.googlegroups.com> warren sander wrote: > And one that I don't recommend but for completeness... (again we don't even > know the os versions etc). But you could always setup pathworks/samba and > use drag and drop from share to share. Of course FTP would be more efficent > etc but completeness. I have already suggested that samba might be used but I was not sure about saying that because I don't know if samba is available for OpenVMS. It's v7.2-1 on the 4100 and v7.3-2 on the ES45 BTW. If memory serves, pathworks is some sort of proprietary sw for doing the comms. This reduces the chances due to license costs. ------------------------------ Date: Wed, 25 Jun 2008 12:07:46 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: How to transfer complete disk images without using tape Message-ID: marlow.andrew@googlemail.com wrote: > Jim Mehlhop wrote: >> Best solution is definitely high speed ethernet (Gigabit prefered) >> clustered and running Volume shadowing, so there is no downtime on the data. > > The 4100 system does not need to be available to users at the time. So > I suggested temporarily unplugging a cable from one of the NICs and > plugging in a gigabit hub to connect the 2 machines together. But I > wasn't sure what sw to use to do the transfer. > Obviously things like FTP are out... FTP of on on-disk BACKUP disk-image should be fine. Run BACKUP/IMAGE /SAVE_SET on each volume and then FTP the save-set to the new system. Finaly restore the save-set to the new disks... Jan-Erik. ------------------------------ Date: Wed, 25 Jun 2008 12:18:45 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: How to transfer complete disk images without using tape Message-ID: marlow.andrew@googlemail.com wrote: > warren sander wrote: >> And one that I don't recommend but for completeness... (again we don't even >> know the os versions etc). But you could always setup pathworks/samba and >> use drag and drop from share to share. Of course FTP would be more efficent >> etc but completeness. > > I have already suggested that samba might be used but I was not sure > about saying that because I don't know if samba is available for > OpenVMS. It's v7.2-1 on the 4100 and v7.3-2 on the ES45 BTW. If memory > serves, pathworks is some sort of proprietary sw for doing the comms. > This reduces the chances due to license costs. > SAMBA is available for VMS, but FTP of BACKUP-images of your volumes must be much easier. B.t.w, how many disks/volumes is the 150 GB's spread over ? Do you have spare space on any volume to store an image-backup of any of the other volumes ? Jan-Erik. ------------------------------ Date: Wed, 25 Jun 2008 05:18:54 -0700 (PDT) From: Bob Gezelter Subject: Re: How to transfer complete disk images without using tape Message-ID: <6cc2651e-813c-4d64-9114-11c61159cd19@34g2000hsf.googlegroups.com> On Jun 25, 7:56 am, marlow.and...@googlemail.com wrote: > Jim Mehlhop wrote: > > Best solution is definitely high speed ethernet (Gigabit prefered) > > clustered and running Volume shadowing, so there is no downtime on the data. > > The 4100 system does not need to be available to users at the time. So > I suggested temporarily unplugging a cable from one of the NICs and > plugging in a gigabit hub to connect the 2 machines together. But I > wasn't sure what sw to use to do the transfer. Obviously things like > FTP are out. I don't know about volume shadowing, I am not a VMS > person. > > -Andrew Andrew, If you do not have licenses for clustering, or for shadowing, then the DECnet route for writing save sets is the most straightforward way. Step 1. Enable DECnet on both nodes (if it is not already installed, most machines sold in the last decade have at least DECnet End Node licenses as part of their license packages). Step 2. Use BACKUP/IMAGE/IGNORE=NOINTERLOCK/VERIFY olddisk ES45"user password"::tempdisk:olddisk.BCK/SAVE_SET Step 3. Use BACKUP to restore the images. Repeat Steps 2-3 for each disk. As mentioned before, for efficiency purposes, I strongly recommend setting the RMS buffering and extend sizes on the ES45 (and the 4100) to maximize the parallelism and data rate of the transfer between the systems. Having done this on many occasions, it can be done quite efficiently, if it is done correctly. Care must be exercised to ensure that the new disks are initialized appropriately. In fact, I have done this migration remotely, for an entire cluster and it went quite well. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 25 Jun 2008 07:27:22 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: How to transfer complete disk images without using tape Message-ID: <6ZwoiSNJfv4s@eisner.encompasserve.org> In article <37f448f4-918e-485f-9e8b-f1d0897912a1@y21g2000hsf.googlegroups.com>, marlow.andrew@googlemail.com writes: > > I have already suggested that samba might be used but I was not sure > about saying that because I don't know if samba is available for > OpenVMS. It's v7.2-1 on the 4100 and v7.3-2 on the ES45 BTW. If memory > serves, pathworks is some sort of proprietary sw for doing the comms. > This reduces the chances due to license costs. > Samba is definitely available for VMS, but since it's designed to support other OS it might not maintain VMS file attributes. Anyone using samba on VMS as both a client and a server want to check? ------------------------------ Date: Wed, 25 Jun 2008 16:51:42 GMT From: Rob Brown Subject: Re: How to transfer complete disk images without using tape Message-ID: On Wed, 25 Jun 2008, Bob Gezelter wrote: > Step 2. Use BACKUP/IMAGE/IGNORE=NOINTERLOCK/VERIFY olddisk ES45"user > password"::tempdisk:olddisk.BCK/SAVE_SET Bob, thanks for your advice and corrections in the past. Now I return the favour. Above, I think you meant to type /IGNORE=NOBACKUP. - Rob -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Wed, 25 Jun 2008 18:08:10 +0100 From: baldrick Subject: Re: How to transfer complete disk images without using tape Message-ID: marlow.andrew@googlemail.com wrote: > The 4100 system does not need to be available to users at the time. So > I suggested temporarily unplugging a cable from one of the NICs and > plugging in a gigabit hub to connect the 2 machines together. But I > wasn't sure what sw to use to do the transfer. Obviously things like > FTP are out. I don't know about volume shadowing, I am not a VMS > person. No disrespect here but I hope you know what you are doing. Saying you're not a VMS person suggests you ought to employ someone that does understand these things. Here's a scenario, are you copying the user authorization data as well? When you make an image copy of the disk, all the security goes along with files (ACL, UIC) so when your "new" users on the ES45 access this data, if their access credentials as laid out in the UAF / rightslist don't match, or alternatively match incorrectly, you've inadvertently created a serious potential breach of security, or you end up with various access failures. The other thing I have seen 100's of times, is a failure to to use logical names correctly, and you end up with DIA5 being equated to DKA200 which in turn now points at $1$DGA507. Ignorance of how VMS deals with this often leads to messy and unnecessarily complicated systems. There is more to think about than moving disk images, and if this is a project where equipment has been purchased and so on, I'm absolutely amazed that no consideration (apparently) has been given to service migration. Failing to plan is planning to fail. Another poster has said you should consider /IGNORE=NOBACKUP, you may need to consider /NOALIAS, you perhaps also should consider correctly initializing the disks with scope for growth before restoring using /NOINIT. Are you moving to ODS5, is there a case for it? The explanation for the BACKUP qualifiers above are in the documentation, but only a seasoned system manager will understand where to use them. Are you moving indexed files, have you even considered the implications of a cluster size change for those indexed files? I presume you have a test plan, and a methodology of backout and user acceptance testing. I have even seen cases where faster hardware has in fact introduced failures due to software restrictions and wild assumptions One final word, be careful moving hardware about. The connectors may well mate up, but there is a big (potential) difference between LVD, HVD and SE (pun intended). -- nclews at csc dot com aka Mr. CP Charges ------------------------------ Date: Tue, 24 Jun 2008 23:41:43 -0700 (PDT) From: j.spilling@t-online.de Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: <17f9e2da-7dbd-4a11-84b5-0ee32f3918af@m44g2000hsc.googlegroups.com> On 25 Jun., 01:16, Rich Jordan wrote: > On Jun 24, 5:22 pm, Jan-Erik S=F6derholm > wrote: > > > > > Bob Gezelter wrote: > > > On Jun 24, 5:37 pm, Rich Jordan wrote: > > >> I need to have the ability for a PCSI install command procedure to > > >> optionally add a record to a MIME$FILETYPES.DAT file in a user > > >> directory on a customer system. This is likely going to include > > >> systems that we do not have access too (hence the reason we're > > >> packaging as a PCSI file; previous installs have been hands on and > > >> custom). > > > >> Some possibilities are easy; if the file doesn't exist, create it > > >> (actually copy a default file with the required entries). If it > > >> exists but doesn't contain the records needed, append a stub with th= e > > >> records. > > > >> If it exists and one or more of the records I need are already there= , > > >> I can't necessarily count on them being the "way" I need them withou= t > > >> parsing individual lines in the file. If one or more needed records > > >> is present but "incorrect" (by my application's opinion) then I've g= ot > > >> a manual intervention requirement; the system manager has to > > >> straighten things up. > > > >> Is there a 'best practices' way to deal with situations like this on= a > > >> random, non-accessible system within the purview of the PCSI product > > >> installer? > > > >> Thanks > > > >> Rich > > > > Rich, > > > > Having written several PCSI scripts, I recommend a thorough reading o= f > > > the Polycenter Install Guide. PCSI has the ability to call command > > > procedures at various points, and most of the limits are very broad. > > > > - Bob Gezelter,http://www.rlgsc.com > > > I guess one could just *document* the needed changes/additons > > to MIME$FILETYPES.DAT and let the sysadmin take care of it. > > > Jan-Erik. > > A tempting option, and currently the default for any situation where > there is already a MIME$FILETYPES.DAT file in place. > > Rich I understand, that it would not be possible to produce a MIME definition file during the installation from what you would say that it is 100% right in veery case (yes I know this situation also from some installation kits). So I would do the following: analyse the existing MIME definition file during installation and create a "merged" file. In this merge process you use the knowlegde from your application (your knowledge). But don't really change the file. Put the merged "copy" into a installation directory (sys$examples:, ...) and provide a hint during installation where the "recommendation" is located and let the admin do the merged/change/copy. By this, you prvide your knowledge and the admin has the liability to check this against it's requirements (which are perhaps unknow to you). Joerg ------------------------------ Date: Wed, 25 Jun 2008 01:11:01 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: <60a59299-8bcd-4a68-883d-77da275532d1@i76g2000hsf.googlegroups.com> On 24 Jun, 22:37, Rich Jordan wrote: > I need to have the ability for a PCSI install command procedure to > optionally add a record to a MIME$FILETYPES.DAT file in a user > directory on a customer system. =A0This is likely going to include > systems that we do not have access too (hence the reason we're > packaging as a PCSI file; previous installs have been hands on and > custom). > > Some possibilities are easy; if the file doesn't exist, create it > (actually copy a default file with the required entries). =A0If it > exists but doesn't contain the records needed, append a stub with the > records. > > If it exists and one or more of the records I need are already there, > I can't necessarily count on them being the "way" I need them without > parsing individual lines in the file. =A0If one or more needed records > is present but "incorrect" (by my application's opinion) then I've got > a manual intervention requirement; the system manager has to > straighten things up. > > Is there a 'best practices' way to deal with situations like this on a > random, non-accessible system within the purview of the PCSI product > installer? > > Thanks > > Rich I think the best way to do this kind of thing is to do software and file delivery through PCSI and then config (of which this is a part) through a configuration command procedure. This means that you can do things like make decisions on files and what to do for specific cases with assistance from the user/system manager. The PCSI script doesn't have to make the decisions all on its own during product installation. Steve ------------------------------ Date: Wed, 25 Jun 2008 05:09:15 -0700 (PDT) From: Bob Gezelter Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: On Jun 25, 4:18 am, JF Mezei wrote: > Your PCSI could deposit a command procedure in SYS$MANAGER which > searches the mime$filetypes file for a string and if not found, it then > proceeds to add whatever new mimetypes need to be added. > > Then, you modify SYLOGIN.COM to call that procedure whenever someone > logs in. So each user ends up modyfying his own copy of mime$filetypes > file when thety login. After a week or two, you remove the call in > SYLOGIN since it will be pointless to constantly search that file. JF, WADR, I disagree. If you are dealing with the login profile, one needs to leave the check there. What about those who do not login within the window? On travel? On vacation? Out sick? One can implement an "execute once" part of the login script, but that involves writing self-modifying DCL. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 25 Jun 2008 09:57:24 -0700 (PDT) From: Rich Jordan Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: <7a8f340d-260f-4d78-bb03-52f7d319faad@r66g2000hsg.googlegroups.com> On Jun 25, 8:35=A0am, Robert Deininger wrote: > In article > <5b7465cb-292c-4807-b727-f8550cf08...@x41g2000hsb.googlegroups.com>, > =A0Rich Jordan wrote: > > > > > On Jun 24, 5:07=A0pm, Bob Gezelter wrote: > > > On Jun 24, 5:37 pm, Rich Jordan wrote: > > > > > I need to have the ability for a PCSI install command procedure to > > > > optionally add a record to a MIME$FILETYPES.DAT file in a user > > > > directory on a customer system. =A0This is likely going to include > > > > systems that we do not have access too (hence the reason we're > > > > packaging as a PCSI file; previous installs have been hands on and > > > > custom). > > > > > Some possibilities are easy; if the file doesn't exist, create it > > > > (actually copy a default file with the required entries). =A0If it > > > > exists but doesn't contain the records needed, append a stub with t= he > > > > records. > > > > > If it exists and one or more of the records I need are already ther= e, > > > > I can't necessarily count on them being the "way" I need them witho= ut > > > > parsing individual lines in the file. =A0If one or more needed reco= rds > > > > is present but "incorrect" (by my application's opinion) then I've = got > > > > a manual intervention requirement; the system manager has to > > > > straighten things up. > > > > > Is there a 'best practices' way to deal with situations like this o= n a > > > > random, non-accessible system within the purview of the PCSI produc= t > > > > installer? > > > > > Thanks > > > > > Rich > > > > Rich, > > > > Having written several PCSI scripts, I recommend a thorough reading o= f > > > the Polycenter Install Guide. PCSI has the ability to call command > > > procedures at various points, and most of the limits are very broad. > > > > - Bob Gezelter,http://www.rlgsc.com > > > Bob, > > =A0 =A0 thanks, I have been working from the manual and do have a > > reasonable understanding of the technical aspects. =A0I've also been > > dissecting some other install command procedures which were pretty > > helpful. =A0I'm just running into more and more little 'issues' with > > this since the PCSI kit is going in cold to an unknown system. =A0I'm > > trying to be as careful and finicky as possible about touching > > anything outside of the actual application directories. =A0And the more > > I look at it and think about it (and play with test systems) it seems > > like the more finicky and extra careful I have to be. > > > =A0 =A0 =A0I know how to do what I need to do in this case; its more a > > question of how much effort needs to be expended (probably a lot) and > > how much is "OK" to leave to a system manager to take care of. =A0In > > this case, do I have to allow for the fact that this one account might > > already have a MIME$FILETYPES.DAT file that might already have records > > for the filetypes I need, and that one or more of those may be > > incompatible with my needs. > > > =A0 =A0 =A0Its highly unlikely; the filetypes records are pretty much > > verbatim out of Netscape/Mozilla browser definitions, and I believe > > pretty much the same elsewhere, but just my luck someone installs this > > then starts venting at us (me!) because it caused j-random other app > > that requires a _different_ custom mime filetype record for a > > particular file type in the same account that just won't work with > > ours, and OBTW we just blew up a week worth of production ;) > > > =A0 =A0 =A0We of course leave inserting startup procedure calls into th= e > > system startup to the system manager; perhaps its not too out of place > > to assume the same for this if there's already a MIME$FILETYPES.DAT > > file in place. =A0Leave it to the installer to deal with the conflict > > (which would be a significant problem...) > > > =A0 =A0 =A0I also need to check for and avoid (or defer to the installe= r) > > conflicts in startup file name (it its to be in SYS$STARTUP; I could > > just leave it in the application directory but I prefer it be in the > > central location) as well as other system resources. =A0The install > > procedure (the install PART of the install/remove procedure) is > > currently at 900 lines of DCL (not counting comments) as I check, and > > recheck, and double check all the possible permutations of changes > > that I can think of that might be different on a customer box that we > > don't have access to. > > > Thanks! > > > Rich > > Advice mixed in with a few questions... > > In general, if the installer can figure out what to do with little or no > user intervention, make the installer fix up MIME$FILETYPES.DAT. > > By "a little" user intervention, I mean something that fits into the > PCSI OPTION mechanism. =A0Something like "Make Rich's product the default > application for file type FOO?" might make sense. =A0If the answer is YES= , > then your install-time procedure knows it is allowed to change an > existing record in the .DAT file. =A0This is a good mechanism to drive > small changes in install-time behavior. > > If a small decision like this has reversible consequences, you can take > advantage of the PRODUCT RECONFIGURE mechanism to let the user change an > option. =A0Your kit could make small changes without needing to supply a > bigger stand-alone configuration tool. > > On the other hand, if complex decisions from the user are needed, follow > Steve's advice and supply a separate configuration procedure that will > be run later. =A0The user may need to reconfigure from time to time, and > will use the same procedure. =A0Or the user may just edit the .DAT file. > > You can combine these methods, with the installer providing a default > configuration if none is already present. =A0The configuration procedure > is still available if the user needs to change things later. > > From the name, MIME$FILETYPES.DAT belongs to the MIME facility. =A0Is tha= t > a VMS component, or an add-on? =A0I don't remember. > > Unless your installer IS the MIME facility, it probably doesn't own this > file. =A0It isn't a "managed object" of your installer in the PCSI sense.= =A0 > If you don't own the file, you should NOT create it or replace it unless > your installer cooperates with the MIME installer. =A0If you treat the > file as a managed object, then you co-own it with the MIME installer. =A0 > If multiple installers co-own a file and coordinate generation numbers, > PCSI can keep everything straight. > > On the other hand, if you go behind PCSI's back and create, replace, or > modify a file that is NOT your kit's managed object, but IS a managed > object of another kit, then PCSI can't help manage conflicts. =A0The last > kit installed will probably win, and installation of kit A can break the > functionality of product B. =A0(This seems to happen a lot in the WeenDoz= e > world.) > > I think you are in the situation where you need to modify a file that's > owned and managed by another product. =A0As long as your installer (and > your configuration procedure, if any) follow the other product's rules > for the file, you should be safe. > > If the other product supplies the .DAT file unconditionally, expect your > modified file to be overwritten the next time the other product is > installed. =A0(This shouldn't be the case for files that the user is > supposed to customize.) > > If the other product supplies a .TEMPLATE file but no .DAT file > (expecting the user to COPY .TEMPLATE .DAT), then you can create the > .DAT if it doesn't exist. =A0It may be a good idea to use the .TEMPLATE > file as your starting point. > > If the other product supplies the .DAT file and expects the user to > modify it, then your kit can modify it on the user's behalf. =A0Are you > clairvoyant enough to know what the user wants? =A0If not, you have to ge= t > the user involved with the decision. > > You could supply a .TEMPLATE file of your own, with your own file name, > which is a PCSI managed object for your product. =A0Leave it up to the > user to copy records from your .TEMPLATE to the active .DAT file. =A0Then > the user's brain and his favorite editor become the "configuration > procedure" and you don't have to supply it. =A0(There's an obvious weak > link in this scheme; it assumes every user has a brain.) > > You mentioned that MIME$FILETYPES.DAT is in a user directory. =A0If there > are multiple users and multiple copies of the file, that's a good reason > to do all the modifications in a configuration procedure after the > install. =A0Non-privileged users can't run PCSI. =A0The PCSI database is > specific to a system disk, and can't keep track of per-user details. > > PCSI only makes it easy to put file in a few "standard" places; dealing > with arbitrary user-specified directories is not one of its strengths. = =A0 > You can fiddle with the SCOPE keyword, and the user can fiddle with > /DESTINATION, but it's still not very flexible. MIME$FILETYPES.DAT is used by the MIME utility that comes with VMS; it may be used by other applications but I'm not certain of that. The file is, as far as I know, NOT created or deposited in a user directory by any automated process, and there is no template version. The file is optionally created "by users" in order to customize operation of the MIME utility. Its format is standardized, but the issue I'm concerned about is that while there are 'de facto' standards for many file types, there's no guarantee or mandate that such are followed. It would not be appropriate for our package to 'take ownership' of the file. /DESTINATION is already restricted (controlled by the preconfigure routine). I will take a look at the SCOPE options (I haven't used or read much about that yet). extension, content type/subtype,[Content-Transfer-Encoding string] doc, application/ms-word, base64 jpeg, image/jpeg, base64 If you try to send a file of type .xyz as an attachment, and there is no corresponding record in the MIME$FILETYPES.DAT file, it gets sent as (if I remember correctly) quoted printable, and is most likely unusable at the other end unless its a text file. The files we are dealing with are binary format and absolutely require a record with 'base64' as the content transfer encoding. Based on that, there is in fact an issue even with creating a MIME $FILETYPES.DAT file since there is a (probably vanishingly small) chance that someone out there is relying on the default transfer encoding for a filetype we need to define. Murphy's Law says they'll be the first ones to try to install my kit ;) I think perhaps it would be best to do the 'drop a template' thing and inform the installer that they have to create the actual data file before the product can be used. FWIW the account in question is SYSTEM, and the MIME$FILETYPES.DAT is in SYS$MANAGER:, not an arbitrary user account. The presence or absence of the file in any other account/directory is not an issue. Another reason to be particularly picky, and yet at the same time probably even less likely to run into a conflict. Yes, there's a good reason it has to be SYSTEM and SYS$MANAGER. ------------------------------ Date: Wed, 25 Jun 2008 14:37:16 +0200 From: "P. Sture" Subject: Re: On the fly PCSI install needs to update text file on target system Message-ID: In article <83b0b37a-1572-4e9c-9cc5-908b9845b869@x35g2000hsb.googlegroups.com>, Rich Jordan wrote: > On Jun 24, 5:22 pm, Jan-Erik Söderholm > wrote: > > Bob Gezelter wrote: > > > On Jun 24, 5:37 pm, Rich Jordan wrote: > > >> I need to have the ability for a PCSI install command procedure to > > >> optionally add a record to a MIME$FILETYPES.DAT file in a user > > >> directory on a customer system.  This is likely going to include > > >> systems that we do not have access too (hence the reason we're > > >> packaging as a PCSI file; previous installs have been hands on and > > >> custom). > > > > >> Some possibilities are easy; if the file doesn't exist, create it > > >> (actually copy a default file with the required entries).  If it > > >> exists but doesn't contain the records needed, append a stub with the > > >> records. > > > > >> If it exists and one or more of the records I need are already there, > > >> I can't necessarily count on them being the "way" I need them without > > >> parsing individual lines in the file.  If one or more needed records > > >> is present but "incorrect" (by my application's opinion) then I've got > > >> a manual intervention requirement; the system manager has to > > >> straighten things up. > > > > >> Is there a 'best practices' way to deal with situations like this on a > > >> random, non-accessible system within the purview of the PCSI product > > >> installer? > > > > >> Thanks > > > > >> Rich > > > > > Rich, > > > > > Having written several PCSI scripts, I recommend a thorough reading of > > > the Polycenter Install Guide. PCSI has the ability to call command > > > procedures at various points, and most of the limits are very broad. > > > > > - Bob Gezelter,http://www.rlgsc.com > > > > I guess one could just *document* the needed changes/additons > > to MIME$FILETYPES.DAT and let the sysadmin take care of it. > > > > Jan-Erik. > > A tempting option, and currently the default for any situation where > there is already a MIME$FILETYPES.DAT file in place. > What about mimicking the way VMS upgrades do things here? E.g. if a file already exists put your version into the relevant directory with a .TEMPLATE file type. This has the advantage of familiarity for the system manager. What about future upgrades of your software? You will not only have to deal with the scenarios you are currently thinking of but those where modifications have been made to the files you originally distributed. I'd be extra cautious about files in user directories as you can really expect the unexpected there. Files may not be in the expected format after a couple of FTP transfers, or there may be a clash in naming conventions. -- Paul Sture OpenVMS Freeware CD listings: http://openvms.sture.ch/freeware/ ------------------------------ Date: Wed, 25 Jun 2008 09:35:26 -0400 From: Robert Deininger Subject: Re: On the fly PCSI install needs to update text file on target system Message-ID: In article <5b7465cb-292c-4807-b727-f8550cf087e3@x41g2000hsb.googlegroups.com>, Rich Jordan wrote: > On Jun 24, 5:07 pm, Bob Gezelter wrote: > > On Jun 24, 5:37 pm, Rich Jordan wrote: > > > > > > > > > I need to have the ability for a PCSI install command procedure to > > > optionally add a record to a MIME$FILETYPES.DAT file in a user > > > directory on a customer system.  This is likely going to include > > > systems that we do not have access too (hence the reason we're > > > packaging as a PCSI file; previous installs have been hands on and > > > custom). > > > > > Some possibilities are easy; if the file doesn't exist, create it > > > (actually copy a default file with the required entries).  If it > > > exists but doesn't contain the records needed, append a stub with the > > > records. > > > > > If it exists and one or more of the records I need are already there, > > > I can't necessarily count on them being the "way" I need them without > > > parsing individual lines in the file.  If one or more needed records > > > is present but "incorrect" (by my application's opinion) then I've got > > > a manual intervention requirement; the system manager has to > > > straighten things up. > > > > > Is there a 'best practices' way to deal with situations like this on a > > > random, non-accessible system within the purview of the PCSI product > > > installer? > > > > > Thanks > > > > > Rich > > > > Rich, > > > > Having written several PCSI scripts, I recommend a thorough reading of > > the Polycenter Install Guide. PCSI has the ability to call command > > procedures at various points, and most of the limits are very broad. > > > > - Bob Gezelter,http://www.rlgsc.com > > Bob, > thanks, I have been working from the manual and do have a > reasonable understanding of the technical aspects. I've also been > dissecting some other install command procedures which were pretty > helpful. I'm just running into more and more little 'issues' with > this since the PCSI kit is going in cold to an unknown system. I'm > trying to be as careful and finicky as possible about touching > anything outside of the actual application directories. And the more > I look at it and think about it (and play with test systems) it seems > like the more finicky and extra careful I have to be. > > I know how to do what I need to do in this case; its more a > question of how much effort needs to be expended (probably a lot) and > how much is "OK" to leave to a system manager to take care of. In > this case, do I have to allow for the fact that this one account might > already have a MIME$FILETYPES.DAT file that might already have records > for the filetypes I need, and that one or more of those may be > incompatible with my needs. > > Its highly unlikely; the filetypes records are pretty much > verbatim out of Netscape/Mozilla browser definitions, and I believe > pretty much the same elsewhere, but just my luck someone installs this > then starts venting at us (me!) because it caused j-random other app > that requires a _different_ custom mime filetype record for a > particular file type in the same account that just won't work with > ours, and OBTW we just blew up a week worth of production ;) > > We of course leave inserting startup procedure calls into the > system startup to the system manager; perhaps its not too out of place > to assume the same for this if there's already a MIME$FILETYPES.DAT > file in place. Leave it to the installer to deal with the conflict > (which would be a significant problem...) > > I also need to check for and avoid (or defer to the installer) > conflicts in startup file name (it its to be in SYS$STARTUP; I could > just leave it in the application directory but I prefer it be in the > central location) as well as other system resources. The install > procedure (the install PART of the install/remove procedure) is > currently at 900 lines of DCL (not counting comments) as I check, and > recheck, and double check all the possible permutations of changes > that I can think of that might be different on a customer box that we > don't have access to. > > Thanks! > > Rich Advice mixed in with a few questions... In general, if the installer can figure out what to do with little or no user intervention, make the installer fix up MIME$FILETYPES.DAT. By "a little" user intervention, I mean something that fits into the PCSI OPTION mechanism. Something like "Make Rich's product the default application for file type FOO?" might make sense. If the answer is YES, then your install-time procedure knows it is allowed to change an existing record in the .DAT file. This is a good mechanism to drive small changes in install-time behavior. If a small decision like this has reversible consequences, you can take advantage of the PRODUCT RECONFIGURE mechanism to let the user change an option. Your kit could make small changes without needing to supply a bigger stand-alone configuration tool. On the other hand, if complex decisions from the user are needed, follow Steve's advice and supply a separate configuration procedure that will be run later. The user may need to reconfigure from time to time, and will use the same procedure. Or the user may just edit the .DAT file. You can combine these methods, with the installer providing a default configuration if none is already present. The configuration procedure is still available if the user needs to change things later. From the name, MIME$FILETYPES.DAT belongs to the MIME facility. Is that a VMS component, or an add-on? I don't remember. Unless your installer IS the MIME facility, it probably doesn't own this file. It isn't a "managed object" of your installer in the PCSI sense. If you don't own the file, you should NOT create it or replace it unless your installer cooperates with the MIME installer. If you treat the file as a managed object, then you co-own it with the MIME installer. If multiple installers co-own a file and coordinate generation numbers, PCSI can keep everything straight. On the other hand, if you go behind PCSI's back and create, replace, or modify a file that is NOT your kit's managed object, but IS a managed object of another kit, then PCSI can't help manage conflicts. The last kit installed will probably win, and installation of kit A can break the functionality of product B. (This seems to happen a lot in the WeenDoze world.) I think you are in the situation where you need to modify a file that's owned and managed by another product. As long as your installer (and your configuration procedure, if any) follow the other product's rules for the file, you should be safe. If the other product supplies the .DAT file unconditionally, expect your modified file to be overwritten the next time the other product is installed. (This shouldn't be the case for files that the user is supposed to customize.) If the other product supplies a .TEMPLATE file but no .DAT file (expecting the user to COPY .TEMPLATE .DAT), then you can create the .DAT if it doesn't exist. It may be a good idea to use the .TEMPLATE file as your starting point. If the other product supplies the .DAT file and expects the user to modify it, then your kit can modify it on the user's behalf. Are you clairvoyant enough to know what the user wants? If not, you have to get the user involved with the decision. You could supply a .TEMPLATE file of your own, with your own file name, which is a PCSI managed object for your product. Leave it up to the user to copy records from your .TEMPLATE to the active .DAT file. Then the user's brain and his favorite editor become the "configuration procedure" and you don't have to supply it. (There's an obvious weak link in this scheme; it assumes every user has a brain.) You mentioned that MIME$FILETYPES.DAT is in a user directory. If there are multiple users and multiple copies of the file, that's a good reason to do all the modifications in a configuration procedure after the install. Non-privileged users can't run PCSI. The PCSI database is specific to a system disk, and can't keep track of per-user details. PCSI only makes it easy to put file in a few "standard" places; dealing with arbitrary user-specified directories is not one of its strengths. You can fiddle with the SCOPE keyword, and the user can fiddle with /DESTINATION, but it's still not very flexible. ------------------------------ Date: Wed, 25 Jun 2008 04:18:02 -0400 From: JF Mezei Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: <4861ff3c$0$8455$c3e8da3@news.astraweb.com> Your PCSI could deposit a command procedure in SYS$MANAGER which searches the mime$filetypes file for a string and if not found, it then proceeds to add whatever new mimetypes need to be added. Then, you modify SYLOGIN.COM to call that procedure whenever someone logs in. So each user ends up modyfying his own copy of mime$filetypes file when thety login. After a week or two, you remove the call in SYLOGIN since it will be pointless to constantly search that file. ------------------------------ Date: Wed, 25 Jun 2008 09:22:56 -0700 From: "Tom Linden" Subject: OT: Tru64 booting Message-ID: I went to power up a PWS 600au that has been on the shelf for more than a year and when I plugged in the Power Card got a loud pop out of the PS. I can I boot another box from the same drives as you can with VMS? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 25 Jun 2008 09:32:50 -0700 From: "Tom Linden" Subject: Re: OT: Tru64 booting Message-ID: On Wed, 25 Jun 2008 09:22:56 -0700, Tom Linden wrote: > I went to power up a PWS 600au that has been on the shelf for more than > a year > and when I plugged in the Power Card got a loud pop out of the PS. > > I can I boot another box from the same drives as you can with VMS? > > Should have added that the other box is an XP1000 -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 25 Jun 2008 18:38:09 +0200 From: "Martin Vorlaender" Subject: Re: OT: Tru64 booting Message-ID: Tom Linden wrote: >> I went to power up a PWS 600au that has been on the shelf for more than >> a year and when I plugged in the Power Card got a loud pop out of the PS. >> >> I can I boot another box from the same drives as you can with VMS? >> > Should have added that the other box is an XP1000 AFAICT, this should work, at least using the generic kernel: >>> b -flags a -file genvmunix and then build a kernel suitable for the XP1000. cu, Martin -- One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin.vorlaender@t-online.de ------------------------------ Date: Wed, 25 Jun 2008 02:31:19 -0700 (PDT) From: Bob Gezelter Subject: Re: Tru64 file system source code now open source Message-ID: <7aa7835f-07d7-4201-84e3-1fa943541861@k30g2000hse.googlegroups.com> On Jun 24, 3:51 pm, JF Mezei wrote: > John Smith wrote: > >http://www.informationweek.com/news/software/open_source/showArticle.... > > ## > Tru64 is a 64-bit Unix operating system for the Alpha microprocessor > architecture owned by HP. Tru64 was a product of Compaq, which was > acquired by HP in 2002. > ## > > No mention of Tru64 coming from Digital. No mention about Alpha having > been murdered and Tru64 development having stopped in 2001. > > The last paragraph though is the best. Finally, a true reflection of > HP's true intentions. And I bet The Stallards/Livermores of HP will > applaud that paragraph instead of writing a letter to informationweek to > deny it. (someone else already posted that paragraphs about HP migrating > apps from VMS/Tru64 to HP-UX). > > This is the official HP press release about it: (Note that HP developped > Tru64). > > ## > HP Contributes Source Code to Open Source Community to Advance Adoption > of Linux > MainSMDS > > PALO ALTO, Calif.--(BUSINESS WIRE)--June 23, 2008-- > > Continuing its efforts to advance customer adoption of Linux, HP > (NYSE:HPQ)today announced the contribution of its Tru64 UNIX Advanced > File System (AdvFS)source code to the open source community. > > The AdvFS source code includes capabilities that increase uptime, > enhancesecurity and help ensure maximum performance of Linux file > systems. HP willcontribute the code as a reference implementation of an > enterprise Linux filesystem under the terms of General Public License > Version 2 for compatibilitywith the Linux kernel, as well as provide > design documentation, test suites andengineering resources. > > Linux is one of the most prominent examples of free software and open > sourcedevelopment, and source code continues to draw interest from > developers, theuser community and customers. HP, which ships a Linux > server at the rate of oneper minute, has long provided open source > alternatives to customers andcontributed to the open source community to > speed market development. > > The source code serves as a rich technology base to advance > ongoingdevelopment of Linux by providing a comprehensive foundation for > Linux kerneldevelopers to leverage and improve Linux file system > functionality. > > Developed by HP, AdvFS has been deployed for more than 16 years by > enterprisesthroughout the world. It simplifies file and storage > management, enables onlinesystem backups and increases data > availability. The integration of key AdvFSfile system features also > accelerates the roadmap of future solutions designedto strengthen Linux > for enterprise customers. > > "To ensure the highest levels of data security and availability, > Linuxcustomers need full and immediate access to established > technology," said MartinFink, senior vice president and general manager, > Business Critical Systems, HP."We continue to invest our engineering > resources in the development of thattechnology, while working with the > open source community to ensure accessibilityand seamless integration." > > Increasing Linux performance and advancing productivity > > Business demands for improved solutions are driving the Linux > kerneldevelopment community to focus on the advancement of file system > functionality.Currently, file systems are being developed through an > open community process.HP's contribution fuels these efforts. > > "HP's contribution of the Advanced File System code, coupled with > theiroverall resource commitment to Linux, will greatly accelerate the > developmentand commercial availability of improved system functionality > for Linux," saidJim Zemlin, executive director, Linux Foundation. "The > technology andengineering resources being made available for > next-generation file systemprojects are proof that HP is a true open > source community leader." > > Linux market leader > > HP extended its worldwide lead in the Linux market with 38.6 percent > ofrevenue market share for the first quarter of 2008, according to IDC. > HP alsoholds the No. 1 Linux server market position in unit shipments, > with 36.4percent of market share worldwide.(1) > > "HP's contribution accelerates the development of future Linux file > systems,ensuring enhanced system performance to meet our increasingly > demanding needs,"said Professor Giovanni Aloisio, chief executive > officer of the Italian SouthernPartnership for Advance Computational > Infrastructures (SPACI) in southern Italy."Linux is playing a > significant role in our building of a supercomputing gridenvironment > running HP Integrity servers. We have used many technologies overthe > years, including Tru64 UNIX with the Advanced File System, and > thisannouncement assures SPACI of continued Linux growth to conduct > significant newresearch." > > The Tru64 UNIX Advanced File System source code, design documentation > and testsuites are available by visitinghttp://advfs.sourceforge.net. > More informationon open source and Linux at HP is available atwww.hp.com/go/linux. > > About HP > > HP focuses on simplifying technology experiences for all of its > customers -from individual consumers to the largest businesses. With a > portfolio that spansprinting, personal computing, software, services and > IT infrastructure, HP isamong the world's largest IT companies, with > revenue totaling $110.4 billion forthe four fiscal quarters ended April > 30, 2008. More information about HP isavailable atwww.hp.com. > > Note to editors: More news from HP, including links to RSS feeds, is > availableatwww.hp.com/hpinfo/newsroom/. > > (1) IDC Worldwide Quarterly Server Tracker, May 2008. > > This news release contains forward-looking statements that involve > risks,uncertainties and assumptions to save bandwidth> ... warranty. HPshall not be liable for technical or > editorial errors or omissionscontained herein. CONTACT: HP > Dayna Fried, +1-949-240-2119 dayna.fr...@hp.com > or Burson-Marsteller for HP Ali Kops, > +1-312-596-3428 ali.k...@bm.com or > HP Media Hotline, +1-866-266-7272 p...@hp.comwww.hp.com/go/newsroom SOURCE: HPCopyright Business Wire 2008 JF, WADR, I disagree with your comment concerning the last paragraph. This single reference to OpenVMS is likely an example of a mis- understanding of the situation or an echo of an earlier, incorrect published account. If that was the case, the general session at the HP Technology Forum would have been flooded with slides promoting HP/UX. In fact, the slides during the warm-up period of the general session were overwhelmingly dominated by OpenVMS 30th Anniversary and StorageWorks displays. Sourcing is everything in journalism and intelligence. One of the ongoing problems with technical issues is that errors creep in. In the health field, there is a well-documented problem with reporters writing articles based upon press releases from research organizations, without an understanding of the underlying paper or phenomenon. Some writers go into the depths of the material to be able to write a good explanation for the general public, and some do not. The technical/business press is no different. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 25 Jun 2008 03:19:06 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: Tru64 file system source code now open source Message-ID: <7716d93d-24e1-44e6-a8f9-3ae9593259b9@25g2000hsx.googlegroups.com> On 24 Jun, 20:51, JF Mezei wrote: > John Smith wrote: > >http://www.informationweek.com/news/software/open_source/showArticle.... > > ## > Tru64 is a 64-bit Unix operating system for the Alpha microprocessor > architecture owned by HP. Tru64 was a product of Compaq, which was > acquired by HP in 2002. > ## > > No mention of Tru64 coming from Digital. No mention about Alpha having > been murdered and Tru64 development having stopped in 2001. > > The last paragraph though is the best. Finally, a true reflection of > HP's true intentions. And I bet The Stallards/Livermores of HP will > applaud that paragraph instead of writing a letter to informationweek to > deny it. (someone else already posted that paragraphs about HP migrating > apps from VMS/Tru64 to HP-UX). > > This is the official HP press release about it: (Note that HP developped > Tru64). > > ## > HP Contributes Source Code to Open Source Community to Advance Adoption > of Linux > MainSMDS > > PALO ALTO, Calif.--(BUSINESS WIRE)--June 23, 2008-- > > Continuing its efforts to advance customer adoption of Linux, HP > (NYSE:HPQ)today announced the contribution of its Tru64 UNIX Advanced > File System (AdvFS)source code to the open source community. > > The AdvFS source code includes capabilities that increase uptime, > enhancesecurity and help ensure maximum performance of Linux file > systems. HP willcontribute the code as a reference implementation of an > enterprise Linux filesystem under the terms of General Public License > Version 2 for compatibilitywith the Linux kernel, as well as provide > design documentation, test suites andengineering resources. > > Linux is one of the most prominent examples of free software and open > sourcedevelopment, and source code continues to draw interest from > developers, theuser community and customers. HP, which ships a Linux > server at the rate of oneper minute, has long provided open source > alternatives to customers andcontributed to the open source community to > speed market development. > > The source code serves as a rich technology base to advance > ongoingdevelopment of Linux by providing a comprehensive foundation for > Linux kerneldevelopers to leverage and improve Linux file system > functionality. > > Developed by HP, AdvFS has been deployed for more than 16 years by > enterprisesthroughout the world. It simplifies file and storage > management, enables onlinesystem backups and increases data > availability. The integration of key AdvFSfile system features also > accelerates the roadmap of future solutions designedto strengthen Linux > for enterprise customers. > > "To ensure the highest levels of data security and availability, > Linuxcustomers need full and immediate access to established > technology," said MartinFink, senior vice president and general manager, > Business Critical Systems, HP."We continue to invest our engineering > resources in the development of thattechnology, while working with the > open source community to ensure accessibilityand seamless integration." > > =A0 =A0Increasing Linux performance and advancing productivity > > Business demands for improved solutions are driving the Linux > kerneldevelopment community to focus on the advancement of file system > functionality.Currently, file systems are being developed through an > open community process.HP's contribution fuels these efforts. > > "HP's contribution of the Advanced File System code, coupled with > theiroverall resource commitment to Linux, will greatly accelerate the > developmentand commercial availability of improved system functionality > for Linux," saidJim Zemlin, executive director, Linux Foundation. "The > technology andengineering resources being made available for > next-generation file systemprojects are proof that HP is a true open > source community leader." > > =A0 =A0Linux market leader > > HP extended its worldwide lead in the Linux market with 38.6 percent > ofrevenue market share for the first quarter of 2008, according to IDC. > HP alsoholds the No. 1 Linux server market position in unit shipments, > with 36.4percent of market share worldwide.(1) > > "HP's contribution accelerates the development of future Linux file > systems,ensuring enhanced system performance to meet our increasingly > demanding needs,"said Professor Giovanni Aloisio, chief executive > officer of the Italian SouthernPartnership for Advance Computational > Infrastructures (SPACI) in southern Italy."Linux is playing a > significant role in our building of a supercomputing gridenvironment > running HP Integrity servers. We have used many technologies overthe > years, including Tru64 UNIX with the Advanced File System, and > thisannouncement assures SPACI of continued Linux growth to conduct > significant newresearch." > > The Tru64 UNIX Advanced File System source code, design documentation > and testsuites are available by visitinghttp://advfs.sourceforge.net. > More informationon open source and Linux at HP is available atwww.hp.com/= go/linux. > > =A0 =A0About HP > > HP focuses on simplifying technology experiences for all of its > customers -from individual consumers to the largest businesses. With a > portfolio that spansprinting, personal computing, software, services and > IT infrastructure, HP isamong the world's largest IT companies, with > revenue totaling $110.4 billion forthe four fiscal quarters ended April > 30, 2008. More information about HP isavailable atwww.hp.com. > > Note to editors: More news from HP, including links to RSS feeds, is > availableatwww.hp.com/hpinfo/newsroom/. > > =A0 =A0(1) IDC Worldwide Quarterly Server Tracker, May 2008. > > This news release contains forward-looking statements that involve > risks,uncertainties and assumptions to save bandwidth> ... warranty. HPshall not be liable for technical or > editorial errors or omissionscontained herein. =A0 =A0CONTACT: HP > =A0 Dayna Fried, +1-949-240-2119 =A0 =A0 =A0 =A0 =A0 =A0 dayna.fr...@hp.c= om > =A0 or =A0 =A0 =A0 =A0 =A0 =A0 Burson-Marsteller for HP =A0 =A0 =A0 =A0 = =A0 =A0 Ali Kops, > +1-312-596-3428 =A0 =A0 =A0 =A0 =A0 =A0 ali.k...@bm.com =A0 =A0 =A0 =A0 = =A0 =A0 or > HP Media Hotline, +1-866-266-7272 =A0 =A0 =A0 =A0 =A0 =A0 p...@hp.comwww.= hp.com/go/newsroom=A0 =A0SOURCE: HPCopyright Business Wire 2008 HP developed Tru64 and AdvFS in the same way that all of the former Digital and Compaq employees will explain their background as being HP employees for all of that employment time. HP "merged" with Compaq, Compaq bought Digital. There is no more Digital and there is no more Compaq brand name. It is all HP. As is commented by some, "We are all HP now". ------------------------------ Date: 25 Jun 2008 07:29:14 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Virtualized VMS in clusters (general questions) Message-ID: In article , Johnny Billquist writes: > > I believe you can more or less do that with E11, but that will limit you to > PDP-11 emulation... A step in the right direction, but a VAX emulation would be more usefull. I haven't powered up my PDP-11 in over a year. ------------------------------ End of INFO-VAX 2008.353 ************************