Article 6867 of comp.org.decus: The DECUServe Journal --------------------- July, 1997 From the Editors' Keyboard . . . . . . . . . . . . . 2 What's inside DCL Directory Spec Hacking . . . . . . . . . . . . . 3 How to derive a file's directory in DCL Lowest File Version Number . . . . . . . . . . . . . 7 More DCL hackery with filespecs Is a TK50 Cartridge Fixable? . . . . . . . . . . . 14 A few details on tape drive maintenance DECstation Boot Failure . . . . . . . . . . . . . 15 Problems with an old Ultrix box PC Telnet Woes . . . . . . . . . . . . . . . . . . 18 PC Telnet sessions randomly disconnect CONSTANT Field on PAK . . . . . . . . . . . . . . 23 What does CONSTANT=foo mean, anyway? About the DECUServe Journal . . . . . . . . . . . 25 Contact Information . . . . . . . . . . . . . . . 26 The DECUServe Journal July, 1997 Page 2 From the Editors' Keyboard From the Editors' Keyboard ---- --- -------- -------- Here at last is the rather tardy July edition of the Journal. We won't bore you with the tales of work and family life that intervened to delay its appearance, only ask your indulgence. In this issue, we start with a couple of DCL "challenges" of the sort that seem to bring out the creative energies in the DECUServe user base. Several random shorter pieces round out the issue. Next month (which is to say actually this month, August), we plan to focus on security topics, particularly network security issues. (We also hope to be closer to on time!) * * * * * The DECUServe Journal July, 1997 Page 3 DCL Directory Spec Hacking DCL Directory Spec Hacking --- --------- ---- ------- Abstract: Here is another DECUServe DCL puzzle: Given a file, what's the best way to figure out the filespec of the directory in which the file resides. (This will become clearer in a minute.) Participants: Rob Brown, David Cantor, Henry Carmichael, Linwood Ferguson, Jeffrey Sue, Don Vickers, Chris Wesling, Tom Williams, Dan Wing. Conference: VMS Note 2828.0, 8-May-1997 Ferguson: Finding spec of containing directory from DCL ------------------------------------------------------- Am I missing some obvious way to do this in DCL (or a program for that matter), e.g. a parameter to one of the lexicals. Given you have a file or directory spec, say in a logical like X X = device:[h.i.j.p]y.z;v (arbitrary depth) Suppose you want to do something to the directory file, like attach an ACL and protection. In a brute force approach you need to go find the last piece, e.g. "p" above, and form a string of: device:[h.i.j]p.dir You can cheat a bit by: device:[h.i.j.-]p.dir but it's still a pain to do in DCL each time, especially finding the "p" at the end if you don't know how many levels are involved. I keep writing little loops for it and each time think "there must be a better way". Is there some lexical I've missed that will do this for you, return the containing directory? I realize a few of the things you might want to do can be done directly, if un-documentedly, e.g. set dir/acl=() device:[h.i.j.p] works fine, but The DECUServe Journal July, 1997 Page 4 DCL Directory Spec Hacking set dir/prot=() device:[h.i.j.p] doesn't, nor does trying to delete the directory itself. Note 2828.1, 8-May-1997 Wing: SET DEFAULT ? ------------------- One trick would be: $ SAVE = F$ENVIRONMENT("DEFAULT") $ SET DEFAULT directory $ SET DEFAULT [-] $ DIR = F$ENVIRONMENT("DEFAULT") $ SET DEFAULT 'SAVE' Note 2828.2, 8-May-1997 Ferguson: Need the file spec of the containing directory -------------------------------------------------------- > $ SAVE = F$ENVIRONMENT("DEFAULT") > $ SET DEFAULT directory > $ SET DEFAULT [-] > $ DIR = F$ENVIRONMENT("DEFAULT") > $ SET DEFAULT 'SAVE' That gives you a directory spec one up, but doesn't give you the file spec of the directory you were in. Simple example: we have a logical SYS_PRINTER that points to a directory where files are stored. I want to set a certain protection on all files in that directory, then set a default acl on the directory itself, and change its protection. From a DCL script. I don't want to assume anything about the logical SYS_PRINTER except that it is a directory spec. What I want to do is set file sys_printer:*.*;* /prot=(whatever) set dir/acl=(whatever) sys_printer set dir/prot=(whatever) sys_printer except the latter doens't work, and SET FILE/PROT seems the only approach and requires a file spec. SET PROT doesn't seem to take /DIR. So somehow I have to turn the logical into a directory spec, pick off the last item in the directory spec, reform a directory spec and add that plus ".DIR" to the end, and use SET FILE/PROT. None of this is difficult, but it appears to require a loop and about 6 lines of code. Over the years I've done it enough in enough variations that I figured it was time to ask if I was missing a simple way to do it. The DECUServe Journal July, 1997 Page 5 DCL Directory Spec Hacking Note 2828.3, 8-May-1997 Brown: ------- > That gives you a directory spec one up, but doesn't give you the file > spec of the directory you were in. But then you could $ LASTDIR = SAVE - DIR and do something with that. > None of this is difficult, but it appears to require a loop and about 6 > lines of code. We might have exceeded that by now .... Note 2828.4, 8-May-1997 Vickers: No loops but more code ------------------------------- I was working down the same lines as Rob suggested in .3 and have created the DCL below that seems to work for the conditions described. It allows for both sub and root directory conditions but exceeds the desired line count by 100%. ('; Have fun, don $ SAVE = F$ENVIRONMENT("DEFAULT") $ set file sys_printer:*.*;* /prot=(whatever) $ SET DEFAULT sys_printer $ LEAF = F$ENVIRONMENT("DEFAULT") $ SET DEFAULT [-] $ IF F$LOCATE(".",LEAF) .LT. F$LENGTH(LEAF) $ THEN $ BRANCH = F$ENVIRONMENT("DEFAULT") - "]" + "." $ DIR_FILE = LEAF - "]" - BRANCH + ".DIR" $ ELSE $ DIR_FILE = F$PARSE(LEAF,,,"DIRECTORY") - "[" - "]" + ".DIR" $ ENDIF $ set dir/acl=(whatever) 'DIR_FILE' $ set dir/prot=(whatever) 'DIR_FILE' $ SET DEFAULT 'SAVE' Note 2828.5, 8-May-1997 Ferguson: The winner, perhaps, but no cigar ------------------------------------------- First attempts at breaking it failed, so looks good. :-) I think everyone is confirming my initial idea that there is no The DECUServe Journal July, 1997 Page 6 DCL Directory Spec Hacking straightforward way of saying: x = f$parent_directory_as_file_spec(spec) But a no-loop technique I think wins over a looping technique. I would look with f$element for the last one with "." as delimiter. Note 2828.6, 9-May-1997 Williams: Four lines, no loop.... --------------------------------- I think that this is the code you're looking for. It takes "current" -- some directory spec -- and turns it into "cur_as_file", which is the filespec for that directory file. $ CURRENT = F$ENV( "DEFAULT") $ CUR_NO_PER = CURRENT - "." - "." - "." - "." - "." - "." - "." - "." - "." $ P_COUNT = F$LENGTH( CURRENT) - F$LENGTH( CUR_NO_PER) $ CUR_NAME = F$ELEMENT( 0, "]", F$ELEMENT( P_COUNT, ".", CURRENT)) $ CUR_AS_FILE = (CURRENT - ("." + CUR_NAME)) + CUR_NAME + ".DIR" $ WRITE SYS$OUTPUT CUR_AS_FILE Note 2828.7, 9-May-1997 Cantor: One missing line. ------------------------- Cool! This needs one more line at the beginning: $ SET DEFAULT [] to ensure that [] are used rather than <>. (And when the number of subdirectory levels allowed increases the line which removes the periods will have to be adjusted.) Note 2828.8, 9-May-1997 Ferguson: I'd call it devious -- I like it ------------------------------------------ > $ CUR_NO_PER = CURRENT - "." - "." - "." - "." - "." - "." - "." - "." - "." > $ P_COUNT = F$LENGTH( CURRENT) - F$LENGTH( CUR_NO_PER) The DECUServe Journal July, 1997 Page 7 DCL Directory Spec Hacking Note 2828.9, 9-May-1997 Carmichael: Another entry ------------------------- Then, of course, there is $ set default sys$print $ if f$element(1,".",f$logical("sys$print")) .eqs. "." $ then x == f$parse(f$logical("sys$print"),,,"device")+"[000000]" + - (f$parse(f$logical("sys$print"),,,"DIRECTORY") - "[" - "]" + ".DIR") $ else myd = f$environment("default") $ set default [-] $ x == f$environment("default")+((myd - (f$environment("default") - "]"))- - "." - "]"+".DIR") $ endif It's seven lines long (it could go on seven lines), but at the end, x is the directory file spec you need. (well, I like it :-)) Note 2828.10, 9-May-1997 Wesling: f$logical -> f$trnlnm ------------------------------ FYI, f$logical is obsolete -- it doesn't even appear in DCL Help any more. Just replace all occurrences of f$logical with f$trnlnm and your code will still work fine. Note 2828.11, 9-May-1997 Sue: Better late than later... ------------------------------ I hate to beat a dead horse, but I love DCL so here's one more... $ set default sys_printer $ set file/prot=(whatever) *.*;* $ cd = f$parse(f$environment("DEFAULT"),,,"directory") - "[" - "]" $ set def [-] $ cd2 = f$parse(f$environment("DEFAULT"),,,"directory") - "[" - "]" $ rdir = cd - cd2 - "." + ".DIR" $ set acl.. 'rdir' $ set file... 'rdir' Lowest File Version Number ------ ---- ------- ------ The DECUServe Journal July, 1997 Page 8 Lowest File Version Number Abstract: For part two of the DECUServe DCL puzzler (no relation to the Car Talk Puzzler), we present this next series of notes. The issue here involves SNA printer emulation software that creates many files with the same name, leading to some interesting issues with file version numbers. Participants: Gus Altobello, Bruce Bowler, John Briggs, Larry Clegg, Dale Coy, Linwood Ferguson, Kevin Gilmore, Pierre Hahn, Terry Kennedy, Larry Kilgallen, Norm Raphael, Pete Sivia, Don Vickers, Dan Wing. Conference: VMS Note 2733.0, 8-Aug-1996 Clegg: Finding Files in Ascending Version Number Order ------------------------------------------------------ Greetings Earthlings and Others: I'm trying to find a DCL trick to take care of this problem: Each day a particular directory gets loaded with 1000's of files. Each file is named the same, e.g. X.DAT. By the end of the day there will be 7000+ X.DATs in the directory. The files are created in spurts throughout the day and must be processed in ascending version number order. F$SEARCH returns things in descending version number order. When I say spurts I mean that within <5 minutes I can get a several hundred X.DATs created then there will be a lull. Toward the end of the day the X.DATs will only be created one or two at a time. And no - there is nothing I can do about them all being named the same thing. A DCL procedure wakes up every few minutes and starts looking for these files to process them. This routine first checks to see if there are any X.DATs to be processed and then if it finds one it starts looking for X.DAT;1, X.DAT;2, etc. It keeps this up until it finds the lowest version number out there. It continues until it finds no more X.DATs. As it processes an X.DAT it renames the file to X.DAT_PRC. In other words it traverses the files in ascending order by version number by brute force. I've tried to come up with a way of intelligently figuring out what the current lowest version number is and starting at that point rather than always starting at one and counting up but nothing seems to work. Any ideas? The DECUServe Journal July, 1997 Page 9 Lowest File Version Number Note 2733.1, 8-Aug-1996 Wing: ;-0 --------- The version number ";-0" will give the lowest version available. For example: $ dir/column=1 login.com Directory USERS:[DWING] LOGIN.COM;292 LOGIN.COM;291 LOGIN.COM;290 LOGIN.COM;289 LOGIN.COM;288 LOGIN.COM;287 Total of 6 files. $ write sys$output f$parse(f$search("login.com;-0"),,,"version") ;287 which will give you a place to start working your way "up". Note 2733.2, 8-Aug-1996 Hahn: Rename the files with time created ---------------------------------------- You could also rename each file X.DAT with a number which you derive from either the time of the file creation or the revision number subtracted from 10,000 (putting leading zeroes) so that they sort properly on a DIR command Note 2733.3, 8-Aug-1996 Kennedy: Might increase directory size -------------------------------------- As I recall from my past work with the VMS filesystem, there's a special optimization in the directory file for multiple versions - it's a short directory entry that just says "same thing, different version". If you go to unique names, I think the directory will get a *lot* bigger. Note 2733.4, 9-Aug-1996 Sivia: You can use DFU to compress the directory ------------------------------------------------ On a related note, if you do have a large directory and you are seeing lousy response times for directory lookups, deletes, etc., simply use the DEC VMS freeware CDROM utility DFU to compress the directory and get back the best possible directory access time. DFU works exceptionally well and is very quick to execute. I had horrible directory performance problems on one of my systems due to a faxing app The DECUServe Journal July, 1997 Page 10 Lowest File Version Number that loved to create and delete temp files in a few directories and performance wouldn't be acceptable after a few hours of running. Using DFU's DIRECTORY/COMPRESS command several times a day worked wonders in speeding up the app, even tho at any one point during the production day there might be a thousand files in the directory. Note 2733.5, 9-Aug-1996 Ferguson: Sort the versions --------------------------- You might just f$search through ("whatever;*") and stuff the version numbers into a string, e.g. versions = this_version + "/" + versions in a loop. Note that puts each lower version at the front of the list. When you're done, then process them by looping through f$element(counter,"/",versions) and use that version number. This only works if you have a limited number of versions of course. If you might have a large number, you could write the versions to a file and SORT them and read them back in to do the same thing. Note 2733.6, 9-Aug-1996 Bowler: but I like the ;-0 idea best ------------------------------------ Of course since the filename remains the same, you would only need to store the version number ala $ versions = "" $ loop: $ file = f$search("x.dat;*") $ if file .eqs. "" then goto process $ versions = f$parse(file,,,"version") + versions $ goto loop $ process: $ counter = 0 $ proc_loop: $ vno = f$element(counter,";",versions) $ if vno .eqs. ";" goto done $ file = "x.dat;" + vno $! process the file $ counter = counter + 1 $ goto proc_loop $ done: $! clean up code goes here Note I've not tested this so there may be a syntax error or two... The DECUServe Journal July, 1997 Page 11 Lowest File Version Number You're still limited to how many versions you can deal with this way but it's alot more than if you need to store the entire name. Note 2733.7, 9-Aug-1996 Altobello: Save state between passes... --------------------------------------- I don't know how long the ;-0 will take, but if it's fast enough I'd go with that. If it's not fast enough, perhaps when your procedure runs it should save the highest version number processed and restart the next time at that number. This saves *all* searching of the directory. Silly question: What happens when you hit ;32767? Note 2733.8, 9-Aug-1996 Clegg: Problem Solved! Thanks. ------------------------------ > I don't know how long the ;-0 will take, but if it's fast enough I'd go > with that. This is the one that works best for us. It's so simple I should have seen it to begin with! We've already implemented it. > Silly question: What happens when you hit ;32767? Not a silly question. I posed this same thing to DEC. What's going on is we are running SNA PRE (IBM Printer Emulation). The software forms a link over our SNA Gateway and the remote IBM shop prints files to us with this software. I've found that each time a file is sent down to us from the IBM systems the file is ALWAYS created with the same name as the printer hence all the version numbers. I've also found that PRE keeps track internally of what was the last version number created. Now get this feature: if 5 files have come down via PRE and and are named X.DAT;1, X.DAT;2...X.DAT;5 then my routine processes them into X.DAT_PRC;1, X.DAT_PRC;2...X.DAT_PRC;5. At this point there are no X.DAT files there. Now another X.DAT is sent down. What would you expect it to be named? X.DAT;1 cause there are no other X.DATs in the target directory...right? Wrong! In Digital's infinite wisdom they made PRE know what the last version number was and the next X.DAT will be version 6 - even if it comes down hours later and there are no other X.DATs in the directory at the time of creation!!! Since we get so many files (7000+) a day with this software we would very quickly hit the version limit. I haven't ever let it run that long but I suspect it would probably freeze. We have to shutdown and restart the PRE The DECUServe Journal July, 1997 Page 12 Lowest File Version Number software each night to get this internal counter reset. I've complained to Digital and demonstrated repeatedly this "feature" but they appear to be unwilling to address it. I look at it as a bug but they do not! Thanks to everyone for all the very useful information! Note 2733.9, 9-Aug-1996 Vickers: 32767 is an architectural limit ---------------------------------------- It is trivial to test the boundary condition: $ cre foo.bar;32766 test ^Z $ cre foo.bar test 2 ^Z $ cre foo.bar %CREATE-E-OPENOUT, error opening USR_SCRATCH:[VICKERS]FOO.BAR; as output -RMS-E-CRE, ACP file create failed -SYSTEM-W-BADFILEVER, bad file version number The bottom line is that 32767 is a hard limit and the application designer must allow for this. There are a number of approaches folks take to address the issue. In addition to periodically deleting all the files that might reach the ceiling, there is code around that renames all the files to go back to ;1 and up. I have been meaning to grab one of the various tools that do the latter for use on our log file areas on DECUServe but I try to have better things to do. Note 2733.10, 9-Aug-1996 Kilgallen: ----------- But according to the report, these tricks do not work when your opponent is this SNA software!!! Note 2733.11, 9-Aug-1996 Coy: Test it or don't complain? ------------------------------- > infinite wisdom they made PRE know what the last version number Hmmm. > I haven't ever let it run that long but I suspect it would > probably freeze. On the other hand, it is quite _possible_ that PRE handles the upper limit on version numbers, and starts over at ;1 or something. The DECUServe Journal July, 1997 Page 13 Lowest File Version Number [Note: I'm not saying whether it is likely or not, but you can't claim it's a bug until you show that it fails] Note 2733.12, 9-Aug-1996 Briggs: ;-0 is plenty fast enough --------------------------------- > I don't know how long the ;-0 will take, but if it's fast enough I'd go > with that. Using ;-0 should be almost exactly as fast as using the actual version number of the first existing version of the file. Either way, the XQP has to dig through all higher version numbers in the directory block containing the file you're after, sequentially scanning until it finds the one you want. In actual testing, any delay is unnoticible. Note 2733.13, 15-Aug-1996 Gilmore: Sorry for the late reply, but, trick PRE. -------------------------------------------------- >> Silly question: What happens when you hit ;32767? >... > What would you expect it to be named? X.DAT;1 cause there are no > other X.DATs in the target directory...right? Wrong! In Digital's Larry, sorry about a late reply to this but I have a suggestion on how to fool the PRE software into reseting its counter. In your procedure after you've deleted all of the prior versions you ... $ CREATE X.DAT;1 and effectively reset the version limit? Note 2733.14, 15-Aug-1996 Clegg: Interesting ------------------ Interesting idea. I'm a little skeptical that it would work cause it seems that PRE doesn't bother to look at what's already in the directory for the next version number but instead relies on it's own internal counters. Using the X.DAT;-0 method works quite well for us and we're very happy to have found that work-around. The DECUServe Journal July, 1997 Page 14 Lowest File Version Number Note 2733.15, 16-Aug-1996 Raphael: Wrong ended again -------------------------- Right as rain. The problems on the sending (SNA) end, and you can't do anything about it. You've probably go the best you can get with ;-0. Is a TK50 Cartridge Fixable? -- - ---- --------- -------- Abstract: Following is a brief exchange concerning TK50 tapes and when to consider them junked beyond repair. (Now there's a set-up line if we've ever seen one....) Participants: Rob Brown, Terry Kennedy. Conference: HARDWARE_HELP Note 2143.0, 14-May-1997 Brown: CompacTape Cartridge Maintenance --------------------------------------- Is any maintenance of CompacTape cartridges necessary or possible? We find many tapes will not load on our TZ30 tape drive. After a lot of whirring, the tape is unloaded and the green light is left flashing. The book says this means "The drive has detected a cartridge or calibration error." Can the cartridge be cleaned or serviced so that it becomes usable again, or is it garbage? Note 2143.1, 14-May-1997 Kennedy: Things to try ---------------------- This could be the tape or the drive. If there's no data of interest on the tape, try using a *strong* bulk eraser (see other discussions here about the type of eraser needed) and then try the tape. The drive could be having problems. Early TZ30's were pretty flakey - I think they're up to rev F or so. If yours is on service, you could ask them to swap it. It also might need cleaning. Here's the info on the cleaning kit for the low-end CompacTape drives: The DECUServe Journal July, 1997 Page 15 Is a TK50 Cartridge Fixable? -TKXX -HC TK30/50/70 HEAD CLEANING KIT E/U Adj. % Service: 1 Year 2 Years 3 Years Gross Net Gross Net Gross Net List: 33.00 33.00 Standard: Description: Head Cleaning Kit o For TK30, TK50, and TK70 BTW, on the TK50 there's a cup that the gunk scraped off the tape falls into. There's no scheduled maintenance to empty it because the the drive fails before the cup fills, and it's emptied as part of the repair process... Note 2143.2, 14-May-1997 Brown: I think the tapes are no good ------------------------------------ Thanks for the advice Terry. I'm pretty sure that the tapes are at least part of the problem. Field service won't replace the drive anymore because they say our tapes are no good. Software distribution tapes (remember those?) still load ok. Bulk-erasing the tape usually does not help. I am using a 7amp hand-held Radio Shack unit (largest they had at the time). This eraser is strong enough to allow tapes previously written by a TK70 to be written by a TK50/TZ30 and vice versa. We have the drive cleaning kit, and do use it. DECstation Boot Failure ---------- ---- ------- Abstract: Another short series, this time concerning an old DECstation 3100 that fails to boot, unable to find vmunix. Participants: John Briggs, Terry Kennedy. Conference: UNIX_OS The DECUServe Journal July, 1997 Page 16 DECstation Boot Failure Note 356.0, 23-May-1997 Briggs: DECstation 3100 boot failure ------------------------------------ I have a network of seven old DECstation 3100's still running Ultrix 4.3A. The network is isolated from the rest of the company since it is used to process classified data. It's been running fine up until now. But since yesterday, the workstations refuse to boot. The "Ultrix 4.3, July 24, 1992" banner comes up indicating (I think) that the systems are successfully reading the boot sector from the boot device. But then they all fail to find vmunix. The behavior is identical on all five disk-ful workstations. The diskless workstations, of course, don't have a load host :-). Cycling power has not helped. Attempts to boot the standalone environment from tape fail: >> boot -f tz(0,4) tz(0,4) in use -- Not exact error message, but close I tried this with two tape drives (TZ50's) on two different workstations. The green light on the drive never even flickers. I did a >> test -c and all disks and tapes show up properly. At this point, I have four theories. 1. There is a date-related bug in the SCSI firmware (If this had happened a couple of days earlier, it'd actually be a likely explanation -- 10K bug). 2. A hostile "virus" has attacked the boot software. (A virus that attacks DECstation 3100's on a classified network?) 3. Someone deleted all our vmunix files and both our tape drives are also dead. (No evildoers have confessed so far :-). 4. A power spike took down the scsi drivers on all five boot nodes while ignoring our surge suppressors and sparing all the other equipment in the room. (Yeah, right). The DECUServe Journal July, 1997 Page 17 DECstation Boot Failure Note 356.1, 23-May-1997 Briggs: *solved* ---------------- >The "Ultrix 4.3, July 24, 1992" banner comes up indicating (I think) that the >systems are successfully reading the boot sector from the boot device. >But then they all fail to find vmunix. All seven copies of vmunix were missing from the root directories. The file systems appear to be otherwise intact. > >> boot -f tz(0,4) > tz(0,4) in use -- Not exact error message, but close You can't boot from a TZ50 tape drive on unit 4. You have to switch the SCSI ID to 5 and then use boot -f tz(0,5). *grrr* > 3. Someone deleted all our vmunix files and both our tape > drives are also dead. (No evildoers have confessed so far :-). Looks like we have a winner. Note 356.2, 23-May-1997 Kennedy: --------- > All seven copies of vmunix were missing from the root directories. The > file systems appear to be otherwise intact. It's always a good idea to keep either the previous kernel (vmunix.old) or the generic kernel (vmunix.generic) around for things like this. > You can't boot from a TZ50 tape drive on unit 4. You have to switch > the SCSI ID to 5 and then use boot -f tz(0,5). That's one of the dumbest designs I've ever heard of 8-) > Looks like we have a winner. Since this is a secure environment, you have detailed logs so you can have the perpetrator(s) drawn and quartered, right? Note 356.3, 27-May-1997 Briggs: Perpetrator identified, more or less -------------------------------------------- > That's one of the dumbest designs I've ever heard of 8-) Yep. My reaction was similar -- but less politely worded. > Since this is a secure environment, you have detailed logs so you can have The DECUServe Journal July, 1997 Page 18 DECstation Boot Failure >the perpetrator(s) drawn and quartered, right? That would be nice. Physical access is carefully controlled, but logins, logoffs and online activity only get the default Ultrix controls and audits. Turns out that there is a cleanup procedure to which some of the users have access which cleans out vmunix* and vmcore* from the crash dump directory. Unfortunately, I'm informed that this procedure can be applied to _any_ directory. Including the root. Apparently, someone managed to run out of disk space and dutifully cleaned up all seven workstations. There are missing log files that are consistent with a disk space shortage. Of course, there _could_ be a knowledgeable and malicious individual behind this, but then that's true of almost any event you care to name. A hypothetical perp out to cause damage could have done far worse. A hypothetical perp out to steal secrets could have left fewer tracks. A hypothetical perp out to tweak our noses has done a pretty fair job. PC Telnet Woes -- ------ ---- Abstract: A couple of issues with PC clients having telnet sessions to a UCX box get dropped for no particularly apparent reason. Participants: Rob Aldridge, Linwood Ferguson, Gary Gladstone, Bob Graham, Norm Raphael, Dan Wing. Conference: PERSONAL_COMPUTING Note 909.0, 28-Mar-1997 Aldridge: PCs lost telnet connectivity to VAX (UCX) --------------------------------------------------- We're having a problem with our PCs losing telnet connection to our VAX system. I'm looking for any ideas on how to hunt down the source of this problem. The PCs are Windows 95, using Microsoft TCP/IP, and Reflection 2 for the terminal emulation. Every day we get calls from 5 to 10 people saying that they received the error: This affects maybe 5% of the users connected to the VAX system. Possibly it's the same group of users that have the problem each time The DECUServe Journal July, 1997 Page 19 PC Telnet Woes -- although we can't be sure because it might just be the top 5% of the "vocal" types that are calling -- the rest just reconnect. I ran the problem by Digital TCP/IP support and they did not see any "drops" or "waits" so did not think the problem was on the VAX. [They also said next time I call for support on UCX 3.3 they will ask for a PO because only 4.0 and 4.1 are supported -- but THAT will be another topic for discussion!] The PCs that have this disconnect problem don't have other network- related problems. For example, the PCs do not lost connection to network drives on the NT server. Any clues in this haystack? I suspect its either a problem localized to the individual PCs -- or an overall ethernet problem. So at this point I'm just trying to gather more facts. Might bring in our network person to run the Sniffer for a while. Note 909.1, 28-Mar-1997 Ferguson: Debugging suggestions ------------------------------- What does the VAX see? Assuming you have virtual terminals turned on so a process can go into a "disconnect" state, it would be informative to look at the processes exit status, when it exited (in relation to when the PC disconnect). This will likely give you an indication of whether the VAX knows it is disconnecting the process first for some reason, or in response to seeing the terminal disconnect first. It might also be interesting to set up a continual ping from (or to) a PC that does this regularily, and see if there's a loss of connectivity at the time the session disconnects. Note 909.2, 28-Mar-1997 Aldridge: More info ------------------- I do have virtual terminals enabled -- that at least pacifies the users. I'm not sure how I would look at the processes exit status. I can say that I see these OPCOM messages which indicate that the VAX thinks the PC is the one that gave up... .... TELNET Logout Request from Remote Host: 131.184.198.174 Port: 1037 TELNET Logout Request from Remote Host: 131.184.198.132 Port: 1032 TELNET Logout Request from Remote Host: 131.184.198.180 Port: 1031 TELNET Logout Request from Remote Host: 131.184.198.186 Port: 1033 TELNET Logout Request from Remote Host: 131.184.198.187 Port: 1030 .... (extra stuff from Opcom message is cleaned out of this log above) The DECUServe Journal July, 1997 Page 20 PC Telnet Woes If I see a series of these Telnet logout messages within say a 5-second interval, I know that users lost connection. Most of the users will stay connected -- just a few will get disconnected, and usually at the same time! Note 909.3, 28-Mar-1997 Wing: duplicate IP addresses ---------------------------- > The PCs are Windows 95, using Microsoft TCP/IP, and Reflection 2 for > the terminal emulation. Every day we get calls from 5 to 10 people > saying that they received the error: > Sounds like duplicate IP addresses. > The PCs that have this disconnect problem don't have other network- > related problems. For example, the PCs do not lost connection to > network drives on the NT server. The way ARPing works this isn't always relevent, and you probably aren't using IP to connect to the NT servers for disk access anyways. > Any clues in this haystack? I suspect its either a problem localized > to the individual PCs -- or an overall ethernet problem. So at this > point I'm just trying to gather more facts. Might bring in our network > person to run the Sniffer for a while. The 'connection terminated' sounds like a RST was received by the PC. Run a sniffer. If you had MultiNet you could run TCPDUMP to see what's happening from MultiNet's perspective; I understand UCX has some undocumented similar tool but don't know its name or location. Note 909.4, 28-Mar-1997 Aldridge: ---------- Thanks for the ideas. The IP addresses are handed out by DHCP on the NT server. It wouldn't be the first time the DHCP server did some strange things... I'll start "sniffing" and/or using the UCX trace program. Note 909.5, 28-Mar-1997 Ferguson: If they can reconnect it's not the process dying ---------------------------------------------------------- > I do have virtual terminals enabled -- that at least pacifies the > users. I think you've answered the main question; the VMS system is not The DECUServe Journal July, 1997 Page 21 PC Telnet Woes booting them off for some reason and deleting their process. If you find the trouble, please post. I've got one user being repeatedly disconnected. We thought it was an IRQ conflict (there *is* an IRQ conflict) and someone is reconfiguring that now, but if that's not the disconnect problem it otherwise sounds identical. Note 909.6, 29-Mar-1997 Aldridge: Logout requested message can indicate either end disconnecting ------------------------------------------------------------------------ Unfortunately, the Telnet Logout requested OPCOM message doesn't help much. When testing, if I deliberately disconnect the Reflection sesssion -- or if I use UCX on the VAX to Disconnect the device socket -- the same OPCOM message is generated. Note 909.7, 8-Apr-1997 Gladstone: We are having problems also -------------------------------------- We have started switching from Chameleon to MS-TCP-32 and started to see the same disconnects. Unfortunately, we have seen it a couple of times lately with the Chameleon users also. Any ideas would be a great help. Note 909.8, 8-Apr-1997 Wing: check WinNT DHCP Server's behavior ---------------------------------------- > Thanks for the ideas. The IP addresses are handed out by DHCP on the > NT server. It wouldn't be the first time the DHCP server did some > strange things... > > I'll start "sniffing" and/or using the UCX trace program. Check with your sniffer. I don't believe the Microsoft DHCP Server does any checking before it hands out an IP Address, and I don't believe the Win95/WinNT DHCP Clients to any checking of the IP Address given to them to verify it isn't already in use. I can't recall for sure, though. Note 909.9, 9-Apr-1997 Graham: -------- I'm pretty sure the first part is correct; the DHCP server doesn't seem to do any checking before it hands out an IP address. However, the Win95 client definitely does an ARP on a new address before it starts using it. If some other station responds, it disables the interface and displays a message box with the IP address and the MAC address of the other user. The DECUServe Journal July, 1997 Page 22 PC Telnet Woes I think the NT client does the same, but we have so few NT workstations (the NT servers all have fixed addresses) that I've never seen an address conflicton one. Note 909.10, 9-Apr-1997 Aldridge: Update on Telnet disconnects (also affects X sessions) ---------------------------------------------------------------- Re: Reflection (Telnet, and X) disconnects We had our network analyst sniff the line. Nothing worth noting, except for a print server that was defective. We replaced that to see if it could have been a problem. No duplicate IP addresses were detected. We also upgrade UCX to 4.0 (was at V3.3) just to rule out the software. That didn't help so far. I am beginning to suspect the load on the VAX is a factor - especially memory which is at 90% all day. Since we can't affordably expand memory on the VAX 4100, we're going to try to reduce usage -- the Unigraphics V9 users are the biggest consumers. Note 909.11, 11-Apr-1997 Gladstone: Found our Problem ---------------------------- We think we found out problem which was with Windows 3.11. We have upgraded the following file: windows\system\msodisup.386 19295 3//9/94 3:11:34pm Note 909.12, 11-Apr-1997 Raphael: Through the window, darkly. ------------------------------------ > <<< Note 909.0 by EISNER::ALDRIDGE "Rob Aldridge" >>> > -< PCs lost telnet connectivity to VAX (UCX) >- > > We're having a problem with our PCs losing telnet connection to our VAX > system. I'm looking for any ideas on how to hunt down the source of > this problem. > > The PCs are Windows 95, using Microsoft TCP/IP, and Reflection 2 for ^^^^^^^^^^ > the terminal emulation. Then > <<< Note 909.11 by EISNER::GLADSTONE "Gary Gladstone (914) 496-4145" >>> > -< Found our Problem >- > The DECUServe Journal July, 1997 Page 23 PC Telnet Woes > We think we found out problem which was with Windows 3.11. We have ^^^^^^^^^^^^ > upgraded the following file: > > windows\system\msodisup.386 19295 3//9/94 3:11:34pm > Gary, These are not the same thing, as I'm sure you know. Rob still has his original problem it would seem. Note 909.13, 13-Apr-1997 Aldridge: ---------- Yes, we two have two different "threads" goin on here. I still am having Win95 problems -- Reflection and Reflection/X lose sessions to our main VAX. Connections from to our main Alpha system never seem to be affected. I upgraded to UCX 4.0 but still have problems. The latest suspect in the mystery is a Cisco router which has been hanging lately -- and that Cisco router might be the default gateway for some of these PCs. Stay tuned! Note 909.14, 4-May-1997 Aldridge: Follow-up ------------------- Thanks for the responses that were posted. As a summary we ended up taking these steps: - "Sniffed" the network and found nothing unusual - Replaced a Cisco 4000 router that was acting up in other ways - Upgraded to UCX 4.0 ECO 5 on the VAX - Enabled virtual terminals to minimize disconnect impact - Defined logical: define/system/exe/nolog ucx$telnet_free_ucb 0 I can't be sure but I think this logical name definition is what helped the most. I noticed that when a certain incoming Telnet connection would be established, maybe four or five Telnet connections were disconnected at the same time. This logical name (ucx$telnet_free_ucb) disables the caching of telnet ports. It seemed that the cached value was usually "4". Defining this logical was not a documented solution -- but it was recommended for other situations where Opcom messages enabled for one user were seen as the Telnet [cached] port was re-used subsequently. The DECUServe Journal July, 1997 Page 24 CONSTANT Field on PAK CONSTANT Field on PAK -------- ----- -- --- Abstract: This next brief set of notes answers a question that we'd asked ourselves many times in the past when looking at license PAKs for some of our favorite products: When it says something like "Activity table code: CONSTANT=2", what exactly does that mean? Participants: Geoff Bryant, Jack Harvey, Bill Mayhew. Conference: VMS Note 2837.0, 30-May-1997 Bryant: CONSTANT= field on PAKs ------------------------------- Does anyone know the meaning of CONSTANT=n in the activity table code filed of a license PAK? Is this for doing user based licensing? Note 2837.1, 30-May-1997 Mayhew: -------- Yes. It means "n" units are required for each concurrent use of the product. This can be modified by "RESERVE_UNITS" under "Key Options", which makes it a reserved user license (or, colloquially, a "named user" license). Note 2837.3, 31-May-1997 Harvey: Example --------------- VMS-USER license: The units field is 1600, activity field is constant = 100. Sixteen users. The DECUServe Journal July, 1997 Page 25 About the DECUServe Journal About the DECUServe Journal --------------------------- The DECUServe Story DECUServe is an electronic conferencing system, somewhat related to bulletin board systems but much larger and more organized. It is devoted to the general area of computer technology such as systems, software, hardware, and communication, in the Digital and related third party vendor market area. DECUServe also has complete access to and from the Internet. Usenet Newsgroups are accessible using newsreaders from DECUServe and the comp.os.vms newsgroup is added to a VAX Notes conference of its own. DECUServe is included as a part of the Sustaining member package for US DECUS which costs $40 a year. A DECUServe membership for other members of US DECUS is $35 a year. A DECUSere subscription for foreign members costs $75 per year. The conferencing system is available nearly 24 hours a day, seven days per week. There is no hourly connect charge. The subscriber pays communication costs to a phone number in eastern Massachusetts. Reduced rate communication services are available in some areas and INTERNET access is available (node - eisner.decus.org). Subscriptions must be used by a single person. Company or group subscriptions are not available, nor may subscriptions be transferred. DECUServe uses the Digital VAX Notes conferencing software. We currently have over 50 technical conferences available on subjects such as Security, the VMS Operating System, ALL-IN-1, Databases, Site Management, Personal Computing, DEC Networking, Third Party Software, Hardware, Workstations, the World Wide Web and many more. Over 130,000 technical notes are on line. All conferences, including the Frequently Asked Questions (FAQ) from the Usenet newgroups, are indexed to allow for fast text content searches. You can obtain up to the date statistics and information via the World Wide Web at the URL http://WWW.DECUS.ORG/decus/decusv/index.html which provides a number of options. One option displays the activity in each of the technical conference. Another option allows you to read issues of the DECUServe Journal which is published worldwide every month and contains samples of the discussions that occur 24 hours a day. If you have access to Internet mail, you can receive a DECUServe Application form directly. Send mail to application@eisner.decus.org -- the mail text may be blank. On-line subscription information is available in the U.S. by dialing 1-800-521-8950 and logging in with username INFORMATION. The DECUServe Journal July, 1997 Page 26 About the DECUServe Journal Publication Information Topic threads in the DEC Notes conferences on DECUServe are selected for publication on the basis of strong technical content and/or interest to a wide audience. They are submitted to the editor from various sources, including DECUServe Moderators, Executive Committee members, and other volunteers. Suggestions for inclusion are enthusiastically solicited. Articles selected for publication are edited on an OpenVMS VAX system in TPU and then formatted with Digital Standard Runoff. Contact Information ------------------- The editors of the DECUServe Journal are Brian and Sherrie McMahon. They can be reached by any of the following means: mcmahon_b@decuserve.decus.org mcmahon_s@decuserve.decus.org mcmahonb@decus.org griffith@decus.org bmcmahon@cisco.com Work phone: +1 408 527 0434