NetNews Usenet Archive 1993 #1

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / vmsnet / decus / journal / 5 next >

Wrap

Text File | 1993-01-12 | 210.8 KB | 4,745 lines

Path: sparky!uunet!noc.near.net!eisner.decus.org!frey Newsgroups: vmsnet.decus.journal Subject: DECUServe Journal, January 1993 Message-ID: <1993Jan5.215046.19@eisner.decus.org> From: FREY@Eisner.DECUS.Org Date: 5 Jan 93 21:50:28 -0500 Organization: DECUS Approved: FREY@Eisner.DECUS.Org Lines: 4734 The DECUServe Journal ===================== January 1993 Hello! I'm glad to present the first Internet issue of the DECUServe Journal. This issue is jam-packed with technical information on everything from Datatrieve to C to VMS to DECstations. I hope that you find this issue of the Journal interesting and helpful. Sharon Frey frey@eisner.decus.org Table of Contents ----------------- Contents and Credits ........................................ 1 Technical Information ....................................... 82 Articles DTR Wizard Needed: Join Counting the MANY Relation ....... 2 Document Quotas .......................................... 3 TK50Z-FA => TK50Z-GA ..................................... 5 How does one attach an LP25 to a VAX 4000? ............... 7 Macintosh and PC share Files via Pathworks/VAX? .......... 10 Decrease pipeline quota for PC performance? .............. 15 Communications wiring for a new house? ................... 16 C Pros & Cons ............................................ 23 Needed - REGIS-capable terminal emulator ................. 35 Can process use 2 or more pagefiles? ..................... 39 V5 performance slowdown .................................. 42 SYS$SETDDIR system service problem? ...................... 44 How are quotas for STARTUP set? .......................... 46 Can you put OPCOM on a DECTERM/Noprocess? ................ 49 Automatic Menu Startup ................................... 51 Collected Notes on VMS 5.5 ............................... 57 Control over scrolling speed in DECterm? ................. 61 Editorial Staff --------------- Editor: Sharon Frey (vmsnet.decus.journal moderator) Assistant Editor: Bruce Bowler Contributing Editors: Alan Bruns Pierre Hahn Jack Harvey Larry Kilgallen Jeff Killeen Marc Kozam Don Roberts The DECUServe Journal January, 1993 Page 2 DTR Wizard Needed: Join Counting the MANY Relation -------------------------------------------------- This is an extract of the DECUServe 4GLS_AND_QUERY_TOOLS conference topic 164. The discussion took place on September 1, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Linwood Ferguson, Damon Brownd (Ferguson) ---------- There is probably some simple answer to this, but we know enough Datatrieve to be dangerous only: I have two files, X and Y. For each record in X there are many records in Y, related by field A. I need to form a collection (in order to report) that includes the records in X (or certain fields) and the COUNT of the records in Y related to them. Sort of: FIND X REDUCED TO X_KEY, COUNT OF Y WHERE X.A = Y.A Now this actually runs (well, with the right field, tables, etc.) but seems to ignore the COUNT part. This is easy in SQL, but these are RMS files. I know I can also CROSS these and use SUM, but I see no way to SUM to a collection. The best I can think of is CROSS them and then in the report use RUNNING COUNT or something, but I was looking to be a bit more elegant. (Brownd: My favorite solution) ------------------------------- Try this: DTR> DECLARE Y_COUNT COMPUTED BY COUNT OF Y WITH Y.A = X.A. DTR> FIND X REDUCED TO X_KEY DTR> PRINT X_KEY, Y_COUNT OF CURRENT I try to avoid using CROSS because it will completely drop a record from domain X if there are no matching records in domain Y. (Ferguson: Thank you -- DECUServe does it again!) -------------------------------------------------- Neat. Sure not obvious to me how that works syntactically, but it works. In my case for a collection I used: FIND X REDUCED TO X_KEY, Y_COUNT OF CURRENT REPORT CURRENT ... The DECUServe Journal January, 1993 Page 3 Document Quotas --------------- This article is an extract of the DECUServe All-In-1 conference topic 396. This discussion occurred between August 8, 1990 and February 17, 1991. This article was submitted for publication by Don Roberts, DECUServe Contributing Editor. Ed. By David Butterwort, Don Plorde, Chris Simon, Mark Hyde, Edward Hald, Les Paul, Bruce Burson (Butterwort) ------------ I've been playing with enforcing document quotas and something seems to be missing. Sure enough, when I run the CDQ housekeeping utility with my user's "Enforce Quota?" flag set to yes, anyone who has gone over their magic number gets locked into OVERQUOTA. But even if they delete messages, empty their wastebaskets and re-count their documents, up comes OVERQUOTA again when they log in the next time. I have noticed that an entry is being placed in the "Document Count" field of their user profile which matches the total number of filed documents *before* they D, EW and RC. Of course I can blank it out for them and things are then OK, but should I have to? Sorry if this has been asked before (SHOW KEYWORD/FULL came up empty). (Plorde: That's a known bug) ----------------------------- This is a known "bug". We don't use the document quotas (the bug was one of the reasons). I believe the workaround is that you have to run the maintenance routine again to get the "flag" cleared that allows the user to escape the OVERQUOTA form. Not a quick solution by any means. I don't know if this one has been fixed in v2.4 or not. I'm not holding my breath on 2.4 or I'll be long dead for doing so. We will likely update to v2.4 next century :-( (Simon: Pointer to 207) ------------------------ See topic 207 for document quota info. The short answer is yes, it's a bug in 2.3. Don't know yet whether it's fixed in 2.4. (Hyde: should be fixed) ------------------------ I've not tested/witnessed it personally, but the word here in the CSC is that it is fixed in V2.4. The DECUServe Journal January, 1993 Page 4 (Hald: Check on 2.4 fix) ------------------------- I had the same problem when we first went to 2.3 last summer. I tried to write some code which would modify the profile quota fields when the user ran the recount option on the OVERQUOTA form but ran into a dead end. I could get it to work from a priviledged account but got an access violation on profile.dat when I ran it from a normal user account. Due to lack of time I never tried to follow up on finding a fix. I just finished installing 2.4 on a test system last week and have not had a chance to see if this problem has been fixed. I will be doing some testing this week and will post any findings. I hope this has been fixed because we are desperately trying to find a painless (from the system manager standpoint) way of enforcing quotas. (Simon: 2.4 document quotas okay) ---------------------------------- I apologize for not getting back to this thread with an answer sooner, but... Version 2.4 DOES do the recount documents correctly (i.e. writes the new document count to the user's profile for him). (Paul: Not counting . . .) --------------------------- I have different problem. When I run the CDQ housekeeping procedure, starting at a certain record, all document counts are recorded as "No Document Count Made". Atlanta CSC has been unable to help. Any ideas? (Burson: Check CHANNELCNT (and reboot if necessary)) ----------------------------------------------------- Try upping SYSGEN parameter CHANNELCNT to be at least 20 more than the number of entries in PROFILE.DAT. There is a DSIN article describing this as causing errors with both CDQ and PT procedures. They say the following errors may be seen in the log file, but I've never seen them in the log. If you run QUOTA.EXE from the ALL-IN-1 subprocess, you'll see the errors then. Error 162 at line 310 ?Cannot open file %DEBUGBOOT-W-CHN, assign channel system service request failed %BAS-F-ERRTRANEE, ERROR trap needs RESUME -BAS-I-FROLINOEG, from line 510 in error handler at 510 in module DOCDB_COUNT -BAS-I-FROLINMOD, from line 1 in module QUOTA %BAS-E-FATSYSIO_, Fatal system I/O failure -BAS-I-ON_CHAFIL, on channel 0 for file SYS$OUTPUT:.; at user PC 000355E9 -RMS-F-CHN, assign channel system service request failed -SYSTEM-F-NOIOCHAN, no I/O channel available" (Paul: You got the right one, BABY!) ------------------------------------- YEP, got that error message. Will try your suggestion. THANKS! The DECUServe Journal January, 1993 Page 5 TK50Z-FA => TK50Z-GA -------------------- This article is an extract of the DECUServe Hardware_Help conference topic 1226. This discussion occurred between August 7, 1992 and September 21, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Bruce Dow, Brian Schenkenberger (Dow) ----- There is a FCO to upgrade a TK50Z-FA to a -GA (so it can be used on a VS4000/VLC and other SCSI devices). Will the BC19J cable still work? (Schenkenberger: FCO ye. real need no?) ---------------------------------------- Yes there is or Was... I have a TK50Z-FA which I have modified to a pseudo TK50Z-GA and it works file on 3100. Despite what others may have to say about its no implementing full SCSI. If you want to know how its quite simple. 1) open the box. 2) there is a board on the top of the drive mechanics held by four plastic standoffs. Carefully pull back the retaining tabs and free the board. You may wish to remove the ribbon cable to make access easier. 3) you will find 3 reddish/orange resistor packs (with 11 leads) in sockets. These are the SCSI terminators. The FA was terminated internally. Carefully pull them from the socket (as you may want to make your box an FA again and its harder than %&!! to find the same resistors if you break them) 4) in the corner of the board are a set of 5 shorting jumpers. The first three (from back of board) define the scsi address. A TK50Z-FA is addressed as SCSI Address 1. The addressing is a binary count. 1 is represented by REMOVAL of a jumper a 0 is repersented by INSERTING the Jumper. Your TK50Z-FA should have the first removed and the next two inserted. (I have added a short ribbon cable to a dip switch epoxied on the rear of my box for ease of changing the SCSI address. 5) You need a terminator on the machine now since you will have pulled the internal terminator. 6) the other two of 5 jumpers are for test/troubleshooting functions. I have had mine working on 3100 VAXstations of several flavors, and other 3100 ╡VAXes up thru and including a 3100m80 VAX. I don't see why the same thing shouldn't work on the 4000. The DECUServe Journal January, 1993 Page 6 (Schenkenberger: I'm using the old cable!!) -------------------------------------------- BTW, I still using the same cable. Off the top of my head I'm not sure of the number BC19J. If that's the cable for connecting the TK50Z-FA to a VAX/VAXstation 2000 then it should still work. (Dow: Need FCO number) ----------------------- Does anyone know the FCO number for the -FA => -GA change? The FS rep hasn't found it yet. (Schenkenberger: Checked BC19J is OK) -------------------------------------- In reference to [my previous reply]: I just got home and looked at my cable. It IS a BC19J-06. So to answer your question, YES. You can still use your BC19J. Also, think you should consider the information in [the first reply]. It will save a lot of $$$ and time. In fact, you can use the TK50Z-FA as is on your SCSI if its the 1) last on the bus (since its internally terminated and 2) of you can accept it addressed at SCSI addr 1. (refer [to the first reply] to address to something else.) (Dow: TK50Z-FA => -GA part number) ----------------------------------- Actually, according to the FS rep, it is not an FCO, but rather you need to order 3 proms to be replaced, part number 23-453E6-00 from DEC Direct. Price ~$30. (Schenkenberger: Keep the $30.00) ---------------------------------- I still find no problem with the -FA on the SCSI except for the need to open box to address SCSI id. Try the box before you swap the ROMS (as per [the first reply]). I don't think the prom's do anytyhing more than change the devices HWID. (And you can put the $30 in your pocket!!) (Dow: DECUServe saves $$$ again) --------------------------------- Thanks Brian for your help. I did order the PROM from DECdirect (my system manager recommended we do that), but with the help from your notes I installed the prom myself and removed the three orange internal SCSI terminators (DEC wanted $200/hour to install with a two hour minimum; thanks for saving us $$$). Here are a few differences I discovered on my particular TK50Z-FA. > 3) you will find 3 reddish/orange resistor packs (with 11 leads) in sockets. > These are the SCSI terminators. The FA was terminated internally. My resistors had 8 leads. They were the only orange resistors in sockets. The DECUServe Journal January, 1993 Page 7 > 4) in the corner of the board are a set of 5 shorting jumpers. The first three My board has 6 shorting jumpers in the corner of the board. It's original configuration was: -- -- == -- == == == is jumper on back of board I tried changing the last three to jumpered, no jumper, jumpered but the system didn't recognize the TK50. So I changed it back to the original configuration and it worked as SCSI id 1. Of course, now that I reread your instructions to my reply, I see that the key is that JUMPER OFF means 1. oops. I already had a device 2. Well, everything is working and I know how to change it in the future if I need to. Thanks again. WARNING: For the blind who skim notes and assume that the jumpers work the normal way in selecting the scsi id -- think again. REMOVE JUMPER to represent a 1. INSERT JUMPER to represent 0. (Schenkenberg: Memory lapses???) --------------------------------- Still 3 res. packs? I did [in first reply] speak from memory. I knew it had some odd numbering of pins relative to the norm for these inlines (10). When I first ripped mine apart, I too was confused by the jumpering. But, the VS2000's rom based tests and its T50 command status help me figure that out quickly. Again, sorry about the number of pins, I modified the box about a year and a half ago. I think I'm suffering from "Anheuser's" disease!! I have heard rumours that the tk50z-fa configure as I described _might_ hang the scsi bus on other nonVAX2000 boxes. I've carried mine from Portsmouth NH to Decatur IL to load/test/backup/etc. on many varied systems. I have yet to find any 'hanging'. By the way, the carrying handle on those boxes make it a nice little piece of carry on luggage and fits nicely under the seat of most commercial airliners. Although its a little hard (sometimes) to get the idiots at the security check (x-ray) to understand its a computer tape drive and not a BOMB!. glad you took my word and saved the $$$'s. How Does One Attach an LP25 to a VAX 4000? ------------------------------------------ This article is an extract of the DECUServe Hardware_Help conference topic 1235. This discussion occurred between August 19, 1992 and September 8, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Saul Tannenbaum, Frank Nagy, Linwood Ferguson, John Burnet, Tom McIntyre, Terry Kennedy, Nick Donovan The DECUServe Journal January, 1993 Page 8 (Tannenbaum) ------------ I have an old LP25 that is currently connected to the "printer port" of a DMF-32 on a VAX-11/785. The VAX-11/785 is going away, soon to be replaced by a VAX 4000 Model 500. How does one attach an LP25 to a VAX-4000? P.S. I'm looking for a cheap solution. (Nagy: LPV11 Line Printer controller?) --------------------------------------- I think the Q-Bus version of the LP11 controller (which is basically what the parallel port of the DMF32 is) is the LPV11. (Ferguson: Some possibilities) ------------------------------- Yes, we've done this often, at least for LP26's which should be the same. I always get confused however between "short line" and "long line" and which is which and whether the DMF32 and the LPV11 are the same. There is a conversion we've often used available from Data Products, installable and servicable by DEC, with no visible side effects (i.e. it is still a "DEC" printer and works just fine without any finagling with the queues or settings). If the LPV11 is viable for you (I do not think it is exactly cheap) and you need to know for sure, let me know and I'll find out if the long->short or short->long is needed (actually someone will probably have already posted the right answer by then :-) Another cheaper possibility is a serial to parallel converter, which should be available relatively cheaply from Black Box or others. Since the LP25 is 300 lpm (I think) speed should not be an issue. Obviously needs a serial port. And a final possibility if you have a LAN is the DECserver 250 (at least I think that's the name) that will control several printers including I think 2 parallel ones). Probably the most expensive of the three choices, but offers a lot of growth and configuration flexibility. (Burnet: Serial->parallel converters) -------------------------------------- We did this on a 4000 with a DEC LXY12 (Printronix 300). Since our P300 originally had a Dataproducts interface, my first attempt used the Black Box serial->parallel converter for Dataproducts printers. Then I found that that particular device won't work reliably at high speeds without hardware flow control, which DEC *almost* supports on the CXY08 (via SET TERM/COMMSYNC), but not quite, as of VMS 5.5. So I then ordered the Centronics cable for the P300 from Printronix (no jumper changes or even termination changes were required), and got a very good, inexpensive ($100) serial-to-Centronics converter from Telebyte that does XON/XOFF flow control. This combination has been working well for the last few months, and with the port set to 19,200 bps, the P300 does print at 300 lpm. As [the previous reply] mentions, the DECserver 250 is the preferred solution, but it's expensive. The DECUServe Journal January, 1993 Page 9 (McIntyre: Second hand LPV-11 is not expensive) ------------------------------------------------ The last time I looked at the Midwest used computer catalog, the LPV-11 was $250. A new one from DEC would cost quite a bit more of course. (Burnet: But was it an -S?) ---------------------------- The question is, can an LPV11-S (skunked) be had for that low a price? It's always possible to cheat by using the old-style board and letting the cable hang out of the cabinet, but that's ugly and you lose the RFI shielding. (McIntyre: FCC is for sissies) ------------------------------- Well... Unless you are near an airport, the FCC probably won't come looking for you. Short answer the cheap boards are the old standard duals I believe. (Kennedy: More on Dataproducts) -------------------------------- Various random answers: All DEC LPxx are "standard" Dataproducts. CSS offered a version with the "long line" interface, which was retired and replaced by the LLF01 extender, which is itself retired now. Older Dataproducts / DEC printers used a Winchester MRAC connector. The newer models (Bx00, LP2x) use a DB-50. The supported controllers are: LP11 - older Unibus DMF32 - newer Unibus LPV11 - older Q-bus LPV11-SA - newer (S-box) Q-bus DS250 - LAT/Ethernet Don't buy Black Box Dataproducts converters - they're a rip-off at $435. Dataproducts is the same as Centronics except that the strobe is inverted and the termination is _lots_ stiffer. You can convert Centronics to DP w/3 chips (1 7404, 2 7407's) and some resistors. Schematics available on request. (Burnet) -------- Also DMB32 (VAXBI). When I mentioned that no termination changes were required on the P300, I should have said that I was expecting that changes would be required, but I found that the cable was short enough that the printer worked fine with the resistors that were in place (1k-ohm instead of 220/330-ohm). (Kennedy) --------- I have heard conflicting things about this board. I _know_ it doesn't have The DECUServe Journal January, 1993 Page 10 all the same stuff as a DMF32, but was unsure which parts were missing. Thanks for clearing this up. You mean that the P300 had "loose" termination (1K) already, right? In that case things should work fine. LP2x printers are "stiff" and won't work properly without a change. (Burnet: DMB32 should be fine for a Dataproducts-interface printer) -------------------------------------------------------------------- Well, all I can say for sure is that we have used P300, P600, and LG02 printers on DMB32s for a long time, and they all work fine (one was even moved directly from a DMF32 to a DMB at one point). I think that what's missing is the general-purpose parallel-I/O port. The DMB32's parallel port is LP32 only and won't do DR11-C (bidirectional) as the DMF32 will. (Tannenbaum) ------------ Ask a simple question, get a prompt, detailed Decuserve response. We'll probably let Black Box rip us off for Dataproducts protocol converter - the GSA discount for it renders it less of a rip off and I wouldn't know what to do with a 7404 and 2 7407s... Thanks for the answers, folks. (Donovan: Try an Emulex box) ----------------------------- As an alternative to the DECserver 250. Emulex makes a LAT-Ethernet to Parallel box for under $1000. We have been quite please with the one that we have. Macintosh and PC Share Files via Pathworks/VAX? ----------------------------------------------- The following article is an extract of the DECUServe Pathworks conference topic 393. This discussion occurred between May 20, 1992 and July 23, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Bart Lederman, Mike Lampson, Nick Donovan, Shawn Chapla, Ta Fuh Chiam (Lederman) ---------- One of the things which Digital has demonstrated using Pathworks is to have a Macintosh put a file into a disk server (or virtual disk, or whatever) on the VAX, and then an IBM-type PC picks it up and uses it. We would like to do that here. The person trying to set up the PC end of things is having a lot of trouble. The Macintosh has no problem getting to it's AppleShare volume. The DECUServe Journal January, 1993 Page 11 Has anyone done this (defined a disk and/or file service on the VAX which is access from both Macintoshes and PC)? Could you explain briefly how it is done? (Lampson: Can do, sometimes a little painful) --------------------------------------------- There are detailed steps for doing this documented in the PATHWORKS for VMS (Macintosh) Server Administrator's Guide (AA-PBFFC-TE), Appendix C. In short, you need to define the root directory of your shared file service from both the Macintosh server and DOS server administration utilities. Then, you need to set up ACLs on the directory structure so that all current and future files have these ACLs on them. Then you can grant the VMS accounts that your PC and Macintosh users are using these identifiers. Note that Macintosh files have something called data forks and resource forks. These "forks" are stored as separate files on a VAX (the resource fork is in a [.MSAF$RESOURCE] subdirectory). Therefore, DOS users can only access the data fork of a Macintosh file. This is fine for most data sharing as text files, word processing documents, etc. store their data in the data fork. If there is a resource fork for these files, it would hold information such as font names and word processor preferences. Also note that a DOS user can only see a file on this shared disk if the name has less characters than the 8.3 file name limit for DOS files. Also, if the Macintosh user uses non-DOS (and non-VMS) usuable character in the file name, then the name is adjusted slightly by PATHWORKS (e.g. My Resum.wpc looks like MY_RESUM.WPC on the DOS machine). Let me know if you don't have the Server Admin manual and I'll type in the most significant commands. However, I recommend you get the manual as it is quite useful. (Lederman: By golly, it works!) -------------------------------- Just having the pointer to the correct location in the correct manual saved me at least an hour of searching, and probably more. The instructions there are fairly clear, though some of the steps are a bit redundant. And they don't give the steps which have to be done in ADMIN/PCSA to set up all of the PC side of it: after creating the service, you still have to start the service, make it known, and then grant each individual user access to it (that last step escaped us for a while), and you have to be certain that anyone who needs to write to the shared file gets write access. I really do not understand why I need two entirely separate sets of controls on the disk: one using VMS and ACLs, the other buried within Pathworks. The Macintosh seems to work fine with just one set of controls, though the PCFS* ACLs seem to take precedence over the ACL identifiers I created according to the Appendix C instructions, and I don't know why I need two sets. (I don't like ACLs much to begin with.) But it is working, and seems to work well now that we set it up. And it isn't all that much trouble, once you know what has to be done. (Donovan: Don't have to use PCSA security) ------------------------------------------- A common question/complain. PCSA maintains its own security database. When a tries to mount a service, the PCSA file server checks its database to The DECUServe Journal January, 1993 Page 12 see if the user has access to the service. This would have been setup with the PCSA_MANAGER> GRANT command. The file server then uses the ACLs that it put on the directory so it can have access. You do not have to use this method, but DEC does not do a very good job of explaining the alternative. A file service does not have to have been exported for a PC to mount it, ie: USER ?: \\VAX7\DUA0:[WP_FILES]%JSMITH * will mount the directory [WP_FILES] without a service having to be created. In this case standard VMS security is used. There are other notes about this in the conference. >(I don't like ACLs much to begin with.) If you play with ACLs you will find that they are very useful. The key is to set them up correctly. For example, if you put the following ACL on a directory: UAF> ADD/ID WP_FILES EDIT/ACL WP_FILES.DIR and add: (ID=WP_FILES,ACC=R+W+E+D) (ID=WP_FILES,ACC=R+W+E+D) (ID=[*,*],ACC=NONE) (ID=[*,*],ACC=NONE) and then if you want to grant access to it, use the command: UAF> GRANT/ID WP_FILES JSMITH or to another user later: UAF> GRANT/ID WP_FILES BJONES ACLs are very flexible! (Chapla: Is pathname supported?) --------------------------------- If you use COMMON file services for the DOS users (instead of APPLICATION services), then the PCFS* ACE's don't propagate down to files and subdirectories under the root. Then, standard RMS protections (i.e. ACL's) handle the protection for your DOS users (though you still need to register them with access to the service). >A file service does not have to have been exported for a PC to mount it, >ie: >USER ?: \\VAX7\DUA0:[WP_FILES]%JSMITH * >will mount the directory [WP_FILES] without a service having to be >created. In this case standard VMS security is used. That's true that this works, but this isn't supported by DEC, is it? Even so, a drawback is that it requires your users to know full file pathnames to The DECUServe Journal January, 1993 Page 13 get to the service. If you have to move the service to another disk, your users have to be notified of its new location. If you stick with the service names, the users are blissfully ignorant (and isn't that the way we like them?). (Lederman: Even works with VMS files.) --------------------------------------- Actually, things are working fairly well now. I can even transfer files between PCs and Macs and the VAX now by just copying them to/from the correct directory. I can even put a VMS text file into the directory, and it shows up with the proper TeachText Icon and resource idendifiers on the Mac. It's just that, for our particular application, UIC based protection would do everything we need with less work on the system manager's part than ACLs. The big stumbling block now is going to be having the users (especially on the Mac side) save the files with attributes and file names that the MS-DOS people can read. I haven't tried to read the virtual disk with PCDISK, but I agree with the previous sentiment: it's really useful for reading and writing PC diskettes on the one VAXstation we have which has a floppy drive. Not all of our machines are going to have Pathworks, and this is a handy option to have around. (Donovan: Use logicals) ------------------------ >That's true that this works, but this isn't supported by DEC, is it? I think that it is supported. I know of some big users that do not want to export thousands of services, one for each directory that they have. If DEC changes this, they will have some major complaints from many sides. >Even so, a drawback is that it requires your users to know full file >pathnames to get to the service. If you have to move the service to >another disk, your users have to be notified of its new location. If >you stick with the service names, the users are blissfully ignorant Not a problem. Use logicals. I was just using an example that anyone could understand. The real service (at our site) might be: USE J: \\VAX7\AREA$MARCOM:[MARCOM]%JSMITH * The logical AREA$MARCOM points to the correct disk. (Chapla: Connection to directories will go away?) -------------------------------------------------- >>That's true that this works, but this isn't supported by DEC, is it? >I think that it is supported. I know of some big users that do not >want to export thousands of services, one for each directory that they >have. If DEC changes this, they will have some major complaints from >many sides. Since I originnaly made the point about support of a connection to a specific VMS directory rather than a service name, we had a conference call with some DEC PATHWORKS development managers (arranged by our eager local The DECUServe Journal January, 1993 Page 14 sales reps) on PATHWORKS futures. One thing they mentioned is not to get too in deep with this technique. DEC's goal is to make PATHWORKS as LAN Manager-like as possible, and since this is not appropriate LAN Manager format, it is *very* likely to go away in a near-term release (though they conceded they will keep the personal file service capability). (Donovan: Another silly idea from DEC...) ------------------------------------------ >One thing they mentioned is not to get too in deep with this technique. >DEC's goal is to make PATHWORKS as LAN Manager-like as possible, and >since this is not appropriate LAN Manager format, it is *very* likely >to go away in a near-term release (though they conceded they will keep >the personal file service capability). This is the silliest thing that I have heard in a long time. If a VAX looks like nothing more than a big PC, then why the hell would I buy a VAX and not a much cheaper PC? The value of Pathworks is that I can integrate a VAX file system with a PC network filesystem and keep a unified environment. If I wanted a pure PC network, I would buy Novell, not Pathworks. Grumble.... With brilliant minds like this "managing" the Pathworks group, no wonder DEC is losing billions... Did you raise any objections? What was the response? Again to re-iterate my complaints. I have thousands of .DIRs on my VAXcluster any one of which, a PC user could want to access. If DEC removes the VMS filename capability from Pathworks, then I would have to export thousands of file services (one for each .DIR) (I guess that a user could learn to use SETDIR, but this does not sound like "standard LAN MAnager" either and I assume that it would go away also). I use ACLs to control access to these .DIRs and PCSA has its own security database, so my entire security database would have to be replicated (and maintained) within the Pathworks security database. This would take weeks, even with automation, and all for what? So I can be "LAN Manager compliant". Who cares? How do I register my complaint? (Chiam: Business_Practices?) ----------------------------- BUSINESS_PRACTICES? It is gaining more and more topics nowadays. The DECUServe Journal January, 1993 Page 15 Decrease Pipeline Quota for PC Performance? ------------------------------------------- This article is an extract of the DECUServe Pathworks conference topic 418. This discussion occurred on July 24, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Rick Davis, Jamie Hanrahan, Alan Striegel (Davis) ------- In the VMS P/W 4.1 release notes, section 2, there's a short section called "improving performance". In it DEC states you should decrease the DECnet pipeline quota to something between 2304 and 3455 IF you are using a VAX 4000 or other VAX using the SGEC (second generation ethernet controller) AND you have PC ethernet cards with (1) no multibuffering support and (2) <16k memory. This is supposed to allow the PC NIC to keep up with the SGEC, and prevent the SGEC from initiating waits. We use 4000's, and have a fair number of WD8003e and Interlan 5210 cards which fit the description. I've talked to DEC about this issue, and haven't gotten a satisfactory answer as to whether I should pay attention to changing the pipeline quota. Performance not always being what we'd like it to be, this seems like something to consider. Can anyone shed any light on this? Is this a valid suggestion? What side effects does decreasing pipeline quota cause? DOES IT HELP? (Hanrahan: Take DEC's advice with several grains of salt...) ------------------------------------------------------------- I infer from this that they are talking about reducing the pipeline quota on the VAX side. (I'm not sure if it's even configurable on the PC side.) This may result in a severe performance hit for other DECnet applications (those talking to nodes other than Pathworks). Here's why: When an application under VMS writes to a DECnet logical link, it is told that the write is done (ie the $QIO to the network link completes) as soon as the data has been copied to a buffer in local nonpaged pool. Eventually DECnet moves it to a buffer in the destination node, at which time the local buffer is freed. The pipeline quota determines the amount of pool that you can use for this, on a per-logical-link basis. This gives you the benefit of multiple queued writes with write-behind cacheing with no extra effort on the part of the application programmer! This benefit vanishes if you make the pipeline quota small. (Many DECnet experts advise you to *increase* the pipeline quota, from its default of 10000 bytes to several times that value, to increase performance on most applications!) The pipeline quota is also used to determine the initial size of the transmit window at the NSP (logical link) layer. The transmit window is the amount of data that can be sent before stopping and waiting for an ACK from the far end. It is init'd to 2/3 of the pipeline quota, and adjusted up or down from there depending on acks, credits, etc., received; it can never be larger than the pipeline quota (for obvious reasons). As anyone who has used old Kermit implementations can tell you, a small transmit window really hurts performance if you have a lot of data to move. The DECUServe Journal January, 1993 Page 16 Another aspect of this is ... what are you trying to improve the performance of? If it's virtual disk or file services, forget it. These use the LAD protocol, which in turn is layered on LAST, which is layered directly on Ethernet... ie DECnet is not involved! (Take a look in NCP> SHOW KNOWN LINKS : do you see logical links for PC disk or file services?) In which case, forget DEC's advice about pipeline quota completely! (Unless there's a pipeline quota for LAST, settable in LASTCP? I haven't looked.) DECnet is only involved in Pathworks file transfers when you are running FAL or NFT on the PC. Homegrown applications that talk from the VAX to programs running on Pathworks nodes of course also use DECnet. If you do a lot of these things, then you might consider DEC's advice... but you will be hurting the performance of VAX-to-VAX DECnet applications, including remote file access. The real trouble, I guess, is that you can't tell DECnet/VMS to use a different pipeline quota for different nodes (ie larger values for VMS nodes, smaller for Pathworks). (Striegel: Well... let's not assume too much) ---------------------------------------------- >DECnet is only involved in Pathworks file transfers when you are running >FAL or NFT on the PC. Homegrown applications that talk from the VAX to >programs Not entirely true all the time. File services only use LAST if you explicitly configure the client node for that (it is not the default) then it tries to connect using LAST first. If it fails, it used DECnet instead. LAD applies only to Disk services and CD-ROM services. Note also that neither LAST nor LAD can be used on token ring networks or across wide area connections. (Even in some ethernet configurations it may not work if traffic or bridge delays make LAST unreliable.) Communications Wiring for a New House? -------------------------------------- This article is an extract of the DECUServe Shop_Talk conference topic 37. This discussion occurred between July 30, 1992 and August 6, 1992. This article was submitted for publication by Alan Bruns, DECUServe Contributing Editor. Ed. By Keith Hare, Curtis Reid, Bill Mayhew, Jamie Hanrahan, Linwood Ferguson, Charlie Luce Jr., Ed Bailey, Jack Harvey, Arnold DeLarisch, John Burnet, Jack Stevens, Rob Brown (Hare) ------ I am in the process of building a new house, and am looking for comments and/or suggestions on data communications wiring. I figure that it is better to wire now, than wire later, even if I have no immediate needs. I am thinking in terms of a star configuration, where I basically run wires to most rooms, but just drop them into the basement for the moment. The DECUServe Journal January, 1993 Page 17 My questions (so far) are: Is it possible to run tv and data over the same wire, either at the same time, or not? The house is nowhere near a tv-cable line (or anything else, for that matter), but a satalite dish is a remote possibility. Is it possible to run tv over rg58 cable? What is cheapest - thinwire or something like 10baseT over twisted pair? Which is going to have the most support in 10 years? Is it worth running fiber at this point or is the cost of the cable prohibitive? Is there something else I should consider? (Reid) ------ In my house, I have a twisted 3-pair telephone cable (I forget which kind) connected in each room in the house and each all drop to the basement to be connected on a 66-block. This way, I can control certain rooms such as guest room from making excessive long distance calls or (heaven forbid) 900 numbers. Another feature is that it is easier to troubleshoot which line is bad. As for the tv cable, it is in similar setup like I did for the phone cable. (Mayhew: Soooo much cheaper now than later!) --------------------------------------------- Relatively speaking, cable is cheap. Labor isn't. In new construction, while the labor is also cheap (i.e. before the walls go up), I would string something like 12- or 25-pair cable to each room. You never know when you're going to decide to turn one room into an office with a need for N serial ports or N unshielded-twisted-pair links and it is oh-so-easy to take advantage of them when they're already there :-) I would simultaneously string at least one thinwire Ethernet link and at least one coax TV line... more, maybe, depending on the wall layouts. In our 70-year-old house we are retrofitting as time and $$ allow. The first floor rooms, except the kitchen, now have at least two loaded DECconnect wall plates each. The second floor is a whole lot more trouble and is mostly serviced by a Rabbit for TV (you know... the thing that will retransmit your "VCR" (or cable, but of course they don't advertise that) signal from your main TV to 'satellites'; ours uses mini untwisted single-pair wire, there are new ones that do it over the house wiring, which I wouldn't trust in a house with lots of competing electronics). Data service to the upstairs rooms is either by modem ;-} or by the throw-a-cable-down-the-stairs method. I wish it were better and it will have to be some day. And don't skimp on the electrical service or number-of-outlets, either :-) (Hanrahan) ---------- >Is it possible to run tv and data over the same wire, either at the same >time, or not? The DECUServe Journal January, 1993 Page 18 Sure. It's called "broadband". In essence you have transceivers that take the Ethernet info and put it on a carrier, and vice versa. Since the carrier is at a different frequency than any of your TV channels, it can coexist on the same wire, just as multiple TV channels do. Sorta expensive for home use though. It'd also be lovely if there were PBX systems that could ride on broadband Ethernet, so that you wouldn't have to run phone wires as well as cable, but I don't think that exists yet. >Is it possible to run tv over rg58 cable? Not unless you like lots of ghosts. rg58 is 50 or 52 ohm impedance, TV cable (RG59, RG6) is 72. >What is cheapest - thinwire or something like 10baseT over twisted pair? For a star configuration thinwire is more expensive for the cable, but twisted pair will need a hub in the basement. otoh, if you really want a star configuration, thinwire will need a "hub" like a DEMPR as well, or else two cables to each room (one going, one coming back). >Which is going to have the most support in 10 years? Your guess is as good as mine. Actually my guess is that 10 years is a VERY long time in this business and new installations at that time will be done with something that's unheard of now. >Is it worth running fiber at this point or is the cost of the cable >prohibitive? The cost of the cable isn't that bad, but if you do this without intending to use it right now, you run the risk of your fiber not being compatible with whatever you do end up using. >Is there something else I should consider? The previous reply about power is good advice. Especially with regard to your "computer room". The manual for my HP LaserJet III, for example, says that it should be on its own circuit. I would run no fewer than four separate 20-amp circuits to this room. Similarly, if you are planning a "media room" with something formidable in the way of TV projectors, high-power audio amps, etc., use at least one separate circuit for this equipment -- maybe more. (Real audio nuts will put the power amp on its own circuit, the other audio gear on another circuit, and video gear, if any, on yet a third.) (Ferguson: Belt and suspenders) -------------------------------- After you do all the wiring, go back and put some conduit in. Put in a box in each room (or ones you might *ever* want something in) and stub the conduit off in the crawlspace or attic. Then in a couple of places run some all the way from the crawlspace to the attic so you can get stuff up and down. If you never need these you spend about $5 per room. If you ever need The DECUServe Journal January, 1993 Page 19 them you save hours and hours and lots of sheetrock repair. If you never need these you guessed exactly right on all the wiring; go directly to Vegas and start playing. (Luce: Dissenting Experience) ------------------------------ >I would simultaneously string at least one thinwire Ethernet link and For the record, I wouldn't -- 10BaseT is far easier to work with. If you keep an eye on the CDDI (Copper, as opposed to Fiber, Distributed Data Interface) and run some proper shielded twisted pair you will be able to upgrade from 10 to 100Mbps if you ever feel the need (and want to spend the $$$ on new hub and interfaces, of course). (Mayhew: Maybe I'm underinformed about new developments, but...) ----------------------------------------------------------------- >For the record, I wouldn't -- 10BaseT is far easier to work with. Isn't 10BaseT limited to one station per segment? In any case I will disagree about it being easier to work with. Admittedly you need to make an investment in tools (or beg/borrow them), and that may be an obstacle in itself, but once you have 'em -- and I think we're talking under $100 here -- thinwire is no problem, compared to unshielded twisted pair. Either one is easier to deal with than shielded twisted pair IMO. I much prefer the notion of shielded cable carrying those high frequency signals around the rooms where I and potentially my family and kids spend the bulk of our lives. Am I being paranoid? (Bailey: Put in conduit!) -------------------------- I'd have to agree with - uh, drat, I forgot their name; sorry! - about putting in conduit. There's no telling what the preferred method of hooking stuff together will be in ten years (I'd bet on some sort of wireless technology myself), so why not concentrate on a method that will give you the most flexibility? Conduit doesn't care if it has rusty coathangers soldered together or a bundle of fiber in it, so put the conduit in now, fill it with whatever is best for your needs right now, and enjoy. Later, you can add more stuff in, or rip it out and put in the latest and greatest... Some thoughts on conduit. (I just installed a satellite dish in the backyard and ran conduit to it, so I'm an expert...:-) ) I'd use the nice grey PVC conduit instead of the steel stuff - it cuts easily, you don't have to worry about bending it (you buy prebent sections), and assembly is a snap. Also, if you want to take a break while "gluing" the stuff together, simply take a good whiff of the solvent, and you'll be in another world for a while... :-) :-) Some other thoughts: You can never have conduit that is too big (there once was a person that thought they put in conduit with too large a diameter, but after walking through it, and looking around, he changed his mind... :-) ) Bigger conduit lets you stuff more cable through it, and (as long as you don't put *too* much The DECUServe Journal January, 1993 Page 20 stuff in it) makes pulling cable easier. For a house with typical 2X4 stud construction, you should be able to get away with something on the order of inch and a half to 2 inch conduit. You will probably want to add cable to it after some time, so it never hurts to pull a hunk of rope/good twine along with your initial bundle (and with every subsequent bundle). The electricians have a name for this, but I forgot it. Stubbing the conduit up to the attic and down to the basement is a good way of doing it (though if there's a floor in the middle you will have some challenges); just make sure you will be able to get to the attic and/or basement end of the stubs when the house is complete. My attic is mostly covered with a couple feet of blown fiberglass; I'd not relish going through it very much. Oh, and you will need to talk to your builder about leaving you a good size "core" from the top of the house to the bottom, so that you can put in a large hunk of conduit, and connect the basement and attic stubs. I'd go at least double the size of the stubs on the core. If you do this, you'll never have a problem connecting anything in your house. Then, when everything goes wireless, you can use the conduit for a central vacuum system! :-) Ed_who_missed_his_chance_at_installing_conduit,_and_regrets_it_still... :-( (Harvey: A vote for Thinwire in this case) ------------------------------------------- >Isn't 10BaseT limited to one station per segment? Yes. What may be confusing is that prior to the 10BaseT standard, there were some low cost twisted pair to RG58 baluns that allowed you to directly interconnect Thinwire and twisted pair. This is VERY HAIRY. True 10BaseT has full Ethernet reliability, but requires a non-trivial hub box at the center of the star to feed each arm going to a single node. Unless you have such a box for free, RG58 will probably be far cheaper for a ten room house. Don't buy made-up cables. Buy the parts and make them for about $30 per room. (Luce) ------ >Isn't 10BaseT limited to one station per segment? I prefer to think of it as only being able to wipe out one node at a time :-) Besides, [the original question] specified a star configuration. >I much prefer the notion of shielded cable carrying those high frequency >signals around the rooms where I and potentially my family and kids spend the >bulk of our lives. Am I being paranoid? I'm not an expert on EMI, but given that DEC has proposed FDDI speeds over UTP I suspect that Etherspeed isn't leaking all that much. OTOH, I question of a wiring scheme that lets Junior (or Spot) trash the net at any node by playing with the T. The DECUServe Journal January, 1993 Page 21 (DeLarisch: Residential FCC regulations are stricter than commercial) ---------------------------------------------------------------------- Just a small point: I believe that the FCC rule in residential areas are stricter then in commercial buildings. Standard RS-232 cables wreak havoc with FM reception. There is even some splatter from good shielded RG58. If it were me, it would be either fiber (assuming I hit at least on jackpot in Las Vegas) or good ol' RG58. Remember, whatever they get to work over shielded/unshielded twisted pair will be much easier to do over coax (Yes, I know ... gross oversimplification OK, High Freq. EE's begin trouncing 8-{) but I think its very close to reality). P.S. I believe that the FCC has no sense-of-humor about rf/emi radiation in residential areas. Cease and desist is what is their normal solution. (Harvey) -------- >I much prefer the notion of shielded cable carrying those high frequency >signals around the rooms where I and potentially my family and kids spend the >bulk of our lives. Am I being paranoid? ^^^^^^^^ Yes. The high frequency signals from the horizontal sweep circuits of your TV sets are far stronger. However, this is a religious issue, with no answer. Some people won't eat food from microwave ovens because it has been exposed to "radiation". (Burnet: Some near-field non-ionizing radiation can be a health hazard) ------------------------------------------------------------------------ Agreed, but... The second part (not eating food from microwave ovens) is obviously silly, but I disagree that there is "no answer". First, it's necessary to specify explicitly what range of frequencies you're talking about. And then, with certain frequencies of non-ionizing radiation, the answers have been deliberately obscured for decades by stonewalling on the part of computer and CRT manufacturers, the newspaper industry (a major CRT user with vested interests in keeping its employees ignorant), the big power utilities, and especially the U.S. regulatory agencies like OSHA, under the Reagan and Bush regimes. The certain frequencies that I'm referring to, of course, are in the 60-Hz neighborhood (power-line frequencies) and the 15-kHz neighborhood (flyback-transformer frequencies in video monitors). (Hanrahan: obligatory skeptic's reply) --------------------------------------- >Some near-field non-ionizing radiation can be a health hazard This simply has not been proven. At best there is a lot of anecdotal evidence and some studies that *may* show correlation between exposure to such radiation and health problems, depending on how you look at the data. But correlation is not proof of cause-and-effect. You might as well claim that the CRT evidence shows that long-term exposure to trace amounts of ozone The DECUServe Journal January, 1993 Page 22 causes problems. There is also good reason to suspect that the correlations that have been shown between living near high-tension powerlines and incidence of certain cancers has a lot more to do with exposure to PCBs (used in older distribution transformers), to the defoliants often used around power poles, and to the wood preservatives used on wooden utility poles, than with exposure to ELF radiation. (Mayhew) -------- Hey, I'm a card-carrying skeptic, too. I agree with Jamie in [the previous reply], e.g. But, when I wire my house, I have control over it. That means I get to make the decision -- I don't have to live with the decision made by a power company or TV manufacturer that is *possibly* more concerned with profit than with my family's personal health. In addition, the TV flyback frequencies only happen while the TV is on. Ethernet would be running 24 hours a day, and hidden in the walls where it's easily forgotten. So even if I am paranoid, I am inclined to be cautious when I'm readily able to. Particularly if there are very young children in the picture. As to the risk of Bobby unhooking the T connector ... isn't that what the fancy make-before-break dual-cable Ethernet wallplate jacks are for? (Harvey: <:-}= ) ------------------ (Hare: Summary, RG58, RG59, and lots of circuits) -------------------------------------------------- Sounds to me like the best bet is to pull rg58 for data and rg59 for tv (I'm more likely to use the rg58 than the rg59). I'm not overly concerned about fm interference and the FCC - this house will be in the middle of 15 acres. And, plenty of circuits, and some extra conduit, just in case. Shouldn't be a problem, since my brother, the electrical contracter, will be helping me wire. (Stevens: Home Busses Are Being Designed) ------------------------------------------ Since I don't have a copy of Popular Science handy, I can't give details, but there are a couple of house-specific wiring systems (cables, faceplates, protocols) you may want to evaluate. They include the things one would expect in a house: power, communications, entertainment, and smart-appliance bus. Naturally, there is no agreement among appliance manufacturers about which one to use, but you may want to look them up and see what they bundle together. (Brown: A pointer to the Articles conference) ---------------------------------------------- 19.49 in the articles conference may be of interest (or it may not). The DECUServe Journal January, 1993 Page 23 C Pros & Cons ------------- The following article is an extract of the DECUServe Shop_Talk conference topic 41. This discussion occurred between August 19, 1992 and October 6, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Dana Schwartz, Brian Schenkenberger, Mike Terrazas, Bart Lederman, Eric Husby, George Merriman, Jane Furze, Jack Harvey, Jeff Killeen, Dale Coy, Bill Wood, Frank Nagy, Bob Hassinger, Bill Mayhew, Matt Holdrege, Charlie Luce Jr., Bruce Bowler, Jack Patteeuw, John Burnet, Curt Snyder, Wayne Steffen, Larry Kilgallen (Schenkenberger: Calling all C haters) --------------------------------------- Hello, I saw your disclaimer that you added to the bottom of a reply on keeping TECO on AlphaVMS in the VMS conference. I just had to say hello. I too find great disdain of the C language. Possibly for several reasons, of which you too may confer (and add onto if you wish.) 1) Its ridiculously (and intentionally) designed and written to be cryptic! 2) It reeks of UNIX (a four letter word in my book) 3) Sophomoric concepts of file access and architecture. 4) Its being sold (thrust down the thoughts of) corporate management as the portable language to end all languages. 5) If you're on VMS->WHY C? C is to UNIX what Bliss is to VMS (I'm certainly no Bliss advocate!! Give me Macro or give me death!) Maybe like the Little Rascal's Women Haters Club, we could start a C hater's club. ??? (Terrazas: C the language people love to hate.) ------------------------------------------------ >1) Its ridiculously (and intentionally) designed and written to be cryptic! Yes it is intentionally designed. It is not written to be cryptic, it is written to be concise. Many C newbies make it cryptic, based on bad habits from languages like Fortran and early versions of BASIC where variables had limitations on length. >2) It reeks of UNIX (a four letter word in my book) Since C came first, perhaps it would be better to say that Unix reeks of C. >3) Sophomoric concepts of file access and architecture. Any portable language cannot expect to find the rich file structure you find on ODS2 disks or under RMS control. The price for portability is over-generalization. The careful programmer has a file handling subsystem The DECUServe Journal January, 1993 Page 24 that uses the features of the operationg system s/he is on, and re-writes that subsystem for the different platforms that s/he is running on. If you choose a language that covers that for you, then you're at the mercy of the compiler implementers as to the behaviors you see. I'd love to tell you about the frustrations our COBOL programmers are having trying to get the same application to have the same temporal characteristics on our Amdahl, Cyber, and VAX machines. They can't even find an acceptable compiler on some other platforms (DECsystem, HP-UX, PCs and others). >4) Its being sold (thrust down the thoughts of) corporate management as the > portable language to end all languages. Interesting. Our management views C as the language of choice only when more productive tools fail to meet requirements. Some of the tools they prefer are 4GLs, authoring languages and the like. These tools seem to all have a C interface. Not so with any other language we've looked at. >5) If you're on VMS->WHY C? C is to UNIX what Bliss is to VMS (I'm certainly > no Bliss advocate!! Give me Macro or give me death!) Indeed. How long are you going to remain purely VMS? How long is Macro going to sustain your needs? Decisions about what technical corner you paint yourself into should be made with an attempt to look at least 5 years down the road. Preferably 10-20. I don't have that kind of faith in Macro, VMS or even DEC. If you do, I hope you're right. MikeT who was DECUS' representative to X3J11 (C Language Standard) until last week. (Lederman: It's not the computer, it's us.) -------------------------------------------- I've switched my "3GL" programming from FORTRAN to C over the past few years, and looked at a lot of programs. I find the biggest problem with C programs being cryptic isn't the language, it's the programmers. People trying to show how "clever" they are, how many odd "tricks" they can put into a program, how many statements they can collapse into one, etc. [As usual, of course: it's almost always not the tools that are at fault, it's the people using them.] I wouldn't want to be forced to use a language which is so rigid you can't do any 'tricks' at all: I wrote programs in RPG when I had to (it was the only tool available), and it's a language where you simply cannot have any unusual language constructs. But there is a lot it simply will not do. Not that I think C is perfect either, but I don't think the majority of bad C programs can be blamed on the language. (Schenkenberg: put it in perspective) -------------------------------------- >>Indeed. How long are you going to remain purely VMS? How long is >>Macro going to sustain your needs? If the application is targeted for a platform (ie. some program just chock- full-o'-VMS-system-services) then use a language more adapted to the job. I've written in C as well as many others from Ada to Pascal. I can't see why The DECUServe Journal January, 1993 Page 25 you would contort yourself with a language in which you must bend over back- wards to solve a problem. Try calling the SMG menu functions in VAX C and VAX Fortran and then tell me its easier in C. And I agree that the programmer has a lot to do with its cryptographic nature. But then that's the nature of the beast. Its a mindset which has been promulgated throughout the UNIX community where C first reared its head from the murky primorial waters. >> MikeT who was DECUS' representative to X3J11 (C Language Standard) >> until last week. Every Mother loves her child! (Husby: In defense of C) ------------------------- I'm no real fan of C although I've used it to make a living for the past 5 years. But had to answer this. The secret to using C to call routines in other languages ( an all VMS RTL's and System Services are other languages) is to use a wrapper. Either a macro or a routine that translates C to the other language. This way you only do the "translation" once, not every time you use the function. This is similar to the comment a previous poster made about a record management system, which, incidentatly is not ODS-2. With proper coding styles, C can be as easy to read as any language. The coding mistakes that C programmers make can be made in any language. (Terrazas: Beginners code is always bad.) ------------------------------------------ [Regarding the previous reply by Brian Schenkenberger] Eric's reply in [the previous reply] answered your first point very well. I've done LOTS with SMG and other system services in C. I have no problems. It is quite a bit easier than in Fortran for me, because I can't read Fortran, and the one program I had to do in it took me 8 times as long as it should. It was probably very bad Fortran, too. That doesn't make Fortran bad, though, just useless to me. >And I agree that the programmer has a lot to do with its cryptographic nature. >But then that's the nature of the beast. Its a mindset which has been prom- >ulgated throughout the UNIX community where C first reared its head from >the murky primorial waters. Again, Unix came from the C, the source of all life ;-} But germane to your point: in general, the good programmers on Unix write very readable C code. Problem is that a lot of the C programs people look at come from college students. Students never code with the thought that someone else will have to look at this code. >>MikeT who was DECUS' representative to X3J11 (C Language Standard) >>until last week. > Every Mother loves her child! The DECUServe Journal January, 1993 Page 26 I have some criticisms for C that are a lot more substantive than I've ever seen on this system. I spent an hour once discussing them with Dennis Ritchie, and he agrees. I use C a lot. I know some of the biggest warts as good buddies. The point of my replies here is that the usual complaints against C can be leveled at any other programming language, particularly if you look at student code or entry-level programmer code. (Merriman: Recommended reading) -------------------------------- I suggest anyone who wants to take other people's money to write C code get a copy of a Digital Press book called "DEC Guide to Software Engineering" or some such. It contains a C coding style guide, which if followed carefully, produces very maintainable C code. It makes your code look a lot like Pascal, in fact. (Furze: C is powerful, not cryptic) ------------------------------------ Everyone talks about C being portable then complains about the differences in the implementation of the RTLs on different platforms. One day I finally realized the virtue of C. It is the only language I have used (abused?) that is guaranteed to produce bug free code every time if you use it in it's pure, vanilla, unenhanced form - that means no added RTLs. Vanilla C has no input or output instructions; these are implemented via RTLs. If you cannot get any data out then, obviously, you cannot get any errors so the code must be bug free! >the Little Rascal's Women Haters Club Don't forget who's note you are replying to! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> sarcasm hat firmly in place but with a smile > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> >Many C newbies make it cryptic I took a C night course in college from a fellow who spends his days in the real world writing C code for American Express. In his first lecture he repeated, at least once every 5 minutes, that well written C code is not and should not be cryptic. The rest of the semester was spent learning all of the neat things you could do with one line of C code because it is so powerful. I got a B in the course when I thought I would get an A. I have always thought that this was directly related to the 1/2 hour argument he and I had one night over whether the instruction if ((++x != ERROR) && (x-- != ERROR)) then x++ is 'powerful' or 'cryptic'. >The price for portability is over-generalization. Think of how much simpler things would be in the auto industry if only The DECUServe Journal January, 1993 Page 27 someone would design one 'portable' engine that could be installed in any and all makes of cars - whether it be a VW BUG or a Jaguar. The designer would make a fortune because customers would insist that every auto manufacturer use that standard, portable engine. >How long is Macro going to sustain your needs? One C proponent explained to me that it's easier to think in C if you think of it as a high-level language designed by and for PDP-11 machine-level programmers. So instead of (R3)++ C lets me say x++ Oh, gee, I see the light now. That's a lot less cryptic and by programming in C I can, essentially, have the power and flexibility of PDP-11 machine code when I program my HP-900. Hey, this is really terrific. Do I see a merger of DEC & Motorola in the offing? GREAT RUMOR. Let's start it! >MikeT who was DECUS' representative to X3J11 (C Language Standard) >until last week. Glad to hear you finally returned to reality, Mike. Welcome. (Harvey: Macro is passe) ------------------------- >5) If you're on VMS->WHY C? C is to UNIX what Bliss is to VMS (I'm certainly > no Bliss advocate!! Give me Macro or give me death!) ^^^^^ You've got it! I have written tens of thousands of lines of both Macro-11 and Macro-32, and I love both. This Spring, I took to calling Macro-32 a dead language, like Latin. Recently, I decided to start calling it a zombie language. Why all this "attitude" about Macro? Alpha. 1. You can't count on Macro-64 as a high performance implementation language on Alpha. You would probably have to recode for each new model of Alpha in order to achieve maximum performance, and the coding will be a statistical nightmare. Machine code is something best left to the new generation of super compilers for high level languages on Alpha. 2. A Macro-32 compiler will be available on Alpha, but: a. It isn't an optimizing compiler. You may take a performance hit over a program written for Fortran or C. b. You frequently need to revise your Macro-32 code to get it to work right, or so say the Digital developers. c. There is no promise it will be supported in the future. The DECUServe Journal January, 1993 Page 28 At first glance, it might appear that any sensible programmer could write a compiler that will turn out good error-free Alpha code. The hitch is the combination of "good" and "error-free", and this is because the Alpha machine does not have physical status bits which your Macro-32 code may very well expect, in tricky ways, to exist. I am not criticizing the Digital developers when I call Macro-32 on Alpha a zombie language. It's dead and they have done an amazing thing: they got it to work! Just don't expect it to be warm and friendly. So, as much as I love Macro, I have decided to write off that part of my skill set and get on with becoming proficient in C. (Wood: Use the "right" language for the job at hand.) ------------------------------------------------------ Can one language really be all things to all people? Would anyone really want to write a device driver in COBOL? Isn't it really easier to read a database, keep some totals and sub-totals, and format 132 column business reports in COBOL than C? C is good for writing utilities, drivers, system level code, etc. C programs are only maintainable if they're written by good, well disciplined, programmers. C is a horrible choice for our shop, since we mostly use contract programmers who are neither good, nor well disciplined. I believe the concise nature of the C constructs encourages C programmers to write in a concise nature. Unfortunately what appears concise when it was written looks quite cryptic to someone else, or even to the author several years after writing it. In contrast the more verbose style of the COBOL and PASCAL languages encourages a more verbose coding style which can be easier to maintain several years later. I find it amusing that an earlier note used a phrase like "code which looks like PASCAL" to describe a good C coding style. I also believe in the value of strongly typed languages, such as PASCAL. Most people, and I am clearly one, have bugs in our code. I like my computer to do as much work as possible. I much prefer having my compiler catch my typoes to having my users catch my typoes because they ran a code path I didn't completely test (since we can't test all code paths completely in medium or large applications.) On the portability argument, FORTRAN makes pretty portable code if the coder sticks to standard FORTRAN. It also provides less opportunity to shoot oneself in the foot than C. Of course that is because it is less powerful. But many application development efforts don't need, and shouldn't have access all that extra power. The principle is much like using a cannon to swat a fly. (Schenkenberg: Help Jane! Stop this crazy thing!!!) ----------------------------------------------------- The reference to the 'Little Rascal''s episode was not intended to offend the women or to be sexist but... more an analog (you know - pre-digital). I happen to like women... even married one!!! Also, my current supervisor is a woman. Understanding, intelligent, and willing to listen. 180░ from my past male supervisors. Glad to see I was able to 'RAKE up the MUCK' about C. Like the Idea of the Standard engine! Fits in anything from a VW to a J(ust) A(t) G(arage) U(ndergoing) A(nother) R(epair). Will it be a 500+ cu.in. V8 configuration or a 750 cc salad oil fueled 4 banger? Personally, I won't give up my King-of-the-Road. The DECUServe Journal January, 1993 Page 29 (Terrazaz: Shouldn't this be moved?) ------------------------------------- >vanilla, unenhanced form - that means no added RTLs. Vanilla C has no input >or output instructions; these are implemented via RTLs. If you cannot get >any data out then, obviously, you cannot get any errors so the code must be >bug free! This used to be true. Since the ANSI Standard there is an RTL with documented behavior that is part of the language. stdio happens to be one of those libraries. I realize the paragraph was supposed to be a joke, but I was afraid someone might believe your statement. >I took a C night course in college from a fellow who spends his days in the >real world writing C code for American Express. In his first lecture he >repeated, atleast once every 5 minutes, that well written C code is not and >should not be cryptic. Just because someone gets paid for something and just because s/he professes something doesn't mean they're good at it... > if ((++x != ERROR) && (x-- != ERROR)) then x++ Is the type of code that's typical of the beginner. In my book, a beginner is one who doesn't code for the maintenance programmer. >Think of how much simpler things would be in the auto industry if only >someone would design one 'portable' engine that could be installed in >any and all makes of cars - whether it be a VW BUG or a Jaguar. >The designer would make a fortune because customers would insist that >every auto manufacturer use that standard, portable engine. I agree. I'm not arguing that C is the only language one should use. By the same token, to rule it out because one has Macro is very much like saying that no other car should be used besides a Peterbilt cab-over with back bench. >Can one language really be all things to all people? No. >Isn't it really easier to read a database, keep some totals and sub-totals, >and format 132 column business reports in COBOL than C? Not for me, I've never done any COBOL. I do have a set of report function primitives that allow me to read databases and format reports in as little time (or less) than most of our COBOL programmers. Those primitives did take me some time to develop, and I wish I was at liberty to put them in the SIG Tapes, but I'm very productive now. The DECUServe Journal January, 1993 Page 30 >C is a horrible choice for our shop, since we mostly use contract programmers >who are neither good, nor well disciplined. It's also a rotten choice for many of our programmers. >later. I find it amusing that an earlier note used a phrase like "code which >looks like PASCAL" to describe a good C coding style. Remember, the person who made that comment was George Merriman. George has posted several notes on this system about how much better Pascal is than C. >I also believe in the value of strongly typed languages, such as PASCAL. >Most people, and I am clearly one, have bugs in our code. I like my computer >to do as much work as possible. I much prefer having my compiler catch my >typoes to having my users catch my typoes because they ran a code path I >didn't completely test (since we can't test all code paths completely in >medium or large applications.) If you like strong typing, you can pass your C code through Lint, or you can use C++. But even strongly typed languages don't catch all your bugs. (Furze: Is anyone really serious about C?) ------------------------------------------- I suppose some might say the arguments presented border on political disagreement. If so, then I have been a DECUserve-badgirl since we do not discuss/argue politics here. But when it 'some-how' migrated to my WHO_AM_I note, I couldn't resist the temptation to respond. You might say "The devil made me do it." Since some people insist on treating this topic seriously (How can anyone take "C" seriously?) and sharing legitimate information perhaps the discussion belongs in a more meaningful conference. If someone suggests a better home for it, I will do the move (and then try to keep my opinions on the subject to myself). (Coy: Languages are fair game) ------------------------------- (Nagy: My experience with C) ----------------------------- Take my comments here in context - I'm not a manager and have written only a couple of pages worth of code in the last couple of years... I came to C from Fortran (one roommate accused me of speaking Fortran in my sleep - just to set the tone). I did so in the context of the Fermilab Accelerator Control system. Having just finished the central alarm processing system - a totally asynchronous, dynamic memory, queue-driven program handling heterogeneous data structures -- and written in Fortran, I was looking for a new language to provide data structures and better dynamic memory support (pointers basically). In addition to Fortran, we had VAX Pascal V1 - a useless product for doing anything useful. I considered Bliss (having been exposed to it in my dim dark undergraduate days) but the compiler cost was more than twice that of VAX Fortran. Just at this time, Digital came out with VAX C and I jumped on that. It solved my problem and was an easy transition The DECUServe Journal January, 1993 Page 31 (I was already familiar with C but hadn't written any) in that I could get "down and dirty" when I needed to; Pascal, on the other hand, restricted me to such an extent that I was unable to call system services and RTL routines I needed. Since then, we've used C as a major implementation language at Fermilab. The new EPICURE beam line control system is mostly written in C, at least for the support subsystems and such. The applications programs are written in a mix of C and Fortran (a particular program is in one or the other language). I've really had little problem reading my own C code. Others have since taken over my code with few problems. I do extensively comment my code (as I write it, not afterwards). This is especially true of any tricky code (written for the sake of run-time efficiency) which usually has a large comment block preceeding it telling the reader what I've done. In summary, I've found C to be productive for me and not a burden for people taking over my code. (Hassinger) ----------- I'll bet you wrote good, understandable FORTRAN code. With that discipline as your background, I think it is far more likely that you would tend to write clear, understandable C. I think there are really two problems with C. One is that it makes it too attractive and easy to write dense, obscure, tricky code. The other is the culture that has grown up around the language that seems to perpetuate and encourage that kind of code. FORTRAN II was not very "powerful" (I know, I used it with punch cards and on a 4K PDP-8!), but modern Fortran is really quite powerful, particularly in it's VAX/VMS incarnation. In fact, I will argue that it is at least as "portable" as C. In its standards compliant form it includes effective I/O as well as the rest of the tools you need. Because it has been in place and _standardized_ for a long time, there are many standards compliant, solid compilers available on nearly all platforms. Indeed, modern OS's are designed to accommodate the needs of Fortran I/O. This is not so true for C (note VAX/VMS C and its less than satisfactory RTL and accommodation to the VMS environment for example). In just about any compiled language comments cost nothing in execution performance. Source formatting designed to reveal the structure and flow cost nothing in execution performance. And typically, expressing the program as a series of simple steps rather than folding as much as possible into one complex statement cost very little at execution time. These principles apply equally well to FORTRAN, C, Macro and just about every other language. (Mayhew: Historical perspective on portability) ------------------------------------------------ Several comments appear in [earlier replies] indicating that C gave birth to UNIX. Not so. UNIX was originally born on the PDP-7 and -9 (in 1969-70, for those of you who think UNIX is newer and therefore better than VMS). The PDP-11 version became operational in February, 1971 on the PDP-11/20. The third version ran on other PDP-11s and used memory management. In the summer of 1973, the first licensed installation of UNIX, using this version, was installed outside the Bell System. I did the installation, along The DECUServe Journal January, 1993 Page 32 with a colleague named Brent Byer. C was developed for the PDP-11 in 1972. Version 4 was the first version written in C. It was written during the summer of 1973 at Bell; we installed it late that year. This history (documented, in addition to my memory, in "The UNIX Time-Sharing System", Bell System Technical Journal, July-August 1978) also demonstrates that portability was not the original goal of UNIX. In fact, Dennis Ritchie, one of the originators of C, states as much in his paper, "A Retrospective", in the same journal: "An extremely valuable, though ORIGINALLY UNPLANNED, benefit of writing in C is the portability of the system." The first known ports of UNIX were to a virtual-machine partition under VM/370 on an IBM System/370 in 1976-77, to an Interdata 7/32 at the University of Wollongong in Australia in approx. 1977-78, and to an Interdata 8/32 at Bell in 1977-78. Thus the first portability exercises for a system that is said to be so portable were not completed until nearly a decade after the system was introduced, 4 years after it was first publicly available, and 5 years after the ostensibly-more-portable-than-anything-else C language was developed. We now return you to your regularly scheduled program. ;-) (Schenkenberg: Vindicated at last!) ------------------------------------ Thank-you for setting it straight! And... As somewhat the perpetrator of this whole thread... I am amazed to see that what was originally intended as "let's poke fun at C" humor has turned into such a sensitive (to some) topic. I find it rather entertaining!!! Keep it up! (Holdrege: Fascinating history) -------------------------------- >UNIX was originally born on the PDP-7 and -9 (in 1969-70, for those of you who >think UNIX is newer and therefore better than VMS). Interesting! What language was it written in? Macro 7? (Mayhew: A little more history) -------------------------------- >Interesting! What language was [original UNIX] written in? Macro 7? C evolved from BCPL and from the language B, which Ken Thompson wrote in 1970 for early UNIX systems on the PDP-7 and -11. B did not last long. Neither B nor C are dialects of BCPL, so perhaps "evolved from" is too strong, but they share a number of attributes with it. The B compiler ran in fewer than 4K 18-bit words on the PDP-7 and was limited to word-access to memory -- but in that era there was not yet a standardized notion of "byte" and memory was commonly measured in words. (Above from "The C Programming Language" in the same edition of the Bell System Technical Journal, written by Dennis Ritchie, S.C. Johnson, M.E. Lesk, and Brian W. Kernighan.) The "UNIX Time-Sharing System" paper mentioned earlier states that early versions were written in assembly language, until 1973 when it was rewritten in C. The DECUServe Journal January, 1993 Page 33 As late as at least 1977, the UNIX kernel consisted of about 10,000 lines of C and 1,000 lines of PDP-11 assembler (NOT Macro-11 btw, but a simple assembler called "as"), about 200 lines of which were for efficiency's sake and 800 lines to perform hardware functions not possible in C (e.g. executing various memory management hardware instructions that don't exist in the C language). [Ref: "UNIX Implementation" by Ken Thompson in the same issue of the BSTJ.] (Luce: "FORTRAN 77, the only true universal assember") ------------------------------------------------------- >FORTRAN II was not very "powerful" (I know, I used it with punch cards and on >a 4K PDP-8!), but modern Fortran is really quite powerful, particularly in >it's VAX/VMS incarnation. In fact, I will argue that it is at least as >"portable" as C. In its standards compliant form it includes effective I/O >as well as the rest of the tools you need. (Nagy: Today's VAX Fortrn much, much better now!) -------------------------------------------------- >>Frank, >> I'll bet you wrote good, understandable FORTRAN code. With that >> discipline as your background, I think it is far more likely that you would >> tend to write clear, understandable C. Thanks for the compliment, the poor ego needs all the egoboo it can get (egoboo == ego boost). One amplification of my previous comment. That project would be a lot simpler to have done in C, but could also be done in today's VAX Fortran almost as easily. The reason is, of course, that modern Fortran now provides flexible definition and manipulation of heterogeneous data structures (STRUCTURE and RECORD statements). The only tricks I would need to use concern the use of dynamic memory and this would be easily accomplished with %VAL statements. (Bowler) -------- >(egoboo == ego boost). I thought EGOBOO would have meant "Boot from device EGO" :-) (Nagy: Do that other funny thing you do...) -------------------------------------------- >>I thought EGOBOO would have meant "Boot from device EGO" :-) Nah, that would have to be "BOO EGO". Besides, one never boots from the EGO, one always boots from the ID. (Patteeuw) ---------- Interesting topic! I haven't had the chance to "plow" through [the earlier replies] but I too The DECUServe Journal January, 1993 Page 34 must admit that I'm not a C lover! In our area of the company some people (including myself in the past) must maintain assembly language programs that are several thousand lines long (automotive electronic fuel injection). Management has a big problem in hiring (either as full time employees or as contractors) people who are competent assembly language programmers (especially for Intel 8096). We are moving to a new CPU architecture and part of that move will include using a high level language. The "company" made a decision to use C without investigating any other languages (Ada may have been a good alternative, but we'll never know). "Management" likes C because "lots of people know it", and this is exactly what scares me ! I don't care how many 19 year old have written how many Windows Apps using MicroSoft C or Borland C, I want programmers that are experienced in Real Time Embedded Controls and know how to write structured code that is easily maintainable. Notice I didn't say that this couldn't be done in C, just an observation that most C programmers I have talked are NOT experienced in my type of application. I would expect that most Ada would be experienced in RT EC. Also most C programmers I have met, seem to have the "UN*X" attitude that "I can hack something together with awk and grep and yacc to do that for you real fast" (where did I see that description of C programmers being like pick up trucks with a bunch of tools bouncing around in the back). These solutions are usually not easy to maintain. (Burnet: Yikes) ---------------- >We are moving to a new CPU architecture and part of that move will include >using a high level language. The "company" made a decision to use C without >investigating any other languages (Ada may have been a good alternative, but >we'll never know). I can just imagine what a conversation with a Ford dealer might have been like, circa 1997: "Yes, not only does this new model have all the latest computer-controlled dashboard features and efficiency monitoring, but you can also plug in your PC to access the 16-megabyte Ada run-time library in ROM!" (Snyder: Picking on C? You nuts?) ----------------------------------- Sigh. I'm a relatively experience C programmer who has NEVER worked on a UNIX platform. C, like any other language, can be written well or poorly. Make sure when Ford hires their programmers that they don't hire those 19 year olds you mentioned. An experienced programmer will write legible, easily-maintainable code. How much of that assembler language code was easily maintainable? Almost all of it, IF it was written by a knowledgeable programmer. And maintained by same. So quit your griping and start coding! ;-} (Steffen: The Future Past) --------------------------- >I can just imagine what a conversation with a Ford dealer might have >been like, circa 1997: "Yes, not only does this new model have all Might have been in like in 1997... You have read "The Restaurant At The The DECUServe Journal January, 1993 Page 35 End of the Universe" too many times or will have been reading too many times. >the latest computer-controlled dashboard features and efficiency >monitoring, but you can also plug in your PC to access the 16-megabyte >Ada run-time library in ROM!" How does the DoD do RT EC with Ada? Or isn't Ada being used in that way? (Kilgallen: In support of higher level languages) -------------------------------------------------- Of course I am a Bliss-bigot when it comes to lower level languages, but I think the real answer to long-term maintainability is the use of higher level languages. I have a lot of experience revisiting code which has been written years ago -- by me. Maintaining a Pascal or Ada program correctly is _much_ easier than a program written in Bliss, Macro or TECO. The compiler is able to alert you about many errors which would be "legal" in lower level languages. Additionally, high level languages are much better for those who switch languages. The chances that "thinking in another language" will result in an error-free compile is much lower. Needed - REGIS-capable Terminal Emulator ---------------------------------------- The following article is an extract of the DECUServe Unix_Os conference topic 100. This discussion occurred between July 31, 1991 and August 2, 1991. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Dale Coy, Richard DeJordy, John McMahon, Terry Kennedy (Coy) ----- My boss now has a MIPS box on his desk. He _used_ to be able to use his PC to acces the VAX, and get graphics output on his screen from an application that uses DECGraph. That was because REFLECTION knows how to do REGIS. Now he is in the situation where the VAX knows perfectly well that he doesn't have a REGIS-capable terminal. So he can't get graphics. Is there a "terminal emulator" for UNIX that will run over TCP/IP and will do REGIS? (DeJordy: DECterm?) -------------------- I would think you should somehow be able to get a DECterm window open over TCP/IP that will support ReGIS.... The DECUServe Journal January, 1993 Page 36 (Coy: Somehow?) ---------------- I guess I need some education (guess?). This is a MIPS box running MIPS software. Are you saying I can get DECTerm to somehow run on it? If so, that would be an ideal solution. (McMahon: Xwindows!) --------------------- Well, I have never seen a MIPS box... however... If you can get the MIPS to run Xwindows, and you have TCP/IP on the VAX you can do the following: 1) On the MIPS, authorize (via XHOST) the VAX to be able to open windows on the MIPS. 2) On the VAX, issue a SET DISPLAY command... /TRANSPORT=TCPIP /NODE=mips-node-name 3) On the VAX, issue a CREATE/TERMINAL Hope this helps... (Coy: Who would have looked at CREATE?) ---------------------------------------- It is running Xwindows (it says). Slowly (but that's another story). Well, I knew about SET DISPLAY. Useful for lots of stuff on my VAXStations. I had played around with it a bit this afternoon, with no success. The missing hints were: > 1) On the MIPS, authorize (via XHOST) the VAX to be able to open > windows on the MIPS. > 3) On the VAX, issue a CREATE/TERMINAL I'll let you know how it works. (Coy: Almost?) --------------- Well - I did all of that, as suggested. No errors on the XHOST or the SET DISPLAY. CREATE/TERMINAL Outer space for about 2 minutes (The VAX had obviously done something and was waiting). No visible effect on the MIPS (that is, no new windows). Finally, NONAME message Message number 02DBC002 System-F-IVLOGNAM, invalid logical name Any clues as to where I should look? Or how to diagnose? It looks very much like it's _trying_ to _almost_ work. (Kennedy: How about this?) --------------------------- Sounds like a problem translating DECW$DISPLAY. Try adding /PERM and /EXECUTIVE_MODE to your SET DISPLAY/CREATE command and try again. The DECUServe Journal January, 1993 Page 37 (Coy: Making progress - but no cigar) -------------------------------------- That changes the behavior. It used to take about 2 minutes to come back with the 02DBC002 message. It now takes about 4 minutes to come back with a 02DBC072 message. BTW - I can telnet in using a VAXStation and do the commands suggested before (without /perm/exec), and it brings up a DECTerm window on the VAXStation just *FINE*. Seemingly proving that the problem lies somewhere in the MIPS box. [Thanks, folks - at least I can now do it on my VAXStation using TCP/IP if I need to] Question: The XHOST command being used on the MIPS (per local advice) is XHOST + which, we are told, should allow "anything". Should I be suspicious of that? (other than the fact that I suspect "everything")? (McMahon: Can't Open Display) ------------------------------ > I did all of that, as suggested. No errors on the XHOST or the SET DISPLAY. FYI: SET DISPLAY has no error checking... >Finally, > NONAME message Message number 02DBC002 > System-F-IVLOGNAM, invalid logical name *Sigh* Typical DECwindows... Message File: SYS$COMMON:[SYSMSG]DECW$TERMINALMSG.EXE;1 ---> %DECW-E-CANT_OPEN_DISPL, Can't open display Which isn't a very descriptive error. I am assuming this is your MultiNet VAX. If it is, and you are running V3.0 try the following command: MU X11DEBUG/LOG It will try to diagnose the problem for you. (McMahon: A very, very long note that will save the Bacon) ----------------------------------------------------------- FYI: SET DISPLAY creates a logical name DECW$DISPLAY which points to a WSA device. Typically this logical is in the Job or Process table. It is a good idea to do a SHOW DISPLAY when debugging a DECwindows problem to make sure that the logical exists in the same context where you are issuing the command. >It now takes about 4 minutes to come back with a 02DBC072 message. Message File: SYS$COMMON:[SYSMSG]DECW$TERMINALMSG.EXE;1 ---> %DECW-E-TIMEOUT_CONTROL, Timeout waiting for DECterm controller to start One of the more annoying DECterm errors... The way DECterms work is a "Controller" process is established as a multiplexer between the network and the user processes. This controller The DECUServe Journal January, 1993 Page 38 process is running the image DECW$TERMINAL and typically has the process name of DECW$TE_X. It communicates to the user processes through a psuedoterminal device. The user end is TWDRIVER, the controller end is PYDRIVER. Anyway, what has happened here is that your terminal controller tried to start up and crashed. A method of debugging it is to do the following: $ SET DISPLAY /TRANS=TCPIP/NODE=foo/CREATE $ SPAWN/NOWAIT RUN SYS$SYSTEM:DECW$TERMINAL ! Start the controller as a subprocess $ CREATE/TERMINAL Now watch for errors. I'll bet that the Controller subprocess crashes after a complaint about missing fonts. Three ways to solve this... 1) Modify the resource files to force DECterm to use fonts that you know the MIPS box has. This works most of the time but is totally unsupported :-) Create a file SYS$LOGIN:DECW$TERMINAL.DAT containing: # # Large font search list # *bigFontSetName: -*-*-*-*-*--24-*-*-*-c-*-*-* # # Small font search list # *littleFontSetName: -*-*-*-*-*--14-*-*-*-c-*-*-* This particular file tells the Xserver to choose a non-proportional font (the "c") in either 24 point or 14 point depending on the "Big/Little Font" switch. All other font criteria is wildcarded. 2) Take the FONTS.ALIAS file from DECW$EXAMPLES and FTP to the MIPS box. Merge this file with the fonts.alias file on the MIPS. This will map the Digital specific font requests to MIT equivalents. This is probably your safest bet. 3) Get copies of the DEC fonts, FTP them to the MIPS and install them. This (probably) costs a lot of money. > XHOST + >which, we are told, should allow "anything". Should I be suspicious of that? Suspect everything... that is about the only problem with "XHOST +". Some potentially good references on this material: VAX Professional (V13 #2 - April '91) "A Remote DECterm Client and Server" By: John McMahon The DECUServe Journal January, 1993 Page 39 Atlanta Spring 91 DECUS: Session GR001/UN123 "Customizing DECwindows Applications via the DECW$*.DAT files" By: John McMahon Atlanta Spring 91 DECUS: Session GR032 "Can't Open Display: Debugging X Transport Problems" By: John McMahon Atlanta Spring 91 DECUS: Session UN(I Forgot) "DECwindows on Non-DEC Equipment" By: John McMahon Obviously, I have a vested interest in the VAX Pro Article... (Coy: OK) ---------- Thanks, John. We'll try this Monday (my boss has already gone home, and I'm half-out-the-door). >FYI: SET DISPLAY creates a logical name DECW$DISPLAY which points to a WSA > device. Typically this logical is in the Job or Process table. Yep. All of the fine references you folks pointed me to helped out. I've been using SHOW DISPLAY every time (in debugging-mode, check _everything_ - and then verify it). Can a Process Use 2 or More Pagefiles? -------------------------------------- The following article is an extract of the DECUServe VMS conference topic 1159. This discussion occurred between November 13, 1990 and November 17, 1990. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Ernest Bisson, Linwood Ferguson, Stuart Fuller, Dan Esbensen, Ed Bailey, Seton Droppers, Pat Scopelliti (Bisson) -------- Can a process have virtual pages reside in 2 or more pagefiles or must they all be in the same one? Many moons ago I thought I had read that under VMS V5.x this was true, but I can't find the reference to it. Am I dreaming? I ask this because we are getting "page file badly fragmented" problems on our Vaxstation II. It has a primary pagefile of 2000 blocks on the system disk and a secondary one of 20000 blocks on another disk. I have seen the primary file go to 0 free pages, while the secondary file still has several thousand free. If the above is true why should we get this error? (Ferguson: Install pagefile early) ----------------------------------- I don't know the answer to the real question, but have a suggestion. Are you installing the pagefile very early in the boot process? If you wait until The DECUServe Journal January, 1993 Page 40 alot of the overhead processes start, they might be consuming the only pagefile at the time. (Fuller: Nuke the small pagefile) ---------------------------------- You'd be better off to not bother with the 2k pagefile on the system disk, and just use the 20k pagefile on the other disk. Just make sure the 20k pagefile is installed in SYPAGESWAPFILES.COM (or however it's spelled). This is as I understand it from VMS Engineering. I don't recall the details, but it has something to with the processes that get started up early in the system's life all mapping to the small pagefile. (Esbensen: Check out "Reserve page count" parameter) ----------------------------------------------------- There is a "special" sysgen parameter for controlling when VMS moves pagefile allocation information to a new pagefile. The name of the parameter is something like "RSVPGCNT"...anyway, the REAL name can be seen by: $ mcr sysgen sysgen> show/special . . the last parameter on the screen is the one I mentioned . The CURRENT value will be 2048...(decide which pagefile to use next every 2048 pages for a given process). Change this value from 2048 to 512... and VMS will do a much better job of "guessing" which pagefiles to use. (Bailey: I'd go the SYPAGSWPFILES.COM approach...) --------------------------------------------------- Neat info, Dan. My personal preference tends towards nuking the small primary on the system disk, however. Here's how to do it: Edit SYS$MANAGER:SYPAGSWPFILES.COM to perform the following tasks: o Check to see if the drive holding your page (and optionally swap) files exists. This is probably not necessary for any system that is *not* part of a cluster (clusters need this check because the CONFIGURE process was *just* started prior to running this command procedure, and it takes a while to find things like HSC-connected drives). If the drive isn't there yet, wait a while and try again... o Mount the desired drive(s). Probably want to have some error checking and retry logic here as well... o Issue the necessary SYSGEN commands to get your page/swap files installed. Make sure it worked correctly. o If any of the above steps failed, or the SYSGEN parameter STARTUP_P1 is equal to the string "MIN", attempt to install the pagefile SYS$SYSTEM:PAGEFILE.MINIMUM. (If you got here by errors, you probably want to print out errors messages with bells, etc., and do whatever is The DECUServe Journal January, 1993 Page 41 necessary to prevent your full production environment from coming up on a wimpy pagefile... Then, create the appropriate files/directories on the appropriate drive(s), and rename SYS$SYSTEM:PAGEFILE.SYS to SYS$SYSTEM:PAGEFILE.MINIMUM. Reboot, and you're in business! I hope I got the message across that this code should really be bullet-proof, as if it fails, you aren't going to be able to get very far. (Droppers: Dump file can be used too) -------------------------------------- We use the dump file as an alternative "minimum" file. This only works if you have a dump file ;-). Don't forget the bells and whistles -- We print nearly three pages of xxx's in a row with the message about missing page/swap files. You wouldn't believe how big a help this is when you boss is breathing down you back because 100 users can't do anything... (Bisson: Where is RSRVPAGCNT documentation?) --------------------------------------------- > -< Check out "Reserve page count" parameter >- Where is this parameter documented? I can't find it in the V5.0 SYSGEN manual. Is it a new feature with V5.2? I didn't find any mention of it in the V5.2 New Features manual or Release Notes. Unfortunately, we don't get documentation updates for the manual set. It also doesn't appear with the SHOW/ALL command within SYSGEN, but does appear with SHOW/SPECIAL. > The CURRENT value will be 2048...(decide which pagefile to use next >every 2048 pages for a given process). Change this value from 2048 to >512...and VMS will do a much better job of "guessing" which pagefiles to use. Anyway, I decreased it to 512 and about half of the primary pagefile is still free after reboot. Before the decrease next to nothing would be free. It seems this parameter also controls the amount of pagefile reserved for a process when it is created, as well as which pagefile to use. Is this true? I think I will get rid of the pagefile on the system disk [as suggested]. Does anyone see any problems if I also decrease RSRVPAGCNT to 512? (Ferguson: Only in the fiche, probably) ---------------------------------------- SPECIAL parameters are generally not documented. (Scopelliti: Even KDBs take a while...) ---------------------------------------- > o Check to see if the drive holding your page (and optionally swap) > files exists. This is probably not necessary for any system that is > *not* part of a cluster (clusters need this Oh yes, it _IS_ necessary! We have an 8800 with three KDB50s and it takes a while for the second and third to finish initializing and recognize their attached disks. The DECUServe Journal January, 1993 Page 42 How long is "a while"? Longer than it takes to get to the MOUNT command in SYPAGSWPFILES.COM; and shorter than it takes for you to login after system startup gets trashed, successfully mount the disk and wonder "Why does it work now?" Yeah.. well, we all have our own set of scars ;-} (Esbensen: SYSGEN "help" tells about "special" parameters!) ------------------------------------------------------------ $ mcr sysgen sysgen> help par rsvpgcnt The HELP file in SYSGEN most always has something to say...even about "special" parameters! (Ferguson: So that's where they [some of them] are) ---------------------------------------------------- Learn something new everyday. However, at least on 5.3-0... They're not here. They seem to be: SYSGEN> help par special etc. And RSRVPAGCNT isn't in there even then. A few others are that I didn't know where documented, however. The "Special_params" topic is underneath the "Params" topic, and at the bottom of a LONG list where I never noticed it before. V5 Performance Slowdown ----------------------- The following article is an extract of the DECUServe VMS conference topic 1187. This discussion occurred between December 13, 1990 and December 19, 1990. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By John Briggs, Saul Tannenbaum, Wayne Bruzek, Bob Graham (Briggs) -------- We have a performance problem under VMS 5.2 on a VAX 6410, clustered. With two compute bound processes (one I/O every two seconds or so) running at interactive priority, the rest of the users on the system get terrible response. I was able to reproduce the behavior by running two compute bound processes and setting up two user processes doing wild-card directories on one of our disks. ($ DIR disk:[*...]). Watching one of the users, I saw it at priority 4, computable most of the time (this is from $ SHOW PROCESS /CONTINUOUS). The directory display would sometimes scroll at full speed and at other times slow greatly -- to about 25% of full speed. I was able to restore full speed by increasing priority of the user process (thus discrediting any argument that the performance slowdown was based on locking contention). I was also able to restore full speed by changing QUANTUM from 20 down to 2. The DECUServe Journal January, 1993 Page 43 At elevated priority, the simulated user processes would chew 16-20% of the CPU each. Without priority elevation, the two compute-bound processes would consume almost 50% of the CPU each and the user processes got almost nothing. Can someone out there explain why this is happening? Alternatively, just give me a feel for what I am giving up by reducing quantum to this level. Could I get similar effects by disabling the V5 scheduling algorithm change? (Tannenbaum: Scheduler preemption changed) ------------------------------------------- You are most likely suffering from a change in the scheduler preemption algorithm. Somewhere in the early 5.n's, the scheduler was changed to require that, for process_1 to preempt computable process_2, process_1 would have to be 3 (?) priority levels higher. Otherwise, it would wait for process_2 to come to quantum end (or otherwise go out of the computable state). Version 5.4 makes this priority difference settable through a system parameter. This changed really killed sites that had (what they thought were) low priority batch queues (priority 3) that suddenly were hogging systems. In that case, the fix is easy; set the base priority of the que to zero or 1. I'm not sure what I would do in your situation (if you can't lower the priority of the compute bound processes, that is). Lowering quantum step by step until performance is acceptable would be a good first start. (Bruzek: Between a rock & a hard place!) ----------------------------------------- Some while back, we lowered our batch que priorities to 1, and found that a batch job, while logging in, lost CPU with SYSUAF locked open, blocking other users from logging in, etc. CSC slapped our wrists, and told us to keep batch queues at 3! (Graham: patch the scheduler) ------------------------------ I agree, it sounds like your problem is with the scheduler preemption change that showed up in v5.2. We had the same problem on our 8550. After asking around at a DECUS symposium, I finally found the DEC developer that was in charge of that part of the scheduler. He wasn't able to explain exactly why it should have behaved that way, but the patch that he gave me to the PROCESS_MANAGEMENT.EXE image to disable the preemptive boost did the trick. When v5.3 came out, I had to change the patch a little to make it work (the table the patch zeroed moved by 1 page). I think I've still got the patch procedures somewhere (even though we've gone to v5.4, which make the preemption a SYSGEN parameter). If I get a change to get back to my system,I'll try to copy the patches here. (Briggs) -------- Thanks. I'd like to give that a try. (Graham: v5.2 & v5.3 patches) ------------------------------ Here's the patch for v5.2 [and the v5.3 patch]. Use this at your own risk. And make sure you keep a copy of the original, unpatched The DECUServe Journal January, 1993 Page 44 PROCESS_MANAGEMENT.EXE. You'll want to put it back before performing any VMS updates. |------------ v5.2 -------------|------------- v5.3 ----------------| process_management.exe process_management.exe examine 3158:31d8 examine 3358:33d8 repl 3198 repl 3398 1fff 1fff 0fff 0fff 07ff 07ff 03ff 03ff 01ff 01ff 00ff 00ff 007f 007f 003f 003f 001f 001f 000f 000f 0007 0007 0003 0003 0001 0001 0000 0000 0000 0000 0000 0000 exit exit 7fff 7fff 3fff 3fff 1fff 1fff 0fff 0fff 07ff 07ff 03ff 03ff 01ff 01ff 00ff 00ff 007f 007f 003f 003f 001f 001f 000f 000f 0007 0007 0003 0003 0001 0001 0000 0000 exit exit update update exit exit SYS$SETDDIR System Service Problem? ----------------------------------- This article is an extract of the DECUServe VMS conference topic 1236. This discussion occurred between February 15, 1991 and February 23, 1991. This article was submitted for publication by Mark Kozam, DECUServe Contributing Editor. Ed. By Jean-Francois Mezei, Jamie Hanrahan, Stu Fuller, Chris Rhode, Jack Pattueew, Larry Kilgallen The DECUServe Journal January, 1993 Page 45 (Mezei) ------- Is there a known problem with the SYS$SETDDIR system service ? It seems to change the default directory, but not the default device. (eg: current directory: USER1:[name1.name2] specify in SETDDIR: USER2:[name3.name4] Result afterwards: USER1:[name3.name4] Is there something I am doing wrong ? The status code returned from SETDDIR is success. Is there a system service to change the default device also ? VMS 5.4 (no -1, that site doesn't feel it is important to install !). The disks are shadowed on an HSC. the USER1 and USER2 are logical names. (Hanrahan: use logical sys$disk to define default device) ---------------------------------------------------------- That's all it's supposed to do. >Is there a system service to change the default device also ? Not exactly. What you need to do is redefine the logical name SYS$DISK. That's the "device" part of the "default device and directory". (Mezei: Thanks for the hints) ------------------------------ So, in essence, the equivalent of SET DEF is to 1- change the logical name SYS$DISK to point to the device in the target directory, and the call SYS$SETDDIR to change the directory portion. The VMS documentation should have a warning. I spent many hours trying to figure out why it didn't work. (by default, I assume problems are my fault...) Thanks for the hints ! (Fuller) -------- Well, the name of the service is "SET DEFAULT DIRECTORY". It doesn't claim to set the default device. However, you're correct in that the manual should have a mention (I would consider "warning" to be too strong) that one should also diddle with the SYS$DISK logical. (Rhode: I think SYS$DISK+SYS$SETDDIR is far from intuitive) ------------------------------------------------------------ I didn't find it intuitive that one changes your default disk/directory by calling a somewhat obscure RMS routine and redefining a logical name ... especially after many months of experience exclusively with system service calls (I wasn't smart enough to figure out that a set default function wouldn't be a system service call, seemed at the time that you could do ANYTHING with system services :-) Fortunately the first time I wanted to do this, I had existing sample code to go from. I -am- somewhat surprised that you didn't get some sort of error out of SYS$SETDDIR ... The DECUServe Journal January, 1993 Page 46 (Patteeuw: DCL lets you SET DEF to a non existent directory !) --------------------------------------------------------------- (Kilgallen: It's a feature!) ----------------------------- $ SET DEFAULT [VERY.OBSCURE.DEEPLY.NESTED.DIRECTORY.SPECIFICATION] $ CREATE/DIRECTORY [] lets you perform the complicated typing just once. How Are Quotas for STARTUP Set? ------------------------------- The following article is an extract of the DECUServe VMS conference topic 1300. The discussion occurred between April 8, 1991 and April 12, 1991. This article was submitted for publication by Alan Bruns, DECUServe Contributing Editor. Ed. By Larry Stone, Stu Fuller, Terry Kennedy, Mark Hyde (Stone) ------- Where does the STARTUP process (the one that runs STARTUP.COM at boot time) get its quotas. Is it the PQL_Dxxxx SYSGEN parameters? (Fuller: Yep) -------------- (Stone: Well I'm not so sure now) ---------------------------------- If only what I'm seeing now would let me believe that. To fill in the story (now that I have time to write it :-) ), our SYSTARTUP_V5 invokes a command procedure that starts our primary application. This command procedure includes an RDO OPEN on the application's database. The RDO OPEN sometimes causes an RDB bugcheck (and yes that is sometimes as in not always). A review of the bugcheck dump indicates that the problem is "exceeded enqueue quota." OK - I can deal with that - let's up ENQLM. But where? The bugcheck is even nice enough to tell you what the original quota for the process was - in this case it says 100. Well PQL_DENQLM is 60 and the SYSTEM account ENQLM is 20,000. WHERE IS THE 100 COMING FROM? Is this hard coded into the boot? I would expect the quotas to be the PQL_Dxxx parameters. If I understand things right, when the STARTUP process is created, VMS (such as it exists at that point) wouldn't even know where to find SYSUAF to get the SYSTEM account quotas. Details: VMS V5.3-1 VAXcluster with two 8530s and two 3500s (the machines with the The DECUServe Journal January, 1993 Page 47 bugchecks were 1 8530 and 1 3500) (Fuller: What's PQL_MENQLM set to?) ------------------------------------ (Kennedy: PQL's, mostly) ------------------------- >Where does the STARTUP process (the one that runs STARTUP.COM at boot time) >get its quotas. Is it the PQL_Dxxxx SYSGEN parameters? It copies them from the "system PQL" area (per the listings for SYSINIT). I'm unsure if they mean the _D's or the _M's. All quotas are created that way except for WSEXTENT (built from SYSGEN WSMAX) and WSQUOTA (built from min[SYSGEN WSMAX, 64K-1]). That last bit seems to be recent (added in 1989). (Stone: 4) ----------- >What's PQL_MENQLM set to? (Hyde: fixed values) --------------------- At system boot time, the SYSINIT process creates the STARTUP process which executes the SYSTARTUP_V5.COM file and any other startup files specified in SYSMAN etc. When SYSINIT sets up the $CREPRC system service call to create the STARTUP process, it specifies *all* the limits and quotas for the process as arguments to the $CREPRC call. The values that it uses are values from a system data structure called PQL$AB_SYSPQL, the SYStem Process Quota List. These are hardcoded, fixed values. I'm at home and don't have the list handy. They are defined in SWAPPER.LIS. (Stone: Sounds like I need to go detached or batch) ---------------------------------------------------- So in other words, if something in SYSTARTUP_V5 needs higher quotas than these fixed values, I need to create a detached process or a batch job. Are there any other options? (Hyde: not really) ------------------- Just set the PQL_Mxxxx values to your needed values. Here's a more complete explanation. I just happen to have this handy because I had to write it up to explain some of the behaviour seen during MAILbus startup. Forgive the MAILbus specifics but the same kind of behaviour happens to other things as well. Maybe this can help clear up the mystery surrounding the use of PQL parameters. MAILbus requires that specific PQL parameters be set, but it has not been clear exactly how the PQL_Dxxxx values are related to or interact with the PQL_Mxxxxx values. (The following is adapted from the VMS Internals and Data Structures Book.) When a process is created, the system uses two tables in the executive to set up quotas for the new process: a minimum quota table and a default quota The DECUServe Journal January, 1993 Page 48 table. Each quota or limit in the system has an entry in both tables. The contents of the minimum table are determined by the SYSGEN parameters whose names are of the form PQL_Mquota-name; the contents of the default table are of the form PQL_Dquota-name. The following is a list of steps used to determine the value for each quota or limit during process creation. PQB = Process Quota Block, a temporary data structure used during process creation that holds various values that will be copied into the Process Header after the process has come into existence. 1. The default (PQL_Dxxxxx) values are copied into the PQB as the initial values. 2. If any quotas or limits are specified as arguments in the $CREPRC system service, (how this whole thing got started anyway), they are copied in the PQB, replacing the corresponding values from Step 1. 3. Now, all values in the PQB are checked against the PQL_Mxxxxx values and forced to be at *least* the minimum. If the value at this point is already larger than the PQL_Mxxxx value then it is left alone. 4. Sometime after this the process will come into being and the PQB values will be copied into the Process Header. 5. If this is an interactive user process, the LOGINOUT image will run and copy the values for the quotas/limits from the SYSUAF record into the Process Header, overwriting whatever is there from the setup of the PQB. One of the questions then is why will the MAILBUS startup procedures sometimes complain about quotas and limits during a system boot but not when you manually run the startup procedures after the system is booted. At system boot time, the SYSINIT process creates the STARTUP process which executes the SYSTARTUP_V5.COM file and any other startup files specified in SYSMAN etc. When SYSINIT sets up the $CREPRC system service call to create the STARTUP process, it specifies *all* the limits and quotas for the process as arguments to the $CREPRC call. The values that it uses are values from a system data structure called PQL$AB_SYSPQL, the SYStem Process Quota List. These values are hardcoded, fixed values (see SWAPPER.LIS sources). So in the scheme of things above, at Step 2, these values are supplied by the $CREPRC system service call, over-writing all the PQL_Dxxxx values from Step 1. At Step 3, if the PQL_Mxxxx values are NOT set properly, the STARTUP process winds up with incorrect values for it's quotas and limits. The STARTUP process does not run as a user process and does not use Step 5 from above so whatever it has in the PQB at the end of Step 3 are the ones copied into the Process Header and in use while the startup procedures are running. When the MAILBUS startup procedures run, they use a DCL loop of F$GETJPI's to get the current value of the quotas and limits that it cares about. These are compared with the values coded into the procedure and can result in the infamous, "%MB-E-QUOLOW, The following quotas for MR....may be too low." message. The DECUServe Journal January, 1993 Page 49 For example, the SYSPQL list has a value of 10 for ASTLM, but MB$$MS_START.COM checks for a value of 24 or larger. Likewise for DIOLM, SYSPQL sets it to 10, MB$$MS_START.COM wants 18 or more. Later when you login as SYSTEM and execute the startup procedures you may not get message. This could be because of Step 5. When you logged in as SYSTEM the LOGINOUT image eventually ran and filled in the process quotas and limits from the SYSTEM account SYSUAF record. Normally, these are large enough to satisfy the MAILBUS startup procedures. So it is important that the PQL_Mxxxx values be set as required by MAILBUS. Most of the PQL parameters are DYNAMIC so it is tempting to set them on the fly, however you then find them changing back to their default values when you run AUTOGEN. So it is also important that these be placed in MODPARAMS.DAT so they will be set whenever AUTOGEN runs and consequently be set correctly for the next system reboot. Can You Put OPCOM on a DECTERM/Noprocess? ----------------------------------------- The following article is an extract of the DECUServe VMS conference topic 1341. This discussion occurred between May 25, 1991 and May 28, 1991. This article was submitted for publication by Don Roberts, DECUServe Contributing Editor. Ed. By Alan Bruns, Glenn Zorn, Ed Bailey (Bruns) ------- I have a VT1200 and would like to bring up a DECTERM window, preferably without a separate process attached to it, that would do nothing but display OPCOM messages. I'd rather not reinvent the wheel, though. Since this seems like such an obvious thing to do, _somebody_ out there has this already. Probably something like 1 Set up a /Noprocess DECTERM window 2 Set an AST from DCL to trap broadcast messages and redirect them to said window 3 REPLY/ENABLE Having "New Mail" notices mixed in doesn't bother me. Being rather frugal, I'd just as soon not waste a process to do this. And it's rather tiresome to have to get up and go the 50' or so over to the console every time the printer doesn't have the sound of a "normal" message. I asked the DECwindows folks at DSNlink about this. The first reply I got suggested that VCS would take care of this. I was polite when I replied to that sillyness, and their second message contained a command procedure that directs OPCOM messages to the Session Manager window. I'll probably fool around with that and see if it can be adapted to my purpose. But if somebody out there has the code to do what I want you'll save me some trouble by posting it... The DECUServe Journal January, 1993 Page 50 (Zorn: Put it into the Session Manager window) ----------------------------------------------- Yes. Put it into your Session Manager window since that is used very little otherwise. The code below will do it if spawned from DECW$LOGIN. (I got the code from Ed Bailey before he left CUC, hope you don't mind) (Before anyone comments on the date of this note: 1) I am oncall this weekend, 2) Our production cluster needs to be rebooted at midnight and I am coordinating the downtime) $ ! $ ! DECwindows OPCOM Option... $ ! $ SET PROC/PRIV=ALL $ SET PROC/NAME="Xopcom" $ ! $ ! Get the name of our session manager window... $ ! $ GET_DEVICE: $ DEVICE = F$GETJPI(F$GETJPI(0,"OWNER"),"TERMINAL") $ IF DEVICE .NES. "" $ THEN $ WAIT 00:00:30 $ ASSIGN/USER 'DEVICE' SYS$COMMAND $ REPLY/ENABLE $ ASSIGN/USER 'DEVICE' SYS$COMMAND $ REPLY/DISABLE=(SECURITY, CENTRAL, NETWORK) $ EXIT $ ENDIF $ ! $ ! The session manager isn't there yet, wait and try later... $ ! $ WAIT 00:00:10 $ GOTO GET_DEVICE (Bailey) -------- No problem, Glenn; although I should be honest - I got this (if I remember correctly) from a DSNlink article. I did massage it a bit, though... Seems like some things never change at ol' CUC, eh? :-) (Bruns: Did it myself.. code included here.) --------------------------------------------- OK, so I decided to try to do this myself. About time I posted some code up here, anyway. This code will create a window /noprocess and direct OPCOM messages to it. It works fine on my VT1200. $! $! O P C O M - W I N D O W $! $! Hang a DECTERM window on the current process, and REPLY/ENABLE $! to send OPCOM messages to the new display. $! $! DEALLOCATE OPCOM_Window to turn it off. The DECUServe Journal January, 1993 Page 51 $! $! Alan Bruns May '91 $! $ CREATE/TERMINAL/LITTLE_FONT/DEFINE=(TABLE=LNM$Job,OPCOM_Window)- /NOPROC/WINDOW=(ROWS=5,COLUMNS=132,ICON="opcom",TITLE="OPCOM Window",- X_POSITION=5,Y_POSITION=800,INITIAL_STATE=ICON) $ ALLOC OPCOM_window $ DEFINE/USER Sys$Command OPCOM_window $ REPLY/ENABLE $ EXIT Automatic Menu Startup ---------------------- The following article is an extract of the DECUServe VMS conference topic 1379. The discussion occurred between July 15, 1991 and August 21, 1991. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Jack Harvey, Geoff Bryant, Michael Baydoun, John Osudar, Mark Shumaker, Jon Jones, Dale Coy, Gary McCready, Chuck McMichael, Brian Tillman, John Burnet (Harvey) -------- As we all know, SYLOGIN.COM runs before the user's LOGIN.COM. This is a good place for the system manager to do things in the user's process that can be common to all users. This paragraph is sort of to set your thinking frame. Now, how can the system manager get a command file, let's call it SYLOGIN_2.COM to execute *after* LOGIN.COM? It needs to do things after LOGIN.COM has altered the process environment and completed. (The case of a LOGIN.COM that never completes prior to logout probably isn't significant at this site.) Obviously, if LOGIN.COM itself executed SYLOGIN_2.COM, the problem is solved, but the system manager can't count on that happening. Any ideas? (Bryant: Try this...) ---------------------- SYLOGIN_2 does: $ IF F$SEARCH("SYS$LOGIN:LOGIN.COM") .NES. "" THEN - @SYS$LOGIN:LOGIN $ POST_LOGIN_STUFF Then in SYSUAF don't point LIGCMD to LOGIN... (Baydoun: Heres a thought) --------------------------- How about renaming your all your users login.com files to something else, ie user.com. The DECUServe Journal January, 1993 Page 52 Then have sylogin.com do something like this: Run sylogin normal commands Figure out who the user is, process name maybe? @[user.directory]user.com The rest of your post login.com commands As far as VMS is concerned, the user will not have a login.com. You probably do not even have to rename them, just go into authorize and modify LGICMD = (null). The only difficulty might be determining who is logging in and what their directory should be, depends on your sites standards. (Osudar: null LGICMD won't do it?) ----------------------------------- Modifying LGICMD to be null won't work, as I recall; a null value causes LOGIN.COM to be executed from the user's default directory. What you may want to do is set LGICMD to something like NLA0: instead. Then have your SYLOGIN look for the user's LOGIN.COM, execute it, and do the post-LOGIN stuff. (The next question is, what will you do when your users want a LOGIN_2.COM to execute after your SYLOGIN_2.COM, so they can change some of the things you do there? :-) (Shumaker: Post-login may not run when expected) ------------------------------------------------- Well, you can plug something like SYS$SYSTEM:USER_LOGIN.COM into LGICMD in SYSUAF, and have USER_LOGIN look for a LOGIN.COM in the user's directory and execute it if there, then do your stuff (as in [the previous reply]); BUT, if the user's LOGIN.COM sets up some stuff and then invokes the program in which the user normally does his work (like a CAD system, for example), then your post-login commands won't run until the user leaves that program. Would this be a problem? (Jones: The bratwurst approach) -------------------------------- We use SYS$SYLOGIN to point to those things that absolutely shouldn't be skipped, not even for a username/NOCOM. We then point all the LGICMDs to another logical that "wraps" the call to LOGIN.COM within before and after commands (like the menu system). (Harvey: DECUServe Does It Again!) ----------------------------------- Thanks very much, people. You have answered my question perfectly... which really was, "Am I overlooking something?" The somewhat bizarre notion (it seems to me) of perverting LGICMD had occurred to me. My version was to have it *be* SYLOGIN_2.COM, with SYLOGIN.COM assigned the duty of executing SYS$LOGIN:LOGIN.COM, if found. That others might want such a feature seemed pretty obvious, and like so many things in VMS, it might already have been implemented, documented and then overlooked by me. It seems that in this case, I managed to keep up. How come something like this hasn't been codified? I expect John put his finger on it: The DECUServe Journal January, 1993 Page 53 >(The next question is, what will you do when your users want a LOGIN_2.COM to >execute after your SYLOGIN_2.COM, so they can change some of the things you >do there? :-) VMS Engineering knows better than to go down that rat hole. (Harvey: Restated Problem) --------------------------- The system manager I have in mind is Dale Coy and the system is DECUServe. (This may be a surprise to Dale, but I doubt it.) We have been looking into ways to offer "options" to DECUServe subscribers that they can select or de-select as easily as clicking on a menu item. The idea is to try to eliminate complex instructions such as "edit your login.com to include DEFINE BARF NEW_MAGIC to enable this dandy new service for you". Readers of this conference won't benefit, of course, but such an instruction upsets some, who reply: "But you don't have vi! I *can't* edit login.com, whatever that is." Now, some options can be controlled in the grandly simplified manner I'm looking for without the postulated SYLOGIN_2.COM. I expect enabling OneKey Noting will be offered without requiring editing in the future. But how about a menu system itself? Suppose that the next time you log into DECUServe, Dale has converted it to Ultrix. A few reading this might be comfortable or even pleased. I expect the rest would be forming a lynching party. No, it isn't about to happen. Although, come to think of it, there is an ominous announcement about something happening on July 26. However, people with a strong taste for Unix probably have about the same reaction to DECUServe *now* as you might have on July 27. So I'd like to be able to *offer* a $-free environment - where the subscriber is swaddled in menus from start to finish, never having to try to guess what the magic DCL (or csh) command might be to accomplish today's objective. (Please note I said OFFER, not establish, and a menu item would be an escape to DCL (or csh), if I still have any say in the matter.) So I am looking for a way to bridge the gap between the end of LOGIN.COM (which we can't control) and menu startup. So let me rephrase the question: 1. How can I get a menu scheme to start automatically on login without depending on login.com to do it? 2. Is there anything really wrong with perverting LGICMD to do this as suggesting by earlier notes in this thread? (Coy: Who, me?) ---------------- [Regarding question #2 above:] Nothing inherently wrong. One caution: there are some subscribers on DECUServe who (I believe) essentially give their Username and Password, and that's the last thing they do. An automatic procedure takes care of all of their "work". The DECUServe Journal January, 1993 Page 54 (Jones: Computing with a mixed bag of users) --------------------------------------------- We do this routinely. We use identifiers with clever names like DCLUSER, MENUSER, CUSTUSER, MEN2USER to split the exection of the joint login file. So programmers get dropped to DCL, most users into generic menu system, customers into a specialized menu system, etc. I don't find this a perversion of LGICMD any more that "IF F$MODE() .EQS. ..." is. With VMS 5.4, you can use f$getjpi to find out if an identifier is held by the process. (Prior to 5.4, we used a special image.) Here, though, you'd probably want to make this user selectable, so you'd need some way for users to change their default identifiers. (McCready: Finding a pre 5.4 ID holder via DCL) ------------------------------------------------ Pre-v5.4 I Kludged DCL - the only real trick is that the identifier has to have the DYNAMIC attribute - the code follows: $saved_message=f$environment("MESSAGE") $set mess/noident/notext/noseverity/nofacility $saved_privs=f$setprv("NOCMKRNL")!have to turn off if present $ !or else always returns "success" $set noon $set rights/enable 'id_to_check' $saved_status=$status $set message'saved_message' $set proc/priv=('saved_privs') !restore it if it was there $! $!if below is true then user had identifer granted to them $! $if saved_status $ then enabled="Y" $ else enabled="N" $endif (McMichael: Grail? We already got one!) ----------------------------------------- > 1. How can I get a menu scheme to start automatically on login without > depending on login.com to do it? Our installation has set up command files to do that. If you're interested, I can see about trying to upload them for your perusal. (Harvey: Yes!) --------------- Most certainly, if you have a improved technique over those already discussed in this thread. The DECUServe Journal January, 1993 Page 55 (McMichael: They're here!) --------------------------- I've put the following files in USR_SCRATCH:[MCMICHAEL] AAAREADME.TXT MASTER_MENU.COM MASTER_MENU_ITEMS.COM MASTER_MENU_START.COM MASTER_MENU_USERS.COM (Harvey: Concrete) ------------------- Hey, thanks, Chuck. As I see it, your scheme works by having SYLOGIN execute LOGIN.COM (if found) and then start a menu if appropriate for the username. This is a very nice package, and I shall certainly study it for details and to see how it handles things. I snarfed a copy of it. Thanks. However, what you have here is an essentially complete submission, including the AAAREADME.TXT, for the DECUServe Tape Library. Why not submit it? It certainly has general interest. To find out how, type: Notes> help decuserve tape It's fun! :-) (McMichael: Try again.) ------------------------ Thanks for the complement. If I can find a way around the "feature" that makes it execute LOGIN.COM whether or not a normal login would, I'll submit it. Also, for documentation purposes, can anyone say which version of VMS had the session manager process of DECwindows change from "username_VUE" to "username_SM"? (Harvey) -------- Except for some trick accounts related to mail and not individuals, I believe every account on DECUServe has LGICMD pointing to SYS$LOGIN:LOGIN.COM. So this is not an issue on DECUServe. What is an issue is that I'd like our menu (if it were to happen) to be able to exit to the DCL prompt. If the menu is running via SYLOGIN.COM, when the menu exits, SYLOGIN.COM exits, and then LOGIN.COM runs a second time. This creates a requirement that LOGIN.COM be able to do that safely. (McMichael: It's in there!) ---------------------------- As you wish. If you'll check the bottom of MASTER_MENU.COM, you'll see that in the case where P1 is true (which should only be at login) and LOGIN.COM was run, the procedure issues a STOP command to prevent LOGIN.COM from running again. The procedure also sets up the symbol MENU to reinvoke the menus without rerunning LOGIN.COM when the user gets tired of DCL. The DECUServe Journal January, 1993 Page 56 (Harvey: STOP!) ---------------- DECUServe does it again! This never occurred to me. If SYLOGIN.COM ends with a STOP, the LOGINOUT image is what stops, right? That prevents whatever is being pointed to by LGICMD from being executed. We don't have to point it to the null device or other strangeness. I *think* this solves all the problems I have been concerned about for this particular application. Now, Chuck, if I give you a program to define a DCL symbol containing LGICMD, will that solve your problem? :-) (McMichael: Serendipity) ------------------------- Strangely enough, the latest VAX PROFESSIONAL has an article dealing with $GETUAF. I'll get back to you folks in a week or so. (Harvey) -------- Two versions of this have been submitted to the librarian. (Tillman: Doesn't STOP just terminate the current command procedure?) ---------------------------------------------------------------------- Jack, I don't think that having STOP in SYS$SYLOGIN stops LOGINOUT. According to the documentation (HELP) for STOP, having STOP merely stops the command procedure containing it. Did you test to see in, in fact, LOGINOUT does stop? (Burnet: No but yes) --------------------- Right -- at the point the SYLOGIN procedure runs, LOGINOUT.EXE has already passed control to DCL, so the STOP has no effect on it. In any case, if DCL is interpreting a command procedure, then (almost by definition) no image is active except the ones that the command procedure invokes. However, putting the STOP in the SYLOGIN procedure does prevent the user's LGICMD from being run, so this story should have a happy ending. (Harvey: Needs more investigation...) -------------------------------------- Brian, I didn't test it exhaustively, but I did find out that a command file pointed to by LGICMD doesn't execute. That's just not a full answer. (McMichael: Full STOP) ----------------------- >According to the documentation (HELP) for STOP, having STOP merely stops the >command procedure containing it. And in the case of nested command procedures, it stops all the levels above it. The DECUServe Journal January, 1993 Page 57 (Harvey: Clarification) ------------------------ Brian Tillman, former MoS here, has been jostling my elbow. :-) I may have implied earlier that on DECUServe, LGICMD contains SYS$LOGIN:LOGIN.COM. (Because I thought it did.) In fact, it's blank. Loginout (or whatever) executes SYS$LOGIN:LOGIN.COM by default for normal accounts. I also want to assure people that we aren't thinking of *requiring* that they keep a login.com file. My whole concern has been to be able to offer options such as an automatic menu with minimum or zero impact on users. (McMichael: Revised Standard Version) -------------------------------------- The revised version of MASTER_MENU is now in USR_SCRATCH:[MCMICHAEL] This one uses MM_LGICMD.EXE to compute the login command file name. There are two files you need MM.TLB text library containing AAAREADME.TXT MASTER_MENU.COM MASTER_MENU_ITEMS.COM MASTER_MENU_START.COM MASTER_MENU_USERS.COM MM_LGICMD.EXE MM_LGICMD.FOR MM_LGICMD.LIS MM_LGICMD.OBJ EXTRACT_TLB.COM to decompose the text library [Editor's note: If you are interested in a copy of the files mentioned in this article, try looking in the DECUS Library Tapes, or on the DECUShare CDROM library.] Collected Notes on VMS 5.5 -------------------------- This article is an extract of the DECUServe VMS conference topic 1800. This discussion occurred between July 7, 1992 and August 7, 1992. This article was submitted for publication by Pierre Hahn, DECUServe Contributing Editor. Ed. By Chris Rhode, Don Roberts, Mike Mattix, Tyler Mainquist, Matt Rollinson (Rhode) ------- The following was compiled from DECUServe, and other sources. References to DECUServe VMS conference note numbers are in [] at the end of bulleted items. I worked forward mid-June from 1604.x in the VMS conference to compile this (there may be material from earlier than that because I also used notes taken from DECUServe, USENET, our LUG etc. over the past few months which are not always great in pointing out where the material came from :-) I reviewed The DECUServe Journal January, 1993 Page 58 the source material with an eye towards items of interest to our site, and thus may have omitted certain areas (such as DECwindows, problems discovered with unsupported areas of VMS, etc.). These notes are not guaranteed to be accurate (though I put some effort into proofing the stuff I drew from DECUserve, which is the vast majority of the material) or complete. You can use the note number cross references to get more detail on things you are concerned about or don't believe -}. Your mileage may vary. I hope this is useful to somebody ... I put it together for somebody that was thinking about upgrading to 5.5. I think some of this material will be useful even for people going to 5.5-1 or beyond ... If anybody reads this and can point out inaccuracies, provide new details, etc., please do ... o If you are running LAT get the latest version of patch kit 0511 (V3.2 or later) and install it ASAP after the upgrade. There were also separate ECOs (#1 and 2) for LATSYM in conjunction with V3.0 of this patch kit, find out if they are needed. TEST LAT SERVER ALL may crash the system even under latest patch revs. [1699.13, 1725.4, 1657.0 etc.] o STOP/NEXT on a queue follow by START on that queue is broken in that the queue must actually stop fully before START will work. Change in behavior. [1604.51] o The queue manager data files are not properly saved as part of a BACKUP operation, even under standalone backup. Backup and restore of a 5.5 system disk will result in lost queue information. Workaround: stop the queue manager, do backup, then restart the queue manager. [1604.59, .64, .76 etc.]. [Note: it's never been "safe" to try to backup the queue files with the queue manager running, but now it appears you have NO chance of recovery, even from a standalone backup.] o Do NOT convert the queues as part of the upgrade procedure. Just Say No, and after the upgrade run @SYS$UPDATE:VMS$UPGRADE_A55_V55 [1604.27] o The VMS 5.5 upgrade procedure destroys the password history list file; preserve a copy of this file before the upgrade and restore it manually after the upgrade. [1604.1] o Disks that go into Mount Verify may cause a system crash. Fixed in 5.5-1. [1604.3] o Pathworks for Mac V1.1 DAL will not work under VMS 5.5 o Pathworks for DOS V4.0 breaks under 5.5. Get patch kit 3018, or wait for Pathworks V4.1. Make sure you get a patch kit with a version of S4.0N or later. [1604.4, .5, .6] o See Chapter 5 of the release notes, you must have the QMAN$MASTER logical name defined in SYLOGICALS before upgrading. [1604.23] o MONITOR DISK/ITEM=QUEUE may be broken (only on SMP machines?) [1604.29] o CPU limits will be ignored on batch queues [1604.31] o If running DQS 1.2 get patch 0554. The installation procedure for this patch may be buggy, there is a workaround [1604.41] o See section 6.5 of installation guide, there is a mistake, SYSUAF must be in SYS$COMMON:[SYSEXE] [1604.44] o Batch jobs present in queues and submitted with the /PRINT qualifier will be lost during the queue file upgrade. [1604.45] o Carefully check the system date/time after each reboot during the upgrade, including after MUPs etc, it may drift by days or years. Stop accounting and all queues before the upgrade and disable anything that might start them during the upgrade. Fix the system time before restarting them and before installing layered products. [1604.45, .90, .91] The DECUServe Journal January, 1993 Page 59 o Under VMS 5.5, one-to-one mapping of characteristic names to number is enforced. A workaround exists [1604.46, .54] o Apparently the queue manager is supposed to "remember" that it was started across reboots and restart itself on reboot (no more need for START/QUEUE/MANAGER in SYSTARTUP). Actually this doesn't work. [1604.71] o Queue manager may run out of virtual memory and die, corrupting your queue file. [1604.72] o Get CSCPAT 1011 - patch for crash scenario (with locks?) [1604.74] o Under VMS 5.5, there are changes in lock performance due to POSIX, ENQ/DEQ are 6% faster but CONVERT is 12% slower [1604.75] o DELETE/ENTRY on a job that was submitted /NOTIFY will no longer send the "job deleted ..." broadcast message to the submittors terminal [1604.79] o SET AUDIT/SERVER/NEW_LOG may result in a corrupted new audit server file. Get CSCPAT_0061. [1604.80] o ANALYZE/AUDIT under VMS 5.5 does not handle some flavors of V5.4 audit records [1604.80] o Force TMSCP_LOAD to 0 in MODPARAMS on nodes without local tape drives or on nodes where you don't want to serve the tape drives. If you don't do this, you may get %TMSCPLOAD-E-SERVE_ERR errors on reboot, among other things. You should force TMSCP_LOAD to 0 in the Standalone Backup parameter set. See the VMS 5.5 Cover Letter. [1604.85, .86] o You can't upgrade from 5.0 thru 5.3-n to 5.5 in a cluster. There is a workaround [1604.88] o If you are running ACMS, see DEC about a patch for a mailbox problem [1604.93] o Possible problems upgrading from the InfoServer, with workarounds [1604.97, .99, .108] o If non-Decwindows Debugger seems to want DECW$TRANSPORT_COMMON loaded, try installing the image manually. DECW$STARTUP may have tried to do this and failed due to an exceeded quota (try increasing PQL_MBYTLM to 65000) or DECW$STARTUP may be partially or fully inhibited depending on system/startup configuration. [1604.104, .116, .117] o There is a patch for 6610 systems, #1000, but it may cause "hideous performance loss" [1606.0] o Read the New Features Manual for VMS 5.5 carefully, especially regarding the new batch/print queue system. Also check out the new SET PREFIX command. o CSCPAT_1012 for queue manager, get latest version. Helps with but does not eliminate queue stalling problems. [1725.x] o If running WordPerfect, get latest version/patch set from vendor [1706.x, 1725.5] o Get CSCPAT_1101 for BACKUP, supersedes old _0101 [1734.0] o If running DECserver 200s, get "BL37B" patch (talk to field service) [1737.2] o Keeping times of cluster nodes in synch is now even more critical for queueing system, set up a procedure to do this several times a day. [1766.x] o Check with DEC for latest news on 5.5 if you are an All-in-One shop, there are potentially major problems. [1604.44, .52 (background formatter), 1757.4 (patch #1012 may fix)] o Check with Multinet vendor ... patch needed ... 3.0 Rev H is okay o If running a DEBNA get patch 0543 o A default LRPSIZE of 1504 is now okay o Ignore p. 2-13 on increasing BYTLM by 320 for users if all users currently have over 10K BYTLM (which they should anyway). A BYTLM of 20480 is a good number for most users. [1661.x] o Custom print symbionts -may- break. [1692.x] The DECUServe Journal January, 1993 Page 60 o Check into patch 1001 for VERIFY utility o A POSIX -license- is included with the VMS 5.5 license. You must purchase a media kit. Get POSIX patches, 1021. o If you have a SYSMANINI file which includes a SET FILE/CLUSTER command, this may cause problems for AUTOGEN. [1579.0] o Check into patch 0059 for TUDRIVER [1710.6] o VPA becomes unsupported under VMS 5.5, use DECps instead [1604.44] 1604.44 - General warning about 5.5 1604.47 - ditto 1604.95 - good writeup on autostart queue mechanism 1604.96 - one site's project plan for 5.5 upgrade 1757.2 - list of patches 1757.3 - list of patches (Roberts: Thanks for compiling this Chris!) -------------------------------------------- Well, I just found out that some third party print symbionts will fail with 5.5, and you need patches 1012 (listed before) and 1022 (not listed) to fix this. This looks like a very thorough list, Chris. I just wish you had posted it two weeks ago, before I upgraded :-( (Mattix: I have not seen this mentioned before??) -------------------------------------------------- Just adding one thing. Let's see if I can get this right... If you have a heterogenous cluster (more than one SYSUAF) and you convert to the new Queue system you will be in for a rude awakening. It seems that the new Queue Manager looks for an entry in the SYSUAF.DAT on the node that starts the Queue Manager for any batch jobs submitted. Even if the Queue the job is submitted to is running on an another node with a different SYSUAF.DAT file. This bit us this last weekend when merging two clusters into one. One was 5.4-2 and the other was 5.5. DEC CSC claims this is the way it is planned to work and has no intention of fixing(??) it. It has caused us to put duplicate entrie on the 6520 that is running the master queue manager for all accounts on a VAX4300 running a totally separate application suite. This is obviously progress.. (Mainquist: New (5.5) queue manager on heterogeneous cluster) -------------------------------------------------------------- The issue in [the previous reply] bit us hard, too, and we were told the same story: "The queue manager was not intended to support a heterogeneous cluster, and this has been true for quite awhile." At the time we had somewhere between 12 and 14 nodes in the cluster with about 5 different UAF environments. We had the luxury of being able to choose which of the 5 UAFs to run on the queue managing node, so we took the one with the most users submitting jobs. BTW(1): This affects more than just batch queues. We are running ALL-IN-1 and the jobs sent to OA$FORMATTER (server queue) were failing left and right after the 5.5 upgrade weekend. Doesn't it report a "record not found" error or something like that? I can't remember if straight PRINT jobs were affected. BTW(2): If users choose to "correct" this situation by adding UAF entries on the queue managing node, the entries do not have to be "usable." All that The DECUServe Journal January, 1993 Page 61 is required is that the queue manager process be able to find a (any) record for the user in its SYSUAF file. You can make them DisUser, no privs, no access, etc., so set up a template account and UAF> COPY it. We had considered going back to the old queue manager, but the performance gains we experienced made the UAF effort WELL worth keeping the new. (Rollinson: v5.5, queueing and multiple uafs) ---------------------------------------------- Some additional info on what we did on Mike's system. 1) Tracked down usernames not on the Queue manager's node. 2) Added all of those usernames regardless of original UIC to a single DISUSERed UIC. The queue manager just wants to see ANY record with the appropriate username. (At least on v5.5...) 3) Started chewing on how we are going to combine UAFs and appropriately change our security scheme. Control Over Scrolling Speed in DECterm? ---------------------------------------- This article is an extract of the DECUServe Workstations conference topic 204. This discussion occurred between March 13, 1992 and April 17, 1992. This article was submitted for publication by Jeff Killeen, DECUServe Contributing Editor. Ed. By Mark Katz, John Burnet, Jack Harvey, Bart Lederman, Eric Husby, Bill Mayhew, Geoff Bryant, Jamie Hanrahan, Duncan Brown, Simon Szeto, Bob Koehler, Bill Wood, Linwood Ferguson, Matt Holdrege, Larry Kilgallen, Keith Chadwick, Patrick Mahan, Gail Walker (Katz) ------ Is there any way to control the scrolling rate in a DECterm window (running V5.5, MOTIF, VS4000 Mod 60)? On my character cell terminal I always used 9600 baud and jump scroll which was just right for most cases. I didn't have to wait a painfully long time for things to display, but I could react fast enough to stop the scrolling with the info I wanted somewhere in the middle of the screen. Now with this workstation, I don't have a serial line to throttle things and this CPU spits stuff out so fast that its off the screen before I can stop it. I know, I can always scroll back and see it but stopping and backing up gets tiring after a while. (Burnet: Probably no easy answer) ---------------------------------- Part of the problem is that X is normally an asynchronous protocol. By the time the DECterm code receives notification of the key-press event, several more lines (possibly a couple dozen more lines) have scrolled by. This can The DECUServe Journal January, 1993 Page 62 also be affected by Ethernet loading, if the particular DECterm isn't running on the same system as the keyboard/mouse/display server. (Harvey: It is a real problem, though) --------------------------------------- I expect smooth scrolling (or even jumpy scrolling) could be emulated but with considerable difficulty with existing hardware. Hence it isn't. It would seem that the developers decided the scroll bar and mouse is an adequate workaround, which in my opinion, is dead wrong. I understand later versions of Windows/Motif have provided a keyboard way to switch window keyboard focus. Has anything been done about a keyboard way of reverse scrolling? Like Prev Screen, for example? That would be a big improvement over the scroll bar, I think. DECterm function is a sore point with me. I have much need of character cell terminals in my work. I wanted a VT420; instead I got a DECstation 3100. The monochrome display is terrific - much better than a VT420 - but it is a terribly poor substitute for a proper terminal. It lives in its box and I have two VT220s on my desk to approximate VT420 capability. (Lederman: I think there is an easy answer.) --------------------------------------------- I agree completely. I am constantly amazed at some of the (in my opinion, very stupid) things DECwindows does. I don't understand why the programmers who implemented this stuff would be willing to use it themselves. The least that should happen is that the window on the local station should stop scrolling immediately, even if the client is still sending data (which can be buffered locally). (Harvey) -------- I think Erik Husby said somewhere here that he seldom if ever uses DECterms. It's my guess that the Windows developers don't use DECterms either, and that the workstation/windows product managers consider DECterms to be a temporary workaround which will disappear when we are all windowized. Erik, what do you think? (Husby: A workstation is much more than a couple of terminals) --------------------------------------------------------------- Since you asked, my feeling is if you want the performance of a traditional terminal, use a traditional terminal. They are not that expensive. One could easily have two or more for the same price as a workstation. I used to be very productive with a VT220 hooked to a terminal server. Between kept subprocesses and the terminal server session switching commands, I could keep very busy. But with my workstation, I am learning to work differently. Now, not only can I keep different sessions going. But I can link them together in ways that are just not possible with a VT220. For instance, I can browse my list of files in FileView. Select one of them, and then have LSE open it. My DECwindows mail knows how to trigger my existing LSE session to edit a message. I can link my mail messages to calendar entries. On and on. The DECUServe Journal January, 1993 Page 63 (Lederman: Can't give up DECterms for a long, long time.) ---------------------------------------------------------- It isn't possible to give up DECterm (though I'm sure the users here would like to). It's the only interface to DCL. Lots of things run as command procedures or batch jobs. DECterm is the only way to get this work done. Also, while development may be done on the workstation, a lot of the "real" work runs on a 3600. The workstation have to SET HOST to the 3600 to do stuff in DCL. So we're stuck with DECterms, and they don't work right. They need to be fixed. P.S.: even if Digital came up with a windowed replacement to DCL, I doubt if anyone here would use it. They have tried FileVue and loathe it intensely. And they are NOT DCL "bigots". They all come from a Macintosh background, and would much rather use a windowed interface, if the utilities are anything less than abominable. (Burnet: X over DECnet may be preferable to CTERM over DECnet) --------------------------------------------------------------- A short side trip here... :-) If you're using CTERM-flavor SET HOST (as opposed to SET HOST/LAT), you may get better results if you scrap that method and instead have the 3600 create a DECterm window directly on the workstation with CREATE/TERMINAL. From the workstation, you can use either SUBMIT/REMOTE or DECnet task-to-task to request the CREATE/TERM/DETACH. (Husby: DECTerm is a terminal emulator, not a terminal) -------------------------------------------------------- My comment about the workstation not being a terminal has not seem to have struck home. DECTerm is a terminal emulator, hence, as in all emulators, will have differences from the real thing. That being that, learn to use the workstation the way it works best. In regards to controling the scrolling rate via XON/XOFF (i.e. Control-S/Control-Q), that is a technique appropriate to a RS232 communication path. It is not appropriate technique on an X communication path. What is appropriate in X is to capture the output in a file or memory like DECterm does, and then use editor like controls to view it. In regards to FileView, I agree, the Macintosh Finder is nicer. However, with a little (and I mean little) bit of work it is possible to make one's life very easy with FileView. (Mayhew: Do you really mean...?) --------------------------------- > [^S/^Q] is not appropriate technique on an X communication path. What is >appropriate in X is to capture the output in a file or memory like DECterm >does, and then use editor like controls to view it. But wait. (Note that I have not yet used one of these beasts yet; I'm happy with VWS for the time being but I do see Father Time's shadow on the wall.) It is often the case that I want to look at the beginning of the output from some program and, based on what I see, decide to let it continue or to abort it. It is often the case that the programs in question will generate The DECUServe Journal January, 1993 Page 64 enough output, or short-enough lines, that relying on the bandwidth of the data link, or the scroll rate of the terminal, is not sufficient; I need to be able to say "stop displaying NOW". I don't mind if some (moderate) amount of additional output piles up in a buffer somewhere, but having to wait for it all to finish and then scrolling back-and-forth is unacceptable. Are you saying that (e.g.) the Hold Screen key, or ^S/^Q, on a VAXstation running DW/Motif essentially has no effect? That's unacceptable from a "terminal emulator". Silly me, I expect it to *emulate* the terminal, including this fundamental behavior of "stop displaying NOW". Am I misreading something, or am I really going to detest switching to the X environment? (Bryant: Scroll bars are the answer) ------------------------------------- DECterm is actually better at this than my VT! Sure the HOLD-SCREEN or the ^Q may be slow, but you get these nifty scroll bars to back with! I find now that when I'm at home I have a harder time since I can't be lazy with the noscroll key and go back with a scroll bar. My Vt100 just won't do that. (Harvey: A Broken UI) ---------------------- >DECterm is a terminal emulator, hence, as in all emulators, will have >differences from the real thing. Yes, but these are serious bad differences. Any decent PC based terminal emulator will emulate far better. >In regards to controlling the scrolling rate via XON/XOFF (i.e. >Control-S/Control-Q), that is a technique appropriate to a RS232 communication >path. It is not appropriate technique on an X communication path. The communication technology is quite beside the point. I have a Hold Screen key on my x-windows keyboard *and it doesn't work!* This is a failure of the User Interface. The ability to use the mouse to scroll back through a couple of hundred lines of text is valuable (and I even use it sometimes) but this is not a substitute for a working Hold Screen key, or even a practical workaround. The two features are quite different. (Hanrahan: DECterms really aren't that bad.) --------------------------------------------- The Hold Screen key *does* work. It's just a little slow. (I'm told that the delay is due more to the "hardware buffering" in smart display devices like GPX and SPX cards than to the DECwindows client/server implementation. Supposedly if you run DECwindows on the old single-bit graphics card (QVSS? something like that) in a Q-bus backplane, even with a 3600 processor dropped in, "hold screen" becomes near-instantaneous. ) I suppose that "hold screen" could compensate for the speed of the display hardware and automatically "back up" the display to compensate. However.... The DECUServe Journal January, 1993 Page 65 Frankly, I hear the echoes here of many, many old arguments. For example, programmers who were used to working on ASR-33 teletypes and on their 30 cps counterparts (thermal printing terminals, daisywheel printing terminals, etc.) complained, when CRTs came in, that they couldn't see as much "history" of their session as they were used to. And make no mistake, they were *right*. What happened? Two things. One, our work habits changed. Two, we got different tools -- screen-based text editors, for example. With the new tools and new work habits it turned out that we didn't *need* to see that much of "past history" at once. And lo and behold, the new terminals were more useful than the old ones. The same applies here. The fact that "hold screen" doesn't work *quite* fast enough to be useful is (imho) far overshadowed by : You can now have a 48 line by 132 col terminal. Or larger! And many of the size increases do not require a condensed type font. You can have FOUR 24 x 80 terminals without overlapping them! (At least you could before Motif came along) You can use the mouse to cut and paste between windows. e.g., do a DIRECTORY in one window. Want to edit a file that you see there? Does it have a huge, long directory spec and file name? No problem. Either in that window or another, type EDIT and then "pick up" the directory-and-device spec from the directory header, and then the file name from the directory listing. Almost as good as FileView might be if I ever get used to using it. Displays happen MUCH faster. In fact I'm not sure that part of the "problem" with "hold screen latency" wouldn't go away if the display was loafing along at the ~480 char/sec or so you would typically get out of a VT100. You can trivially scroll back to display a previous screen -- or even save a whole screen to a file. (Don't want to save in Postscript form? Go to another window and type CREATE SAVESCREEN.TXT at the DCL prompt. Go back to first window, use the mouse to select the part or all of a display (there's a SELECT ALL under the Edit pulldown if you want everything), go to second window, paste, type ^Z.) Note to DEC: There really oughtta be a menu option for this. Sun has it! And you should have the option of retaining display attributes like bold, reverse video, etc.) And all of that is without using any new tools like FileView. Personaly I'm just not used to FileView yet, but I do (finally) use the 'more' that Don Roberts put up here, and that has made life a WHOLE lot simpler. If you get in the habit of typing 'more' instead of 'type', you may come to never use your hold screen key... or miss it. OTOH, if you *really* miss "hold screen", try setting your DECterm to 48 lines. I then find the "hold screen" to be quite fast enough; that is, the 24 lines I "wanted to see" are still on the screen by the time it stops. Bottom line: Yes, DECterms are different from real CRT terminals. And, yes, some of those differences will require us to adopt some new work habits and some new tools before we will stop missing some of the old functionality. But that's nothing new; it's been going on since the dawn of technology. You might as well complain that your buggy whip isn't very useful on your car! And once the new tools become part of your work habits, I promise you that a few DECterms on your workstation screen will be much handier than a bunch of *real* terminals.* Besides, you don't have to have space on your desk for all those CRTs... and all those keyboards! The DECUServe Journal January, 1993 Page 66 But if you really have no use for that workstation that's still sitting its box, why don't you throw it away? Just give me a bit of advance notice. I promise you, it'll never hit the ground. *Unless, of course, you really need to make a hardwired RS232 connection to something without going through your workstation's CPU and Kermit or whatever! (Harvey: Maybe we are broke...) -------------------------------- >The Hold Screen key *does* work. It's just a little slow. On my DECstation 3100, the time it takes to work is apparently infinite. I have never seen it work. The DECterm also doesn't understand about most of the LK201 upper row function keys - F10 for example. I have to use CTRL Z. >But if you really have no use for that workstation that's still sitting its >box, why don't you throw it away? Just give me a bit of advance notice. I >promise you, it'll never hit the ground. I tried to get rid of it several ways - the boxes are big and clutter up my office. My boss won't let me. Sorry. Jamie, you make a good point that workstations do represent major technology improvements, and I agree - I wish I could use the large screen capability of the one I have. The broke DECterm prevents it, however. There is just too much wrong. I guess your TPU/EVE/EDT is broke too, since you still use EDT.EXE. :-) (Brown: But don't investigate this- just send me the DECstation...) -------------------------------------------------------------------- >On my DECstation 3100, the time it takes to work is apparently infinite. I >have never seen it work. The DECterm also doesn't understand about most of >the LK201 upper row function keys - F10 for example. I have to use CTRL Z. I've never seen a DECstation, but it sure sounds like your DECterm is acting as a VT100 emulator! Is it possible there's a setting somewhere that needs to be tweaked? Or maybe the Unix DECterms aren't as nice as the VMS DECterms....? (Hanrahan) ---------- >On my DECstation 3100, the time it takes to work is apparently infinite. I >have never seen it work. The DECterm also doesn't understand about most of >the LK201 upper row function keys - F10 for example. I have to use CTRL Z. Do you mean DECstation or VAXstation? And, yes, F10 works for ctrl-Z here (VAXstation). The upper row function keys are supposed to be programmable, just like on a real VT(>220). If all else fails you could set them up yourself... >I guess your TPU/EVE/EDT is broke too, since you still use EDT.EXE. :-) Yes, I still use EDT.EXE, for reasons I explained elsewhere. And this is more of the same thing -- sluggishness to adapt to new tools. The DECUServe Journal January, 1993 Page 67 I know that TPU/EVE with EDT keypad would give me lots of things I don't have now, like support for those 48-line DECterms, not to mention CALLability (my EDT is customized in ways that require it to be invoked by code of my own, hence I'm using SPAWNed, not CALLable, EDT form NOTES). But, just as i haven't taken the time to get used to FileView, I haven't taken the time to translate my customizations to TPU and to otherwise use EVE. And my fingers are very used to those customizations. I'm far more productive than I could ever be with satandard EDT. (Oh, otoh, it isn't quite the same thing -- I'm not going around saying "TPU/EVE/EDT is broke", just "I haven't had time to switch over". Stop putting words in my fingers.) (Harvey: DECstation) --------------------- >Do you mean DECstation or VAXstation? As in MIPS Ultrix. Maybe my boss is hoping it will turn out to be an Alpha in disguise. :-) I've tweeked everything in sight. Atlanta, who were absolutely tops helping me stumble through getting ULtrix, DECnet, LAT, etc., up and working, seem to think it's doing what it's supposed to do. It's a DECterm. :-} (Szeto: cultural difference in function keys?) ----------------------------------------------- Well, I never had the pleasure (yet) of using a DECstation, but I do believe that F10 and F6 as ^Z and ^Y are VMS-isms. Unless you are displaying back to your DECstation from your VMS system, your DECterm probably doesn't know about F10 and F6. (Mayhew: emulate: to imitate with effort to equal or surpass) -------------------------------------------------------------- I concede Jamie's point; I don't want to be stuck in the horse-and-buggy era forever. What I find annoying though is that my VWS VAXstation gives me all of the attributes Jamie mentioned in .-5 or so, PLUS an instantaneous Hold Screen and ^S (which behave slightly differently from each other, for rational reasons). Moving into the future is only useful if you can drag your customers along with you. In my case, selling workstations or even X terminals to my clients is about as likely as DEC selling me a personal 9000-210. Some day, when the price comes down and I can afford an Alpha that runs as fast as today's 9000-210, I'll buy it. Clients tell me the same thing about workstations and X terminals today. Consequently I am trying to use new tools to maintain and develop "old technology" (character-cell-interface software). If I have to have a separate VT on my desk, then I maintain that DECterm isn't doing its job as an emulator and should be advertised instead as a "DCL window" or some such thing (a VMS-centric definition to be sure but you get the point). BTW the definition in the title is from the Random House Dictionary. The DECUServe Journal January, 1993 Page 68 (Koehler: add a scroll bar) ---------------------------- >On my DECstation 3100, the time it takes to work is apparently infinite. The default setup under ULTRIX does not seem to be as robust as VMS. To start with, you probably need to customize in a vertical scroll bar and save the customization. ULTRIX DECwindows seems to be an effort to prove that a single GUI can be great on one machine and poor on another. I use FileView on my VAX all the time, and with a little customization, I rarely bring up a DECterm. UE on ULTRIX use fairly useless, and I cannot find any customization that allows prompting for data and getting the user's response in a shell variable. (Or am I missing something?) The developers I talked to just shrugged and said they don't use UE. Looks like VMS was easier to do well early. (Gee, wow, big surprise :-)) (Wood: DECterm works just grand here.) --------------------------------------- Thanks Jamie, I was really beginning to wonder what these guys have been talking about. My VAXstation 3100 with monochrome (not grey scale) monitor has never been slow in responding to the Hold Screen key. I do notice that when I run the EWS software (essentially as a DECwindows terminal) served from a DECstation Hold Screen is a bit sluggish. Using SET DISPLAY and CREATE/TERM/WINDOW/DETACHED does better. I also notice that if I use DLOGIN from a DECstation to a VMS machine VMS doesn't know a terminal type until I Set it. Obviously the upper row function keys don't work until VMS knows I am a VT3xx emulation. Maybe the reason I have never spent the time to make a Fileview environment which will work well for me is that DECterms are working so well. (It may also be because I keep 13 DECterms active on 9 nodes across 3 clusters and I don't know where to begin customizing Fileview to support me.) (Burnet: Ultrix 4.2 DECterm is flaky -- use the VMS one instead) ----------------------------------------------------------------- Jack, there may be a very simple solution, *if* what you want is one or more DECterm windows giving you access to one or more VMS systems. Yes, the Ultrix DECterm is busted in many ways, but that should only affect you if you want to use Ultrix. If you want to use VMS, *don't use the Ultrix DECterm* except to start up VMS DECterms (via dlogin or rsh or DECnet task-to-task or whatever other method you prefer). On the VMS system of your choice, just type $ create/terminal/display=node::0 to get your very own VMS DECterm, displaying on your Ultrix DECstation. You will need to use "session manager -- customize -- security" to allow access to the X server from the VMS node and username that you will be using. In the CREATE/TERM command, you can also specify the window title and icon name. The DECUServe Journal January, 1993 Page 69 (Burnet: CREATE/TERM/DETACH) ----------------------------- Sorry, I forgot to add /DETACH. Also, it's best to set up some easy way of executing the command remotely so that you don't even have to dlogin to the VMS system. I'm being intentionally vague here -- although I've done this for VMS-to-VMS connections, I haven't yet got around to doing it for our few Ultrix workstations. rsh or its DECnet-Ultrix equivalent, if any, might do what you want. (Harvey: Hey, maybe I can get rid of my twin VT220s!) ------------------------------------------------------ >Jack, there may be a very simple solution, *if* what you want is one or more >DECterm windows giving you access to one or more VMS systems. Bingo! I'll drag the blamed thing out and try your suggestions. Who knows? Maybe I'll end up with the world's most expensive X-term. >Yes, the Ultrix DECterm is busted in many ways, but that should only affect >you if you want to use Ultrix. ^^^^^^^^^^^^^^^^^^^^^^^^^ Bite your tongue! Why would anyone who knows VMS want to do that? :-) Anyway, thanks, John, for the confirmation that it has problems. (Burnet: OK, so I was wrong... there *is* an easy answer :-) ) --------------------------------------------------------------- Back to the scrolling-speed problem... I just happened to be browsing through the DECwindows Motif user's manual, and I ran across this gem in Appendix E: There is a DECterm resource (under Decw$terminal.Main.Terminal) called syncFrequency that can be changed in DECW$XDEFAULTS.DAT and that "Specifies the number of lines scrolled before DECterm synchronizes with the server. This number limits the rate of scrolling. The higher the number, the faster DECterm scrolls. The default is 10." (Husby: X seems to have more resources than VMS has sysgen parameters!) ------------------------------------------------------------------------ >OK, so I was wrong... there *is* an easy answer :-) Glad that you were able to gain control of your DECterm (I've recently switched jobs and the new one is not quite up to Motif yet so I don't have access to the new manuals). I was also pleased to see my opinions generate a little discussion. The DECUServe Journal January, 1993 Page 70 (Ferguson: Possibilities) -------------------------- >$ create/terminal/detach/display=node::JACK >%NONAME-E-NOMSG, Message number 02DBC002 That message is "Can't open display". Were you logged in to node at the time? If not, you need separate security settings (DECW$SERVER_ACCESS_ALLOWED.DAT in SYS$MANAGER). Also, I'm not familiar with the format "node::JACK". What I had been doing is: set display /create/node=node create term/detach I can't say the SET DISPLAY is needed, but it works when I used it. I don't know what to use for "node::JACK" to make it work that way. (Burnet: Node/server/screen specifiers) ---------------------------------------- The format of a display name (using DECnet) is node::server.screen -- for example, FOO::0.1 to specify the second screen of the first server on node FOO. On single-screen systems, the server and screen area always 0.0, which is the default. So "node::JACK" is incorrect (I presume that JACK is the username?) -- try "node::0" instead. FWIW, "set display/create" followed by "create/term" (without a /DISPLAY qualifier) is equivalent to "create/term/display", all other things (node, server, screen, and transport) being equal. (Harvey: I'm in over my head) ------------------------------ First some explanation. Linwood was responding to a note I deleted out from under him. I realized what one major mistake was and tried to hide my goof by deleting the stupid note. I should know better. This was *exactly* my command. The nodename is JACK. |-} > $ create/terminal/detach/display=node::JACK So I went back and tried: $ create/terminal/detach/display=JACK::0 where JACK is the nodename of the VMS workstation. This didn't work either, and I can't reproduce what happened the first time I tried it. I got a message about an invalid logical name, DWS$?. Now it just hangs and never completes. I broke it. > %NONAME-E-NOMSG, Message number 02DBC002 > That message is "Can't open display". How did you get the message text? My host system and the workstation can't translate 02dbc002. Maybe something is missing here. $ create/terminal/detach/display=JACK::0 The DECUServe Journal January, 1993 Page 71 This command now just hangs forever on both the host and the workstation. (Still pure VMS - no Ultrix yet.) (Ferguson: 5.4-3? Need 0.0) ----------------------------- What VMS? I just noticed in 5.4-3 there is a note in the release notes that you must include the screen number (i.e. jack::0.0). I tried the above (though substituted LEF for JACK) and it worked (above = 0.0 on 5.4-2). >How did you get the message text? My host system and the workstation can't >translate 02dbc002. Maybe something is missing here. I use this wonderful routine someone posted on DECUServe to look at all the message files. Since I can't find it right now, here it is (it's short). Do @MESSAGE <hex-string> $ set noon $ on control_y then goto exit $ file = "<default>" $ goto middle $ $loop: $ file = f$search("sys$message:*.exe") $ if file.eqs."" then exit $ set message/noid/notext/nofac/nosev $ set message 'file' $ stat = $status $ set message/id/text/fac/sev $ if .not. stat then goto loop $ $middle: $ x = f$message(%x'p1') $ y = f$element(0,",",f$element(2,"-",x)) $ if y.eqs."NOMSG" then goto loop $ write sys$output file $ write sys$output x $ $exit: $ set message/id/text/fac/sev $ exit (Holdrege: Try from a DECwindows node) --------------------------------------- I get the invalid logical name and the NONAME error message when I try the CREATE/TERM command from a non-DECwindows node. (a node that does not have decwindows started and the decwindow logicals defined.) Are you sure you are trying this from a node with DECwindows FULLY enabled? (Harvey: Progress!) -------------------- This is what I think the situation is. I have two VMS 5.4-2 nodes, let's call them HOST and JACK. They are LAVC clustered and DECnetted. HOST is a The DECUServe Journal January, 1993 Page 72 4000-200, no graphics device, and probably did *not* have DECwindows enabled, but does now. JACK is a VS3100 with a display, and is running DECwindows. I'm not sure about *anything* in this area, but I think I've stumbled on how to do this. Doing: $ create/terminal/detach/display=JACK::0 !on HOST produces a hang. The "hung" process is logged in via a terminal server. Node name JACK, username HARVEY (me), under DECwindows, is where I did the session manager -- security stuff. However, Linwood provided the clue: $ create/terminal/detach/display=JACK::0.0 !on HOST works, *provided* username HARVEY is logged into a window session on JACK. That isn't immediately obvious, until it becomes obvious. :-) Now I'm off to find a piece of RG58 to splice in so I can connect the Ultrix beast in my office. That's something I know how to do! (Harvey: DECUServe Does It Again!) ----------------------------------- Hey, I'm logged in via a GOOD VMS DECterm running on the worlds most expensive X-terminal - the DECstation 3100 on my desk. Now we know what these things are good for. VAXstation 2000 replacements. :-) The function keys all seem to work, including Hold Screen. What a pleasure! Thanks to all, many, many thanks. (Ferguson: More off-topic stuff on creating DECterms) ------------------------------------------------------ The security settings you said you changed are YOUR security settings, and apply only while you are logged in. The default security settings (which apply when noone is logged in) do not allow the random user to display things on the workstation (i.e. Joe in the other room can't put up a login-like screen). The file DECW$SERVER_ACCESS_ALLOWED.DAT in SYS$MANAGER can be used to allow access when noone is logged in. I keep mine with: * * * Which means from all nodes, all users, all transports (not sure which * is which actually). DOING SO IS A SECURITY RISK, but simplifies mucking around with putting things up on different displays when noone is logged in. I haven't tried this explicitly with a Decterm, but it applies to the login screen. BTW, I'm not sure what you're trying to do, but it sounds like you might want to do what I do with my 4000-200. I go into my VaxStation and STOP/ID the loginout process, then go to the 4000-200 and do: SET DISPLAY/CREATE/EXEC/NODE=vaxstation R SYS$SYSTEM:DECW$STARTLOGIN This puts up a new login screen (it went away when I STOP'd the other process) but running from the 4000. You can then log in, and all sessions and everything else are running from the 4000, but displayed on the workstation. The DECUServe Journal January, 1993 Page 73 (Harvey: On to the next problem) --------------------------------- Yeah, I'm going to get around to fooling with the scrolling speed and report results here. In the meantime, my purpose for this exercise was two replace my twin VT220s with a single machine. I haven't done that, because (and I know I didn't tell you people this) one of the VTs was being my debugger DBG$INPUT and DBG$OUTPUT. That terminal must be logged out so the debugger can use it for terminal I/O. (I'm working on screen forms, and I *hate* to debug the software drive the form on the same terminal that is displaying the debugger.) So, moderators, where should I ask about solving this problem? I.e., how do I get DBG$INPUT and DBG$OUTPUT to another window on my workstation? I've still got one VT220 too many. (Brown: Try it- I think it can do what you want...?) ----------------------------------------------------- I'm a DECWindows neophyte, but the one time I fired up the native DECwindows debugger, it sure looked like it could do all you want and more! (Separate windows for each of the debugger functions). I think you're going to like this X stuff once you use it for a while! (Burnet: You can do it even with the CCT debugger interface) ------------------------------------------------------------- [The previous reply] is probably right -- the DECwindows flavor of the VMS debugger will do what you want. However, if you want to stick with the tried-and-true VT interface (line mode or screen mode), you can do that too. Just use CREATE/TERMINAL/NOPROCESS, which will create the terminal window on your screen but will not associate a process with it or log it in. I recommend using the /DEFINE_LOGICAL qualifier as well, so that you never have to mess with WSAn: or FTAn: physical device names (or TWAn:, if you're using DECwindows V2). Then you can define DBG$INPUT and DGB$OUTPUT to point to that window. You can even create two windows and use one for input and one for output if you want. This is in addition to your previously-existing logged-in DECterm windows, of course. Ain't life fun when everything's virtual? 8-} (Burnet: Expensive, but a *great* X terminal!) ----------------------------------------------- Jack, I just wanted to point out that the DECstation itself doesn't have to be completely wasted, even if you hate Ultrix. You can use it to run clients locally that don't have to run on VMS. This might amount to a small fraction of what you use every day, but at least the clock and calculator and puzzle and stuff won't take up memory on your VAX systems or consume network bandwidth. CPU-bound programs will probably run much faster on the DECstation anyway. :-P (Harvey: /NOPROCESS, of course!) --------------------------------- >DECwindows debugger, it sure looked like it could do all you want and more! >(Separate windows for each of the debugger functions). I think you're going >to like this X stuff once you use it for a while! The DECUServe Journal January, 1993 Page 74 DECwindows debugger? Canon violation! It's too full of mice and bugs. I've done quite a bit of X stuff, using and writing, and I hate it. I like software that returns error messages when I screw up, instead of just ignoring me. Anyway, thanks for the tips, John, I'll probably get this all cleaned up by tomorrow. I like using the tried-and-true debugger in a big window, by the way. It knows what to do with it. The big breakthrough for me here, is learning that I can get a real VMS DECterm on the MIPS box. This is amazingly *faster* than the Ultrix DECterm, too. (Harvey: Off and running) -------------------------- I sent the following this morning on my work system: From: nnn::HARVEY "Jack Harvey" 20-MAR-1992 08:46:37.71 To: xxx Subj: You had your chance, and you blew it! My DECstation 3100 workstation is no longer available for sale or for reassignment elsewhere. My friends on DECUServe showed me how to use it as a VMS workstation. It is now a superior X-terminal, and considerably better than a VT420. ~~~~ I'm still having lots of beginner problems with this, but they are things that Digital telephone support can handle. So I won't need to bother the experts here anymore. Again, thanks. (Kilgallen) ----------- Let's see, if expert advice costs $60 per year, then TSC must be cheap :-). (Harvey) -------- Nice thought, Larry, but Xcom knows the truth. The $60 per year is silly nonsense. The true cost of getting the benefit of all this expertise is far higher. First, there is the communication cost, which can run up around one or two grand a year for someone who really digs in here and uses all the available goodies. Second, there is the cost of the member's own time. People reading DECUServe conferences are not *simultaneously* solving immediate problems for their boss. In my particular case, I was greeted this afternoon by a smiling vice president joking about my sudden protective behavior towards the X-terminal (a.k.a. DECstation 3100) I was trying to get him to get rid of, but which is now proudly occupying the seat of honor on the typing-table side-arm of my desk. I've got some mechanical fiddling to do to get this dressed up to my satisfaction, but that will happen. With a hole here and there, the thick pizza box MIPS cpu in the DECstation 3100 will be under my desk and I will be able to get this gorgeous monochrome very high resolution (sorry for you poor suckers with color) display down to where Jack thinks it should be. I've got The DECUServe Journal January, 1993 Page 75 a VT4200, at least! I have 52 lines when I read VAX Notes, and I'm being conservative! *Two* clean classic VT220s are available for disposition to many needy desks. (Yes, I've got the debugger running reliably [I hope] in one {or two} windows.) I still have to battle the stupid mouse technology, but there is hope. I'll try a track-ball, and who knows? Maybe X-windows will grow up. (Harvey: Aye of Newt...) ------------------------- >I'm still having lots of beginner problems with this, but they are things >that Digital telephone support can handle. Okay, I was right about this. I'm trying to make this point in BUSINESS_PRACTICES also. Digital Telephone Support is tuned for dummies, (like me in this case) and you general-purpose DECUS wizards just shouldn't be allowed to complain (Jack's rule) if Telephone Support can't answer wizard-level questions. I had some real sillies: why does an attempt to save the session attributes fail on permission? Answer: I'm a campus wheel at this site. Real Answer? The DECstation 3100 trying to save session setup parameters into a file in my SYS$LOGIN: can only use the owner authority on SYS$LOGIN:. I didn't own my own SYS$LOGIN. My having bypass didn't solve this (entirely correctly, from a Security viewpoint) so rewrite of the options file into my directory failed properly. By correcting the ownership, suggested by Atlanta, the problem is solved. Second dumb problem. I wanted a 52 line DECterm. I fiddled with the create/TERM command (/window_attributes=rows=52) and with the default file and got exactly the same: I would get a 52 line window, which then after a few seconds shrank to 24 lines. Dumb explanation suggested by Atlanta: I had a SET TERM/INQUIRE in my LOGIN.COM. It looked at the DECterm, saw it was a VT320, and set the page to 24 lines. My window box clamped down to therefore 24 lines. !Comment out the SET TERM/INQUIRE in my LOGIN.COM and Atlanta wins again. (This guy was good.) Now, you people don't want to be bothered with that level of nonsense, right? THAT'S the level of nonsense we pay Digital to support, and rightly so, because there are far more dummies like me than there are wizards like you. But wait. Can you imagine Digital telephone support people, no matter how skilled they are, being able to handle a complaint along the lines of: "I think the DECstation 3100 stinks and I am trying to get my management to get it out of my office. Aren't they silly for not doing this?" Yet, this is pretty much what I gave this conference as a problem, not even knowing it myself. DECUServe people were able to see underneath my frustration and reveal the truly creative solution: turn my DECstation (MIPS) into a super X-terminal, thereby benefiting everybody involved. This is the magic of DECUServe. Larry, we can't put a price on magic. Well, maybe we could, but none of us would be able to afford it. Let's just rejoice that it's here. The DECUServe Journal January, 1993 Page 76 (Ferguson: DEC should refund money if I am "not allowed") ---------------------------------------------------------- I'll stop complaining as soon as they provide support for what you (not me) call "wizard level questions". Some of the questions I ask that they cannot answer , I think, do not fall in that category, but let your definition stand. WHY SHOULD DEC NOT BE ABLE TO ADDRESS THIS AUDIENCE. WHY SHOULD I NOT BE ALLOWED TO COMPLAIN, since DEC does not complain about accepting "wizard level" money? But [token effort to try to stay on topic], Jack, I'm glad you summarized the problems here because now the next person will be able to get their solution from DECUServe and never have to bother CSC. (Burnet: Not quite infinitely customizable, but almost...) ----------------------------------------------------------- >I've got a VT4200, at least! I have 52 lines when I read VAX Notes, and I'm >being conservative! Are you using the DECwindows interface, or just Notes in a DECterm? Try the DW interface -- you'll like it. For local conferences, I mean -- I don't think you can get it to work for DECUServe connections over a serial line. :-( The same goes for VMS Mail: you might prefer the DW interface to just running Mail in a DECterm. >I still have to battle the stupid mouse technology, but there is hope. I'll >try a track-ball, and who knows? Maybe X-windows will grow up. Two thoughts about that: First, I assume that your DS3100 has the old VSXXX-AA "corporate mouse" (round). If you don't like it, get one of the newer models (can't remember the model number, but I think it just has a different suffix). You might like the new design better. Both mice are made by Logitech, but the new one is the standard new Logitech ergonomic design that's more comfortable to use. Second, remember that Motif has key bindings for most window and menu actions. Take a look at Appendix A of the VMS DECwindows Motif User's Guide. Motif is available for Ultrix too. (Harvey: Key driven window hopping) ------------------------------------ Motif is what I need to be able to use a key to move the keyboard focus between windows, right? >Motif is available for Ultrix too. Does this mean I need to install Motif on *both* the VMS system and my Ultrix X-terminal? (Burnet: Motifying your DECwindows is recommended) --------------------------------------------------- >Motif is what I need to be able to use a key to move the keyboard focus >between windows, right? Yep. The DECUServe Journal January, 1993 Page 77 >Does this mean I need to install Motif on *both* the VMS system and my Ultrix >X-terminal? I don't think so, although it depends on what version of DECwindows (and thus what version of Ultrix) you're running on the DECstation. Motif requires an X11R4-compliant server. I don't know whether the Ultrix 4.2 DECwindows (DECwindows V2?) server is R4-compliant... can someone else here say whether this is the case? There are discussions in USER_INTERFACES-WINDOWS about mixing DECwindows V2 and V3 (pre-Motif and Motif). For ordering information for Ultrix Motif, see topic 135 in the UNIX_OS conference. If you have Ultrix 4.2A (or maybe 4.2 is good enough), you don't need a license, just the H-kit. (Kilgallen: Why I haven't considered DECwindows interfaces) ------------------------------------------------------------ > Are you using the DECwindows interface, or just Notes in a DECterm? Have either of these products fixed previous problems requiring that editors be spawned (editors which can be called in a normal process)? (Burnet: Don't know, myself... anyone?) ---------------------------------------- (Chadwick: VSXXX-GA) --------------------- >old VSXXX-AA "corporate mouse" (round). If you don't like it, get The new mouse part number is VSXXX-GA. (Holdrege: Irish mice) ----------------------- Are you sure the mice are from Logitech? They are made in Ireland and they don't say Logitech anywhere on them. I realize Logitech could have OEM'd them for Digital, but I didn't think they were in Ireland. (Mahan: Give it a try!) ------------------------ >Does this mean I need to install Motif on *both* the VMS system and my >Ultrix X-terminal? Depends. Chances are the X window server that is running under Ultrix is X11R4. If it is still at X11R3, then there are some problems when running an X11R4 client to an X11R3 server. Most of these problems are due to ICCCM non-conformance. The DECUServe Journal January, 1993 Page 78 (Szeto) ------- > Are you sure the mice are from Logitech? They are made in Ireland and I don't know any more than you do about this, so ignore my place of employment. Could it be that only the design was Logitech's? (Szeto: That's no editor; that's the text widget) -------------------------------------------------- >Have either of these products fixed previous problems requiring that >editors be spawned (editors which can be called in a normal process)? No, Larry, they both use the Text Widget still. I understand that some part of the NAS architecture would make it possible for these two applications to call the editor of the user's choice, but I don't think that either DECwindows Motif Mail or VAX Notes V2.2 supports it. By the way, if you do use the Text Widget instead of doing your editing in another window that has your favorite editor, I suggest you turn off auto-wrap. (No, I haven't followed my own advice; I'm also not a heavy user of DECwindows Mail, except for reading and short replies, and I seldom use DECwindows Notes.) (Brown: Even DEC says it's a Logitech) --------------------------------------- >Are you sure the mice are from Logitech? They are made in Ireland and they >don't say Logitech anywhere on them. I realize Logitech could have We wondered about that- we compared it to a Logitech mouse we have and they appear IDENTICAL...yet it doesn't say Logitech anywhere on it. But if you look in the docs- I believe it's the packing list- it says "Logitech mouse" !! DEC may indeed make it (using Logitech's design, if not also tooling), since it has the previous-DEC-mouse-compatible connector on it. (Harvey: SHOW SERVER) ---------------------- >Depends. Chances are the X window server that is running under Ultrix is >X11R4. Any idea how to determine if I have X11R4? I've got the full Ultrix doc set unstashed on a shelf behind me, but I haven't a clue where to look. (Mahan: Some solutions that should help) ----------------------------------------- Jack, I believe you will need to load the unsupported tape that came with the Ultirx OS. This contains a lot of X applications, most notably, "xdpyinfo" (quotes are mine). If that is not a possiblity, then check for the server log on the Ultrix box (not sure exactly where they are). Basically, if it says something about Motif or bug compatiblity mode, the X server is at X11R4. Failing all the above, I will post the X11R4 xdpyinfo here and you can make a stab at building on the Ultrix, or go ahead and load DECwindows/Motif and you can build it under VMS. The DECUServe Journal January, 1993 Page 79 If you do use "xdpyinfo" the basic rule of thumb is that if it reports anything about X Server extensions, then it is an X11R4 server. (Harvey: X11R4 xdpyinfo) ------------------------- I have checked my Ultrix node and find no mention of xdpyinfo in the unsupported section of the doc set. I'll also look for the other indications you mentioned, and try Atlanta. I don't want to try altering the node at this time, so no need to post for me. At any rate, my "workstation" has now become a real workstation; both VT220s are shelved, the classic debugger window (but 50 lines) is great. I'll be summarizing what I needed to do to get it all going shortly. (Walker: xdpyinfo results on Ultrix 4.2) ----------------------------------------- I have xdpyinfo in /usr/bin/X11, I'm pretty sure it came off the unsupported tape. When I run it I do get information about 8 extensions so I guess it is based on X11R4. I'm running Ultrix 4.2 on a DECstation 5000 model 120. (Husby: Why do you need to spawn?) ----------------------------------- >Have either of these products fixed previous problems requiring that >editors be spawned (editors which can be called in a normal process)? But with a X based system, why do you need to spawn an editor. My editor is always running, so I simply switch to it and edit a way. One can either write a file or cut/paste to get into Notes or Mail. Note, that you can have TECO running in a DECterm window and use the DECterm cut/paste capablities. (Kilgallen) ----------- I want the editor to automatically start up with the text in it (and the quotation margin inserted) when I do something simple in the communications tool. (Harvey: DECterm 3100 Hold Key) -------------------------------- My DECstation 3100 serving as an "X-terminal" for VMS DECterms is working out very well. As reported earlier, the Ultrix version of DECterms apparently has no support for the Hold Screen key, but a VMS originated DECterm does. However, there is an anomaly which once understood is no big problem. In this setup, the Hold Screen key (F1) is a repeater. That is, if you hold the key down, the Hold Screen LED on the LK201 keyboard rapidly cycles on and off. Until I understood this, I was getting some *very* strange behavior. The time interval for holding it down before the Hold state starts cycling on and off is pretty short - maybe 100 milliseconds. If the current state is hold, and you press the key to release the screen, but forget to release it quickly, the screen advances a few lines and the hold state comes back on. Weird, until understood. The DECUServe Journal January, 1993 Page 80 I haven't found a use for this yet - I expect it was done on purpose - but once I learned to just tap the key quickly, the behavior seems to be fine. :-) Oh, yes, I guess I have the only terminal that needs disk backups. :-} (Katz: Thanks for scrolling slowdown help) ------------------------------------------- Interesting thread started by my "simple" question. I haven't had a chance to try out the solution John presented in .24, but I think that is what I need. Right now, my WS has been taken off it's own system disk and is using a system disk off on an HSC elsewhere in the cluster (A5.5 vs. V5.5 issue), so the network slows things down enought that it isn't as much of a problem. Once I can run on my own again, I'll try it out. (Harvey: Command File for DECterms) ------------------------------------ Early we had some chat about /DISPLAY=<nodename>::0 vs. /DISPLAY=<nodename>::0.0 Linwood, I think, reported the second form [0.0] as a new syntax, and I said it was required. I lied. The old form works too. For someone needed a working example, here is the command file I execute when I dlogin to VMS from my RISC workstation. RISC is also the DECnet nodename. $ !DECterm.com create three named DECterms on RISC $ create/terminal/detached/display=RISC::0/window_attributes=( - x_position=100,y_position=10, - rows=48, - title="Debug Top1",icon_name="Debug Top1",initial=icon) $ create/terminal/detached/display=RISC::0/window_attributes=( - x_position=200,y_position=20, - rows=24, - title="Top2",icon_name="Top2",initial=icon) $ create/terminal/detached/display=RISC::0/window_attributes=( - x_position=300,y_position=30, - rows=52, - title="Modem",icon_name="Modem",initial=icon) (Harvey: Debugger in DECterm Window) ------------------------------------- This is the command file I execute to creat a window on RISC that will be used by the VMS debugger. $ create/terminal/display=risc::0/detach/noprocess - /window=(rows=50,title=debug,icon_name=debug,init=icon, - x_position=300,y_position=60) - /define_logical=(debugit) $ allocate debugit $define/nolog dbg$output debugit: $define/nolog dbg$input debugit: The DECUServe Journal January, 1993 Page 81 (Burnet: node::server.screen (for DECnet & LAT transports, anyway) ) --------------------------------------------------------------------- >Linwood, I think, reported the second form [0.0] as a new syntax, and I said >it was required. I lied. The old form works too. The first number (before the dot) is the server number, and the second is the screen number. The screen number should always default to zero if it's omitted, so "foo::0" should be equivalent to "foo::0.0". You would only need to be concerned about the screen number if you were working with a two- (or more-) headed display, where one server controls more than one screen. (Ferguson: Bug) ---------------- Actually, it was that I had read somewhere (some release notes, but I cannot find it now) that for some version(s) of VMS and/or DECwindows and/or Motif the ".x" part was required due to a bug (or restriction or some such). That I cannot find it now may mean this happened in one of those dream worlds, of course. The DECUServe Journal January, 1993 Page 82 The DECUServe Journal - Technical Information ============================================= Publication Information ----------------------- Topic threads in the DECUServe VAXNotes conferences are selected for publication on the basis of strong technical content and/or interest to a wide audience. They are submitted to the editor by a team of Contributing Editors who are DECUServe Moderators, Executive Committee members and other volunteers. Articles in the DECUServe Journal are downloaded to a 286 PC and formatted using a standard text editor. Editorial Content Disclaimer ---------------------------- Opinions and information presented here belong to each individual author. No inferences should be made that the authors are expressing the policies of their employers unless specifically stated. Content has been deemed acceptable by the Moderators of DECUServe according to the DECUServe Canons of Conduct. How can I use DECUServe? ------------------------ DECUServe is available 24 hours a day, 7 days a week, except for Fridays between the hours of 7am to 9am Eastern time for backups. Membership is by individual subscription only, and subscriptions are sold on a yearly basis currently for $75.00. Subscription forms are always included in DECUS New Member packets and Symposia registration packets. Free six-month subscription forms are often distributed at symposia as well. Also subscription forms can be downloaded directly from DECUServe by dialing 1-800-521-8950 with the username INFORMATION. Set your modem to 2400 or 9600, no stop bits, 8 bits, 1 parity bit. Other access modes are Tymnet, PC pursuit, and Internet.