INFO-VAX Wed, 08 Aug 2007 Volume 2007 : Issue 432 Contents: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity versions of VMS. Re: Alpha/Integrity versions of VMS. Re: Alpha/Integrity versions of VMS. Re: Easy DCL question PURGE vs. DELETE Re: Easy DCL question PURGE vs. DELETE Re: Integrity Workstations? Re: Integrity Workstations? messages Re: messages Re: OPA0 messages Re: OPA0 messages Re: OPA0 messages Re: OPA0 messages Re: OpenVMS and Smart Array Controllers Re: OpenVMS and Smart Array Controllers Re: OpenVMS and Smart Array Controllers Patch problem Re: Patch problem Re: REXX Re: REXX Re: Rexx for OpenVMS Re: TPU on MAC OS-X ? Re: TPU on MAC OS-X ? Re: VMS cluster behind a *NIX firewall Re: VMS cluster behind a *NIX firewall Re: Wonderful things happen to an OS when it has an internal champion ---------------------------------------------------------------------- Date: Wed, 08 Aug 2007 05:47:37 -0700 From: tadamsmar Subject: Alpha/Integrity Dead Pool Message-ID: <1186577257.443229.202970@19g2000hsx.googlegroups.com> The reason that we might want to upgrade to Integrity is that someday it will be hard to get replacements or maintenance for Alpha hardware (DS10ish systems in our case). I guess that date is probably 10 to 30 years out. Any better guesses? Anyway, if Integrity sales are poor and it gets discontinued, then Integrity will have a similar slow death. Will Alpha really die before Integrity? If not, then there is no real point in upgrading in order to forstall death. By die, of course, I mean become unreplacable and unmaintainable. ------------------------------ Date: Wed, 08 Aug 2007 05:59:34 -0700 From: "Tom Linden" Subject: Re: Alpha/Integrity Dead Pool Message-ID: On Wed, 08 Aug 2007 05:40:45 -0700, tadamsmar wrote: > The reason that we might want to upgrade to Integrity is that someday > it will be hard to get replacements or maintenance for Alpha hardware > (DS10ish systems in our case). > > I guess that date is probably 10 to 30 years out. Any better guesses? > > Anyway, if Integrity sales are poor and it gets discontinued, then > Integrity will have a similar slow death. > > Will Alpha really die before Integrity? If not, then there is no real > point in upgrading in order to forstall death. > > By die, of course, I mean become unreplacable and unmaintainable. > You could certainly stock up on spares as many VAX sites have done, but you will likely be out of luck on support and enhancements -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 08 Aug 2007 10:50:44 -0400 From: Stephen Hoffman Subject: Re: Alpha/Integrity Dead Pool Message-ID: tadamsmar wrote: > The reason that we might want to upgrade to Integrity is that someday > it will be hard to get replacements or maintenance for Alpha hardware > (DS10ish systems in our case). > > I guess that date is probably 10 to 30 years out. Any better guesses? > > Anyway, if Integrity sales are poor and it gets discontinued, then > Integrity will have a similar slow death. > > Will Alpha really die before Integrity? If not, then there is no real > point in upgrading in order to forstall death. > > By die, of course, I mean become unreplacable and unmaintainable. You're focusing on the hardware expenditures and on attempting to predict the future of a hardware and software platform, and -- for you and for most other folks -- the real costs here are usually in maintaining and upgrading the existing application software. Not in the hardware. Accumulations of Fortran or COBOL application code can be fairly portable. C code is usually somewhere between trivially portable and entirely unportable. C code with DECwindows calls can even be portable, depending on how many of the DIGITAL X Windows extensions and OpenVMS mechanisms got used, and how much of the C code stuff is straight C and X Windows calls. Accumulations of DCL, Macro32, TPU or VAXscan or other such are rather less portable. Though there are various approaches available here. Right now, there's no need to do anything; no need to act. What you do want to do here is to decide where you want to end up, and roughly how long you'll need to get there. Nobody here can answer that question, nor various of the other questions underlying the questions you have been asking here recently. If that's twenty years while remaining on OpenVMS and your applications, then you do want to look at spares and at long-term hardware. (HP and Compaq and DIGITAL before it all forecast out about five years or so. The current platform roadmap is out through 2012 or so, when last I looked. And then there's the whole "What happens if Intel cancels Itanium?" fear/FUD/concern/worry, this akin to Compaq's announcement around the end of Alpha some years back.) Regardless, you'll have some warning and some planning time. Figure out what this time is for you -- how long it will take for you to act, based on Bad News delivered, say, today If it's a decade, you'll want to spend more time and thought on remediation. If the time required for you to act on Bad News is, say, three or four years to work out a port, then you'll have rather less concerns over whatever future plans HP or Intel might have or whatever decisions might occur outside your control. In a small number of years, you can port your code. (Of course, then there's the discussion of what spending a few years on a port does to the rest of your business; what other costs are secondary to the cost of porting the code.) If you need or want to ensure continued service, you can certainly contract for it -- large-scale projects can and do plan for, for instance, manufacturing line or project lifetimes of fifteen or twenty years. Or you can stage for the support yourself. This because these projects last longer than the typical vendor product windows. If you can't afford such contracts, you can look to stock up on spares. Disks and power supplies are probably the most typical failures in general, though individual system can and often do have some unique weaknesses; some likely early failure(s). Some stuff can sneak up on you: latent disk size addressing limits, compatibility with older SCSI interconnects or older device command sets, etc. As for platform spares, AlphaServer DS10 and AlphaServer DS10L systems are currently widely available on the used-equipment market. And you can protect gear with battery-backed and/or conditioned power and similar mechanisms. Integrity gives you fairly low software costs and easier porting from an existing OpenVMS VAX or OpenVMS Alpha environment, and it's also the current-generation platform. Accordingly, it's likely to last a while, both new and used. Probably (at present) slightly longer than Alpha, just based on the differing vintages of the gear. (The longer Integrity and Itanium exists subsequent to Alpha, the better the choice.) Alpha systems are either refurb or new-old-stock starting earlier this year. Upgrades are available through next year. VAX systems are, well, still around and still in use. Spare parts and systems are widely available. Or you can decide you'll be porting sooner or later and start spending the money to work on application portability. (There's no return on this investment until and unless you port, however.) There's no simple answer. There's no short answer. And if somebody here does know a real answer to your "dead pool" -- and not something you'd get from a Magic Eightball as an answer -- they're unlikely to chime in here. Here are some related discussions: http://64.223.189.234/node/225 http://64.223.189.234/node/226 If you want to discuss this off-line, do contact me via email or such. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Wed, 8 Aug 2007 10:51:54 -0400 From: "David Turner, Island Computers" Subject: Re: Alpha/Integrity Dead Pool Message-ID: <13bjm3efppk6357@news.supernews.com> IN the case of DS10/DS10L systems, we are stockpiling these parts We have EVERYTHING for Alphaserver DS10 and DS10L Even down to LEDs and fans and side covers. All parts at massive discounts off list ! David "tadamsmar" wrote in message news:1186576845.885991.85450@w3g2000hsg.googlegroups.com... > The reason that we might want to upgrade to Integrity is that someday > it will be hard to get replacements or maintenance for Alpha hardware > (DS10ish systems in our case). > > I guess that date is probably 10 to 30 years out. Any better guesses? > > Anyway, if Integrity sales are poor and it gets discontinued, then > Integrity will have a similar slow death. > > Will Alpha really die before Integrity? If not, then there is no real > point in upgrading in order to forstall death. > > By die, of course, I mean become unreplacable and unmaintainable. > ------------------------------ Date: Wed, 08 Aug 2007 10:00:58 -0700 From: tadamsmar Subject: Re: Alpha/Integrity Dead Pool Message-ID: <1186592458.513478.7680@w3g2000hsg.googlegroups.com> On Aug 8, 10:50 am, Stephen Hoffman wrote: > tadamsmar wrote: > > The reason that we might want to upgrade to Integrity is that someday > > it will be hard to get replacements or maintenance for Alpha hardware > > (DS10ish systems in our case). > > > I guess that date is probably 10 to 30 years out. Any better guesses? > > > Anyway, if Integrity sales are poor and it gets discontinued, then > > Integrity will have a similar slow death. > > > Will Alpha really die before Integrity? If not, then there is no real > > point in upgrading in order to forstall death. > > > By die, of course, I mean become unreplacable and unmaintainable. > > You're focusing on the hardware expenditures and on attempting to > predict the future of a hardware and software platform, and -- for you > and for most other folks -- the real costs here are usually in > maintaining and upgrading the existing application software. Not in the > hardware. > > Accumulations of Fortran or COBOL application code can be fairly > portable. C code is usually somewhere between trivially portable and > entirely unportable. C code with DECwindows calls can even be portable, > depending on how many of the DIGITAL X Windows extensions and OpenVMS > mechanisms got used, and how much of the C code stuff is straight C and > X Windows calls. > > Accumulations of DCL, Macro32, TPU or VAXscan or other such are rather > less portable. Though there are various approaches available here. > > Right now, there's no need to do anything; no need to act. > > What you do want to do here is to decide where you want to end up, and > roughly how long you'll need to get there. > > Nobody here can answer that question, nor various of the other questions > underlying the questions you have been asking here recently. > > If that's twenty years while remaining on OpenVMS and your applications, > then you do want to look at spares and at long-term hardware. (HP and > Compaq and DIGITAL before it all forecast out about five years or so. > The current platform roadmap is out through 2012 or so, when last I > looked. And then there's the whole "What happens if Intel cancels > Itanium?" fear/FUD/concern/worry, this akin to Compaq's announcement > around the end of Alpha some years back.) > > Regardless, you'll have some warning and some planning time. Figure out > what this time is for you -- how long it will take for you to act, based > on Bad News delivered, say, today If it's a decade, you'll want to > spend more time and thought on remediation. If the time required for > you to act on Bad News is, say, three or four years to work out a port, > then you'll have rather less concerns over whatever future plans HP or > Intel might have or whatever decisions might occur outside your control. > In a small number of years, you can port your code. (Of course, then > there's the discussion of what spending a few years on a port does to > the rest of your business; what other costs are secondary to the cost of > porting the code.) > > If you need or want to ensure continued service, you can certainly > contract for it -- large-scale projects can and do plan for, for > instance, manufacturing line or project lifetimes of fifteen or twenty > years. Or you can stage for the support yourself. This because these > projects last longer than the typical vendor product windows. > > If you can't afford such contracts, you can look to stock up on spares. > Disks and power supplies are probably the most typical failures in > general, though individual system can and often do have some unique > weaknesses; some likely early failure(s). Some stuff can sneak up on > you: latent disk size addressing limits, compatibility with older SCSI > interconnects or older device command sets, etc. As for platform > spares, AlphaServer DS10 and AlphaServer DS10L systems are currently > widely available on the used-equipment market. And you can protect gear > with battery-backed and/or conditioned power and similar mechanisms. > > Integrity gives you fairly low software costs and easier porting from an > existing OpenVMS VAX or OpenVMS Alpha environment, and it's also the > current-generation platform. Accordingly, it's likely to last a while, > both new and used. Probably (at present) slightly longer than Alpha, > just based on the differing vintages of the gear. (The longer Integrity > and Itanium exists subsequent to Alpha, the better the choice.) Alpha > systems are either refurb or new-old-stock starting earlier this year. > Upgrades are available through next year. VAX systems are, well, still > around and still in use. Spare parts and systems are widely available. > > Or you can decide you'll be porting sooner or later and start spending > the money to work on application portability. (There's no return on > this investment until and unless you port, however.) > > There's no simple answer. There's no short answer. And if somebody > here does know a real answer to your "dead pool" -- and not something > you'd get from a Magic Eightball as an answer -- they're unlikely to > chime in here. > > Here are some related discussions: > > http://64.223.189.234/node/225http://64.223.189.234/node/226 > > If you want to discuss this off-line, do contact me via email or such. > > --www.HoffmanLabs.com > Services for OpenVMS That was a helpful post. I am trying to chart a course. Seems like we plan to stay on Alphas, then we should buy some spare DS10s soon and put them in storage. If I play Hamlet too long ("to be or not to be") they could get hard to find. (I will soon have one AlphaStation 400 retired to storage.) The two Alphas we have declared dead developed some sort of motherboard failure or flakeyness. They were both Alphastation 400s, about 10 years old, IIRC. Not sure what would kill a DS10, never seen one die. We have APC BACK-UPSes on all the Alphas. This protects them from short power outages that we get once or twice a year. ------------------------------ Date: 8 Aug 2007 08:50:28 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Alpha/Integrity versions of VMS. Message-ID: In article , JF Mezei writes: > > And it won't be long before VMS management starts to claim that they are > not seeing demand for new versions of VMS on Alpha (the same claim that > was used to justify killing the promise of a V8.* on VAX.) Sadly true. They don't see demands for things they don't market. They have all the forsight of the 3M manager who said there would be no market for post-it notes. None of the customers were asking for them. ------------------------------ Date: 8 Aug 2007 09:55:03 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Alpha/Integrity versions of VMS. Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , JF Mezei writes: >> >> And it won't be long before VMS management starts to claim that they are >> not seeing demand for new versions of VMS on Alpha (the same claim that >> was used to justify killing the promise of a V8.* on VAX.) > > Sadly true. They don't see demands for things they don't market. There is a significant difference because creating a new VAX version in parallel with a 64-bit version is significantly more work than creating a new Alpha 64-bit version in parallel with a 64-bit Itanium version. ------------------------------ Date: Wed, 08 Aug 2007 12:20:51 -0500 From: Ron Johnson Subject: Re: Alpha/Integrity versions of VMS. Message-ID: On 08/08/07 09:55, Larry Kilgallen wrote: > In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article , JF Mezei writes: >>> And it won't be long before VMS management starts to claim that they are >>> not seeing demand for new versions of VMS on Alpha (the same claim that >>> was used to justify killing the promise of a V8.* on VAX.) >> Sadly true. They don't see demands for things they don't market. > > There is a significant difference because creating a new VAX version > in parallel with a 64-bit version is significantly more work than > creating a new Alpha 64-bit version in parallel with a 64-bit Itanium > version. That just means there will just be that much less valid justification when They stop adding new features. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 08 Aug 2007 09:10:27 -0700 From: Doug Phillips Subject: Re: Easy DCL question PURGE vs. DELETE Message-ID: <1186589427.453314.125470@q3g2000prf.googlegroups.com> On Aug 7, 3:53 pm, norm.raph...@metso.com wrote: > Doug Phillips wrote on 08/07/2007 04:15:30 PM: > > > > > On Aug 7, 2:49 pm, bri...@encompasserve.org wrote: > > > In article > 006A3...@metso.com>, norm.raph...@metso.com writes: > > > > > bri...@encompasserve.org wrote on 08/07/2007 02:10:59 PM: > > > [snip] > > > >> Interaction of /KEEP with /BEFORE, /SINCE, /BY_OWNER, /EXCLUDE, etc: > > > > >> PURGE will always retain the highest existing file version > regardless > > > >> of any file selection criteria or /KEEP[=n] qualifier. > > > > >> PURGE will always retain all file versions that fail to match the > > > >> file selection criteria. The only versions that are candidates for > > > >> deletion are those that match all specified criteria. > > > > >> If /KEEP=1 or /KEEP is specified or defaulted along with one or more > > > >> file selection criteria then the retention of the highest existing > > > > version > > > >> satisfies the /KEEP qualifier. All lower versions that match the > > > >> selection criteria will be purged. > > > > >> If /KEEP=n is specified with n>1 along with one or more selection > > > >> criteria then in addition to the highest existing file version, > > > >> the next n-1 versions that match the selection criteria and > > > >> would thus have otherwise been purged will instead be retained. > > > >> All lower versions that match the selection criteria will be purged. > > > > [snip] > > > > So if I have this and use > > > > > PURGE/BEFORE="2-AUG-2007" FOO.BAR > > > > > FOO.BAR;15 7-AUG-2007 14:30:02.26 > > > > FOO.BAR;14 7-AUG-2007 12:30:02.51 > > > > FOO.BAR;13 7-AUG-2007 10:30:01.54 > > > > FOO.BAR;12 7-AUG-2007 06:30:03.77 > > > > FOO.BAR;11 6-AUG-2007 12:30:01.07 > > > > FOO.BAR;10 6-AUG-2007 10:30:02.25 > > > > FOO.BAR;9 6-AUG-2007 06:30:04.56 > > > > FOO.BAR;8 3-AUG-2007 12:30:01.06 > > > > FOO.BAR;7 3-AUG-2007 10:30:02.01 > > > > FOO.BAR;6 3-AUG-2007 06:30:03.75 > > > > FOO.BAR;5 2-AUG-2007 12:30:01.21 > > > > FOO.BAR;4 2-AUG-2007 10:30:02.12 > > > > FOO.BAR;3 2-AUG-2007 06:30:02.62 > > > > FOO.BAR;2 1-AUG-2007 12:30:01.11 > > > > FOO.BAR;1 1-AUG-2007 10:30:01.56 > > > > > will versions 2 and 1 be deleted, or > > > > just version 1? > > > > Playing fair and making the prediction before testing it... > > > > Both versions 2 and 1 will be deleted. > > > > /KEEP is not specified. That means /KEEP=1 > > > Version 15 is the highest existing version. It is retained. > > > That satisfies the /KEEP count. > > > All lower versions matching the /BEFORE will be deleted. > > > That means versions 2 and 1. > > > > And the test... > > > > Directory EISNER$DRA3:[DECUSERVE_USER.BRIGGS] > > > > FOO.BAR;19 7-AUG-2007 14:44:53.51 > > > FOO.BAR;18 7-AUG-2007 14:44:52.69 > > > FOO.BAR;17 7-AUG-2007 14:44:51.57 > > > FOO.BAR;16 7-AUG-2007 14:44:50.87 > > > FOO.BAR;15 7-AUG-2007 14:44:48.31 > > > FOO.BAR;14 7-AUG-2007 14:44:47.52 > > > FOO.BAR;13 7-AUG-2007 14:44:46.96 > > > FOO.BAR;12 7-AUG-2007 14:44:46.37 > > > FOO.BAR;11 7-AUG-2007 14:44:45.72 > > > FOO.BAR;10 7-AUG-2007 14:44:44.24 ! Not matching > > > FOO.BAR;9 7-AUG-2007 14:44:43.24 ! Matching > > > FOO.BAR;8 7-AUG-2007 13:01:12.37 ! Matching > > > > Total of 12 files. > > > $ purge foo.bar /before=14:44:44 /log > > > %PURGE-I-FILPURG, EISNER$DRA3:[DECUSERVE_USER.BRIGGS]FOO.BAR;9 deleted > (0 > > > blocks > > > ) > > > %PURGE-I-FILPURG, EISNER$DRA3:[DECUSERVE_USER.BRIGGS]FOO.BAR;8 deleted > (0 > > > blocks > > > ) > > > %PURGE-I-TOTAL, 2 files deleted (0 blocks) > > > $ > > > Yes, and the logic is: > > > FOO.BAR;19 7-AUG-2007 14:44:53.51 !new file; keep highest version; > > count=1 > > FOO.BAR;18 7-AUG-2007 14:44:52.69 !no match; skip > > FOO.BAR;17 7-AUG-2007 14:44:51.57 !no match; skip > > FOO.BAR;16 7-AUG-2007 14:44:50.87 !no match; skip > > FOO.BAR;15 7-AUG-2007 14:44:48.31 !no match; skip > > FOO.BAR;14 7-AUG-2007 14:44:47.52 !no match; skip > > FOO.BAR;13 7-AUG-2007 14:44:46.96 !no match; skip > > FOO.BAR;12 7-AUG-2007 14:44:46.37 !no match; skip > > FOO.BAR;11 7-AUG-2007 14:44:45.72 !no match; skip > > FOO.BAR;10 7-AUG-2007 14:44:44.24 !no match; skip > > FOO.BAR;9 7-AUG-2007 14:44:43.24 !Match; incr count; > > count.gt.keep; delete > > FOO.BAR;8 7-AUG-2007 13:01:12.37 !Match; incr count; > > count.gt.keep; delete > > > If you added: /KEEP=2 only FOO.BAR;8 would be deleted. /KEEP=3 and > > nothing would be deleted. > > Aha! ...but that's illogical. No wonder folks are conflicted. Makes you wonder why the HP folks have been so silent on this (and not just here.) Seems like *someone* in-the-know would explain it if there is an explanation. Do you suppose there's been just such a debate as this going on internally? Is there a purge-gate cover-up conspiracy? (and JF's door opens.) Or, does no one in HP see it as an issue worth discussing? ------------------------------ Date: Wed, 8 Aug 2007 12:40:41 -0400 From: norm.raphael@metso.com Subject: Re: Easy DCL question PURGE vs. DELETE Message-ID: Doug Phillips wrote on 08/08/2007 12:10:27 PM: > On Aug 7, 3:53 pm, norm.raph...@metso.com wrote: > > Doug Phillips wrote on 08/07/2007 04:15:30 PM: > > > > > >[snip >8] > > > > Aha! ...but that's illogical. No wonder folks are conflicted. > > > Makes you wonder why the HP folks have been so silent on this (and not > just here.) Seems like *someone* in-the-know would explain it if there > is an explanation. Do you suppose there's been just such a debate as > this going on internally? Is there a purge-gate cover-up conspiracy? > (and JF's door opens.) Or, does no one in HP see it as an issue > worth discussing? > > On fait ce q'on peut. ------------------------------ Date: Wed, 08 Aug 2007 13:39:12 +0200 From: Martin Krischik Subject: Re: Integrity Workstations? Message-ID: <46b9ab60$1@news.post.ch> urbancamo schrieb: > I have two 19" 1280x1024 panels at work. They were bought when > anything over 19" was three times the price of two panels. Same here. But for home I just got myself an HP 1920x1200 24" - real coool... Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ------------------------------ Date: Wed, 8 Aug 2007 09:21:00 -0400 From: "FredK" Subject: Re: Integrity Workstations? Message-ID: "Martin Krischik" wrote in message news:46b9ab60$1@news.post.ch... > urbancamo schrieb: > >> I have two 19" 1280x1024 panels at work. They were bought when >> anything over 19" was three times the price of two panels. > > Same here. But for home I just got myself an HP 1920x1200 24" - real > coool... > Yes indeed. Plus you can connect various video inputs besides your computer ;-) ------------------------------ Date: Wed, 08 Aug 2007 00:51:58 -0700 From: norbert Subject: messages Message-ID: <1186559518.463181.69920@l70g2000hse.googlegroups.com> Hi, how can i disable the message: "LPD Retrying failed job:........" or is there a way to redirect this kind of message into a file? Thank you ------------------------------ Date: Wed, 08 Aug 2007 11:35:55 +0200 From: Joseph Huber Subject: Re: messages Message-ID: norbert wrote: > how can i disable the message: "LPD Retrying failed job:........" > or is there a way to redirect this kind of message into a file? I assume this is part of an operator (OPCOM) message: OPCOM messages can be directed to a logfile, but not selectively: $ REPLY/LOG see HELP REPLY OPCOM messages can be disabled to go to Your terminal: LPD messages are probably of the PRINTER class: $ REPLY/DISABLE=PRINTER Of course one can disable OPCOM (and other broadcasts) at all: $ REPLY/DISABLE or for a terminal session: $ SET BROADCAST=NOOPCOM and of course for Your particular message: wouldn't it be better to resolve the LPD-problem itself instead to let it continue forever ? (stop/delete the job in question, stop/restart the queue, or whatever causes the problem.) -- Joseph Huber - http://www.huber-joseph.de ------------------------------ Date: Wed, 08 Aug 2007 05:36:03 -0700 From: "Tom Linden" Subject: Re: OPA0 messages Message-ID: On Tue, 07 Aug 2007 20:45:08 -0700, John Santos wrote: > JF Mezei wrote: >> What would have been nice, and much simpler would have been a /NOLOGIN >> qualifier to SET TERM. >> This would have made it obvious that no matter what data arrives on >> that port, a login process would not be started and the port would >> remain inactive. Yet, it would still allow an application to assign a >> port to it and use the remaining characteristics properly (including >> type ahead buffer which is necessary when dealing with high speed >> serial lines). >> BTW, also remember that /AUTOBAUD will result in a character >> being sent out the terminal port upon the terminal driver having >> received a identifiable character (normally a carriage return) which >> then allows the terminal driver to set the proper speed on the port. >> Normally, upon completion of this, the terminal driver then starts the >> login process. > > Generally, when you have a terminal port that you don't want to log in, > you either have to allocate it to a process or set it /notypeahead. I had it set that way. > > Since the process might die, get deleted, or might not have started yet, > here's what I do. > > 1) During system startup (before logins are enabled): > > $ set terminal TTA0:/notypeahead/permanent > > 2) Start up the control program. (This can be immediately, or on demand, > i.e. by using set terminal/dte or Kermit or whatever. Doesn't matter > if it is days or weeks after step 1, or only milliseconds later.) > > $ allocate TTA0: > $ set terminal TTA0:/typeahead > $ ! Note absence of /permanent! > $ set host/dte TTA0: > $ ! or Kermit or run an application > > The "allocate" and the "set terminal/typeahead" can be done with DCL > interactively or in a command file, or can be done in a program using > $ALLOC and $QIO with an IO$_SETMODE. (Don't use IO$_SETCHAR, that's > the > equivalent of "set term/permanent"!) > > 3) When done, or the process dies, or you log off, or you deallocate the > terminal, the permanent characteristics are automatically restored, > so > it reverts to /notypeahead. > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 8 Aug 2007 09:22:43 -0400 From: "FredK" Subject: Re: OPA0 messages Message-ID: "Tom Linden" wrote in message news:op.twp0vohnhv4qyg@murphus.linden... > On Tue, 07 Aug 2007 11:39:23 -0700, wrote: > >> In article , "Tom Linden" >> writes: >>> I tried NOINTERACTIVE following Fred's suggestion, but that did not >>> suppress it. Have now tried NOBROADCAST, and we'll see. >> >> As I've mentioned previously, /NOINTERACTIVE is synonymous with >> /PASSALL and is deprecated/obsolete. >> >> If you haven't already, you should probably turn /INTERACTIVE back >> on. > NOINTERACTIVE and NOBRADCAST didn't help > OK. From the expert: 1) On system doing set host $ allocate ttax $ set term/perm/type/nobroadcast/alt ttax 2) On system logging into $ set term/perm/noauto/secure opa0 ------------------------------ Date: Wed, 08 Aug 2007 07:33:49 -0700 From: "Tom Linden" Subject: Re: OPA0 messages Message-ID: On Wed, 08 Aug 2007 06:22:43 -0700, FredK wrote: > > "Tom Linden" wrote in message > news:op.twp0vohnhv4qyg@murphus.linden... >> On Tue, 07 Aug 2007 11:39:23 -0700, wrote: >> >>> In article , "Tom Linden" >>> writes: >>>> I tried NOINTERACTIVE following Fred's suggestion, but that did not >>>> suppress it. Have now tried NOBROADCAST, and we'll see. >>> >>> As I've mentioned previously, /NOINTERACTIVE is synonymous with >>> /PASSALL and is deprecated/obsolete. >>> >>> If you haven't already, you should probably turn /INTERACTIVE back >>> on. >> NOINTERACTIVE and NOBRADCAST didn't help >> > > OK. From the expert: > > 1) On system doing set host > > $ allocate ttax > > $ set term/perm/type/nobroadcast/alt ttax > Does this still work if the above is opa0 instead of tta0? > > > 2) On system logging into > > $ set term/perm/noauto/secure opa0 > > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 8 Aug 2007 12:12:25 -0400 From: "FredK" Subject: Re: OPA0 messages Message-ID: It should. Since the line is allocated, and broadcasts are blocked - there should not be an issue unless you halt/crash the system and need OPA0 ;-) "Tom Linden" wrote in message news:op.twqv2nrnhv4qyg@murphus.linden... > On Wed, 08 Aug 2007 06:22:43 -0700, FredK wrote: > >> >> "Tom Linden" wrote in message >> news:op.twp0vohnhv4qyg@murphus.linden... >>> On Tue, 07 Aug 2007 11:39:23 -0700, wrote: >>> >>>> In article , "Tom Linden" >>>> writes: >>>>> I tried NOINTERACTIVE following Fred's suggestion, but that did not >>>>> suppress it. Have now tried NOBROADCAST, and we'll see. >>>> >>>> As I've mentioned previously, /NOINTERACTIVE is synonymous with >>>> /PASSALL and is deprecated/obsolete. >>>> >>>> If you haven't already, you should probably turn /INTERACTIVE back >>>> on. >>> NOINTERACTIVE and NOBRADCAST didn't help >>> >> >> OK. From the expert: >> >> 1) On system doing set host >> >> $ allocate ttax >> >> $ set term/perm/type/nobroadcast/alt ttax >> > Does this still work if the above is opa0 instead of tta0? >> >> >> 2) On system logging into >> >> $ set term/perm/noauto/secure opa0 >> >> > > -- > PL/I for OpenVMS > www.kednos.com ------------------------------ Date: Wed, 08 Aug 2007 03:14:09 -0700 From: MattF Subject: Re: OpenVMS and Smart Array Controllers Message-ID: <1186568049.317571.246860@19g2000hsx.googlegroups.com> > On the subject of using SATA disks with VMS: > > I also tried a LSISAS1068-based controller and it worked on > my rx2620 with SATA drives with no changes to the system needed. > The system will boot from the disk but it VMS crashes shortly > into the boot. As with the P600 this isn't a problem for me > since I can boot from SCSI disks. > Out of curiousity, were the disks configured as a hardware RAID volume? (Playing around with VMware ESX - it would only accept SATA on the 1068's if the controller had the disks configured as a RAID (anything) volume - then the controllers 'logical volume' looks like SCSI to the host) Anyone know whether the LSISAS1068 cards work on Alpha? (seem to remember driver was there in 8.3 last time I checked) Unfortunately they're 3.3V only PCI-X cards so probably only something newer like a DS15 with 3.3V PCI slots. If they work, does anyone know of a 'cheap' 3.3V -> 5V 'shim' to allow the LSI 3.3V PCI-X cards to be used in older Alphaserver slots (5V)? The 1068 cards are low-profile so only a bit of bracket mangling would be needed if it actually worked MattF ------------------------------ Date: Wed, 08 Aug 2007 07:16:52 -0400 From: Robert Deininger Subject: Re: OpenVMS and Smart Array Controllers Message-ID: In article <7vbui.7695$dD3.456@trnddc07>, dittman@dittman.net wrote: > I notice the Smart Array 5302, 5304, 6402, 6404, and P400 > controllers are supported on OpenVMS but the P600 is not. > Was there a reason why support for the P600 wasn't added? Is P600 the PCI-X based SmartArray controller for SAS (and SATA) disks? I don't have my secret decoder ring handy to translate the code names (which I know) to product names (which I don't remember off the top). If I'm thinking of the right card, the main factor in the decision was to concentrate effort on fewer cards in order to get them ready for market sooner. The PCI-Express card was chosen over the PCI-X card. The SmartArray controllers are always a bit of a challenge for VMS (and HP-UX and linux). Our workloads tend to uncover firmware problems that don't matter in the Proliant environment where the controllers are first introduced. These have to be diagnosed and fixed, and new FW gotten into the supply chain and out to customers. Usually this happens a few times before the card is ready to support. There are known problems with older firmware on the controllers and disks. If the HW came from the Proliant supply chain, it doesn't necessarily have the right firmware. If it came from the Integrity supply chain, recently, it should be right. Since you're providing your own support, it's up to you to check, and upgrade the FW if necessary. AFAIK, the P600 did NOT get FW fixes matching the ones that went into it's relatives to permit VMS and Unix support. > I was looking at a way to add inexpensive large hard drives > to my home systems and thought the P600 would be ideal since > it works with SATA drives. I borrowed one to try and after > adding the PCI ID to SYS$SYSTEM:USER_CONFIG.DAT it does work > but not as a boot device. That's not a show-stopper for me > as there are a couple of SCSI drives in the system that are > used for the VMS system disk shadow set and a third hard > drive that's the dump device/scratch disk. You didn't specify: Integrity or Alpha? All bets are off on Alpha. > On the subject of using SATA disks with VMS: > > I also tried a LSISAS1068-based controller and it worked on > my rx2620 with SATA drives with no changes to the system needed. > The system will boot from the disk but it VMS crashes shortly > into the boot. As with the P600 this isn't a problem for me > since I can boot from SCSI disks. Last I heard, in informal use, HP SATA drives work just as well as HP SAS drives with these controllers. To maximize the likelihood of success, make sure you have: 1. VMS V8.3 with the latest patches. 2. The latest FW and EFI driver for your controller. 3. The latest FW for your disks. VMS hasn't formally qualified the SATA disks because the platform HW teams haven't done so. Even if VMS did all the OS testing required, there'd still be no supported systems to put the cards into. There could be FW problems lurking in the SATA disks that have been fixed in the SAS disks. At some point, Integrity servers and VMS may start supporting SATA disks. > Neither option is supported but I don't have support on the > systems. I did a lot of testing on the drives and didn't see > any issues but I have the data backed up to tape. ------------------------------ Date: Wed, 08 Aug 2007 09:34:04 -0700 From: etmsreec@yahoo.co.uk Subject: Re: OpenVMS and Smart Array Controllers Message-ID: <1186590844.210436.256070@o61g2000hsh.googlegroups.com> On 8 Aug, 05:19, ditt...@dittman.net wrote: > I notice the Smart Array 5302, 5304, 6402, 6404, and P400 > controllers are supported on OpenVMS but the P600 is not. > Was there a reason why support for the P600 wasn't added? > > I was looking at a way to add inexpensive large hard drives > to my home systems and thought the P600 would be ideal since > it works with SATA drives. I borrowed one to try and after > adding the PCI ID to SYS$SYSTEM:USER_CONFIG.DAT it does work > but not as a boot device. That's not a show-stopper for me > as there are a couple of SCSI drives in the system that are > used for the VMS system disk shadow set and a third hard > drive that's the dump device/scratch disk. > > On the subject of using SATA disks with VMS: > > I also tried a LSISAS1068-based controller and it worked on > my rx2620 with SATA drives with no changes to the system needed. > The system will boot from the disk but it VMS crashes shortly > into the boot. As with the P600 this isn't a problem for me > since I can boot from SCSI disks. > > Neither option is supported but I don't have support on the > systems. I did a lot of testing on the drives and didn't see > any issues but I have the data backed up to tape. > -- > Eric Dittman > ditt...@dittman.net In our experience at the moment, getting 5302A or 6402A cards is rather a challenge. They're on a lead time of weeks rather than days (i.e. like 6 weeks) if you can get them at all. :o( ------------------------------ Date: Tue, 07 Aug 2007 23:29:13 -0700 From: domen.setar@izum.si Subject: Patch problem Message-ID: <1186554553.510361.289670@l70g2000hse.googlegroups.com> Hi, I'm urgently looking for patch UPDATE V2.0 for OpenVMS V8.3 Alpha. Does anyone have this patch? Best regards Domen ------------------------------ Date: Wed, 08 Aug 2007 08:50:10 +0200 From: Martin Vorlaender Subject: Re: Patch problem Message-ID: <5ht7d1F3kl1ilU1@mid.individual.net> domen.setar@izum.si schrieb: > I'm urgently looking for patch UPDATE V2.0 for OpenVMS V8.3 Alpha. > Does anyone have this patch? Any good reason why you wouldn't want UPDATE V3.0? That one is available at ftp://ftp.itrc.hp.com/openvms_patches/alpha/V8.3/VMS83A_UPDATE-V0300.ZIPEXE For the sake of completeness, here's the list of ECOs that make up UPDATE V2.0: VMS83A_ACMELDAP-V0100 VMS83A_ADDENDUM-V0200 VMS83A_RMS-V0100 VMS83A_SECSRV-V0100 VMS83A_TZ-V0100 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://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin@radiogaga.harz.de ------------------------------ Date: Wed, 08 Aug 2007 14:21:25 +0200 From: Bernard Giroud Subject: Re: REXX Message-ID: <46b9b4b7$0$902$426a34cc@news.free.fr> Tom Linden a écrit : > As this has been mentioned by more than me, I wonder if anyone > knows who did the port to VMS of Regina, as mentioned on > following page. > > http://regina-rexx.sourceforge.net/ > AFAIR, when I needed to evaluate REXX on OpenVMS for my last employer (around may 2004), I just downloaded the kit and managed with a few mods to compile and run it, using the VMS conditionals already there. At that time, I send my mods to Mark, but I don't remember having received an ack from him. Hope this helps, -- Bernard Giroud 110, rte des Roguets FR-74930 PERS-JUSSY ------------------------------ Date: Wed, 08 Aug 2007 05:54:07 -0700 From: "Tom Linden" Subject: Re: REXX Message-ID: On Wed, 08 Aug 2007 05:21:25 -0700, Bernard Giroud wrote: > Tom Linden a écrit : >> As this has been mentioned by more than me, I wonder if anyone >> knows who did the port to VMS of Regina, as mentioned on >> following page. >> http://regina-rexx.sourceforge.net/ >> > > AFAIR, when I needed to evaluate REXX on OpenVMS for my last employer > (around may 2004), I just downloaded the kit and managed with a few mods > to compile and run it, using the VMS conditionals already there. At that > time, I send my mods to Mark, but I don't remember having received an > ack from him. > > Hope this helps, As I posted else where got following response from Mark and reproduce for convenience. Hi Tom, I did the port many years ago. I don't have access to a VMS machine anymore so can't tell you if it still compiles. But here are the contents of the README.VMS that comes with Regina: This is a preliminary version of Regina for OpenVMS. It has been tested on OpenVMS 6.1, 6.2 on VAX and AXP systems. To build Regina, you need MMK. This can be obtained from: ftp://ftp.wku.edu/ Run the build.com DCL script to compile and link Regina. This is a front-end to the MMK description file; descrip.mms. Things that don't work: - Stream BIF when the target is a directory. This is due to the C runtime funtion stat() not behaving the same as on other operating systems. - Time('O') does not work. The C runtime function gmtime() does not return valid values. - Uname BIF doesn't return anything. - Execution of external commands crash Regina. Same deal with THE. It ported some years ago, but unsure of its current status. For both packages you have to build it yourself from the source. Cheers, Mark -------------------------------------------------------------- Mark Hessling http://www.rexx.org/ Author of THE, Rexx/SQL, Rexx/cURL, Rexx/gd, Rexx/DW, Rexx/curses, etc.. Maintainer of Regina Use Rexx ? Join the Rexx Language Association: http://www.rexxla.org/ Google Earth: 27 43' 43.10"S,153 02'20.03"E -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 08 Aug 2007 19:08:12 +0200 From: krischik@users.sourceforge.net Subject: Re: Rexx for OpenVMS Message-ID: <8730409.ys5V6uXsJ9@linux1.krischik.com> Tom Linden wrote: > On Tue, 07 Aug 2007 11:10:25 -0700, > wrote: > >> Tom Linden wrote: >> >>> Is this available? >> >> I would just love that as well. And if you google for "OpenVMS REXX" >> there >> are in fact hits. Only there seem to be no download available :-( . >> >> Martin > > I got following reply from mark Hessling in private mail > > Hi Tom, > > I did the port many years ago. I don't have access to a VMS machine > anymore so can't tell you if it still compiles. But here are the contents > of the README.VMS that comes with Regina: > > This is a preliminary version of Regina for OpenVMS. It has been tested > on OpenVMS 6.1, 6.2 on VAX and AXP systems. > > To build Regina, you need MMK. This can be obtained from: > ftp://ftp.wku.edu/ > > Run the build.com DCL script to compile and link Regina. This is a > front-end to the MMK description file; descrip.mms. > > Things that don't work: > > - Stream BIF when the target is a directory. This is due to the C runtime > funtion stat() not behaving the same as on other operating systems. > - Time('O') does not work. The C runtime function gmtime() does not > return valid values. > - Uname BIF doesn't return anything. > - Execution of external commands crash Regina. Sad, as it is the most interesting feature of the "REstructured eXtended eXecutor". An executor which can't execute anthing is pretty useless. It it worked REXX would have been a cool extension to DCL as Rexx has this unique feature of passing on unused strings return values to the command prompt or the editor - or whereever Rexx was embedded into. This is what makes Rexx so usefull: Rexx is designed to be embedded into another tool. > Same deal with THE. It ported some years ago, but unsure of its current > status. > > For both packages you have to build it yourself from the source. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ------------------------------ Date: Wed, 08 Aug 2007 05:38:14 -0400 From: JF Mezei Subject: Re: TPU on MAC OS-X ? Message-ID: Jim Duff wrote: > erm, see TPU procedure CALL_USER? It's trivial to implement logical > name and symbol functions using a user written program. Yeah, standard answer for an operating system that won't see user level improvements: WRITE YOUR OWN. If TPU had built in access to logicals and symbols as had been requested many times back where there was still some hope of seeing improvements made, it would make the TPU language much more versatile and it might have made the language far more popular to build apps other than just customizing your editor. Lets face it, the only "priorities" left at VMS management is ensuring VMS runs and supports the hardware that HP tells it to support. Any other improvements are just icing on the cake if they have time for it. And you don't see much improvements to any X applications on VMS, mostly because they were declared "mature" long ago and maintenance shifted to another continent where their only role is to compile and test it for each new version. Not happy that I say these things ? Tough luck. It is reality. Wake up and smell the coffee. ------------------------------ Date: Wed, 08 Aug 2007 15:30:59 +0200 From: "P. Sture" Subject: Re: TPU on MAC OS-X ? Message-ID: In article <1615375.22NOzJ5N3m@linux1.krischik.com>, Martin Krischik wrote: > Bob Koehler wrote: > > > As many products in many industries have proven, being stable is not > > the same as being dead. > > Depends on your definition on dead and stable. Mine is defined around the > German proverb "Stillstand ist Rückschritt" - which translates to "To stand > still is to go back" (because everybody else around you move foreward). > > Which in turn means that to keep stable you have to move foreward at a > moderate rate and if you don't move foreward at all you are - or soon will > be - dead. > Software is usually a compromise. Getting it right can be knowing when to stop. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Wed, 08 Aug 2007 10:26:27 -0000 From: Thomas Dickey Subject: Re: VMS cluster behind a *NIX firewall Message-ID: <13bj6ijnf8vprc8@corp.supernews.com> David J Dachtera wrote: > You'll want to look into SMG. See the following... >> but all of them are complex > Not much worse than "termcap" and "curses", really... ...but certainly far more limiting. If the terminal supports features not explicitly in one of DEC's terminals, SMG doesn't support it. For the things it was designed to do in 1985, SMG is adequate. (On the other hand, if all one knows of curses is what SMG supports, then sure - they look the same ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ------------------------------ Date: Wed, 08 Aug 2007 10:35:09 -0000 From: Thomas Dickey Subject: Re: VMS cluster behind a *NIX firewall Message-ID: <13bj72tdpkg31b6@corp.supernews.com> Thomas Dickey wrote: > David J Dachtera wrote: >> You'll want to look into SMG. See the following... >>> but all of them are complex >> Not much worse than "termcap" and "curses", really... > ...but certainly far more limiting. If the terminal supports features > not explicitly in one of DEC's terminals, SMG doesn't support it. > For the things it was designed to do in 1985, SMG is adequate. > (On the other hand, if all one knows of curses is what SMG supports, > then sure - they look the same ;-) to refresh your memory - and perhaps motivate you into learning more about the topic: http://unix.derkeiler.com/Newsgroups/comp.sys.dec/2005-05/0051.html' or http://mvb.saic.com/freeware/info-vax/2005_273.txt -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ------------------------------ Date: 8 Aug 2007 17:04:07 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <5hubc7F3lq3t9U1@mid.individual.net> In article , david20@alpha2.mdx.ac.uk writes: > In article <752c3$46b8b34e$cef8887a$5871@TEKSAVVY.COM>, JF Mezei writes: >>Bill Gunshannon wrote: >>> Never gonna happen!!! HP will never sell it and IBM would never want it. >> >>As long as the idiot middle managers keep on brainwashing Hurd that they >>can retain VMS customers and move them to HP-UX, then Hurd isn't going >>to consider selling VMS. >> >>If, on the other hand, it would be made very clear to Hurd that those 2 >>idiots are manipulating him and that not growing VMS means losing those >>customers to competitors, then HP might see an advantage of selling VMS >>to a friendly outfit. This way, HP gets some money from the sale of VMS >>and its custormers and wouldn't be giving more market share to IBM/Sun. > > If VMS ran on industry standard x86-64 or on Power then just maybe IBM might be > interested for the right price. But running on Itanic ? This concept has come up before but never really been asnwered. Why would IBM want to see anything other than the final death of VMS? (And they don't need top buy it for that, HP is doing just fine on it's own.) Where, exactly, do people here see a hole in IBM's offerings that could be filled by VMS? They already cover desktop to mainframe, what more could they want that owning VMS would give them? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ End of INFO-VAX 2007.432 ************************