1 INFO-VAX	Mon, 08 Aug 2005	Volume 2005 : Issue 440       Contents:" Re: "the normal ordering process"?? Re: Alpha Server 1200: first install VMS then upgrade firmware?   CI, Gigaswitch hardware for sale Re: EFI is out to lunch  Re: EFI is out to lunch  Re: EFI is out to lunch 7 how to get rid of "explicit carriage returns" in a file ; Re: how to get rid of "explicit carriage returns" in a file ; Re: how to get rid of "explicit carriage returns" in a file / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive 7 Re: Killing a process that has allocated the tape drive  lib$ tree routines Re: Newbie DCL Question F Re: OpenVMS under the umbrella - or umbrella is supported at the time? PERL Re: PERL+ Re: strange terminal-characteristic problem + Re: strange terminal-characteristic problem + Re: strange terminal-characteristic problem + Re: strange terminal-characteristic problem J Wendy Koenig (was Re: Killing a process that has allocated the tape drive)  F ----------------------------------------------------------------------  # Date: Mon, 08 Aug 2005 10:57:15 GMT " From:   VAXman-  @SendSpamHere.ORG+ Subject: Re: "the normal ordering process"? 0 Message-ID: <00A47F6E.DF51AF76@SendSpamHere.ORG>  g In article <8660a3a1050807200330e685d7@mail.gmail.com>, William Webb <william.w.webb@gmail.com> writes: F >On 8/7/05, VAXman-@sendspamhere.org <VAXman-@sendspamhere.org> wrote:M >> In article <AGwJe.10204$WQ.467@trnddc03>, John Santos <john@egh.com> writ=  >es: >> >Larry Kilgallen wrote:M >> >> In article <BF1681F1.11C2A%roktsci@comcast.net>, Jeff Cameron <roktsci=  >@comcast.net> writes: >> >> M >> >>>On 8/2/05 1:57 PM, in article 00A47B0B.AE905A81@SendSpamHere.ORG, "VAX=  >man- < >> >>>@SendSpamHere.ORG" <VAXman-  @SendSpamHere.ORG> wrote: >> >>> >> >>>M >> >>>>OK... I need to break down and get myself a copy of the OpenVMS Itani=  >um ; >> >>>>source listings.  On one of the /DSPP pages it says:  >> >>>> L >> >>>>DSPP does not provide listings kits.  Partners may order them from HPM >> >>>>through the normal ordering process.  Part numbers are provided below=  >..  >> >>>>  >> >>>> L >> >>>>OK, what *is* a normal ordering process with HP.  My experiences haveK >> >>>>not left me to believe that there is such a beast.  Anybody that has E >> >>>>obtained the Itanium source listings, please help me out here.  >> >>>> L >> >>>>I'm sincerely hoping this doesn't turn into the rack mounting kit de-# >> >>>>bacle of several months ago.  >> >>>M >> >>>When you are a registered OpenVMS partner with HP your "normal orderin=  >gM >> >>>process" is spelled out in the contract, and is different in details f=  >or  >> >>>each partner.  >> >>  >> >>  >> >> Nice theory. >> >>  >> >> L >> >>>Are you a registered partner? If so your agreement should specify your5 >> >>>process. If you are not then you must register.  >> >>  >> >> K >> >> Presumably that includes DSPP, for which no such solution is provided ' >> >> (which is what Brian was saying).  >> >< >> >Not exactly a followup to this post, but to this thread: >> >L >> >My DSPP Alpha VMS SDK showed up on Friday.  (Naturally, I was out of theF >> >office...)  It included yet another copy of Alpha VMS V8.2 and theH >> >missing "OpenVMS Alpha Software Products Library Q2CY2005", i.e. the+ >> >June 2005 SPL.  Also the June 2005 ODL.  >> >F >> >According to the shipping labels, as best I can figure out, it wasI >> >shipped UPS Ground from Nashua on Aug 4 and arrived here in Lexington ' >> >(about 25 miles away) the next day.  >>=20 J >> Great news!  Even if Q3 is just around the corner at least I can expect3 >> to see the Q2 CDs soon.  Better late than never!  >>=20 K >> Now the only hurdle is the Itanium source listings.  I have some contact J >> numbers and names but I'm still not at easy with the lack of any updateJ >> service.  I simply can't afford to outlay $2284 for each release of VMSJ >> on Itanium.  Anyway, as soon as I have waded my way through this septic? >> quagmire of obtaining these listings, I'll report back here.  >> -- M >> VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)C=  >OM  >>=20 7 >>   "Well my son, life is like a beanstalk, isn't it?"  >>=20  > % >We got our 3Q2005 VAX SPD last week.  >  >? >  >WWWebb     - DSPP... Delayed Software Purchase Procurement    --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------   Date: 8 Aug 2005 09:35:23 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) H Subject: Re: Alpha Server 1200: first install VMS then upgrade firmware?3 Message-ID: <qhMtVFKgdGlX@eisner.encompasserve.org>   w In article <dd5k3h$ji9$3@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  > J > Is there any reason not to do this?  Is there any reason to upgrade the ! > firmware before installing VMS?   B    I've never encountered a "good enough" version if the firmware.F    Since I've always had the correct version or a version that must beH    updated, I've always done the firmware first.  I highly recommend it.   ------------------------------   Date: 8 Aug 2005 10:17:29 -0700 $ From: "Ed Wilts" <ewilts@ewilts.org>) Subject: CI, Gigaswitch hardware for sale A Message-ID: <1123521449.165413.8210@g44g2000cwa.googlegroups.com>   D It's the end of an era around here - I migrated my disaster-tolerantG cluster from CI-based storage to EVA storage.  This means that I've got E a ton of stuff lying around here waiting to be sold.  This includes a D dozen HSJ-50 controllers, 2 star couplers, 4 GigaSwitches, 7 CIPCAs,C and 14 FDDI cards, plus, of course, a bunch of CI cabling.  Anybody ; interested in making offers?  You can email (do not post to E comp.os.vms!) the offers or your interest to me but I won't be making E the final decision (or even determining how we're going to dispose of  it all).  E It's also interesting to note that I did the migration without taking C the cluster offline.  Thanks to VMS Engineering for making this all G possible - without HBVS and DVE, this wouldn't have been possible.  One E application had to go down for 45 minutes but that was it.  My 6-year D uptime is still going strong (much stronger than the uptimes project web site these days!).  	    .../Ed  mailto:ewilts@ewilts.org   ------------------------------  # Date: Mon, 08 Aug 2005 13:39:56 GMT * From: "FredK" <fred.nospam@nospam.dec.com>  Subject: Re: EFI is out to lunch2 Message-ID: <MgJJe.9976$r52.8183@news.cpqcorp.net>  J Remember that there are at least 3 sources of input during EFI.  COM1 (theA actual serial port), the MP serial port, and a USB keyboard (plus G potentially a network connection to the MP - which I assume you are not K using).  It appears that input works when you in the MP console, which says   to me that this port is working.  G Check to make sure that the other 2 sources are not broken or hooked to 2 something noisy.  Unlplug the KB/Mouse if present.    , <VAXman- @SendSpamHere.ORG> wrote in message* news:00A47DE9.2293472A@SendSpamHere.ORG... > In articleA <rdeininger-0608050803030001@user-uinj4j1.dialup.mindspring.com>, 7 rdeininger@mindspringdot.com (Robert Deininger) writes:  > {...snip...}K > >Since you are using the "console" connection on the DB25 MP port, the MP K > >could be causing the problem if it is catatonic.  (And make sure you are L > >using the "console" connection, not the "remote" or "modem" connections.) > K > I am indeed using the MP port.  The one denoted "console" on the 3xDB9 to L > DB 25 connector.  This is how I was told it had to be at the bootcamp lastL > year and the developer forum in Mahwah last Dec.  I've been using the suc-J > cessfully for months.  I only wanted to take the box down (de-cluster itK > so to speak) and Shell> boot -fl 0,1 to SYSBOOT> SET VAXCLUSTER 0 to test  > some software standalone.  >  >  > J > >1. Move your serial cable to the BMC's console connection.  This is theL > >DB9 port, likely labeled "console", that's NOT in the row with all the MPJ > >ports.  On this port, ESC-( and ESC-Q switch between BMC and the system > >console.  > K > I can give that a go... but this bypasses the MP.  Is the boot process on K > the BMC the same?  (It has been over a year since I played with this back  > at the bootcamp.)  >  >  > J > >2. Reset the MP to factory defaults.  There's a recessed push-button onG > >the MP card, barely visible from the back of the system.  If you are L > >holding this button down when you apply power to the box, you'll get someL > >kind of prompt and you can tell the MP to reset itself.  That might clear? > >up the problem, if it is indeed something weird with the MP.  > L > I tied that.  I held it in and then put the plug back into the system.  It@ > appears to work the same way I reset my Apple Airport Express. >  >  > I > >And we do recommend upgrading to the latest firmware.  The recommended  way H > >is to download ISO images from the HP web site, burn CDs, and run theF > >upgrade tool(s) from CD.  Last I checked, there's no unified kit toD > >upgrade all the FW components on an rx2600; you'll need 2 or more separate( > >kits depending on how old your FW is. > = > ***********************************************************  > * ROM Version : 02.21  > * ROM Date    : 08/20/2003 > * BMC Version :  01.50= > ***********************************************************  > K > Catch-22!  How do I run the "upgrade tool(s) from CD"?  I assume this has I > to be booted like I've boot VMS.  If so, I'm SOL as I can't get the EFI J > Shell> prompt to give me control.  If there's some other way, please let
 > me know. >  >  > --  2 > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM > 6 >   "Well my son, life is like a beanstalk, isn't it?"   ------------------------------   Date: 8 Aug 2005 09:18:07 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)   Subject: Re: EFI is out to lunch3 Message-ID: <v1W5jSVMFnhy@eisner.encompasserve.org>   X In article <acRIe.9956$7L6.4459@news.cpqcorp.net>, hoff@hp.nospam (Hoff Hoffman) writes:  A >   The consoles on I64 can have more than one connection, and it A >   can be a bit surprising when you first see another session on 0 >   another line acquire and access the console.  I    Which brings up the question of whether it's possible that the script  G    kiddies on the network have find some way to attach to this console?   >    I'm under the impression that the console is IP accessable.   ------------------------------  # Date: Mon, 08 Aug 2005 16:23:23 GMT 3 From: Robert Klute <robert_klute_removethis@hp.com>   Subject: Re: EFI is out to lunch8 Message-ID: <he0ff19qfk3esoh11in9mtj6r9a5cof4t1@4ax.com>  F On Mon, 08 Aug 2005 13:39:56 GMT, "FredK" <fred.nospam@nospam.dec.com> wrote:  K >Remember that there are at least 3 sources of input during EFI.  COM1 (the B >actual serial port), the MP serial port, and a USB keyboard (plusH >potentially a network connection to the MP - which I assume you are notL >using).  It appears that input works when you in the MP console, which says! >to me that this port is working.  > H >Check to make sure that the other 2 sources are not broken or hooked to3 >something noisy.  Unlplug the KB/Mouse if present.   H Also, hook a terminal up to COM1.  If you, or someone else, has set COM1H to be an input/output device in the boot options of the EFI menu you canH wind up with I/O switching over to COM1.  I have only seen it post boot,	 but ...     G The rx2600 is a bit perverse in someways because it has so many command  interface options.   Robert Klute Cupertino Solution Center  Hewlett-Packard Company  ----- 6 The opinions are those of the poster, not the company.   ------------------------------  * Date: Mon, 8 Aug 2005 16:11:34 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)@ Subject: how to get rid of "explicit carriage returns" in a file$ Message-ID: <dd807m$hp1$1@online.de>  % I have a file with this organization:   C Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytes 4 Record attributes:  Carriage return carriage control  ; It is a "normal text file", but comes from a unix tar file.   G I can use ANALYZE/RMS and CONVERT/FDL or SET FILE/ATTR or just edit it  C with EDT to get the attributes to be what I want (variable length,  G longest < 80 bytes).  However, I see <CR> at the end of each line and,  F where there is supposed to be more than one line break, in addition a G <CR> on a line by itself.  (Of course, it is not really "<CR>" but the  " single character this represents.)  H I believe if it is <CR><LF> then EDIT/TECO will fix things, but how can D they be fixed (short of an explicit script, of course) in this case?   ------------------------------  % Date: Mon, 08 Aug 2005 09:58:44 -0700  From: Z <Z@no.spam> D Subject: Re: how to get rid of "explicit carriage returns" in a file* Message-ID: <5bMJe.9648$_41.3959@fe02.lga>  / Phillip Helbig---remove CLOTHES to reply wrote: ' > I have a file with this organization:  > E > Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytes 6 > Record attributes:  Carriage return carriage control > = > It is a "normal text file", but comes from a unix tar file.  > I > I can use ANALYZE/RMS and CONVERT/FDL or SET FILE/ATTR or just edit it  E > with EDT to get the attributes to be what I want (variable length,  I > longest < 80 bytes).  However, I see <CR> at the end of each line and,  H > where there is supposed to be more than one line break, in addition a I > <CR> on a line by itself.  (Of course, it is not really "<CR>" but the  $ > single character this represents.)  
 EDIT/TPU file  [DO] or [PF4] or [PF1][KP7]  Command: Replace Old String: ^V^M[ENTER]  New Sring: [ENTER] All  ^Z     All better?    ------------------------------   Date: 8 Aug 2005 10:28:59 -0700 " From: chris_doran@postmaster.co.ukD Subject: Re: how to get rid of "explicit carriage returns" in a fileA Message-ID: <1123522139.440720.3950@g47g2000cwa.googlegroups.com>   / Phillip Helbig---remove CLOTHES to reply wrote: ' > I have a file with this organization:  > E > Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytes 6 > Record attributes:  Carriage return carriage control > = > It is a "normal text file", but comes from a unix tar file.  > H > I can use ANALYZE/RMS and CONVERT/FDL or SET FILE/ATTR or just edit itD > with EDT to get the attributes to be what I want (variable length,H > longest < 80 bytes).  However, I see <CR> at the end of each line and,G > where there is supposed to be more than one line break, in addition a H > <CR> on a line by itself.  (Of course, it is not really "<CR>" but the$ > single character this represents.) > I > I believe if it is <CR><LF> then EDIT/TECO will fix things, but how can F > they be fixed (short of an explicit script, of course) in this case?  E If you hex DUMP the file, do you see 0D0A at the end of each line? If  so, then you can fix it with:    $ SET FILE/ATTRIBUTES=RFM:STM   G Your Stream_LF means "line ends with LF only", (Stream_CR = "CR only"), < but files from some operating systems have both terminators.   Chris    ------------------------------   Date: 8 Aug 2005 14:20:09 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)8 Subject: Re: Intel hammer another nail in Itanium coffin, Message-ID: <3lp80pF13jjp9U2@individual.net>  3 In article <ncUBCtUdNlRP@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:\ > In article <11f7jsmo631u7f3@corp.supernews.com>, Dave Froble <davef@tsoft-inc.com> writes: >>  I >> An interesting statement.  Care to share some details of what type of  H >> application runs so much better on VMS?  Specifics on why it runs so  >> much better on VMS? > C >    It's a real-time application and it runs so much better on VMS H >    because the VMS kernel is deigned to handle real-time applications.I >    UNIX orignally wasn't but some variations have been modified to come 5 >    closer.  Windows wasn't and has no reason to be.  >   E Any particular reason why you haven't looked at porting to one of the G Real Time OSes available today for common Intel hardware (not itanium!)  like QNX or OS9000?    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 8 Aug 2005 09:10:46 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 8 Subject: Re: Intel hammer another nail in Itanium coffin3 Message-ID: <ncUBCtUdNlRP@eisner.encompasserve.org>   Z In article <11f7jsmo631u7f3@corp.supernews.com>, Dave Froble <davef@tsoft-inc.com> writes: > H > An interesting statement.  Care to share some details of what type of G > application runs so much better on VMS?  Specifics on why it runs so   > much better on VMS?   A    It's a real-time application and it runs so much better on VMS F    because the VMS kernel is deigned to handle real-time applications.G    UNIX orignally wasn't but some variations have been modified to come 3    closer.  Windows wasn't and has no reason to be.    ------------------------------   Date: 8 Aug 2005 09:14:53 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 8 Subject: Re: Intel hammer another nail in Itanium coffin3 Message-ID: <03Nx4gvRVNmS@eisner.encompasserve.org>   h In article <KaKdnQ3Yt9GJ8GnfRVn-jQ@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: >  > No?  To what, specifically?  > J > Do you think that VMS sales alone can support Itanic without increasing  > by an order of magnitude?   ?    I was reponding to your notion that UNIX and Windows provide @    alternatives and the VMS some how depends on IA64.  Since VMSD    on a VAX is handling something for me that UNIX and Windows can'tA    then I find continuing to use VMS on a VAX as a viable future.   G    Not to mention continuing with VMS on Alpha, IA64, Charon, SIMH, or  $    whatever else it someday runs on.   ------------------------------  % Date: Mon, 08 Aug 2005 10:56:25 -0400 ( From: Bill Todd <billtodd@metrocast.net>8 Subject: Re: Intel hammer another nail in Itanium coffin= Message-ID: <BvadnTPTlPkH72rfRVn-gA@metrocastcablevision.com>    Bob Koehler wrote:j > In article <KaKdnQ3Yt9GJ8GnfRVn-jQ@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: >  >>No?  To what, specifically?  >>J >>Do you think that VMS sales alone can support Itanic without increasing  >>by an order of magnitude?  >  > A >    I was reponding to your notion that UNIX and Windows provide 7 >    alternatives and the VMS some how depends on IA64.   G Which is absolutely correct:  alternatives more attractive then Itanic  G exist for both Unix and Windows (hence they won't be supporting Itanic  I sales all that vigorously, save possibly for HP-UX - but of course HP-UX  C users have the option to move to a different Unix which offers its  3 customers more palatable choices), but not for VMS  F (soon-to-be-unavailable platforms not generally being very attractive ! for anything but the short term).       Since VMSF >    on a VAX is handling something for me that UNIX and Windows can'tC >    then I find continuing to use VMS on a VAX as a viable future.   E Ah, I see - apparently you just misread what I said.  Hope the above   helps to clarify it.   - bill   ------------------------------  % Date: Mon, 08 Aug 2005 11:44:40 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 8 Subject: Re: Intel hammer another nail in Itanium coffin0 Message-ID: <11fev7bit6cjkbd@corp.supernews.com>   Bill Gunshannon wrote:5 > In article <ncUBCtUdNlRP@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > \ >>In article <11f7jsmo631u7f3@corp.supernews.com>, Dave Froble <davef@tsoft-inc.com> writes: >>I >>>An interesting statement.  Care to share some details of what type of  H >>>application runs so much better on VMS?  Specifics on why it runs so  >>>much better on VMS? >>C >>   It's a real-time application and it runs so much better on VMS H >>   because the VMS kernel is deigned to handle real-time applications.I >>   UNIX orignally wasn't but some variations have been modified to come 5 >>   closer.  Windows wasn't and has no reason to be.  >> >  > G > Any particular reason why you haven't looked at porting to one of the I > Real Time OSes available today for common Intel hardware (not itanium!)  > like QNX or OS9000?  >  > bill >     If it ain't broke, don't fix it.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 8 Aug 2005 12:07:26 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 8 Subject: Re: Intel hammer another nail in Itanium coffin3 Message-ID: <++V7WGLtbD41@eisner.encompasserve.org>   W In article <3lp80pF13jjp9U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > G > Any particular reason why you haven't looked at porting to one of the I > Real Time OSes available today for common Intel hardware (not itanium!)  > like QNX or OS9000?  >   F    We use other RTOS all the time.  I can't justify spending the money@    to replace the system, re-implement Qbus interfaces, port the2    software, and add a second system to handle theE    timesharing/user-interface parts of the application, and port that 
    code, too.   D    What we are spending the is cost of using up some otherwise spareB    space storing a couple VAXen of the same model we pulled out ofF    excess for spare parts.  Historically one of the VAX power suppliesD    goes every few years, and one of the disks at less than half thatC    frequency.  I did get DSSI - SCSI blocks on them so I don't have &    to count on buying RF series disks.   ------------------------------  % Date: Mon, 08 Aug 2005 09:28:39 +0200  From: S <soterroatyahoodotcom>@ Subject: Re: Killing a process that has allocated the tape drive& Message-ID: <42f7099a$1@news1.ethz.ch>   John Santos wrote:J > There is a very good reason for this.  It is to keep the tape controllerF > from writing all over memory that no longer belongs to it.  The tapeG > drive has been instructed to read or write data, but hasn't completed H > yet.  If VMS just let you kill the process, eventually the drive would  > trash someone else's memory.     o_O E Is it common practice that a driver has access to physical memory or  F something? Or that it has the privileges to do so? Or that the system G can't dismount it and trash whatever further data comes from it to the  	 dumpster? G I _certainly_ wasn't expecting to hear it on this particular operating   system.    S    ------------------------------  % Date: Mon, 08 Aug 2005 09:31:50 +0200  From: S <soterroatyahoodotcom>@ Subject: Re: Killing a process that has allocated the tape drive& Message-ID: <42f70a5c$1@news1.ethz.ch>   S wrote:I > I _certainly_ wasn't expecting to hear it on this particular operating  	 > system.   G Or particular architecture, if it's in the hardware (sounds a bit like   the DMA of peecees)    S    ------------------------------   Date: 8 Aug 2005 04:36:31 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) @ Subject: Re: Killing a process that has allocated the tape drive3 Message-ID: <WL4RY3Rr8aYy@eisner.encompasserve.org>   G In article <42f7099a$1@news1.ethz.ch>, S <soterroatyahoodotcom> writes:  > John Santos wrote:K >> There is a very good reason for this.  It is to keep the tape controller G >> from writing all over memory that no longer belongs to it.  The tape H >> drive has been instructed to read or write data, but hasn't completedI >> yet.  If VMS just let you kill the process, eventually the drive would ! >> trash someone else's memory.    >  > o_O G > Is it common practice that a driver has access to physical memory or   > something?  D That is the definition of DMA.  (If you think about it, process pageA tables for the initiating process are not available at DMA time.)   ) > Or that it has the privileges to do so?    CMKRNL beats all.    > Or that the system  I > can't dismount it and trash whatever further data comes from it to the   > dumpster?   C If hardware is malfunctioning, there is little that software can do ( to protect against hardware malfunction.  I > I _certainly_ wasn't expecting to hear it on this particular operating  	 > system.   I You should have been.  This is one of the great safety features of VMS -- G it does not _pretend_ that things have been cleaned up when in fact the 4 future behavior of the hardware cannot be predicted.   ===============   E As to the original problem, the DECUS award-winning answer from Wendy C Koenig on older tape drives was to change the unit plug and use the  "new" tape drive.    ------------------------------  % Date: Mon, 08 Aug 2005 18:27:52 +0800  From: prep@prep.synonet.com @ Subject: Re: Killing a process that has allocated the tape drive- Message-ID: <87hde0u3iv.fsf@prep.synonet.com>     S <soterroatyahoodotcom> writes:   > John Santos wrote:  @ >> There is a very good reason for this.  It is to keep the tapeD >> controller from writing all over memory that no longer belongs toE >> it.  The tape drive has been instructed to read or write data, but ? >> hasn't completed yet.  If VMS just let you kill the process, : >> eventually the drive would trash someone else's memory.  F > Is it common practice that a driver has access to physical memory or@ > something? Or that it has the privileges to do so? Or that theE > system can't dismount it and trash whatever further data comes from  > it to the dumpster?   E How do you expect the driver to run? It is in KERNEL mode so it could B do anything. Plus it could shove any address it likes into the DMA address register of controller.   > > I _certainly_ wasn't expecting to hear it on this particular > operating system.    What did you expect?   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 08 Aug 2005 14:38:20 +0200  From: S <soterroatyahoodotcom>@ Subject: Re: Killing a process that has allocated the tape drive& Message-ID: <42f7522c$1@news1.ethz.ch>  D Between the OS and the tape there at least few things: the software B driver, the drive controller (also running some firmware) and the G mechanics. Please see also my other post on this thread for a complete  E picture on why I fail to see why a system must hang in the mentioned  
 situation.   prep@prep.synonet.com wrote:G > How do you expect the driver to run? It is in KERNEL mode so it could D > do anything. Plus it could shove any address it likes into the DMA! > address register of controller.   C In my nice ideal world a software driver would be less privileged,  H supervised by a kernel mode manager taking care of the sensitive issues  (like that address shoving).  F But this has obviously nothing to do with VMS as I had no idea before F how it handles that stuff internally. Now I got a few hints, and they & didn't look like the best way _to me_.   S    ------------------------------  # Date: Mon, 08 Aug 2005 14:34:13 GMT 7 From: John Malmberg <malmberg@dskwld.zko.dec.compaq.hp> @ Subject: Re: Killing a process that has allocated the tape drive2 Message-ID: <F3KJe.9978$O47.5375@news.cpqcorp.net>   MUSTAFA ATAKAN wrote:  > Hi,  >   H >   I have a problem in killing a process that has already allocated theI > tape drive (that is, the system user mounted the tape drive, but closed I > the session without deallocating the drive). I want to the kill process G > since I want to mount the tape drive (as a system user, of course) in ) > another telnet session. In other words:  >   J > ------------------------------------------------------------------------J > ------------------------------------------------------------------------ > -----------------------  > $mount $2$mga1: /ov=id; > %MOUNT-I-OPRQST, device already allocated to another user  >    > $dismount $2$mga1:> > %SYSTEM-W-DEVALLOC, device already allocated to another user >    > $ show dev mga1 /full E > Magtape $2$MGA1: (TILOT3), device type COMPAQ SuperDLT1, is online,  > allocated,E > deallocate on dismount, mounted, file-oriented device, available to 
 > cluster,E > device has multiple I/O paths, error logging is enabled, controller 
 > supportsF > compaction (compaction disabled), device supports fastskip (per_io).- > Error count 2 Operations completed 33626407 + > Owner process "SYSTEM" Owner UIC [SYSTEM] @ > Owner process ID 20602CF3 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL > .. > ...  >    > $ stop /id=20602CF3  > $ stop /id=20602CF3  > $ stop /id=20602CF3  >    > $ show user system /full > ...  > ... 6 > SYSTEM TILOT3 SYSTEM 20602CF3 TNA346: (disconnected)  F Stopping a process causes it's I/O to be canceled, which for many I/O F devices means waiting for either an I/O to complete or for the device ) driver to time out the I/O to the device.   G The value of the SYSGEN parameter TAPE_MVTIMEOUT may also be involved.  G On my OpenVMS 8.2 Alpha system it is set to 600 seconds, or 10 minutes.   F For tape operations, such as a rewind, there could be a long timeout. H Not being involved in the tape drivers directly, I do not know how long K such a timeout would be, but I would expect it to be in minutes, not hours.   H If the device is malfunctioning, or there is a problem in the Fabric or F the MDR type device that is connecting the device to the Fabric, this = can delay the amount of time that it takes to cancel the I/O.   I Please make sure that you are up to date on the FIBRE-SCSI ECO kits, and  2 if so, please log a call with HP customer support.  D If you are not up to date with the FIBRE-SCSI ECOs, one of them may G contain a fix to your problem.  Of course installing it will require a   reboot.    > ... J > ------------------------------------------------------------------------J > ------------------------------------------------------------------------ > -----------------------  >   H > What is the reason that i can not stop the above process? Is there anyG > command like "kill -9" in *nix environments? Is there any way to stop @ > this process without rebooting or waiting some timeout period?  H What ever is hung may clear up after a timeout, or by power cycling the I tape drive.  Some of the timeouts specified by Fibre-SCSI devices can be  ? large, on the order of many minutes, depending on the operation   G Other than that, the stop/id should cause the process to exit and free  ! up it's allocation to the device.    -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  % Date: Mon, 08 Aug 2005 09:33:41 -0500 & From: Thomas Wirt <twnews@kittles.com>@ Subject: Re: Killing a process that has allocated the tape driveE Message-ID: <57e78$42f76d45$4367aba2$17265@msgid.meganewsservers.com>    MUSTAFA ATAKAN wrote:    > Hi,  >   I >   I have a problem in killing a process that has already allocated the  J > tape drive (that is, the system user mounted the tape drive, but closed J > the session without deallocating the drive). I want to the kill process H > since I want to mount the tape drive (as a system user, of course) in ) > another telnet session. In other words:   G Perhaps I am old and senile, but I thought that they put a sort of fix  H in for this sometime around 7.3.  The idea was that eventually, after a I fairly long time-out, the process would die and the device would be free  D without a reboot.  I know that a similar problem existed for disks. E They could get stuck in, I believe, mount verification, and it would  H take a reboot to get them back.  I know the disk problem is fixed.  Did G they not add a similar fix for the tape drive driver?  As I recall the  H time-out was on the order of magnitude of minutes, not hours.  It saved 1 me from rebooting a cluster right after a reboot.    [snip] >   I > What is the reason that i can not stop the above process? Is there any  H > command like "kill -9" in *nix environments? Is there any way to stop @ > this process without rebooting or waiting some timeout period? >    > Thanks in advance...     --     Thomas Wirt  Systems Manager  Kittle's Home Furnishings  Indianapolis, IN   ------------------------------   Date: 08 Aug 2005 16:02:52 GMT$ From: "Doc." <Doc@openvms-rocks.com>@ Subject: Re: Killing a process that has allocated the tape drive1 Message-ID: <Xns96ACB665E8281Doc@212.100.160.126>   1 On Mon, 08 Aug 2005 13:50:23 GMT, "Richard Maher" + <maher_rj@hotspamnotmail.com> wrote message = news:dd7nuu$g62$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com . . .    ? > PS. The removalists are now taking me away from the keyboard.  > E > PPS. Is Australia the only place that says "Removalist" or is it an G > American thing that we picked up? Everyone here keeps laughing at me. ? > (Of course might not have anything to do with how I speak :-)   I Removalists is a new one on me, and sounds like something dreamt up by a   marketing droid.  L On the other hand, are you sure it's the furniture they've come to remove?  7 Is the inside of their vehicle fitted with padding? ;-}        Doc. --  F OpenVMS:    Eight out of ten hackers prefer *other* operating systems.F             http://vmsbox.cjb.net          http://vmsbox.cjb.net/docs/   ------------------------------   Date: 8 Aug 2005 12:14:15 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) @ Subject: Re: Killing a process that has allocated the tape drive3 Message-ID: <kAo+YmKV5NA7@eisner.encompasserve.org>   u In article <dd7nuu$g62$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, "Richard Maher" <maher_rj@hotspamnotmail.com> writes:  > Hi,  > L > The "software" always has the option of CANCELing any pending I/O when the! > user process is being run down.   B    Not always.  From the application level $CANCEL depends on the G    cooperation of the device driver,  which depends on the cooperation  C    of the hardware.  VMS will do a $CANCEL for you when the process A    is being run down so applications don't actually have to worry     about it.  A    I've seen device drivers without a properly implemented cancel D    routine (yes, this is also "software").  I've seen hardware whichE    would not cooperate (no interface to cancel a DMA once requested).   B    You see a process RWAST for this when VMS does a $CANCEL and itF    doesn't return.  VMS puts the process into RWAST when it starts theB    $CANCEL because it's expecting a kernel mode AST (thus the nameE    RWAST) at the completion of the $CANCEL.  Normally process rundown F    puts processes into RWAST for a few milliseconds all the time.  ItsB    when that kernel mode AST never comes that we notice the RWAST.   ------------------------------   Date: 8 Aug 2005 06:35:37 -0700 ! From: filip.de.block@proximus.net  Subject: lib$ tree routines B Message-ID: <1123508137.397460.23790@g14g2000cwa.googlegroups.com>  
 good morning,   F I am a happy user of LIB$INSERT_TREE (and friends) for many years. ButD until today, I had no reason for removing a single node from a tree.8 So I was slightly horrified to find out that there is no LIB$REMOVE_TREE ...   # Anyone an idea about a workaround ?    ------------------------------   Date: 8 Aug 2005 09:29:16 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)   Subject: Re: Newbie DCL Question3 Message-ID: <jYsjZ$bxi7Cr@eisner.encompasserve.org>   T In article <yJhJe.1050$Y04.98@newsfe4-win.ntli.net>, Kevin <kevin@ps8.co.uk> writes: > Hi > H > If this isn't an appropriate group to post this question, I apologise. > I > I am prompting the user for a nickname using read/prompt from within a  H > login script in a captive account.   I will use this name to create a # > subdirectory later in the script.  > F > Apart from using f$length to check size, and f$edit to collapse and I > convert to uppercase, how can I validate against users entering quoted  : > strings and various punctuation that will upset cre/dir?  @    1)  for security reasons you may want to replace INQUIRE with       READ/PROMT  0    2)  use f$parse with the "syntax_only" option   ------------------------------   Date: 8 Aug 2005 14:10:59 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)O Subject: Re: OpenVMS under the umbrella - or umbrella is supported at the time? , Message-ID: <3lp7fjF13jjp9U1@individual.net>  B In article <1123346547.509721.33630@g47g2000cwa.googlegroups.com>,$ 	susan_skonetski@hotmail.com writes:G > Ok I am smiling and not writing all the funny comebacks I am thinking  > ;')  > I > And you are correct VMS is rock solid but alas VMS does not manufacture H > customer customer gifts.  We do purchase them from vendors.  And whileI > the blinky balls did last a while they did not have the same up time as H > VMS.  After all most customer gifts are designed for people that loose) > them (guess they don't know VMS folks).   B Gee.  I feel priveledged.  I just tested mine and it still flashes just fine.  :-)      bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  * Date: Mon, 8 Aug 2005 16:19:05 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)
 Subject: PERL $ Message-ID: <dd80lo$iko$2@online.de>  D What is the best source for PERL for VMS?  I would prefer a version H which just works out of the box and, of course, is compatible with PERL ; on other systems.  However, it should work fine with ODS-2.    Is there a VMS PERL for VAX?   ------------------------------  $ Date: Mon, 8 Aug 2005 13:13:23 -0400, From: Carl Friedberg <frida.fried@gmail.com> Subject: Re: PERL 7 Message-ID: <890539d905080810135acd3ba0@mail.gmail.com>    Hi,   L To get a version that works out of the box, use the version which is built = for # use with Apache by VMS engineering:   G http://h71000.www7.hp.com/openvms/products/ips/apache/csws_modperl.html   ) but, I see that is not available for VAX.   + The distributed version of perl (now 5.8.7)   ' http://www.perl.com/download.csp#stable   F You will, however, need a C compiler, a make tool (MMK), GZIP for VMS,G and TAR for VMS, all but C available on the freeware cdroms (as is Perl  itself, I suspect)  F http://h71000.www7.hp.com/freeware/freeware70/perl/freeware_readme.txt   You can find readme.vms here:   . http://perl.active-venture.com/README.vms.html  G Direct specific questions to the VMS Perl mailing list vmsperl@perl.org    HTH,   Carl Friedberg    3 On 8/8/05, Phillip Helbig---remove CLOTHES to reply ( <helbig@astro.multiclothesvax.de> wrote:E > What is the best source for PERL for VMS?  I would prefer a version I > which just works out of the box and, of course, is compatible with PERL = > on other systems.  However, it should work fine with ODS-2.  >=20 > Is there a VMS PERL for VAX? >=20 >    ------------------------------   Date: 8 Aug 2005 01:05:04 -0700 " From: "Jose Baars" <peut@peut.org>4 Subject: Re: strange terminal-characteristic problemB Message-ID: <1123488304.633025.52280@f14g2000cwb.googlegroups.com>  B I'm not sure of VAXstatations, but usually you have to set console characteristics F at console level, i.e. at the boot prompt. How to do this should be in the owner's  manual of th VAXstation    ------------------------------  * Date: Mon, 8 Aug 2005 12:32:48 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)4 Subject: Re: strange terminal-characteristic problem$ Message-ID: <dd7jdg$ume$1@online.de>  5 In article <42F6ADCD.54A2380E@teksavvy.com>, JF Mezei ' <jfmezei.spamnot@teksavvy.com> writes:     > David J Dachtera wrote: + > > How long are these async. serial lines?  > D > Based on what he said, that isn't the problem. If he uses the sameF > terminal, same cable, same system/OPA0: and from $ he TELNETS or SET > HOST/LAT to another host,    Or to the same host!  H > You need to TYPE a large file with aligned data, hopefully not greaterG > than 80 characters in record length, and use the hold-screen button a F > few times to see if there might be flow control issues. With alignedD > data, you will easily see any missing stuff since the data will beG > screwed up after you release the hold and it starts scrolling again.    F I'll give it a try when I next have a chance (a month or so from now).  5 > Out of curiosity, did you say Vaxstation 4000xx ?      Yes.   > If so, does the ' > serial port really appear as OPA0: ?     Yes.  " > Is there a second serial port on > those machines ?     Yes.  H The one with the printer symbol is the console port, OPA0:, and that is E what I am using.  The other one, with the double arrows, is a serial  F port, but not the console port.  It works fine (no scrambling either).  6 > Once booted, if you plug the terminal into the other7 > port and login, does it exhibit the same behaviour ?     No.    > Or is thatE > behaviour limited to ports that are seen as OPA0: (eg: the OPERATOR 3 > device driver acting above the terminal driver).     Yes.  E > If you use the graphics display without decwindows, you get a truly 8 > basic character cell interface without VT100 support.   9 Right.  However, I prefer a real terminal as the console.    ------------------------------  * Date: Mon, 8 Aug 2005 12:34:06 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)4 Subject: Re: strange terminal-characteristic problem$ Message-ID: <dd7jfu$ume$2@online.de>  5 In article <42F6AF13.A28C1E8B@teksavvy.com>, JF Mezei ' <jfmezei.spamnot@teksavvy.com> writes:    1 > Phillip Helbig---remove CLOTHES to reply wrote: E > > console.  Of course, when I log in via LAT or TELNET, the logical I > > terminal is no longer OPA0:.  Thus, it appears to be a combination of & > > OPA0: and the VAXstation hardware. > 1 > From OPA0:, if you use EDT, it is bad. Right ?     Right.   > If from OPA0: you SET F > HOST/LAT to another node and on that other node you use EDT, is that > output also flaky ?   D No.  It's OK whether I set host to another node or to the same node.   ------------------------------   Date: 8 Aug 2005 09:33:49 -0700 # From: "WhoDat?" <whohe@whoever.com> 4 Subject: Re: strange terminal-characteristic problemC Message-ID: <1123518829.600891.114830@o13g2000cwo.googlegroups.com>   / Phillip Helbig---remove CLOTHES to reply wrote: 7 > In article <42F661E0.A65B3D78@teksavvy.com>, JF Mezei ( > <jfmezei.spamnot@teksavvy.com> writes: > M > > And you checked the SYSGEN parameter TTY_DEFCHAR and TTY_DEFCHAR2 on that < > > system against that of a system where OPA0: works fine ? > ; > Both are the same and equal to the defaults on all nodes.  > Q > > Does the VT320 itself have the right setup in terms of speed, parity and flow O > > control ? Does it emit xoff at 64 or 128 characters ? (get it to emit at at O > > 128, giving more time for any data to stop flowing before buffer overflow).  > H > All of my VTs have identical setups.  (Remember, I swapped the VTs andH > the problem stayed with the node.  I also swapped the computer and theJ > problem stayed with the system disk, though I did swap it with a similar > model. > > P > > Something else to test is to bring down the machine, change the OPA0: serialR > > port speed on the hardware switch (or >>> approciate command), change terminalR > > to match and then start VMS again. Bring it down to 300 and see if the problem > > happens again. >  > It's 300.  >     E Are all of your system's consoles (OPA0:'s) set to 300 or is this the  only one set to 300?    Q > > There is some funky stuff that happens because OPA0: doesn't use the standard O > > TT driver, it has the "OPERATOR" driver on top of it as well as being quite N > > dependant on the hardware itself which is different from a standard serial1 > > card since it is embedded in the motherboard.  > > > That could explain why the problem seems to happen on all my2 > VAXstations, but not on VAXes and not on ALPHAs.  A >From everything you've said, the problem is in the software or a D setting, not the hardware. You said the problem followed the "disk",C but really, it followed the software, no? You've changed everything = except the operating system and setting files. I think you've # eliminated the hardware, don't you?   G Compare your sylogin and your user login files to the system that works @ and see what's different. How about patches? Are all of your 7.3C systems at the same patch level? Do the SHOW TERM comparison as you  mentioned, too.    ------------------------------  $ Date: Mon, 8 Aug 2005 10:59:02 -0400 From: norm.raphael@metso.comS Subject: Wendy Koenig (was Re: Killing a process that has allocated the tape drive) Q Message-ID: <OF607EC696.3456EBDA-ON85257057.005232BF-85257057.00525194@metso.com>   H Kilgallen@SpamCop.net (Larry Kilgallen) wrote on 08/08/2005 05:36:31 AM:   [Snip] > ===============  > G > As to the original problem, the DECUS award-winning answer from Wendy E > Koenig on older tape drives was to change the unit plug and use the  > "new" tape drive.   ) Nice to see Wendy's name.  Takes me back.    ------------------------------   End of INFO-VAX 2005.440 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            