INFO-VAX Thu, 26 Jun 2008 Volume 2008 : Issue 354 Contents: 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: Network gear pricing Re: Network gear pricing 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 systemsys Re: OT: Tru64 booting Support for PL/I applications on OpenVMS Itanium Terminal servers and LANCP Re: Tru64 file system source code now open source ---------------------------------------------------------------------- Date: Wed, 25 Jun 2008 23:46:55 -0400 From: "William Webb" Subject: Re: Book "OpenVMS for Unix Users" Message-ID: <8660a3a10806252046i2ae3e9e5sb6152e0579865b8f@mail.gmail.com> On 6/23/08, Anton Shterenlikht wrote: > On Mon, Jun 23, 2008 at 05:37:37PM +0200, 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... > > I recommend "unix for openvms users", isbn 1-55558-276-1 > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 928 8233 > Fax: +44 (0)117 929 4423 > You forgot to mention that they'd need to read it from end to beginning. :-) WWWebb ------------------------------ Date: Wed, 25 Jun 2008 13:25:20 -0700 (PDT) From: LakeGator Subject: Re: Book: "Writing for the Reader" by John O'Rourke Message-ID: <610543cc-83f5-465a-b29e-dfa1f0f66d7d@k13g2000hse.googlegroups.com> On Jun 25, 1:01=A0pm, VMS is Virus Free wrote: > 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 fantasti= c > >job of double-sided scanning and OCR to .pdf at up to 18 pages/minute. > >Resulting .pdf is fully searchable. =A0Runs 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 Exc= el > >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.- Hide = quoted text - > > - Show quoted text - I answered your email and would assume we can arrange to loan the hard copy book to you. ------------------------------ Date: Wed, 25 Jun 2008 17:42:45 -0400 From: "John Smith" Subject: Re: Book: "Writing for the Reader" by John O'Rourke Message-ID: "Bill Gunshannon" wrote in message news: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 I don't recollect much about it other than they were early 1980's era machines similar to this one http://images.google.com/imgres?imgurl=http://www.digibarn.com/collections/systems/wang2200a/TN_DSC06187.JPG&imgrefurl=http://www.digibarn.com/collections/systems/wang2200a/&h=192&w=256&sz=13&hl=en&start=2&um=1&tbnid=5tD4bWRxBSF-7M:&tbnh=83&tbnw=111&prev=/images%3Fq%3Dwang%2Bword%2Bprocessor%26ndsp%3D18%26um%3D1%26hl%3Den%26newwindow%3D1%26safe%3Doff%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26hs%3DdtG%26sa%3DN I never paid much attention to them other than to use them for word processing. I had a number of password protected documents on these disks so I don't think that anything short of a real Wang device (and my recollecting the passwords) will help. But thanks for the offer - I have paper copies of pretty much everything which the scanner will handle quite nicely. I had my 750 with the floating-point accelerator, TU81, RA81's and LSI-11/x.25 gateway for real work. Just me, Fortran, APL, Rdb, Lindo, Powerhouse, 2780/3780 software, and a small crew of 1-3 students building OLTP and financial analytics running 24/7. ------------------------------ Date: Wed, 25 Jun 2008 11:39:43 -0700 (PDT) From: Bob Gezelter Subject: Re: How to transfer complete disk images without using tape Message-ID: On Jun 25, 11:51 am, Rob Brown wrote: > 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/ Rob, Concur. I mis-typed. Command should read: BACKUP/IMAGE/IGNORE=NOBACKUP/VERIFY olddisk ES45"user password"::tempdisk:olddisk.BCK/SAVE_SET Thank you for the correction. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 25 Jun 2008 11:58:44 -0700 (PDT) From: Bob Gezelter Subject: Re: How to transfer complete disk images without using tape Message-ID: <6ef6bdb6-b54d-4568-a503-351f465bd2a8@x41g2000hsb.googlegroups.com> On Jun 25, 12:08 pm, baldrick wrote: > marlow.and...@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 baldrick, Indeed. While this evolution is a routine one for an experienced system manager, there are numerous ways for things to go wrong. Done correctly, it is not a lot of work. Omitting a consideration could be a recipe for a major interruption of service. Indeed, if the old hardware is disposed of prior to the discovery of a problem, it could be quite a tangle to resolve. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 25 Jun 2008 12:27:51 -0700 (PDT) From: Bob Gezelter Subject: Re: How to transfer complete disk images without using tape Message-ID: <403ac6d6-b03b-4776-a838-02d7b7a7b213@a1g2000hsb.googlegroups.com> On Jun 25, 7:02 am, marlow.and...@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. Andrew, SAMBA (known as "CIFS" on OpenVMS) is only available at releases 8.2 and later (see http://h71000.www7.hp.com/network/CIFS_for_Samba.html ). In any event, Samba could only be used to migrate the BACKUP save sets. Otherwise a wide variety of meta-data may be lost. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 25 Jun 2008 15:07:15 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: How to transfer complete disk images without using tape Message-ID: <08062515071562_20200492@antinode.info> From: Bob Gezelter > BACKUP/IMAGE/IGNORE=NOBACKUP/VERIFY olddisk ES45"user > password"::tempdisk:olddisk.BCK/SAVE_SET /IGNORE=NOBACKUP because it's so important to preserve the contents of the page and swap files? Might make more sense to search for the files which are marked NOBACKUP, and see if the data in them have any value. If you have it installed: DFU SEARCH /CHARACTERISTICS = NOBACKUP device: ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 25 Jun 2008 16:17:14 -0400 From: JF Mezei Subject: Re: How to transfer complete disk images without using tape Message-ID: <4862a7d5$0$10704$c3e8da3@news.astraweb.com> marlow.andrew@googlemail.com wrote: > 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. You will need to better define the above need. If "one by one" disk transfer doesn't cut it, it eliminates most forms of BACKUP, FTP, NFS etc. It leaves you with BACKUP/PHYSICAL which makes a block by block copy of the drive and loads it into a save set. That save set happens to be a raw disk image in one container file. All other forms of BACKUP copies the disk file by file. BACKUP/IMAGE gives you additional features such as copying the disk name/features, and the file aliases, and will recretate a bootable disk if the source disk is a bootable disk. But it is still file by file. BACKUP/IMAGE will not recreate your files in the same physical position on the target disk. (It will defragment files and create a clean disk). is the 4100 a vax or alpha ? What versions are you running on each machine ? ------------------------------ Date: Wed, 25 Jun 2008 13:22:38 -0700 (PDT) From: Bob Gezelter Subject: Re: How to transfer complete disk images without using tape Message-ID: <91fbaa22-efcc-4e2a-b355-6e420cd725f7@f36g2000hsa.googlegroups.com> On Jun 25, 4:07 pm, s...@antinode.info (Steven M. Schweda) wrote: > From: Bob Gezelter > > > BACKUP/IMAGE/IGNORE=NOBACKUP/VERIFY olddisk ES45"user > > password"::tempdisk:olddisk.BCK/SAVE_SET > > /IGNORE=NOBACKUP because it's so important to preserve the contents > of the page and swap files? Might make more sense to search for the > files which are marked NOBACKUP, and see if the data in them have any > value. If you have it installed: > > DFU SEARCH /CHARACTERISTICS = NOBACKUP device: > > ------------------------------------------------------------------------ > > Steven M. Schweda sms@antinode-info > 382 South Warwick Street (+1) 651-699-9818 > Saint Paul MN 55105-2547 Steve, No, not the page and swap files. Several years ago, I encountered a site where people had implemented their own backup regimes for a variety of reasons, some valid (e.g., confidentiality requirements) and some less valid. Unfortunately, they had not noticed the NOBACKUP bits before migrating disks, and some important files were lost. It is safer to exclude the rare page and swap files explicitly, and ignore the NOBACKUP flag than it is to try to scan for the affected files (I prefer to take the safer option). - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 25 Jun 2008 19:51:52 -0700 From: Joe Bloggs Subject: Re: How to transfer complete disk images without using tape Message-ID: <1n06641fjt8fan16k5ks7nu25avj9gpshk@4ax.com> On Tue, 24 Jun 2008 02:43:45 -0700 (PDT), marlow.andrew@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. Any >ideas how to do this other than by tape please? TK50 backups will just >be so slow. > >I was thinking if there was any way to hook up the 2 machines via a >dedicated hub could the 4100 disks be made visible via some kind of >NFS software? Is samba available for OpenVMS? Would a network copy be >faster than using tape backup? > >Regards, > >Andrew Marlow Maybe consider using the Alpha-based InfoServer ? Having said that, and since you've referred to moving 150gb of data I don't know if what the upper limit on the size of the disk that can be served ... I'd also recommend dedicated cross-over cabling btw the two systems, rather than trying to do this over a local subnet. ------------------------------ Date: Wed, 25 Jun 2008 16:15:53 -0400 From: "John Smith" Subject: Re: Network gear pricing Message-ID: Thanks David. "David" wrote in message news:bjb8k.10111$AJ6.7838@bignews8.bellsouth.net... > Ellacoya Product > > E30-64-ac (A/C Power for 64K with 64K subscriber license subscriber) > $61,400 > E30-64-dc (DC Power for 64K with 64K Subscriber license Subscriber) > $61,300 > > Availabilty 2 weeks > > Regards > > > > > -- > David B Turner > > ============================================= > > Island Computers US Corp > PO Box 86 > Tybee GA 31328 > > Toll Free: 1-877 636 4332 x201, Mobile x251 > Email: dturner@islandco.com > International & Local: (001)- 404-806-7749 > Fax: 912 786 8505 > Web: www.islandco.com > > ============================================= > "John Smith" wrote in message > news:df6ce$486132e7$4c0aab67$11203@TEKSAVVY.COM... >> >> Does anyone here know ballpark pricing for these traffic shaping devices? >> >> Arbor Ellacoya e30: >> Support up to 64,000 subscribers at 4 Gbps speed. >> >> Arbor Ellacoya e100: >> Support up to 500,000 subscribers at 20 Gbps speed >> >> Thanks. >> > > ------------------------------ Date: Thu, 26 Jun 2008 01:26:47 -0400 From: "William Webb" Subject: Re: Network gear pricing Message-ID: <8660a3a10806252226x79f25e27l5d08b8f14515657@mail.gmail.com> On 6/25/08, John Smith wrote: > Thanks David. > > > "David" wrote in message > news:bjb8k.10111$AJ6.7838@bignews8.bellsouth.net... >> Ellacoya Product >> >> E30-64-ac (A/C Power for 64K with 64K subscriber license subscriber) >> $61,400 >> E30-64-dc (DC Power for 64K with 64K Subscriber license Subscriber) >> $61,300 >> >> Availabilty 2 weeks >> >> Regards >> >> >> >> >> -- >> David B Turner >> >> ============================================= >> >> Island Computers US Corp >> PO Box 86 >> Tybee GA 31328 >> >> Toll Free: 1-877 636 4332 x201, Mobile x251 >> Email: dturner@islandco.com >> International & Local: (001)- 404-806-7749 >> Fax: 912 786 8505 >> Web: www.islandco.com >> >> ============================================= >> "John Smith" wrote in message >> news:df6ce$486132e7$4c0aab67$11203@TEKSAVVY.COM... >>> >>> Does anyone here know ballpark pricing for these traffic shaping devices? >>> >>> Arbor Ellacoya e30: >>> Support up to 64,000 subscribers at 4 Gbps speed. >>> >>> Arbor Ellacoya e100: >>> Support up to 500,000 subscribers at 20 Gbps speed >>> >>> Thanks. >>> >> >> > John, Your new email address cracked me up. I know the John Smith at HP of whom you speak, he's a good guy. And I think you are, too. You've had more better VMS marketing ideas than anyone else I've ever known. Best regards, and I'd like to shake your hand one day. WWWebb > > ------------------------------ Date: Wed, 25 Jun 2008 14:17:39 -0700 (PDT) From: Rich Jordan Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: <9a535c56-dbe1-43bd-ae46-0127aacd153d@26g2000hsk.googlegroups.com> On Jun 25, 3:08=A0pm, JF Mezei wrote: > Bob Gezelter wrote: > > One can implement an "execute once" part of the login script, but that > > involves writing self-modifying DCL. > > Or the script deposits "I've been here" file in the users' SYS$LOGIN to > indicate his MIME file was already updated, so next time around, you can > just chck for existance of that file and skip the searching portion. > > Another option is to go through the SYSUAF and check every SYS$LOGIN for > the mime types file and update it and be done with it. You don't need to > then have stuff executing when people login. Not relevant to this situation but thanks for the continuing feedback. Only one single account has to have the MIME$FILETYPES.DAT file with appropriate records for this app. ------------------------------ Date: Wed, 25 Jun 2008 21:15:30 -0400 From: Robert Deininger Subject: Re: On the fly PCSI install needs to update text file on target system Message-ID: In article <7a8f340d-260f-4d78-bb03-52f7d319faad@r66g2000hsg.googlegroups.com>, Rich Jordan wrote: > On Jun 25, 8:35 am, Robert Deininger > wrote: > > In article > > <5b7465cb-292c-4807-b727-f8550cf08...@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. > > 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. It looks like this is correct. You can look in [VMS$COMMON]HP-*VMS-*.PCSI$DESCRIPTION to see what the VMS kit actually puts on a disk. MIME$FILETYPES.DAT is NOT listed. Does this file allow comments? You could append your stuff at the end of an existing file, with each line commented out, and some header material explaining where it came from, how to customize, pointer to documentation, etc. (Well-designed text-format data files should always allow for comments.) > 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. You could install FOO$FILETYPES.TEMPLATE unconditionally. (FOO is your product name.) And put MIME$FILETYPES.DAT on the disk with the PCSI WRITE option. WRITE means the user is expected to modify the file, so PCSI only creates the file if there's no existing copy. Look in the VMS kit's .PCSI$DESCRIPTION file. The entries for SYSTARTUP_VMS.COM and SYSTARTUP_VMS.TEMPLATE show how one familiar example is implemented. (You won't need this if you decide the user always needs to make the decision.) > > 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. That makes it easy. If you tell PCSI to put a file in [SYSMGR] with the default scope, it will go in [VMS$COMMON.SYSMGR]. > > Yes, there's a good reason it has to be SYSTEM and SYS$MANAGER. ------------------------------ Date: Wed, 25 Jun 2008 16:08:49 -0400 From: JF Mezei Subject: Re: On the fly PCSI install needs to update text file on target system systemsys Message-ID: <4862a5d5$0$8490$c3e8da3@news.astraweb.com> Bob Gezelter wrote: > One can implement an "execute once" part of the login script, but that > involves writing self-modifying DCL. Or the script deposits "I've been here" file in the users' SYS$LOGIN to indicate his MIME file was already updated, so next time around, you can just chck for existance of that file and skip the searching portion. Another option is to go through the SYSUAF and check every SYS$LOGIN for the mime types file and update it and be done with it. You don't need to then have stuff executing when people login. ------------------------------ Date: 25 Jun 2008 13:43:23 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: OT: Tru64 booting Message-ID: In article , "Tom Linden" writes: > 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? Generally, yes. And you may run into the same licensing issues if the spare box is more capable. I'd try it and see. ------------------------------ Date: Wed, 25 Jun 2008 19:41:49 -0700 From: "Tom Linden" Subject: Support for PL/I applications on OpenVMS Itanium Message-ID: We are pleased to announce that we have developed an environment facilitating the portation of PL/I applications running on VAX or Alpha to Itanium. Kednos is announcing the field test release of it's PL/I Run-Time Library for Translated Images on OpenVMS I64. This means that PL/I images originally compiled and linked under OpenVMS Alpha can now be translated using HP's OpenVMS Migration Software for Alpha to Integrity Servers (OMSAIS) and executed on OpenVMS I64. For more information see the Kednos website at: www.kednos.com For the announcement: http://www.kednos.com/pli/docs/announcements/pli_rtl_av-20080623.pdf The kit may be download from our website and instructions for obtaining a license are included there. What is next? Web enablement of existing PL/I aplications, coming soon. Tom Linden CEO -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 26 Jun 2008 00:17:55 -0400 From: "William Webb" Subject: Terminal servers and LANCP Message-ID: <8660a3a10806252117j3165ac38md4bec88ff6131bec@mail.gmail.com> Has anybody actually tried backing up and restoring terminal server configurations via LANCP in VMS 8.3 or newer? If so, I'd kill to see a sample script. Thanks WWWebb ------------------------------ Date: Wed, 25 Jun 2008 16:05:16 -0400 From: JF Mezei Subject: Re: Tru64 file system source code now open source Message-ID: <4862a501$0$8490$c3e8da3@news.astraweb.com> etmsreec@yahoo.co.uk wrote: > 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. Since the death of Tru64 was announced in Sept 7th 2001 (merger announcement), and the official HP takeover of Compaq was formalised on May 7th 2002, HP got an already dead product, just like Alpha. The word "developped" just doesn't fit well. "HP inherited Tru64" would be far more accurate. Same with Alpha. Did AOL develop Time Magazine ? ------------------------------ End of INFO-VAX 2008.354 ************************