Info-Vax-REQUEST@KL.SRI.COM (Ramon Curiel) (05/08/87)
Info-Vax Digest Friday, 8 May 1987 Volume 0 : Issue 14 Today's Topics: RE: VWS (aka UIS) - VAX/VMS Workstation Software checking status of remote node Forwarded Mail U. of Salzberg & LQP02 Programmer's Manual SWING sources posted to comp.sources.misc Help with LAT/DECservers Problems with BASIC 3.0 and/or VMS 4.5 Defining keys in EDITOR to RING BELLS, FORM FEED, etc. DECNET across x.25 JUICER ---------------------------------------------------------------------- Date: Thu, 7 May 87 04:28:26 PDT From: nagy%warner.hepnet@lbl.arpa Subject: RE: VWS (aka UIS) - VAX/VMS Workstation Software >Date: Tue, 5 May 87 12:34:50 EDT >From: "Patrick J. O'Neill" <poneill@AMSAA.ARPA> >Subject: UIS Software on MicroVAX > > We have a Microvax (actually a VAXstation II) running Microvms >version 4.5. We have a layered product that requires UIS (User Interface >Services) version 3.0 or 3.1. Alas, when we dump some headers of UISSHR.EXE, >it appears we have version 1.5 or so of UIS. My question is, "is UIS an >integral part of VMS , or is it separately ordered ? UIS - really called VWS for VAX Workstation Software (or System?) is a VMS layered product and is ordered/shipped separately from VMS. My manual set claims it is for V3.0 which I believe is the current version. =Frank Nagy =Fermilab Research Division EED/Controls =FNAL::NAGY.HEPNET or NAGY@FNAL.Bitnet ------------------------------ Date: Thu, 7 May 87 09:16 EDT From: <GEOFFRIL%UNION.BITNET@wiscvm.wisc.edu> Subject: checking status of remote node We have many DCL procedures that access resources on other DECNET nodes. Is there an easy way from DCL to inquire if a remote node is available on the net. I know you can simply try to access the file and wait for DECnet to timeout, but that is tedious and slow. I'd like to do it much faster. Does anyone know of a much faster trick? ------------------------------ Date: Thu, 07 May 87 09:07:23 EDT From: Harold C Pritchett <HAROLD%UGA.BITNET@wiscvm.wisc.edu> Subject: Forwarded Mail The note below was send incorrectly to the BITNET Re-distribution list. I am forwarding it to the entire list. ---------------------------Original Mail---------------------------------- Chris Yoder's [CHRIS@ENGVAX.SCG.HAC.COM] letter regarding the speed of SETUP got me curious. > I'm not quite sure what to say about the issue of speed... The > approach outlined above [SETUP/PREPARE] will be quicker than one big > long command procedure most of the time, but I really have no data or > feel for how long it takes to add another command procedure onto the > stack. I quite frankly never thought of worry'n about how much overhead SETUP incurred simply because it was a one shot deal/per terminal session/per command. But just for 'grins' I did a very non-scientific test of all the commands that are currently SETUPable on our system (49 at last count). I have a quick and dirty little COM file that will 'time' the elapsed time and CPU time of any DCL 'command' by calling lexical functions before and after execution of the command. With this tool, I checked the time it took for SETUP to define each command, as well as to SETUP an empty file (to check the overhead of SETUP itself). System: VAX/VMS 4.2 on an 8600 Batch Jobs: 5 Interactive Users: 49 Response time: 'Decent' (told you this wasn't scientific) ----------------------------------------------------------------------- File Size Elapsed Time CPU seconds ----------------------------------------------------------------------- SETUP by itself 314 lines 0.82 secs 0.28 An average application 3-20 lines 1-2 secs 0.3 - 0.9 Fastest 1 line 0.96 secs 0.40 Slowest 34 lines 15.77 secs 0.74 Most CPU 83 lines 7.97 secs 1.38 ----------------------------------------------------------------------- - The 'Fastest' SETUP file is a one-line symbol definition. - The 'Slowest' is for a program called (PC-LINK). This SETUP file has to execute an image to initialize some stuff. Thus this particular application is not very representative of a typical SETUP job. - The title of 'Most CPU' goes to the SETUP of a chemical engineering modeling package. This program came with several humungous (i.e. BIG) COM files to be executed by the user who wants to use this porker. We broke it up a bit so that the SETUP does those things that only need to be done once per terminal session. Still, using the model they gave us, this SETUP COM turns around and opens 6 others. Again, this isn't very scientific (for one thing, my timer COM is not particularly accurate). But it did confirm my casual observations; playing with files from a COM file is expensive in terms of response time. On the other hand, logical and symbol definitions, playing games with lexical functions, and even big jumps done by a GOTO command really seem to work a lot faster than they have any right to. (For example, SETUP uses all kinds of string handling lexicals to parse it's command line, but as you can see it zips right along.) But when you open another COM file, or start reading or writing files from the command procedure, you can really notice the effect in terms of response time! So, maintaining one big COM file may be a pain in the neck, but it wouldn't surprise me that it might be faster than our SETUP. On the other hand, SETUP, even as a COM file "ain't that bad....". (Still, SETUP should be an executable. Someday we're going to do it right....some day....). ---------------------------------------------------------------------- Bill Costa Thought for today: UNH Computer Services University of New Hampshire There's never time to do it right. Durham, NH 03824 There's always time to do it over. Voice: (603) 862-3056 Bitnet: W_COSTA@UNHH ------------------------------ Date: 7 May 87 10:45:00 EDT From: "WILKINSON R.O." <sherman@nusc.arpa> Reply-to: "WILKINSON R.O." <sherman@nusc.arpa> Subject: U. of Salzberg & LQP02 Programmer's Manual Two questions: 1) Is anybody out there listening in from the University of Salzberg? If so, I'd be interested in getting in touch with you. 2) If somebody in the Connecticut/Massachusetts/Rhode Island area has the LQP02 Programmer's Reference booklet handy, I'd be interested in borrowing it to copy a few pertinent pieces of information from it. Thanks, Bill. +------------------------------------------------------------------------------+ | ARPANET: sherman@nusc.arpa USPS: Bill Sherman | | AT&T: (203) 440-6210 Navel Underwater Systems Center | | MIS/OA/WP Group, Code 334 | | Building 28, Room 200 | | New London, CT 06320 | +------------------------------------------------------------------------------+ | "Exhilaration is that feeling you get just after a great idea hits you, and | | just before you realize what's wrong with it." - Unknown. | +------------------------------------------------------------------------------+ ------------------------------ Date: 7 May 87 03:54:47 GMT From: munnari!murdu!u3369429@seismo.css.gov (Michael 'I love VMS' Bednarek) Subject: SWING sources posted to comp.sources.misc I posted the (hopefully) stable version of SWING to comp.sources.misc As that is a moderated group, it will probably take a few days to be available. Thanks to: Eric Andresen (the original Author), Portia Shao (the original poster), Mike Strasser (who contributed ISADIR) and many more who submitted bug reports and improvement suggestions. Michael Bednarek u3369429@murdu.oz.au or U3369429@xvax.dn.mu.oz.au Here is the introduction of that posting: Finally. Here is SWING version '04-May-87' . (SWING is a VAX/VMS utility for displaying the graphical representation of directory trees on a VT100 or VT200 type terminal.) Because this is strictly a VAX/VMS tool, I packaged it not in the traditional "shar" format, but as self-unpacking VMS command procedure. It comes in 10 parts (to keep each part below 16000 characters). You have to save all 10 parts to files, remove all the mailer header lines and CONCATENATE them to one single file. The size of that file should be 278/279 blocks, 4628 lines, 16722 words, 134734 characters. ------------------------------ Date: 1 May 87 07:44:06 GMT From: munnari!otc!metro!basser!nucs!morrison@seismo.css.gov (David Morrison) Subject: Help with LAT/DECservers We have recently (January) replaced two VAX 11/780s by two VAX 8550s. This also meant replacing nice predictable DZ11s with an Ethernet and DECserver 200s. We also have a Micom Micro 600 port selector. For various reasons, most of the DECservers have temporarily been connected in place of the DZ11s on the back of the Micom, and set to be transparent to the users. However, we have taken advantage of the ability in LATplus V1.1 to have serial printers (LA120s) shared between the two machines. Certain terminals which only access our library circulation system have been connected directly to servers, with the server configured as dedicated to that machine. (They are VT100s and lookalikes used with Fortran and FMS for enquiries, etc.) Since January, we have had no problems with the DECservers connected to the Micom. However, we have had no end of problems with the DECservers used directly. Appeals to DEC software and hardware support have been no help at all. Can anyone offer any suggestions on the following problems? 1. Most of the library terminals jam up about once a fortnight for no apparent reason. The symptoms are that any character typed is not echoed, and a beep sounds. If it were connected to a DZ, I would say that it was input buffer overflow on a terminal with NOHOSTSYNC. However, the terminal characteristics are explicitly set to HOSTSYNC, and in any case, the server was configured for XON/XOFF flow control. Strangely, the job running at that terminal disappears! Even more strange is that fact that the server still thinks that something is using the terminal, since its status display shows the port still connected to the host. The only way to clear this is to connect to the server's remote console with NCP and manually logout the port. (I'm not sure what the relationship of HOSTSYNC is to the DECserver software. It appears that the server attempts to emulate the behaviour of a DZ line for buffer overflow, that is, if HOSTSYNC is set, send an XOFF to the terminal (ie, lock the keyboard), otherwise, reply with a beep for every character lost. For a DZ, you can unlock the keyboard and type a Ctrl/Y to interrupt whatever is going on. For a DECserver, nothing can get through until the host issues a read. For NOHOSTSYNC, Ctrl/Y interrupts the program on both DZ and DECserver. All this in spite of the DECserver being configured for XON/XOFF flow control!) 2. The queues for the serial printers that are heavily used often appear in the stalled state, and eventually stop. They then have to be manually restarted. We have observed this behaviour on printers connected to DZ11s when there has been a paper jam or something else that caused the printer to send an XOFF. In this case, it looks as though the queue gets stalled because the other VAX is using the printer. This is not always the case. Sometimes it stalls in the middle of a print job, and the queue stops, leaving the job checkpointed. The other VAX cannot get the printer because the server still thinks it is connected to the machine with the stopped queue. Surely the LAT symbiont must be able to recognise that it is in a queue for the printer, and avoid stopping the queue. 3. I wanted to be able to login to a local Unix machine and copy files around, so I set up an applications port with LATCP. I first tried using SET HOST/DTE LTAxx: just to see if I had everything set correctly. I found that even though the line was set to 4800 baud, the output was coming back to me at about 30 characters per second. Later on, it picked up a bit, but after about 1 - 2 minutes, it locked up and nothing had any effect except exiting from SET HOST with Ctrl/\. So I tried Kermit, which at least gave reasonable speed, but it eventually locked up also. I suspect that it is again a synchronisation problem. Changing the line to NOHOSTSYNC made no difference to SET HOST (since it sets HOSTSYNC itself!!), but caused Kermit to lose incoming characters. (This cannot be attributed to Unix since I tried connecting the line to the VAX I was using with the same results. (Is this incest? :-)) Someone suggested disabling the flow control at the DECserver, and this seemed to work, but I wonder what will happen at high baud rates when the Ethernet is busy. 19.2Kbaud = about 150 characters in 80 milliseconds which is the time between messages on the Ethernet. Has the server got enough buffer space? The first problem could possibly be triggered by noise on the lines to the terminals, since we haven't got enough money yet to extend the Ethernet to the library. (We have had remarkably few problems driving RS232 signals up to 4800 baud for over 2 kilometres.) However, I cannot see why this results in the behaviour we have seen. PS Has anyone any experience with DEC's Terminal Server Manager software? Thanks in advance for any help David Morrison, Computing Centre, Uni of Newcastle, Australia ARPA: morrison%nucs.oz@seismo.css.gov UUCP: {seismo,hplabs,mcvax,ukc,nttlab}!munnari!nucs.oz!morrison ------------------------------ Date: 7 MAY 87 17:19-N From: BERGER%CSGHSG5A.BITNET@wiscvm.wisc.edu Subject: Problems with BASIC 3.0 and/or VMS 4.5 With BASIC 3.0 we also got quite a few new problems !!! The following program is supposed to signal "Normal successful completion". It did so under BASIC 2.4, but now it signals "Message number 00000004" and kills my program. The problem is that when calling LIB$SIGNAL in a BASIC Error-Routine the fatal bit is a l w a y s set in the message code. Therefore LIB$SIGNAL behaves like LIB$STOP. DEC says that LIB$SIGNAL is not supported with BASIC because BASIC has its own error handling facility (whatever that means). Does anybody know the problem or even know a solution ? Does anybody know about other problems with BASIC 3.0 ? Ruedi Berger Informatikbereich HSG St. Gallen, Schweiz ------------------------------------------------------------------------------ 10 EXTERNAL LONG CONSTANT SS$_NORMAL ON ERROR GOTO 20 H1% = 0% H1% = 1% / H1% 15 PRINT "Back from error routine" GOTO 30 20 CALL LIB$SIGNAL (SS$_NORMAL BY VALUE) RESUME 15 30 END ------------------------------ Date: 7 May 87 13:38:00 GMT+536:14 From: "Daniel Gregory" <gregory@brl-lvax.ARPA> Reply-to: "Daniel Gregory" <gregory@brl-lvax.ARPA> Subject: Defining keys in EDITOR to RING BELLS, FORM FEED, etc. This is what I do for bells and whistles. In my login.com $ define edtini sys$login:edtini.edt Then create the file EDTINI.EDT with some or all or more of the following: DEFINE KEY GOLD 15 AS "SHL." DEFINE KEY GOLD 14 AS "SHR." DEFINE KEY CONTROL G AS "7asc." DEFINE KEY CONTROL L AS "10asc." DEFINE KEY CONTROL F AS "12asc." Then when you are editing a file and wish to insert a bell in your text type CTRL G Want a form feed? CTRL F Want several line feeds? CTRL L several times. The first line will shift the text on the crt to the left by pressing PF1 and the left arrow key. The second line moves it to the right by pressing PF1 and the right arrow key. All this works when you are editing in mail too. Enjoy. :-) Dan Gregory GREGORY@BRL-LFD.ARPA P.S. You know it took me a while to realize that :-) was a happy face sideways. I hate the digest format. :-( ------------------------------ Date: 7 May 87 20:11:23 GMT From: decvax!necntc!jeff@ucbvax.Berkeley.EDU (Jeff Janock) Subject: DECNET across x.25 As the summary states, we are in need of finding out how much overhead there is in maintaining a DLM circuit across X.25. The current situation is this: In the USA, there is one system (VMS) hooked up to TYMNET via a 9.6kbps HDLC line and the VAX PSI software. We run on an 8300 using the DMB32 for our psi sync port. All this works nice. There are many other systems within the USA but only the one node with the X.25 connection. We have setup PSI ACCESS for the other nodes in the USA to utilize the X.25. Now the problem. We have sites in Europe that we must connect to for transfer of data. I have succeeded in established an X.25 DLM circuit to one machine in Germany on Datex-p. I have found that during the day (0700-2000 EST), throughput is horrible and the link is extremely prone to faults (circuit fault type messages from decnet). I have a couple of questions/queries given this backgroud: 1) What parameters may be tweeked to help maintain this circuit? 2) How may the actual cost of maintaining this circuit be determined? If you have any experience with X.25 DLM circuits, I sure would like to chat with you for a little bit... Please respond via email. Regards, -- Jeff Janock - NEC Electronics +1 617 655 8833 jeff@necntc.NEC.COM {ames, decvax, harvard, linus, mit-eddie}!necntc!jeff ------------------------------ Date: Thu, 7 May 87 19:30 EST From: "John H. Yates" <YATES%a.chem.upenn.edu@cis.upenn.edu> Subject: JUICER I asked about user experiences with JUICER a few weeks ago, but got only a request for it if I obtained it. I will have the appropriate DECUS tape next week, but still would like to hear from users about its reliability. I hope not to reduce user disks to pulp. Thanks, John ------------------------------ End of Info-Vax Digest **********************
tedcrane@batcomputer.UUCP (05/11/87)
"Daniel Gregory" <gregory@brl-lvax.ARPA> writes: >This is what I do for bells and whistles. >DEFINE KEY CONTROL G AS "7asc." >DEFINE KEY CONTROL L AS "10asc." >DEFINE KEY CONTROL F AS "12asc." >Then when you are editing a file and wish to insert a bell in your >text type CTRL G >Want a form feed? CTRL F >Want several line feeds? CTRL L several times. Sorry, Dan, I'm not trying to flame on you, but for all those to whom EDT is still "just a little" arcane: Before you all run out to do this, stop to think that the standard EDT definition for "CONTROL L" is "12asc.". This is because control-L is the <FF> formfeed character. Why define F to do what L does already? It might be more prudent to leave control-L as is, and redefine CONTROL-J (the <LF> linefeed character) instead. It normally defaults to "DBW.", but perhaps you don't use that?