INFO-VAX Fri, 29 Feb 2008 Volume 2008 : Issue 119 Contents: DCPS downloadable? Re: Eunice Re: Eunice (was: Wollogong TCP/IP stack) Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff OpenVMS & Oracle BLOBS Re: OT: Universal healthcare in England failing - boy dies ! Wide drives on VAXstation 4000-60 WYSE-160 Setup Question Re: WYSE-160 Setup Question Re: WYSE-160 Setup Question Re: WYSE-160 Setup Question ---------------------------------------------------------------------- Date: Thu, 28 Feb 2008 15:13:25 -0800 (PST) From: Rich Jordan Subject: DCPS downloadable? Message-ID: <7da53c14-68b5-49d1-a774-13ef37d0e0b9@s37g2000prg.googlegroups.com> I think the answer is 'no' but I thought I'd ask. Since DSPP discontinued the Alpha media kit as part of the service, severely downgrading their usefulness to us, we only get very rare updates. Usually when a new OS release comes out we'll get the next quarterly kit. OpenVMS Alpha V8.3 includes DCPS 2.5 on the layered products disk. I've been asked to see if getting V2.6 is possible without spending unhealthy gobs of money on a CONDIST set. If it still isn't I'll just tell them they need to shell out some more cash. I'll echo an earlier post here on this subject; it would be awfully nice if HP made layered products that are licensed with the OS available without spending so much on a media kit. Thanks Rich ------------------------------ Date: Thu, 28 Feb 2008 19:31:11 GMT From: John Santos Subject: Re: Eunice Message-ID: <3_Dxj.9180$xg6.871@trnddc07> Bob Koehler wrote: > In article , John Santos writes: > >>Not necessarily! It depends on the implementation. Fork() could record >>the current I/O state of all the open channels, pass it to the spawned >>process, and during startup, replicate the i/o state. > > > Which would fail since VMS by default opens many I/O channels for > exclusive access. VMS doesn't open any channels if you don't let it... As I hinted at in the part you snipped out, you need to include the necessaries in the unix-emulating i/o library that is also part of your package. You don't need a complete unix virtual machine in the process. If someone goes behind your back and accesses VMS files (or other I/O) directly, then fork() wouldn't work, but that same code would definitely *not* work on any Unix system either. > Yes, you could achieve the affect by emulating an entire UNIX kernel > inside on process, except that then everyone who logged onto EUNICE > would see themselves as having a separate virtual machine. > No, the separate VMS processes running the unix emulator could co-operate. They wouldn't all have to be running inside one process to do so. (They would have to share a lot of information, though.) Emulating an entire unix system within a single VMS process was the 2nd option that I described. > When you logged onto EUNICE, you got a csh prompt and some UNIX-like > libraries, not you own machine. I wasn't saying Eunice worked this way (or either of these ways, since there were 2 of them), but that it was possible to implement a unix-like fork() without messing around with the VMS kernel. I vaguely remember encountering Eunice in some previous millennium, but I don't think I ever actually did any work using it, probably just a demo or helping a friend with something. I have no idea how it worked under the hood. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 28 Feb 2008 21:03:18 -0000 From: "John Wallace" Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <13se8dl4u2goie9@corp.supernews.com> "Bill Gunshannon" wrote in message news:62nvojF23m54kU2@mid.individual.net... > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > In article , John Santos writes: > >> > >> Not necessarily! It depends on the implementation. Fork() could record > >> the current I/O state of all the open channels, pass it to the spawned > >> process, and during startup, replicate the i/o state. > > > > Which would fail since VMS by default opens many I/O channels for > > exclusive access. > > > > Yes, you could achieve the affect by emulating an entire UNIX kernel > > inside on process, except that then everyone who logged onto EUNICE > > would see themselves as having a separate virtual machine. > > > > When you logged onto EUNICE, you got a csh prompt and some UNIX-like > > libraries, not you own machine. > > That was the part I couldn't remember. I thought there was more to it than > just a shell and commands because that wouldn't result in it being so slow. > If it was merely a shell and commadns then doing an "ls" under "csh" should > not have been any slower than doing a "dir" under "DCL". But it was. > Painfully slower!! That was the reason most people I knew abandoned it in > favor of getting their own small Unix systems (like CT Miniframe, Tandy-6000. > Sage, etc.) > > But, looking back at your second paragraph. In this day of > "virtualization". Is this not a possible solution to the > "How do I run OpenOffice under VMS" question? Surely the > systems are fast enough today that better than acceptable > performance could be delivered. Of course, this comes back > to my past comments on The Software Tools Virtual Operating > System project. Maybe this is another of those things which > wasn't practical at the time it started but technology has now > caught up to it. > > 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 1) What could the Software Tools Virtual OS project do right that the various POSIX people didn't? On paper it ought to be a whole load easier to get a set of *specifications* approved, and leave the implementation to others, but that didn't quite happen with POSIX in the way it did with (say) the Internerd RFCs. 2) Whither DEC's own VMS Posix? Surely whatever it did with fork would be the definitive implementation for use on VMS??? 3) Processors have indeed got faster, and virtualisation more widely used, but that relies in part on not having to emulate the non-privileged instruction set in the guest environment. Surely you're not suggesting a return to SoftPC-class setups where every instruction requires emulation, or even FX!32 -class setups where every group of instructions needs on-the-fly translation? Although processors have got faster, software has got also fatter/slower (at least the stuff which the big names try to push), and in my experience today's low/mid-range PCs doing run of the mill stuff don't actually *feel* that much faster than something from five or ten years ago. 4) CT Miniframe, thank you, I think that was the name of the rather unstable 68k/System V implementation I referred to a few days back. A couple of other reasons this wasn't preferred over VMS were (1) the VMS software development environment, especially once the V4 debugger came out (2) our Miniframe was 68010 based and therefore iirc it didn't do demand paged virtual memory, just swapping. Even when compared with a lowly VAX11/725, the Miniframe was the loser (the OS on this box may not have been CT's own CTIX, because ours was going to be rebadged by Gould once the bugs had been ironed out) ------------------------------ Date: Thu, 28 Feb 2008 14:41:09 -0500 From: JF Mezei Subject: Re: Long term archiving of VMS stuff Message-ID: <47c70e9d$0$1452$c3e8da3@news.astraweb.com> BobH wrote: > If there are no VMS systems left to read the files, then there should be > only minimal need for examples of how to do things on VMS. :-) Just because I might no longer have a running VMS system doesn't mean that I would no longer get requests for CMUIP patches for instance. They would be served from a non-VMS platform without access to "BACKUP". ------------------------------ Date: 28 Feb 2008 17:53:22 -0500 From: Rich Alderson Subject: Re: Long term archiving of VMS stuff Message-ID: VAXman- @SendSpamHere.ORG writes: > In article , Rich Alderson > writes: >> JF Mezei writes: >> .... >>> Since BACKUP save sets are essentially proprietary to VMS, one can't >>> move those savesets to a platform that will outlive VMS and expect to >>> ever be able to unpack those savesets in the future. >> .... >>> Any recommendation on which of those I should use, and whether there >>> might be other formats I could choose ? >> Let me second the recommendation of SimH virtual disk and virtual tape >> images. If need be, package a copy of the SimH souces with them. >> Use a ZIP or StuffIt! program to compress them for space savings, if you >> like. NB: StuffIt! provides tar, zip, and other archive formats as well as >> its own proprietary ones. > ...and 20 years from now do you believe that there will still be a Weendoze > box that will run this? I don't care if there's a Windows box that will run this *today*. JF Mezei indicates that he's moving to a Macintosh. Do I think that there will be systems running either Apple or Microsoft OSes in 20 years? I do not. Do I think that, because of the harsh learning curve WRT software preservation that those of us who care about such things have had, there will be tools to handle those formats on whatever systems are in use at that time? I think probably so. Do I think JF Mezei will wait 20 years before migrating off the Macintosh he's currently moving to? I do not, and I believe that he will make whatever arrangements are necessary to get to the next stage when the time comes. -- Rich Alderson "You get what anybody gets. You get a lifetime." news@alderson.users.panix.com --Death, of the Endless ------------------------------ Date: 28 Feb 2008 17:57:26 -0500 From: Rich Alderson Subject: Re: Long term archiving of VMS stuff Message-ID: VAXman- @SendSpamHere.ORG writes: > In article <47c622af$0$90264$14726298@news.sunsite.dk>, > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> VAXman- @SendSpamHere.ORG wrote: >>> In article , Rich Alderson >>> writes: >>>> JF Mezei writes: >>>> .... >>>>> Since BACKUP save sets are essentially proprietary to VMS, one can't >>>>> move those savesets to a platform that will outlive VMS and expect to >>>>> ever be able to unpack those savesets in the future. >>>> .... >>>>> Any recommendation on which of those I should use, and whether there >>>>> might be other formats I could choose ? >>>> Let me second the recommendation of SimH virtual disk and virtual tape >>>> images. If need be, package a copy of the SimH sou ces with them. ^^^^ ^^^r^^^ >>>> Use a ZIP or StuffIt! program to compress them for space savings, if you >>>> like. NB: StuffIt! provides tar, zip, and other archive formats as well >>>> as its own proprietary ones. >>> ...and 20 years from now do you believe that there will still be a Weendoze >>> box that will run this? >> Neither tar or zip is windows specific. > No, but 'tar'ring or 'zip'ping a SimH setup which will run on Weendoze > would imply some Weendoze specificity. Where in all the above, other than in your own fevered imagination, do you see a recommendation that a Windows binary of the SimH VAX simulator be included? I've left you a hint above, if you can find it. -- Rich Alderson "You get what anybody gets. You get a lifetime." news@alderson.users.panix.com --Death, of the Endless ------------------------------ Date: Fri, 29 Feb 2008 10:31:58 +1100 From: Phaeton Subject: Re: Long term archiving of VMS stuff Message-ID: <47c7446f$1_4@news.chariot.net.au> Stanley F. Quayle wrote: > On 27 Feb 2008 at 22:14, Arne Vajhøj wrote: >> And would not be surprised if it was difficult to read CD's in 20 years. > > A friend of mine has a theory about this. If a medium is "ubiquitous" (present > everywhere), it'll be readable for a long, long, time. His examples: > > - 9-track tape vs. TK50 > - Open reel audio tape vs. wire recording > - 8-track tape vs. cassette ? This might be the case in the US, but the rest of the world has clearly embraced the audio cassette, IMHO. > - VHS vs. Betamax > - Floppy vs. magneto-optical > > Millions of CD/DVD/HD DVD/Blueray drives have been sold, all of which can read a CD. I > believe that newly-developed drives will continue to read a CD for many, many years. > > --Stan Quayle > Quayle Consulting Inc. Cheers, Csaba ---------------------------------------------------------------------------------- |d|i|g|i|t|a|l| http://csabaharangozo.blogspot.com ---------------------------------------------------------------------------------- EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]: Heller's Law : The first myth of management is that it exists. ------------------------------ Date: Thu, 28 Feb 2008 19:12:19 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Long term archiving of VMS stuff Message-ID: <47c74de5$0$90274$14726298@news.sunsite.dk> VAXman- @SendSpamHere.ORG wrote: > In article <47c622af$0$90264$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> VAXman- @SendSpamHere.ORG wrote: >>> In article , Rich Alderson writes: >>>> JF Mezei writes: >>>> >>>> .... >>>>> Since BACKUP save sets are essentially proprietary to VMS, one can't >>>>> move those savesets to a platform that will outlive VMS and expect to >>>>> ever be able to unpack those savesets in the future. >>>> .... >>>>> Any recommendation on which of those I should use, and whether there >>>>> might be other formats I could choose ? >>>> Let me second the recommendation of SimH virtual disk and virtual tape images. >>>> If need be, package a copy of the SimH souces with them. >>>> >>>> Use a ZIP or StuffIt! program to compress them for space savings, if you like. >>>> NB: StuffIt! provides tar, zip, and other archive formats as well as its own >>>> proprietary ones. >>> ...and 20 years from now do you believe that there will still be a Weendoze >>> box that will run this? >> Neither tar or zip is windows specific. > > No, but 'tar'ring or 'zip'ping a SimH setup which will run on Weendoze > would imply some Weendoze specificity. Ah - it was the simh part. I belive simh runs on other OS's as well. >> (but MS would need to make a real big fuckup to ensure there will be no >> Windows systems around in 20 years) > > Like VISTA? Vista is only selling 10 million copies per months, which is below expectations. But a company does not go down by *only* selling 10 million licenses per months. Arne ------------------------------ Date: Thu, 28 Feb 2008 23:43:57 -0500 From: "Stanley F. Quayle" Subject: Re: Long term archiving of VMS stuff Message-ID: <47C7473D.5450.1211FA8C@infovax.stanq.com> On 29 Feb 2008 at 10:31, Phaeton wrote: > > - 8-track tape vs. cassette > > ? This might be the case in the US, but the rest of the world has clearly > embraced the audio cassette, IMHO. Sorry, had those swapped. That you recognized my error proves the case... --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: Thu, 28 Feb 2008 15:22:15 -0800 (PST) From: rcyoung Subject: OpenVMS & Oracle BLOBS Message-ID: Does anyone have some examples of extracting jpg, doc,txt files from an Oracle BLOB field under OpenVMS using ProC? I have put in some requests re this over in the Oracle groups, but 99.999% of the people there are Unixers/Windowers and many things do not apply ( or other things like setting logicals DO!) to OpenVMS! bob y ------------------------------ Date: Thu, 28 Feb 2008 20:37:52 -0600 From: David J Dachtera Subject: Re: OT: Universal healthcare in England failing - boy dies ! Message-ID: <47C77000.71A7D92D@spam.comcast.net> ultradwc@gmail.com wrote: > > here is a glance of things to come if Hillary or Obama implement > their healthcare plan ... the bbc did not report it but a teen died > while waiting on an ambulance that was setting at the hospital > with a patient inside because the hospitals were full and did not > want to violate a government mandate of a 4 hour must treat law. > > Canada people coming here ... England people that have the money > flying to India to have surgery ... > > don't worry, those rich liberal Harvard grads will be able to afford > it while those they claim to want to help will be dying waiting for > an ambulance ... > > that what socialism does, it ruins a country ... > > http://news.bbc.co.uk/1/hi/uk/7249514.stm (Relax, folks, Boob is just trying to up the post tallies for this year to stem the downward spiral of VMS. Maybe the "MI5" guy will help him out.) ------------------------------ Date: Fri, 29 Feb 2008 00:23:42 -0600 From: Chris Scheers Subject: Wide drives on VAXstation 4000-60 Message-ID: <62pmndF24fq2fU1@mid.individual.net> I have a need to set up a VAX test environment with 4GB drives. I have a VAXstation 4000-60 available as the test bed. Unfortunately, I do not have narrow RZ29 drives. I do have several RZ29B-VWs available. I know I can't use RZ29B-VWs in a BA350. (I tried it anyways, it still doesn't work.) I set up a BA356 with a BA35X-MG (8 bit) card. (There are previous usenet reports of this working with RZ29B-VWs and a MicroVAX 3100/98.) With the BA35X-MG card, the VAXstation 4000-60 can still only see narrow drives in the BA356. It does not see the RZ29B-VWs, even if one of these is the only drive in the chassis. The BA356 appears to be terminated correctly. It has a 16 bit terminator behind slot 1 and no card behind slot 7. Can anyone provide a suggestion on how to get this to work? Is there some switch setting I am missing? Thanx! -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074 ------------------------------ Date: Thu, 28 Feb 2008 19:42:52 -0800 (PST) From: Chuck Moore Subject: WYSE-160 Setup Question Message-ID: <392f9ff7-6a1e-4d32-b20c-f4123fa06de7@u10g2000prn.googlegroups.com> Hi, If anyone out on this group has a Wyse-160 connected to an Alpha/Vax, please contact me. I've not been able to get my Wyse-160 working. My Wyse-160 is connected to serial port 1 of my Alpha (the upper one of the two that came with the Alpha). I normally connect my VT420 to this port for booting the system, so I know the port works. The Wyse-160 is set for VT220-8 "personality" with a VT220 ID (see http://www.wyse.com/service/support/kbase/Setup1.asp?Q=17 section "General Level" if you're wondering what a "personality" is). I've tried VT220-7 and VT100, with no results. Chuck ------------------------------ Date: Thu, 28 Feb 2008 21:54:33 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: WYSE-160 Setup Question Message-ID: <08022821543372_206707C4@antinode.org> From: Chuck Moore > If anyone out on this group has a Wyse-160 connected to an Alpha/Vax, > please contact me. I've not been able to get my Wyse-160 working. > > My Wyse-160 is connected to serial port 1 of my Alpha (the upper one > of the two that came with the Alpha). I normally connect my VT420 to > this port for booting the system, so I know the port works. The > Wyse-160 is set for VT220-8 "personality" with a VT220 ID (see > http://www.wyse.com/service/support/kbase/Setup1.asp?Q=17 section > "General Level" if you're wondering what a "personality" is). I've > tried VT220-7 and VT100, with no results. "[M]y Alpha" is not a well-defined object. Knowing nothing about how you're connecting this thing, I'd worry more about the cable and the speed settings than I would about the personality. What do "show term tta0" and "show term ttb0" say? Have you tried both ports? What are the terminal settings? If you connect the TxD and RxD pins (2 and 3?) on the cable (instead of connecting it to the Alpha), can the terminal talk to itself? Have you tried a null-modem cable? (DEC (and related) computers tend to have DTE terminal ports, just like terminals, so a null modem is normally needed to connect the DTE terminal to the DTE computer port.) If you own a voltmeter, it's fairly easy to tell TxD (relatively big voltage) from RxD ((relatively small voltage) on each side. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 28 Feb 2008 22:09:18 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: WYSE-160 Setup Question Message-ID: <08022822091834_206707C4@antinode.org> From: Chuck Moore > My Wyse-160 is connected to serial port 1 of my Alpha (the upper one > of the two that came with the Alpha). [...] Which port on the WY-160? This page looks more useful than yours: http://www.wyse.com/service/support/kbase/Intface1.asp?Q=17 ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 29 Feb 2008 04:16:20 GMT From: Michael Austin Subject: Re: WYSE-160 Setup Question Message-ID: Chuck Moore wrote: > Hi, > > If anyone out on this group has a Wyse-160 connected to an Alpha/Vax, > please contact me. I've not been able to get my Wyse-160 working. > > My Wyse-160 is connected to serial port 1 of my Alpha (the upper one > of the two that came with the Alpha). I normally connect my VT420 to > this port for booting the system, so I know the port works. The > Wyse-160 is set for VT220-8 "personality" with a VT220 ID (see > http://www.wyse.com/service/support/kbase/Setup1.asp?Q=17 section > "General Level" if you're wondering what a "personality" is). I've > tried VT220-7 and VT100, with no results. > > Chuck > Personality does not make a whole lot of difference - that is only used when you do a "set term/inquire". Your port speed or bits/parity may not be set correctly or the cable is different. ------------------------------ End of INFO-VAX 2008.119 ************************