INFO-VAX Fri, 01 Feb 2008 Volume 2008 : Issue 63 Contents: Re: "file locked by another user" mystery Re: "file locked by another user" mystery Re: "file locked by another user" mystery Re: Looking for a DECserver 200/MC/ or 300 Re: Looking for a DECserver 200/MC/ or 300 Re: Looking for a DECserver 200/MC/ or 300 Re: Restricting Access to TCP/IP and DECnet Re: Restricting Access to TCP/IP and DECnet Re: Restricting Access to TCP/IP and DECnet Re: VT100 standards Re: VT100 standards and EDT Re: VT100 standards and EDT Wrong place but desperate Yet another hobbyist software kit request. Re: Yet another hobbyist software kit request. Re: Yet another hobbyist software kit request. ---------------------------------------------------------------------- Date: Thu, 31 Jan 2008 19:40:40 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: "file locked by another user" mystery Message-ID: In article , briggs@encompasserve.org writes: This seems like an appopriate thread to bring up the old chestnut: $ RESET := ON ERROR THEN RESET Think about it. For starters, it is NOT the same as SET NOON, since a severe error will exit. ------------------------------ Date: Thu, 31 Jan 2008 19:05:11 -0800 (PST) From: AEF Subject: Re: "file locked by another user" mystery Message-ID: On Jan 29, 6:14 pm, Fred Bach wrote: > Mr Briggs, > > Holy crow! You're right. However, it is not explicitly stated > in the DCL Help that if you have an ON SEVERE command that you > cannot have a previous ON WARNING command and expect it to work. > The HELP just implies that, in the absence of the ON WARNING or > and ON ERROR command, execution would simply continue. The DCL > HELP does *not* say that previous ON WARNING or ON ERROR commands > are thereby nullified and rendered useless! Not quite; HELP does give a strong hint about it. See below. > Looks like the DCL > HELP needs to be amended to say what it really should! > > The DCL Help says: > > > > >> ON > > >> Parameters > > >> condition > > >> Specifies either the severity level of an error or a Ctrl/Y > >> interrupt. Specify one of the following keywords, which may be > >> abbreviated to one or more characters: > > >> WARNING Return status of warning occurs ($SEVERITY equals > >> 0). > > >> ERROR Return status of error occurs ($SEVERITY > >> equals 2). > > >> SEVERE_ERROR Return status of error occurs ($SEVERITY > >> equals 4). > > >> CONTROL_Y Ctrl/Y character occurs on SYS$INPUT. > > >> The default error condition is ON ERROR THEN EXIT. > > >> command > > >> Specifies the DCL command line to be executed. Optionally, you > >> can precede the command line with a dollar sign ($). > > >> If you specified an error condition as the condition parameter, > >> the action is taken when errors equal to or greater than the > >> specified level of error occur. > > >> Examples > > >> 1.$ ON SEVERE_ERROR THEN CONTINUE > > >> A command procedure that contains this statement continues > >> to execute normally when a warning or error occurs during > >> execution. When a severe error occurs, the ON statement signals > >> the procedure to execute the next statement anyway. Once > >> the statement has been executed as a result of the severe > >> error condition, the default action (ON ERROR THEN EXIT) is > >> reinstated. > > [ snip ] > > Note that the help does NOT say that it is illegal to have an > ON WARNING THEN CONTINUE or an ON ERROR THEN GOTO EXIT. The HELP > doesn't even say it's futile. The above text would seem to say > that the program executes "normally" for warning and error > conditions. The word 'normally' is rather confusing - it would > suggest that you could actually use an ON WARNING or ON ERROR > command and expect its specified action to be taken when only a > warning condition happened. At least that was the way I always > understood the help. Not quite. I will quote the relevant part from your HELP excerpt: > >> If you specified an error condition as the condition parameter, > >> the action is taken when errors equal to or greater than the > >> specified level of error occur. While this doesn't explicitly explain it, it does strongly hint that you can't have separate commands for the 3 different error levels. (Note the "equal to or greater than" phrase.) The User's Manual is the appropriate reference here. I admit it's certainly not clear here in the HELP reference -- especially as the CONTROL_Y condition, which _is_ independent of ON W|E|S, is commingled with W, E, and S!, but the hint is there. > I did this all the time. FOR YEARS, and it really did seem to > work just fine. I guess the ON command is really forgiving or > maybe I got the order accidentally correct. ;-) Or maybe you just coded very well in a stable environment? > Typically, to handle all possible conditions that might happen to > the user, I feel that I need to specify different actions for > the various ON conditions. Such as "ON WARNING THEN CONTINUE" > and "ON ERROR THEN GOTO EXIT" and "ON SEVERE THEN STOP" which > would be the typical set of ON commands I would use. They > all seemed to function just fine together in the same DCL routine. > Over all these years they did not appear to interfere with each > other. Things worked very well and the desired action seemed > to be taken. Well, I wouldn't want to STOP on severe errors as I'd probably want to do some cleanup. Also, it's somewhat arbitrary what constitutes a warning vs. an error vs. a "severe error". Why should editing ADSF: be fatal while TYPEing it only a warning?: $ TYPE ASDF:[ASDF]ASDF %TYPE-W-SEARCHFAIL, error searching for ASDF:[ASDF]ASDF.LIS; -RMS-F-DEV, error in device name or inappropriate device type for operation $ SH SYM $SEVERITY $SEVERITY == "0" $ $ EDIT/EDT ASDF:[ASDF]ASDF %EDT-F-OPENIN, error opening ASDF:[ASDF]ASDF.; as input -RMS-F-DEV, error in device name or inappropriate device type for operation $ SH SYM $SEVERITY $SEVERITY == "4" $ If you want to take different actions based on different values of $SEVERITY, you need to use SET NOON and check the $STATUS and/or $SEVERITY symbols after each command. Alternatively, here's a trick that might do what you want. It will branch to different parts of the code based on a single ON command. And it uses the ampersand!!! (What more could you want??? ;-) (See below for info about the RETURN trick.) $ ON WARNING THEN GOTO &$SEVERITY . . . $0: $2: $4: Here's the example I tested: $ TYPE HANDLER.COM $ ON WARNING THEN GOTO &$SEVERITY $ 'P1' $ exit $0: $ WRITE SYS$OUTPUT "WARNING!" $ EXIT $2: $ WRITE SYS$OUTPUT "ERROR!" $ EXIT $4: $ WRITE SYS$OUTPUT "FATAL!" $ EXIT $ SET VERIFY $ @HANDLER "RETURN 0" $ ON WARNING THEN GOTO &$SEVERITY $ RETURN 0 %NONAME-W-NOMSG, Message number 00000000 $0: $ WRITE SYS$OUTPUT "WARNING!" WARNING! $ EXIT $ @HANDLER "RETURN 2" $ ON WARNING THEN GOTO &$SEVERITY $ RETURN 2 %NONAME-E-NOMSG, Message number 00000002 $2: $ WRITE SYS$OUTPUT "ERROR!" ERROR! $ EXIT $ @HANDLER "RETURN 4" $ ON WARNING THEN GOTO &$SEVERITY $ RETURN 4 %NONAME-F-NOMSG, Message number 00000004 $4: $ WRITE SYS$OUTPUT "FATAL!" FATAL! $ EXIT This way you can have different actions for different severity levels without having to explicitly check $SEVERITY after each command! Still, I'm not sure how useful this really is as I find that assignments of W, E, and F to various errors are somewhat arbitrary as I mentioned elsewhere in this post. > > I just wrote a short script that would CONFIRM WHAT YOU SAY! > I moved various ON command lines around to test their effects. > > $! test of error condition responses > $! 29-JAN-2008 FWB. > $ > $TOP: > $ Inquire filename "Enter file to type " > $ on error then goto CONDITION_E > $! on severe then goto CONDITION_S > $ on warning then goto CONDITION_W > $ on control_y then goto exit > $ type 'filename' > $ > $ filename = "" > $ goto top > $ > $EXIT: > $ exit > $ > $CONDITION_W: > $ write sys$output "WARNING" > $ GOTO TOP > $ > $CONDITION_E: > $ write sys$output "ERROR" > $ GOTO TOP > $ > $CONDITION_S: > $ write sys$output "SEVERE" > $ GOTO TOP > $ > > It would seem that the LAST "ON" command sets the course of > events. In the above example the CONDITION_W: code is executed > if I give a bogus filename in response to the question. If, > however, I put the "on error then goto condition_E" statement > after the "on warning" statement, then the Condition_W: code > never gets executed!! Wow. > > Much like I do for $STATUS now, to handle errors in a custom > way I suppose that now I will have to save and test the value > of $SEVERITY if I really want different actions to be taken on > different values! Can a fellow do that? Ya learns something > every day.... Thanks for the correction! > > My above code did NOT check things in the other direction - that > is: what if I want something special to happen on an ERROR > condition and all I get is a WARNING condition, and the ON WARNING > was specified LAST. I'm not quite sure how a fellow could cleanly > create only an error condition while trying to type a file. > Can you suggest some code to test this case? Thanks! Well, I use the following trick (only works if you are NOT in a local subroutine) Use the return command and specify 0 for warning, 2 for error, and 4 for severe error. Example: $ TYPE TEST-ERROR.COM $ SET VERIFY $ SET NOON $ RETURN 4 $ SHOW SYMBOL $STATUS $ SHOW SYMBOL $SEVERITY $ ON WARNING THEN SHOW TIME $ RETURN 0 $ SET NOVERIFY $ EXIT $ $ @TEST-ERROR $ SET NOON $ RETURN 4 %NONAME-F-NOMSG, Message number 00000004 $ SHOW SYMBOL $STATUS $STATUS == "%X00000004" $ SHOW SYMBOL $SEVERITY $SEVERITY == "4" $ ON WARNING THEN SHOW TIME $ RETURN 0 %NONAME-W-NOMSG, Message number 00000000 1-FEB-2008 02:10:05 $ SET NOVERIFY $ Alternatively you can simply experiment by running commands like $ DIR ASDF: and checking the value of $SEVERITY that it produces and then using what you need from the results. (Note that you can't always go by the error level in the % line!!! Run DIR ASDF: to see a counterexample.) > ********* > > One thing that IS important to know is that after an "ON" > condition is acted upon, the last pertinent ON statement is > more or less rendered 'cancelled' by its having its specified > action taken. The ON condition executed then returns to its > default condition, so another set of ON ... statements is > frequently needed. Now even though the HELP confirms this, > that IS something that I learned the hard way. And I had > built myself a little DCL test procedure to prove it and in > some of my coding you would find a block of ON conditions > repeated many times. The code looks funny, too. How does > a fellow set the *default* ON conditions themselves?? Have your code reset the ON behavior as needed. If you're not exiting based on the error, then you simply put in your "default error handler command" in the code you branch to. > > Thanks again. > > .. fred bach .. > I use something closely modeled on the method given in "Writing Real Programs in DCL". (I have no financial interest in the book. I have the book and it's very good; I strongly recommend it.) The idea is to be modular: Always exit with an appropriate $STATUS value. AEF &-) ------------------------------ Date: Thu, 31 Jan 2008 19:58:50 -0800 From: Fred Bach Subject: Re: "file locked by another user" mystery Message-ID: <47A298FA.8050203@triumf.ca> Comments interspersed. You fellows are sure coming up with some cool ideas. AEF wrote: > On Jan 29, 6:14 pm, Fred Bach wrote: >> Mr Briggs, >> >> Holy crow! You're right. However, it is not explicitly stated >> in the DCL Help that if you have an ON SEVERE command that you >> cannot have a previous ON WARNING command and expect it to work. >> The HELP just implies that, in the absence of the ON WARNING or >> and ON ERROR command, execution would simply continue. The DCL >> HELP does *not* say that previous ON WARNING or ON ERROR commands >> are thereby nullified and rendered useless! > > > Not quite; HELP does give a strong hint about it. See below. > > >> Looks like the DCL >> HELP needs to be amended to say what it really should! >> >> The DCL Help says: >> >> >> >>>> ON >>>> Parameters >>>> condition >>>> Specifies either the severity level of an error or a Ctrl/Y >>>> interrupt. Specify one of the following keywords, which may be >>>> abbreviated to one or more characters: >>>> WARNING Return status of warning occurs ($SEVERITY equals >>>> 0). >>>> ERROR Return status of error occurs ($SEVERITY >>>> equals 2). >>>> SEVERE_ERROR Return status of error occurs ($SEVERITY >>>> equals 4). >>>> CONTROL_Y Ctrl/Y character occurs on SYS$INPUT. >>>> The default error condition is ON ERROR THEN EXIT. >>>> command >>>> Specifies the DCL command line to be executed. Optionally, you >>>> can precede the command line with a dollar sign ($). >>>> If you specified an error condition as the condition parameter, >>>> the action is taken when errors equal to or greater than the >>>> specified level of error occur. >>>> Examples >>>> 1.$ ON SEVERE_ERROR THEN CONTINUE >>>> A command procedure that contains this statement continues >>>> to execute normally when a warning or error occurs during >>>> execution. When a severe error occurs, the ON statement signals >>>> the procedure to execute the next statement anyway. Once >>>> the statement has been executed as a result of the severe >>>> error condition, the default action (ON ERROR THEN EXIT) is >>>> reinstated. >> [ snip ] >> >> Note that the help does NOT say that it is illegal to have an >> ON WARNING THEN CONTINUE or an ON ERROR THEN GOTO EXIT. The HELP >> doesn't even say it's futile. The above text would seem to say >> that the program executes "normally" for warning and error >> conditions. The word 'normally' is rather confusing - it would >> suggest that you could actually use an ON WARNING or ON ERROR >> command and expect its specified action to be taken when only a >> warning condition happened. At least that was the way I always >> understood the help. > > Not quite. I will quote the relevant part from your HELP excerpt: > >>>> If you specified an error condition as the condition parameter, >>>> the action is taken when errors equal to or greater than the >>>> specified level of error occur. > > While this doesn't explicitly explain it, it does strongly hint that > you can't have separate commands for the 3 different error levels. > (Note the "equal to or greater than" phrase.) I agree that is a hint. But the help says an ERROR condition. Notice that the help does NOT say what would happen if the $SEVERITY were lower and the ON WARNING were previously specified. I agree that if one were to apply parallelism from the ON ERROR structure to the ON WARNING structure, then one could say that it is all explained in the help. However, as it stands, the help wouldn't make it past any lawyers, that's for sure. > The User's Manual is the > appropriate reference here. No fair. :-) :-) It's just that the DCL help is so much easier to get to. I know I read most, if not all, of the User's Manual probably over 20 years ago back when it was paper and when I took the bus a lot. Can't seem to hold it all in my head, though. I know this stuff is all online at HP, but who has time to actually read it 'cover to cover', so to speak, at work? But a paper manual is much easier to read on the bus. To search the DCL Help, I used to extract ALL the DCL HELP to a single file from time to time and then search that for keywords. Was very useful. And then the DCL HELP file got bigger and bigger. Maybe I should get back to doing that now that our SYS$SCRATCH space is bigger too. > I admit it's certainly not clear here in > the HELP reference -- especially as the CONTROL_Y condition, which > _is_ independent of ON W|E|S, is commingled with W, E, and S!, but the > hint is there. > >> I did this all the time. FOR YEARS, and it really did seem to >> work just fine. I guess the ON command is really forgiving or >> maybe I got the order accidentally correct. ;-) > > Or maybe you just coded very well in a stable environment? Yeah, I thought about that too. You're probably exactly right. The Controls group here tries for a very solid stable environment, with all logicals and symbols automatically redefined depending on what machine we were on (be that VAX, or ALPHA, or now ITANIUM). All the correct binaries and executables go into their own directories based on machine type, and then the logicals are automatically redefined to pick up the right image type from the correct [BIN] directories. And some automatic routine to re-link when necessary. So the executables were well taken care of on upgrades. And I certainly took care of $STATUS correctly, like I learned on this newsgroup, and generated my own messages. If I think really hard, I might be able to come up with a very few instances of why the incorrect ON path seemed to happen. Nevertheless I sure as heck learned something useful here this week! > >> Typically, to handle all possible conditions that might happen to >> the user, I feel that I need to specify different actions for >> the various ON conditions. Such as "ON WARNING THEN CONTINUE" >> and "ON ERROR THEN GOTO EXIT" and "ON SEVERE THEN STOP" which >> would be the typical set of ON commands I would use. They >> all seemed to function just fine together in the same DCL routine. >> Over all these years they did not appear to interfere with each >> other. Things worked very well and the desired action seemed >> to be taken. > > Well, I wouldn't want to STOP on severe errors as I'd probably want to > do some cleanup. Also, it's somewhat arbitrary what constitutes a > warning vs. an error vs. a "severe error". Why should editing ADSF: be > fatal while TYPEing it only a warning?: > > $ TYPE ASDF:[ASDF]ASDF > %TYPE-W-SEARCHFAIL, error searching for ASDF:[ASDF]ASDF.LIS; > -RMS-F-DEV, error in device name or inappropriate device type for > operation > $ SH SYM $SEVERITY > $SEVERITY == "0" > $ > $ EDIT/EDT ASDF:[ASDF]ASDF > %EDT-F-OPENIN, error opening ASDF:[ASDF]ASDF.; as input > -RMS-F-DEV, error in device name or inappropriate device type for > operation > $ SH SYM $SEVERITY > $SEVERITY == "4" > $ > Yes, that's a really great question! Why *does* TYPE give a Warning whereas EDIT gives a SEVERE? Beats me. As far as "STOP" on severe_error goes, well, I guess the idea was to get the operators to call for help. Now and then I would throw in my phone number at a point like that. > If you want to take different actions based on different values of > $SEVERITY, you need to use SET NOON and check the $STATUS and/or > $SEVERITY symbols after each command. Alternatively, here's a trick > that might do what you want. It will branch to different parts of the > code based on a single ON command. And it uses the ampersand!!! (What > more could you want??? ;-) (See below for info about the RETURN > trick.) > > $ ON WARNING THEN GOTO &$SEVERITY > . Now there's another trick I might not have thought of! I seem to recall, perhaps incorrectly, from somewhere that it was bad form to start symbols with numbers, so I never did it. And I guess I applied that subconsciously to DCL labels as well. I know that in some of our private graphic routines (not DCL) I cannot read lines of data into symbols (based on field locations) that begin with numerals. I'd bet that spilled over to my DCL coding. > . > . > $0: > > $2: > > $4: > > > Here's the example I tested: > > $ TYPE HANDLER.COM > $ ON WARNING THEN GOTO &$SEVERITY > $ 'P1' > $ exit > $0: > $ WRITE SYS$OUTPUT "WARNING!" > $ EXIT > $2: > $ WRITE SYS$OUTPUT "ERROR!" > $ EXIT > $4: > $ WRITE SYS$OUTPUT "FATAL!" > $ EXIT > > $ SET VERIFY > $ @HANDLER "RETURN 0" > $ ON WARNING THEN GOTO &$SEVERITY > $ RETURN 0 > %NONAME-W-NOMSG, Message number 00000000 > $0: > $ WRITE SYS$OUTPUT "WARNING!" > WARNING! > $ EXIT > > $ @HANDLER "RETURN 2" > $ ON WARNING THEN GOTO &$SEVERITY > $ RETURN 2 > %NONAME-E-NOMSG, Message number 00000002 > $2: > $ WRITE SYS$OUTPUT "ERROR!" > ERROR! > $ EXIT > > $ @HANDLER "RETURN 4" > $ ON WARNING THEN GOTO &$SEVERITY > $ RETURN 4 > %NONAME-F-NOMSG, Message number 00000004 > $4: > $ WRITE SYS$OUTPUT "FATAL!" > FATAL! > $ EXIT > > This way you can have different actions for different severity levels > without having to explicitly check $SEVERITY after each command! > Still, I'm not sure how useful this really is as I find that > assignments of W, E, and F to various errors are somewhat arbitrary as > I mentioned elsewhere in this post. > >> I just wrote a short script that would CONFIRM WHAT YOU SAY! >> I moved various ON command lines around to test their effects. >> >> $! test of error condition responses >> $! 29-JAN-2008 FWB. >> $ >> $TOP: >> $ Inquire filename "Enter file to type " >> $ on error then goto CONDITION_E >> $! on severe then goto CONDITION_S >> $ on warning then goto CONDITION_W >> $ on control_y then goto exit >> $ type 'filename' >> $ >> $ filename = "" >> $ goto top >> $ >> $EXIT: >> $ exit >> $ >> $CONDITION_W: >> $ write sys$output "WARNING" >> $ GOTO TOP >> $ >> $CONDITION_E: >> $ write sys$output "ERROR" >> $ GOTO TOP >> $ >> $CONDITION_S: >> $ write sys$output "SEVERE" >> $ GOTO TOP >> $ >> >> It would seem that the LAST "ON" command sets the course of >> events. In the above example the CONDITION_W: code is executed >> if I give a bogus filename in response to the question. If, >> however, I put the "on error then goto condition_E" statement >> after the "on warning" statement, then the Condition_W: code >> never gets executed!! Wow. >> >> Much like I do for $STATUS now, to handle errors in a custom >> way I suppose that now I will have to save and test the value >> of $SEVERITY if I really want different actions to be taken on >> different values! Can a fellow do that? Ya learns something >> every day.... Thanks for the correction! >> >> My above code did NOT check things in the other direction - that >> is: what if I want something special to happen on an ERROR >> condition and all I get is a WARNING condition, and the ON WARNING >> was specified LAST. I'm not quite sure how a fellow could cleanly >> create only an error condition while trying to type a file. >> Can you suggest some code to test this case? Thanks! > > > Well, I use the following trick (only works if you are NOT in a local > subroutine) > > Use the return command and specify 0 for warning, 2 for error, and 4 > for severe error. > > Example: > > $ TYPE TEST-ERROR.COM > $ SET VERIFY > $ SET NOON > $ RETURN 4 > $ SHOW SYMBOL $STATUS > $ SHOW SYMBOL $SEVERITY > $ ON WARNING THEN SHOW TIME > $ RETURN 0 > $ SET NOVERIFY > $ EXIT What a novel use of the RETURN command right inside a single script itself! And I would have guessed that this was illegal because you are not actually returning from any subroutine. And for sure this example is not in the DCL Help either. I looked under HELP RETURN. Nice thinking! > $ > $ @TEST-ERROR > $ SET NOON > $ RETURN 4 > %NONAME-F-NOMSG, Message number 00000004 > $ SHOW SYMBOL $STATUS > $STATUS == "%X00000004" > $ SHOW SYMBOL $SEVERITY > $SEVERITY == "4" > $ ON WARNING THEN SHOW TIME > $ RETURN 0 > %NONAME-W-NOMSG, Message number 00000000 > 1-FEB-2008 02:10:05 > $ SET NOVERIFY > $ > > Alternatively you can simply experiment by running commands like $ DIR > ASDF: and checking the value of $SEVERITY that it produces and then > using what you need from the results. (Note that you can't always go > by the error level in the % line!!! Run DIR ASDF: to see a > counterexample.) > >> ********* >> >> One thing that IS important to know is that after an "ON" >> condition is acted upon, the last pertinent ON statement is >> more or less rendered 'cancelled' by its having its specified >> action taken. The ON condition executed then returns to its >> default condition, so another set of ON ... statements is >> frequently needed. Now even though the HELP confirms this, >> that IS something that I learned the hard way. And I had >> built myself a little DCL test procedure to prove it and in >> some of my coding you would find a block of ON conditions >> repeated many times. The code looks funny, too. How does >> a fellow set the *default* ON conditions themselves?? > > Have your code reset the ON behavior as needed. If you're not exiting > based on the error, then you simply put in your "default error handler > command" in the code you branch to. Yes, with the tricks I learned here this week, I fully intend to do this from now on. > >> Thanks again. >> >> .. fred bach .. >> > > I use something closely modeled on the method given in "Writing Real > Programs in DCL". (I have no financial interest in the book. I have > the book and it's very good; I strongly recommend it.) The idea is to > be modular: Always exit with an appropriate $STATUS value. > > AEF &-) Always meant to pick that book up. In fact, I suggested it to people here (hoping that they would do the purchasing from their budgets and make the book available to all here). Never happened, as far as I know. Can a fellow get a e-copy online somewhere? Thanks again. .. fred bach .. ------------------------------ Date: Thu, 31 Jan 2008 14:22:53 -0500 From: "David Turner, Island Computers" Subject: Re: Looking for a DECserver 200/MC/ or 300 Message-ID: <13q480a1r3jh5bf@news.supernews.com> Yeah right, and the Tooth fairy is coming to your house tonight... Better hide them dentures.. -- David B Turner Island Computers US Corp 1207 East Highway 80 Suite D Tybee GA 31328 Toll Free: 877-6364332 x201 Intl: 912 786 8502 x201 Fax: 912 786 8505 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. wrote in message news:47a1f182$0$25057$607ed4bc@cv.net... > In article <13q3okgn0g95hc9@news.supernews.com>, "David Turner, Island > Computers" writes: >>If you could use a DSRVZ-MC 32port Decserver 900 I have a few > > OK. I'll take one. They're free right? ;) > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker > VAXman(at)TMESIS(dot)COM > > "Well my son, life is like a beanstalk, isn't it?" > > http://tmesis.com/drat.html ------------------------------ Date: 31 Jan 2008 20:18:05 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Looking for a DECserver 200/MC/ or 300 Message-ID: <47a22cfd$0$25049$607ed4bc@cv.net> In article <13q480a1r3jh5bf@news.supernews.com>, "David Turner, Island Computers" writes: >Yeah right, and the Tooth fairy is coming to your house tonight... >Better hide them dentures.. While most of my teeth have been bonded (I ate too many handle bars and pavement in my youth, not from lack of oral hygiene care), none of them come out ... yet. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 31 Jan 2008 20:38:38 -0500 From: "Glen Thompson" Subject: Re: Looking for a DECserver 200/MC/ or 300 Message-ID: wrote in message news:48072fe0-b8ca-4517-90c8-491429780a21@i7g2000prf.googlegroups.com... > Hello > Was wondering if anybody has a 200/MC or 300 laying around that they > are not using and really dont want to send the item(s) to the trash. > tks > phil I have a DecServer 700-16 that's available. I even have a second one that won't work because I've been unable to clear the password on it. glen ------------------------------ Date: Thu, 31 Jan 2008 21:48:25 GMT From: "Robert Jarratt" Subject: Re: Restricting Access to TCP/IP and DECnet Message-ID: "Bob Koehler" wrote in message news:+qIY+3VhprSS@eisner.encompasserve.org... > In article , "Robert Jarratt" > writes: >> >> Thanks for all the replies. A few people have pointed out that my >> question >> is not entirely clear. The reason I want to do this is that I want to >> give >> an acquaintance access to my hobbyist VAX. I have opened up telnet access >> to >> it from the internet, but the machine is on my home network and just to >> be >> safe I would rather he be unable to go anywhere else on the home network, >> including back out on to the internet. I suppose I could put the machine >> in >> a DMZ if I was doing this properly, but my firewall server only has 2 >> nics >> at the moment. >> >> I will remove NETMBX and see if that does the trick. > > You've asked about TELNET and DECnet, are you running any other > protocols, such as LAT, that you might need to block? (I assume the > system is not part of a cluster). Yes I have LAT but normally I do not have other systems switched on so there would be nowhere to go with it. Regards Rob ------------------------------ Date: Thu, 31 Jan 2008 21:49:30 GMT From: "Robert Jarratt" Subject: Re: Restricting Access to TCP/IP and DECnet Message-ID: "IanMiller" wrote in message news:38bcdfed-8c7d-479c-880c-338c15eb18d0@s19g2000prg.googlegroups.com... > Note that allowing telnet means a valid username & password for your > systems are travelling over the internet unencrypted. > Yes I know that, but I am prepared to accept that risk. That said, what alternatives do you suggest? Regards Rob ------------------------------ Date: Thu, 31 Jan 2008 14:39:00 -0800 (PST) From: Bob Gezelter Subject: Re: Restricting Access to TCP/IP and DECnet Message-ID: <13952503-1a12-4c30-91ad-0f937b5560b5@s19g2000prg.googlegroups.com> On Jan 31, 4:49 pm, "Robert Jarratt" wrote: > "IanMiller" wrote in message > > news:38bcdfed-8c7d-479c-880c-338c15eb18d0@s19g2000prg.googlegroups.com... > > > Note that allowing telnet means a valid username & password for your > > systems are travelling over the internet unencrypted. > > Yes I know that, but I am prepared to accept that risk. That said, what > alternatives do you suggest? > > Regards > > Rob Rob, With LAT, I would first consider disabling OUTGOING connections. See the HELP text within LATCP. If outbound is enabled, I would fix the setup commands in SYS$MANAGER_LAT$SYSTARTUP.COM. If you need outbound connections, I would consider looking into the ACL idea that I mentioned earlier in this thread. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Thu, 31 Jan 2008 14:08:32 -0500 From: "warren sander" Subject: Re: VT100 standards Message-ID: How about looking at sys$system:smgterms.txt "Richard Maher" wrote in message news:fnsje4$63d$1@news-01.bur.connect.com.au... > Hi, > > Is anyone willing to discuss at length the escape sequences for lighting > up > my VT100 LEDs? If we could incorporate that with some form of ^G pitch > control then I really think we can show off VMS's core strengths :-( > > Regards Richard Maher > > PS. Is it true that VT100s shipped with a choice of cord length? I've > often > wondered what the part numbers might have been. > > ------------------------------ Date: Fri, 01 Feb 2008 04:02:25 GMT From: Roger Ivie Subject: Re: VT100 standards and EDT Message-ID: On 2008-01-31, Bill Gunshannon wrote: > In article , > Roger Ivie writes: >> On 2008-01-31, Michael Moroney wrote: >>> I learned this the hard way when my allegedly ANSI Standard >>> H19 terminal didn't work with EDT. >> >> Yeah, but the H19 worked very well with EDT in VT-52 mode. > > I thought the H19 did VT52 not VT100. I know the termcap entry for it > uses VT52 style escape codes and not VT100 style. There are both dipswitches and escape sequences to put it in ANSI mode. I always used them in VT52 mode. -- roger ivie rivie@ridgenet.net ------------------------------ Date: Fri, 1 Feb 2008 05:21:07 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: VT100 standards and EDT Message-ID: billg999@cs.uofs.edu (Bill Gunshannon) writes: >In article , > Roger Ivie writes: >> On 2008-01-31, Michael Moroney wrote: >>> I learned this the hard way when my allegedly ANSI Standard >>> H19 terminal didn't work with EDT. >> >> Yeah, but the H19 worked very well with EDT in VT-52 mode. >I thought the H19 did VT52 not VT100. I know the termcap entry for it >uses VT52 style escape codes and not VT100 style. It could do either VT52 mode or ANSI (not quite VT100) mode. A real VT100 could also do VT52 codes. ------------------------------ Date: Thu, 31 Jan 2008 14:20:37 -0500 From: "David Turner, Island Computers" Subject: Wrong place but desperate Message-ID: <13q47s1pku01g85@news.supernews.com> Is there anyone out there that can write a device driver for Tru64 5.1B Specifically the LSI 53C1010 U160 Controller? I know most people here are VMS specific but there are a few people familiar with Tru64 here. The 53C895 U2 Controller works with certain raid arrays but the Adaptec, of course, is not very friendly with the LSI based external raid controllers out there. Email dturner@islandco.com if interested or know of anyone who has the ability to do this. Remuneration of course depends on success. David -- David B Turner Island Computers US Corp 1207 East Highway 80 Suite D Tybee GA 31328 Toll Free: 877-6364332 x201 Intl: 912 786 8502 x201 Fax: 912 786 8505 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. ------------------------------ Date: Thu, 31 Jan 2008 16:44:12 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Yet another hobbyist software kit request. Message-ID: <08013116441245_2062A39A@antinode.org> I'm looking for a current DECset kit for Alpha and IA64. I gather that there's an ECO1 for V12.8, but I might settle for less (a plain V12.8) if I can't get a pointer to the latest and greatest. Confidentiality (and gratitude) assured, of course. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 31 Jan 2008 23:32:34 -0500 From: JF Mezei Subject: Re: Yet another hobbyist software kit request. Message-ID: <47a2a229$0$22105$c3e8da3@news.astraweb.com> Steven M. Schweda wrote: > I'm looking for a current DECset kit for Alpha and IA64. I gather > that there's an ECO1 for V12.8, but I might settle for less (a plain > V12.8) if I can't get a pointer to the latest and greatest. Sorry, all I have is 12.7 > HP Code Management System for OpenVMS Alpha Systems" 0W1AA 4.4 > SSB NCH Y N N DECSET127 3 > "HP DECset for OpenVMS Alpha Systems" MUPAA 12.7 > SSB NCH Y N N DECSET127 3 > "HP Digital Test Manager for OpenVMS Alpha Systems" 0W4AA 4.3 > SSB NCH Y N N DECSET127 3 > "HP Language-Sensitive Editor/Source Code Analyzer for OpenVMS Alpha" 0W2AA 5.0 > SSB NCH Y N N DECSET127 3 > "HP Module Management System for OpenVMS Alpha Systems" 0W5AA 3.7 > SSB NCH Y N N DECSET127 3 > "HP Performance and Coverage Analyzer for OpenVMS Alpha Systems" 0W3AA 4.9 > SSB NCH Y N N DECSET127 3 If you still want that, get in touch. ------------------------------ Date: Thu, 31 Jan 2008 22:33:26 -0800 (PST) From: Cluster-Karl Subject: Re: Yet another hobbyist software kit request. Message-ID: <63f3d297-7b95-450a-b997-df8d56ee742c@c4g2000hsg.googlegroups.com> On 1 Feb., 05:32, JF Mezei wrote: > Steven M. Schweda wrote: > > I'm looking for a current DECset kit for Alpha and IA64. I gather > > that there's an ECO1 for V12.8, but I might settle for less (a plain > > V12.8) if I can't get a pointer to the latest and greatest. > You can find the alpha kit here: ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha/ regards Kalle ------------------------------ End of INFO-VAX 2008.063 ************************