CHAPTER VAX PAGESWAPPER - November 1987 - Volume 9 Number 4 Undocumented System Space Watchpoint Utility . . VAX-3 Editor's Workfile . . . . . . . . . . . . . . . VAX-7 Migration to MicroVMS from DEC Operating Systems VAX-8 Online Security Monitoring System . . . . . . VAX-25 VAX/VMS System Performance Management . . . . VAX-35 Converting Code for Parallel Processing . . . VAX-48 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-62 VAX System SIG Committee List . . . . . . . . VAX-117 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-122 System Improvement Request Submission Form . . VAX-124 PAGESWAPPER - November 1987 - Volume 9 Number 4 To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. Articles for publication in the Pageswapper can be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters and the number of text lines per page should not exceed 48 (these limits are particularly important for sample commands, etc. where simple text justification will not produce a meaningful result). Please do not submit program source, as that is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations (or other meetings) as they are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides to get the content across to a wider audience than is able to attend. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - November 1987 - Volume 9 Number 4 Undocumented System Space Watchpoint Utility Undocumented System Space Watchpoint Utility Lee K. Gleason Principal, Control-G Consultants 2416 Branard D Houston TX 77098 I received my VMS 4.6 kit yesterday, and immediately copied it to a disk, to look for new features. I noticed a new driver in SYS$SYSTEM - WPDRIVER.EXE, and along with it, WP.EXE. My first guess was that it was related to Word Processing. A little study showed that this guess was all wrong. It turned out to be a driver for a "software" device, like NOA0 or SWA0 - a device driver that has no physical device associated with it, but exists to provide a convenient QIO oriented interface to some complicated bit of internal trickery. The WP driver implements a system space watchpoint utility. QIOs directed to it (by its command interface utility, WP.EXE) cause it to monitor and log changes to specified locations in S0 space. I did some more looking, and found the details of its operation in SYS$HELP:WP.HLB and WP.HLP. To enable use of WP, first load the driver and create a unit. $ MCR SYSGEN SYSGEN>CONNECT WPA0:/NOADAPTER SYSGEN>EXIT $ To enter WP commands, run the command interpreter... $ RUN SYS$SYSTEM:WP.EXE Once in WP, the command syntax is as follows. The WATCH command sets up a watch point WATCH watch_addr address to watch /BYTE watch a byte sized field /WORD word /LONG long (the default) /QUAD quad VAX-3 PAGESWAPPER - November 1987 - Volume 9 Number 4 Undocumented System Space Watchpoint Utility /SILENT take no extreme action on watch (default) /XDELTA enter XDELTA on watch /FATAL do a BUGCHECK on watch The SHOW command shows information about a watch point SHOW watch_addr address being watched /CONTROL_BLOCK show watchpoint control block (default) /TRACE_TABLE show watchpoint trace table /FULL show everything The SET command controls logging of output to a file, WP.LOG SET /LOG write output to log file and terminal /NOLOG close log file The IGNORE command cancels a watch point IGNORE watch_addr addr of watch point to cancel The EXIT command does what you would guess - returns you to DCL. Control-Z will do the same thing. To get a feel for this, I needed a location in system space that I knew would change often enough to be interesting. The answer was no further away than my copy of "VAX/VMS Internals and Data Structures" (and let me assure you, it is never very far away). A look through it suggested something that would change on a pretty regular basis - the entries in the Timer Queue. The Timer Queue has a listhead that would change as Timer Queue Elements are added and deleted at the head of the list. I used ANALYZE/SYSTEM to get the address of the listhead. $ ANALYZE/SYS VAX/VMS System analyzer SDA>EVALUATE EXE$GL_TQFL Hex = 80002B58 Decimal = -2147472552 EXE$GL_TQFL And then used that value to set a watch point with WP. $ run sys$system:wp.exe Watch Point Utility Version X-1N2 WP> WATCH 80002B58 VAX-4 PAGESWAPPER - November 1987 - Volume 9 Number 4 Undocumented System Space Watchpoint Utility I waited a few minutes, to let a few TQEs pass into history, and then did a SHOW on that watchpoint. WP> SHOW/FULL 80002B58 Base Address = 80002B58 Length = 04 Address Touched = 80002B58 Type = SILENT Time Touched = 03:33:19.60 Touched Count = 00000509 Watch Point Contents Initial = 00000000802569E0 Previous = 00000000802569E0 Post = 000000008014B720 Register Contents R0 = 00000000 R1 = 7FFB09B6 R2 = 00000000 R3 = 7FFB08B8 R4 = 8010A850 R5 = 802569E0 R6 = 7FFB0580 R7 = 7FFB0646 R8 = 7FF41D38 R9 = 7FFB0208 R10 = 7FFB0400 R11 = 7FFE0270 AP = 80045052 FP = 7FFE9DE4 SP = 802947D4 PC = 8000A160 PSL = 04180004 Instruction Stream 0050AF500BA50200EF1208DA55650F .PP........Ue. 8000A160 8000A160: REMQUE (R5),R5 8000A163: MTPR #08,#12 8000A166: EXTZV #00,#02,0B(R5),R0 %WP-W-INSKIPPED, unreasonable instruction stream-220 bytes skipped Base Address = 80002B58 Ref. Ref. Ref. Op. Previous Byte Count Time Code PC PSL Contents 00 00000509 02:33:19.60 0F 8000A160 04180004 802569E0 00 00000508 02:33:19.39 0F 8000A160 04180004 8014B720 00 00000507 02:33:19.38 0F 8000A160 04180004 80002B60 The information displayed is pretty much self explanatory. I was impressed to see that it decoded the instructions that did the modification that triggered the watchpoint. I recognized the REMQUE as part of the software timer interrupt service routine. VAX-5 PAGESWAPPER - November 1987 - Volume 9 Number 4 Undocumented System Space Watchpoint Utility This utility will be useful for figuring out what's happening in the Executive. Using it to help debug a device driver comes immediately to mind, and it would be useful for debugging user written system services as well. A few caveats are probably in order, for the incautious. The help file for this utility has even more disclaimers from DEC than usual, and a look at the commands show that crashing a system with this tool would be no effort at all. Proceed, at your own risk, and with caution. There may be a reason for this being undocumented and unsupported. This utility can also cause a drastic system slowdown if you watch any location that is modified often at high IPL. I found this to be the case when I set a watchpoint at the listhead of my terminal's UCB IRP queue. The system slowed down to a crawl, and output to my terminal became very leisurely. The system recovered when I used the IGNORE command to cancel the watchpoint. WP implements watchpoints by changing the memory protection on the page that contains the location being watched, and analyzes each access violation that occurs to see if it would result in the modification of the watched variable. In order to do this, the WPDRIVER "steals" the interrupt vector for Access Violation - that is, it replaces the address at 20+@EXE$GLSCB with the address of its own routine, so that it can examine every access violation that occurs, and deal appropriately with the ones caused by watchpoints. As far as I could tell, there is no way to list the watchpoints you have set up, so if you don't record the addresses where you set them, you can't find them to SHOW or IGNORE them. Since I haven't installed VMS 4.6 yet, these tests were done by copying the components of WP to a 4.5 system. It seems to work just fine there. I presume, that since WP came with the 4.6 kit, it would work on that version as well. VAX-6 PAGESWAPPER - November 1987 - Volume 9 Number 4 Editor's Workfile Editor's Workfile Computer Security The (DoD) National Computer Security Center has finally acknowleged the importance of computer security concerns other than secrecy. Even after receiving some duties regarding civilian computer security in the controversial presidential order NSDD 145, the military-oriented agency has kept it's "Orange Book" concentrated on preventing secrets from leaking, rather than dealing also with questions of integrity (avoiding improper MODIFICATION of data) or denial of service. A new publication called the "Trusted Network Interpretation", however, discusses plans for accrediting network security, and in the process gives plenty of attention to integrity and denial of service issues. It seems as though they didn't want to actually admit the Orange Book was deficient but they realized they would not make it anywhere with a commercial audience talking only about secrecy. Symposium Transcripts this Issue Many thanks to Ron Frederick for providing the Pageswapper with transcriptions of several Symposium sessions for this issue. Let me know how you feel about transcripts in the Pageswapper. I get very little feedback about what people do or do not want to see, other than one recurring comment about I/O entries being difficult to understand if the antecedent entries were from a previous month. I'm working on that one. Larry Kilgallen Pageswapper Editor VAX-7 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Migration to MicroVMS from DEC Operating Systems Spring 1987 US DECUS (Nashville) Symposium Session V172 presented by Bill Taber, W. I. Taber Inc. and Henry Schneiker, Pivotal transcribed by Ron Frederick N.I.P.E.R. P.O. Box 2128 Bartlesville, OK 74005 We are going to just take questions. We need to do the standard DECUS procedure of coming up to the microphone, one question per iteration through the line. Please identify yourself and the company you work for. Come up and ask your questions about various migration things. Q: Laura Berry, MDB Systems, currently we have a PDP-11/73 running RT11 and TSX. We would like to convert to MicroVAX-II, but have somewhere between 700 and 1000 COBOL programs that need to be converted. Does anybody know how difficult that's going to be? A: You will have to recompile them all, plus you will have to account for any differences between the compilers from your current system to the MicroVAX. There is no getting around that you are going to be doing a bit of work, having both machines sitting side by side and setting someone to the task of converting one at a time. You will have to test them also. There is a filter program, but I'm not sure whether it exists for the VAX. We might be able to twist DEC's arm to get it out. This program filters from COBOL11 to COBOL81. Q: Is COBOL81 what the MicroVAX-II uses? A: It's COBOL8X or whatever they are up to. That program does exist. I'll go back to the PDP-11 group and see if that does exist on the VAX as well. Q: Russ Hanson, Mayo Clinic. I've programmed an RSX for a while in MACRO and I have to convert to a MicroVAX, but VAX-8 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems I get to convert to a MicroVAX-II. I haven't looked at all at MACRO in VMS. Is it much different? A: Totally different. You are going to get very confused, very fast. Moving R0 to R1, for example, works in reverse. It will take R1 and put it in R0, not R0 into R1. Q: Are there any good introductory books? A: There happens to be a very good one downstairs in the bookstore. It has to do with the VAX architecture. Q: I'm Ed McKay from Galveston College in Galveston, Texas. We are a small 2000-student, two-year junior college, annual budget of about $6 million or so. We do everything on a PDP-11/70. That means student records, budgeting, accounting, our own payroll, as well as teaching FORTRAN, BASIC, PASCAL, COBOL81 on the PDP-11/70. We have two DH emulators and 8 DZs. That's something like 104 terminals and we typically run 50 jobs on the 70. We are converting to VAX hardware primarily for political reasons. The other schools in our area have all gone to VAX and we are kind of in the Dark Ages if we don't have VAX hardware. My first MicroVAX is sitting in a box down there to be installed next week when I get back and I don't know whether it's going to take two, three, or perhaps, four MicroVAX-II's to replace the 70. I'm confused at this point about what way I ought to be going. Should I plan just to connect my MicroVAX-II's with DECNET over the Ethernet, or I should go to a local area cluster over the Ethernet? Perhaps I should be looking at Ultrix because of the much, much lower cost and some of the basic products that are available on Ultrix? I would like to have the panel vote which of the three ways you would go -- whether you think it's going to take two, three, or four MicroVAXes to replace my 70. I have to prepare the budget for the next year's addition as soon as I get back. A: One MicroVAX should be able to effectively replace the CPU power of your 11/70. That shouldn't be that much of a problem. If you want to add additional CPUs, however, clustering is a very convenient way to go because all of your resources are available to all of the MicroVAXes. Just remember that you have to manage a cluster as if it were a single processor. It is basically a distributed VAX-9 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems operating system. You have to manage the entire thing as if it were one machine because when you cluster, it actually is. You can incrementally increase the amount of power you want, including peripherals and CPU. VAX clusters are a very nice way to go in that regard. I want to add something. You said you were coming off RSTS. Most RSTS programmers make use of the operating system itself to do things that are very, very nice, like little programs, lots of changing. That works on an RSTS system; that hits the VAX in the worst possible place -- image activation. You will need to make your running applications all one large program in a hurry so you can activate them all at once. Do a lot of calls to subroutines. Another thing, the compilers on the MicroVAX are much, much faster than the 11 compilers. You will pick up a lot of throughput there. Q: Ron Frederick, NIPER in Oklahoma. We have a PDP-11/70 running under RSX- 11M-PLUS right now. We write a lot of command files. Is there a difference in the DCL from one DCL to the other. I understand there are some differences. What's the situation there. A: Are you referring to DCL or indirect on RSX? Q: I am primarily asking about DCL at this point. Is DCL on the RSX different from . . . A: Yes. There are differences. The DCL on the VAX is much more powerful. You will run into syntax problems. It shouldn't take very much to convert a DCL command file from one operating system to the other. Q: Ron Frederick, NIPER. You asked about indirect. Indirect versus the indirect command process? I am confused at this point by your bringing up indirect. A: Okay. There is a DCL command parser and there is also the indirect, which is the utility, the parser under RSX with the dot commands and so forth. They are totally different. You are going to do a lot of work if you convert an indirect command file as opposed to a DCL command file. Q: I wonder if you could address the pros and cons of MicroVAX-II clusters that would allow us to go to the VAX-10 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems VAX in pieces, as opposed to just jumping in the water with the big one. Somebody told us that for our needs, we are going to need an 8350. We currently have two 11/44s, one of them has 3 meg the other, four meg. We are making use of the virtual disk. We've got Eagle disks on both machines, one also has an RA80. One machine has about 25 users, with 10 or 12 hard copy printers attached as terminal lines. On that system it's BASIC, BASIC+2, primarily inquiry, maintenance, report generation. We also have a fairly large DIBOL package that could have as many as four or five users. The second machine is our development machine, primarily where we write and compile, taskbuild our programs. It's got the 3 meg, an Eagle disk. It's also an 1144. A: The kind of applications you run determines whether to go with one big CPU or a lot of smaller CPUs and cluster them together. If you are going to write a lot of small, independent jobs that don't need lots of CPU individually, it's often much more efficient to run them parallel on separate processors of a cluster. If you've got one big job that sits there and runs all day long, then you want one big processor to run it on. Having several processors won't do you any good because it's only going to run on one and the others will just sit there idle. If your job mix allows you to spread those jobs over multiple processors, such as you have lots of students and you can log five onto one processor or something like that, quite often it is advantageous to go to a cluster system and buy the first MicroVAX. When you run out of CPU, buy a second one and stick it on a cluster, a third one, a fourth one, and so on. The advantage of doing clustering versus networking is that you can access all the resources if they are a part of that CPU. You have to manage that as one big system. The other thing to watch out for when you go to a cluster, I am going to be very conservative at this point, you probably are going to lose about 20 percent of the horsepower of the machine. Two MicroVAX are equivalent to 1.6 MicroVAX. Also, you need to consider the I/O bandwidth because you have very little disk space. The MicroVAX uses the Q-bus, which tends to be a bit slower than what other systems use, HSC-50's for instance. That is another consideration on total system throughput. VAX-11 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Q: Bob Van Curan, Userware. One comment on that. If they are separate applications that don't have shared data, you might even consider having separate MicroVAXes and not putting them in a cluster. Q. Jim Cronin, Carolina Power and Light. I've got an application that runs currently on a 780 and I need to move it to a MicroVAX-II. I've been told, and I read, that a VAX is a VAX is a VAX. Should I expect any problems moving this application from a 780 to a MicroVAX? A: While there are some distinctions between VAX, in general, they are correct -- a VAX is a VAX is a VAX. The problem comes in certain areas, such as how they actually implement it and which bus they are using. DEC rates MicroVAX as it comes configured about .9 versus a main 780, partly because it uses slower peripherals. We maintain that if you put fast peripherals on a MicroVAX, it will go about as fast as a 780. The second major distinction is the number of instructions and which instructions they have actually implemented in hardware. The VAX has the capability of having the software implement instructions. This saves on the hardware. That's what they did with the MicroVAX and a good number of instructions just aren't implemented. I think 40 percent of the instructions are missing and are implemented in hardware, but that shouldn't bother you. They did a study of what applications use which instructions and implemented the popular ones. One instruction missed was the "string move" instruction or "string compare." I don't remember which. At the time they did the study, none of the compilers generated the instruction so it wasn't a problem. About the time MicroVAX was released, the optimizing FORTRAN compiler came out. The optimizing FORTRAN compiler uses that instruction. If you write FORTRAN programs that do a lot of string manipulation, for instance, you will find that it runs about half as fast as a 780. There are certain considerations like that. In general, a VAX is a VAX is a VAX. It's the same operating system and everything else. You should also remember none of the PDP-11 emulation instructions are on the MicroVAX. If you are thinking of running compatibility mode, don't bother to think about it. Go out and buy a real 11. Q: Harold Addleman, National Computer Systems. I wonder if any VAX-12 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems of you would care to comment on the recent, very large increase in fees for license of MicroVMS end user and what the Digital strategy is in doing that. A: I don't like high fees any more than you do. DEC tried to equalize all of their licensing and the MicroVAX got stuck in there with some higher prices, especially for the licenses. Beyond that, I am not sure I want to comment much further. As I mentioned, I don't like higher prices any more than you do. Yes, it is because you can't put more terminals on it. Q: Russ Hanson, Mayo Clinic. I've had my MicroVAX-II for about six months and I have had one TK50 problem. It didn't let the cartridge back and I had to have a service guy come out to release it. How many should I expect? I haven't been using the tape very much, but I am going to be. How often should I expect a failure. A: The TK50s are a problematic drive at best and are notorious for having problems. There are certain things that you should know if you have a TK50. There actually is a procedure for causing errors and there are two types of errors you will typically run into. In one, you stick the tape halfway into the drive, change your mind, and pull it out. The system thinks there is a tape in there and won't let you insert the tape again. The second problem -- it's got your tape and won't give it back. Quite often half of the tape is on the internal reel so you can't pull it out anyway. There would be tape everywhere if you did. These two conditions are cleared by pushing the red, or dismount button. Push it in, push it out, push it in, push it out, and let the thing whir-buzz-click until it finishes. At that point the error should be cleared. If the tape was inside the drive, it should be possible to pull the tape. If the tape could not be inserted into the drive, the drive should have reset itself so that you can. There is also a difference physically on the cartridges. DEC has an old-style cartridge and a new-style cartridge. If you look on the edge there are little indentations. Originally they thought "Oh, well, we want people to be able to pull the cartridges back out." If you turn it sideways so you can see into the depression, there is a ramp on one side and a flat side VAX-13 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems on the other. On the old style, the ramp was on the out-facing side so you could pull it back out. On the new style, it's on the inward side so you can push it in. They decided it was more important to let you get it all the way in and not have the situation where you couldn't stick it in any more than try to get it back. I have had experience when it wouldn't give back your tape and nothing else would clear it. You actually had to go in there, physically take the machine apart, reach in, and grab the solenoids without powering the machine down. Powering down the machine while the TK50 is actually doing something is not good for the poor tape. You risk mangling your tape in the process. In general, they are problematic, but if you are nice and kind to them -- sit there and don't try to rush them or anything, put your tape in, wait until it settles, push the button, wait until it does its thing, then run your program. When you come back, make sure your program has stopped accessing the tape, push the button in, let it do all of its rewinding. Wait until you hear the final click before you pull up the latch and pull the tape out. If you are very smooth about it and don't rush the tape at all, the chances are you will have fewer problems. The human interface problem with that thing is pretty bad. Q: Bob Van Curan, Userware International. A couple of comments. I have heard throughout the week about the pricing issue. From what I have heard the change in price is prompted by realignment of all the VMS prices for the entire series of computers because MicroVMS is going away in the sense it is just going to be part of VMS itself. There won't be any formal distinction between it and the other parts of VMS. I've heard a lot of comments from people that this price change will slow their migration to VMS because the pricing balance between staying on a PDP-11 and going to a VAX changes. I also attended a BOF session where some people were considering moving to a UNIX on the VAX instead of VMS specifically because of the increased prices. There were some rumors that a third party vendor has a version of BASIC on UNIX that is very similar to BASIC+. I think this is going to slow down our customers in their migration to VMS. They are always looking at "how much bang for my bucks am I going to get if I move over to VMS" and this changes the whole equation. Some interesting things as a result of this price change. VAX-14 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems A: That is indeed the fact. You should see, I believe, around 4.6 disappearance of MicroVMS altogether and there will be one common command procedure. I imagine that tailoring for the 730 is going to go away at the same time and you will have one command procedure that installs everything. That is going to be nice. Q: That frightens me. I only have 8000 blocks left on the system disk. Q: Bob Perry, Tektronics. Just a few comments on some things talked about here so far. We have a large number of MicroVAXes at Tektronics and realistically we have only seen something less than a 10 percent failure rate on the TK50s. Primarily those are from the grabber mechanism that comes out and tries to grab the tape initially. A lot of times it won't let loose. We have had cases where it has ripped the leader. I don't think I have ever seen any of the wrap problems on our systems, but you have to realize that a TK50 is a delicate mechanism. You don't want to slam the tape in, you don't want to pull it out fast. If you do, you are going to jam it, guaranteed. You've got to push it carefully -- just shove it with one finger until it snaps in. Then push the button in. When you are taking them out, don't jiggle them from side to side because they will jam. You have to be very careful with them. If you do that, you won't have as high a failure rate. We are careful in the way we handle our TK50s in our TK50 drives and they are still a pain. We have a number of migrations from different operating systems to MicroVMS, the toughest being from VMS to MicroVMS. In most of those cases the system parameters and quotas were different. When you are going from a larger (larger being physically larger) VAX to a MicroVAX, watch what has been set on your system. It can set sizes and some of the dynamic system parameters may be different, thus causing your task or your process (I work in RSX too!), to react differently under the MicroVAX system. Watch your quotas or you may run out of quotas. Make sure you have just about the same quotas that you had on the VMS system. We have had some migrations from both RSTS and RSX to VMS. VAX-15 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Some more comments on the TK50. I understand you can buy leaders from DEC Direct for $2.00 each in packages of 10. DEC sells them for some ungodly price, I don't know what. If you are interested in replacing your leaders, buy a package of 10 for $20.00 bucks or so, and replace them yourself. If you have a TK50 and the leader is pulled back so the internal mechanism cannot grab it, you will have to release two cams inside the TK50 box. There are little bitty holes with latches that you can stick a pen into and release both. It takes three hands to do this operation. One hand to hold each pen and another hand to turn the tape with the door open. Rotate the tape so that the leader is sticking out again, then release the door and all the cams. You can fix things that way also. When you own a TK50 you learn a lot of tricks to get it up and running again. Q: I am willing to trade anybody my load device for a TK50. I have an RX50 load device. Q: Bob Henbeck, Winrock International. I have been curious about the MicroVAX 2000. I haven't heard a lot about them this week and I wondered if you had any comments, especially where they might fit in small networks and clusters. A: You mean a 2000. The new, small MicroVAX 2000. The little, recently announced one. The diskless version? Either that or whatever configuration. Those are actually very nice on a cluster. I think that is what DEC's intention was originally -- diskless cluster members. You put enough memory on them so they don't cause your Ethernet great consternation and they run just fine. Ethernet is an approximation of hard disk speeds for transferring a lot of things. You tend to not see degradation. By the way, some interesting timings. If you have a 13-node Ethernet cluster, you can quite typically run around 20 percent bandwidth of your Ethernet. When you look at bands of Ethernet, never try to get more than about 35 to 40 percent because the technology doesn't work that way. You will have increasing collisions, increasing delays, and everything else beyond that point. Most VAX-16 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems people consider a utilization of 35 to 40 percent for such a technology to be the maximum. If your cluster node does not have sufficient memory or local paging and swapping, you will need to increase utilization of the bandwidth substantially. It will have to page and swap. This is why DEC recommends that whenever you have a cluster node, you have a minimum of 10 to 16 megabytes of memory or a local hard disk to do your paging and swapping. Q: Bob Perry, Tektronics again. Another note for those of you making your migration from RSX to VMS. DEC has not formally announced the product, but there is a coprocessor board to fit the Q-bus of the MicroVAX-II and run RSX- 11M-PLUS. It's a J11 board and talks to VMS. You can give your commands, log onto the VMS system, and talk to the M+ system. They haven't announced the product, but they have announced the study program and they have a working model on the floor. We are interested in it from a real time standpoint. We do a lot of data acquisition with RSX. It would be nice to be able to sit a MicroVAX out and be able to do processing on a MicroVAX. Look for the product announcement along about the end of this year. There is a second version of this system. They were talking about not even having to put it in the backplane, just having an Ethernet connection between the MicroVAX and the RSX system. It is like an AME under VMS, but a little more involved than that. You might want to talk to the folks down on the exhibit floor. Q: Barbara Lawrence, Starsburg Electric System again. I know my questions are very naive, but I really know very little about what we are fixing to do. Number 1: how much of our existing hardware would be practical, as well as possible, to take over to VAX. We've got LP25 printers and LP26 MS11 tape drive, the Eagle disk. I know the RA81 will plug right into the VAX. In terms of other peripheral equipment, of course, we've got multiplexers and such things. How much of that will be usable on a VAX? A: None of your multiplexers because they are Unibus not Q-bus. None of the controllers for your disks or your tape drives. You can, however, get controllers from others vendors for your Eagle disks that work very nicely. VAX-17 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Q: Oh, good. I wondered if we couldn't do that. A: There is a controller for it. It's a J11 anyway. Q: Well, I know it's not everybody's favorite. At least temporarily. A: The printers. Again, you would have to get proper controllers for them, either through DEC or some other third party people. Q: Is that the practical thing to do rather than replace them? A: Peripherals are rather expensive to replace, so it is a matter of can you afford to replace them or is it cheaper to just buy new controllers. You might also check the used market. You can quite often get either used or refurbished equipment for very nice prices. Q: That's probably where we are going to go for everything, certainly everything we can. A: The Eagles do run. I've got a MicroVAX-II with one Supereagle and one Eagle on it. Q: Fantastic. I don't see anybody else waiting; I wonder if I could ask something else. You may not be able to answer it, not being fully aware of what we are doing and what have you, but I will describe it to some degree. We are primarily I/O-bound as opposed to compute-bound. How many users could I expect to support on a MicroVAX-II? A: It really depends on the application. I have an application right now that supports probably 45 active users on a MicroVAX. Q: Okay, what kind of application is that? A: A single application. It's a lot of data inquiry, credit collection bureau. Q: Okay, that's probably comparable. We are doing utility billing and all that goes with it. A: Two things you must consider as far as how many users to specify for a MicroVAX, or any other piece of computer gear for that matter are: what hardware you actually VAX-18 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems have and how much memory you have. These things have a direct effect on how much swapping and paging you do for many applications, which directly affect how much of your disk bandwidth is chewed up for other things than doing useful work. There are things you can trade off. You will probably have to put the users on, look at any bottlenecks you might have, release those bottlenecks, and go from there. Your typical performance thing. Watch the system, make some changes, watch the system, make some changes, and grow the system as necessary. The other thing on the system I currently have running -- it was a ground zero start-up. It was designed with the MicroVAX in mind. Everybody sits in one image, everybody is running one shared image. I have 16-meg on it. Normally 4 meg is free most of the time with 35 users on it. Q: What is the maximum number that you can put on the MicroVAX-II. A: 16 meg. Q: Is that maximum? A: That is the address bus width. There is a physical hardware limitation that won't allow you to address any more than 16 physical megabytes. Q: Does DEC now sell 8 meg boards? A: Yes, DEC now sells 8 meg boards along with all of DEC's competitors. Q: When we put it together, we couldn't get DEC memory for it. Q: ** with Caterpillar Incorporated. I recently got a MicroVAX Workstation2. What would be a reasonable page faulting number to shoot for with graphics running and DECNET. A: If you look in the performance manual in the big manual set -- all of you who have MicroVAX need access to a full manual set. I highly recommend that you go out and buy one. You should have a minimum of one big manual set per VAX site. It is very important because a lot of things are not in those two user manuals that you got. VAX-19 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Q: It's four now. A: Yes, but the other two don't count. I mean they are FORTRAN manuals, but no FORTRAN compiler. Going back to performance, the manual says that a maximum number to consider for paging or swapping on any CPU is enough soft page faults to constitute 5 percent of the CPU time in processing those page faults. A soft page fault is generated through the page cache, the free list or the modified list. I'm not sure if you are familiar with any of these terms. Q: Not really. No. A: Okay. Since I don't have 20 minutes to explain this, just believe that a page taken out of your working set is placed in this cache area and is available when the system needs memory. It can pull these out and use them. Finding a page in that cache is far faster than going all the way out to disk to get one. Once you have figured what 5 percent is, and on a VAX780- MicroVAX-type machine 5 percent represents around 100 soft page faults per minute. Some around 100 or 120, plus or minus. You are allowed 10 percent of the number of soft page faults as hard page faults. This means somewhere between 10 and 12 hard page faults. Those are the ones you get by going all the way out to disk. Q: Per minute? A: No, per second. Q: Per second. Okay. A: Per second. Do a SHOW SYSTEM or SHOW PROCESS/CONTINUOUS. This also affects how fast your disk device is and whether to raise or lower these numbers. The guidelines indicate this is a starting point and you as a system manager must decide how much paging you are willing to have on your system. Also understand that you can never get rid of paging to activate an image. The system sets up all the paging tables and then faults that particular image into memory. Whenever you activate an image you see a large increase in pages that slowly drops to a base level. You will never be rid of paging. Once a process has been activated and is up and running, you should set things so it does not do more than these VAX-20 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems guidelines for paging. Q: Thank you. Q: Fritz Merkle, Temple Union High School District. Could you elaborate more on the image activation on RSTS and include information about where you have written programs, heavily overlaid techniques, resident libraries, things like that. From a very naive, talk about it naively because I... A: Throw your overlays away. They don't really exist on a VAX. Two things that RSTS did very well were single character I/O from a terminal and starting a program. A run command or a chain command to activate a program was very, very fast on RSTS; it is extremely slow under the VAX. There is an awful lot of set up to get a program running internally in a VAX. Are you programming in BASIC+2 or something like that? A perfect example of what occurs as far as the I/O goes is if you take your BASIC+2 program and go -- 10 PRINT"."; 20 GO TO 10 -- run it, it will take about 3 percent of the CPU on an 11. You have just gone 95 percent CPU-bound on a VAX because of the QIO processor. These are things you have to be aware of and you have to look at them when you start. Quite often on a RSTS system you ran out of memory, then you broke your programs into model streams and ran one program right after the other, chaining back and forth. All these programs you were chaining can be called as subroutines on the VAX. You will run a lot faster. Almost everything you have in the VAX is a resident library. There are things you need to do when you get running...My favorite command for tuning a system is to say -- SHOW DEVICE /FILE/NOSYSTEM -- and find all the VAX VMSRTL program files that multiple people have copies of. Immediately find those, reinstall them -- SHARED/OPEN -- then only one copy resides in memory. This is more effective use of your CPU memory. Oh, yes, /HEADER. Q: Mel Potter, Atomic Energy of Canada. Are there any limitations on a MicroVAX-II with equal drives? Can the drive be the system drive? A: Yes, the drive can be a system drive. VAX-21 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Q: Do you have any comments on using the CDC9772 disk system on the MicroVAX-II? A: Have not run across it. I haven't run across it either. If the hardware is smart enough to be told to go out and access the boot files, you must not be required to load microcode before using the disk. If that is the case (all of DEC's drives are that way), then you can boot off it and there is no problem. I have a reference here for DIGITAL REVIEW, January 26, 1987. There is apparently an article about that. Q: Thank you. A: Talks about the drives and controllers. Anybody looked that article up? Q: Russ Hanson, Mayo Clinic. I've been comparing transfer rates over the network between an 11/73 using a RD53, and a MicroVAX-II using a RD53; I get something like two or three times faster with the MicroVAX. Is that to be expected? I get about seven times faster than an 1123 with an RL02. A: Which controllers are you using? Q: The second version. A: RQDX2? Q: Right. A: I believe the other controller is the better controller, the -3, and goes faster. Q: The -3 is, you say. A: Yes. RQDX3 is about three to four times faster than the RQDX1. I don't know the difference between the RQDX1 and the RQDX2 -- someplace in the middle. Q: Do you know if version 3 on an 11/73 versus a MicroVAX with the same hardware going the same place are different? Using identical hardware, my MicroVAX is at least twice as fast when moving big files across. VAX-22 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems A: With the same hardware on an 11 and on a MicroVAX, DMA transfer should be equally fast as long as you are transferring to onboard memory because the hardware is basically identical. If you are transferring into Q-bus memory, it may be a tad slower. Not too much slower, otherwise the disk would overrun the memory. That should never be the case. The Q-bus is plenty fast to do those transfers. The only problem would be the operating system setting up and making actual use of that information. The actual transfer time should be the same because the hardware is identical. Q: Mel Potter, Atomic Energy of Canada. I'm going to have a lot of people using the MicroVAX that don't necessarily want to learn all the command language. What about the A-Z product, is that a good solution? A: Anybody here work with A-Z? I don't know anything about A-Z. As another possibility, write command procedures, sometimes even CAPTIVE command procedures, to do what you need the user to do. Give them a menu of what you want for an interphase, give them some prompt, make it look like some favorite computer these guys know and love. It will slow things down a little bit, but sometimes the convenience is well worth the effort. A: Most of my systems are written with CAPTIVE processes. People are getting CAPTIVE and can't do anything other than what they are given the capability of doing. A lot of procedures are then passworded at the next level down. System accounts for my nontechnical managers -- I have given them menus in the system so they can add users, delete users, run backup, do most of the system management from command processes. A: Anybody else have a question? Q: Laura Berry, MDB Systems. You mentioned that you can't put TS-11 on a MicroVAX-II. Is that correct? A: The reason is the controller DEC supplies is a Unibus controller, not a Q- bus controller. If you can find somebody who supplies a Q-bus controller, you can put it on. VAX-23 PAGESWAPPER - November 1987 - Volume 9 Number 4 Migration to MicroVMS from DEC Operating Systems Be aware that there is no support for any tape drive whatever for MicroVMS on Digital. DEC does sell a TSV05, which means when you buy the TSV05 from DEC you have to buy an additional software package, the TSV05 tape driver. There is no tape support other than the TK50 that comes with MicroVMS. Also, they don't include device drivers with MicroVMS because you haven't got the hardware and you can't possibly put it on. They eliminated that so it wouldn't take up additional disk space. Q: Ron Frederick, NIPER. We are in the process of looking into a new tape drive and we are looking at the TU81+ to go on a MicroVAX and also onto our PDP. Does what you just said about tape drives mean we are going to have to get some software in addition to the hardware and the controller? A: Yes. It's only like $250, I think. Q: I'm John Santos, from EG_H. The TU81+ uses the same driver as the TK50 and that's already there. It uses the TMSCP tape driver and that isn't good in a MicroVMS so I don't know what they would give you, that would be additional. A: Okay, I wasn't aware of that. Thank you. Q: What happens if you have both, what's it going to do? A: It will see two different units. Q: Mel Potter, Atomic Energy of Canada. I was looking at some benchmarking MicroVAX-II programs and occasionally I came across the words "coded BLISS". What is "BLISS", a compiler or just a switch on the FORTRAN compiler? A: It's a compiler and you can buy it from Digital. VAX-24 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System Online Security Monitoring System Spring 1987 US DECUS (Nashville) Symposium Session V004 presented by Linda Lankowicz Computer Science Department of Springhill College Mobile, Alabama and Marino Nikolai Computer Science Department University of South Alabama Mobile, Alabama transcribed by Ron Frederick N.I.P.E.R. P.O. Box 2128 Bartlesville, OK 74005 This presentation is the result of on-going research efforts to develop an algorithm for identifying security violations. While VMS provides a means of auditing, our research is directed more to developing an on-line security system that will examine the activity of authorized users. Assistant managers' responsibilities include a number of areas that require knowledge of the parameters of resource utilization. From creating access control lists for directories to setting . . . limits for authorizing users, to examining the CPU time for cost accounting, and finally, tuning the system for performance. Security is just one aspect of the responsibilities of the system manager. A system manager might establish procedures for the physical security and rely on the mechanisms of the operating system for the internal system. A system manager develops a certain sense of how his system behaves and how certain activities use his system. An experienced manager develops an intuition about what activity is taking place based upon resource utilization of a specific system. When I worked as system manager, it seemed to me that a process's use of system resources could be used to identify the activity of that user. Resources such as the disk, with page faults and . . . or the terminal usage with buffered . . ., the memory . . ., or the CPU with processor time. I thought other parameters that were not readily available, such as the page faults per image or the processor time per image, would be also good to look at and evaluate. A process might generate a lot of page faults, you have to have a very low ratio of page VAX-25 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System faults per image. In some instances while monitoring the users, I was able to detect unusual behavior patterns based on abnormal patterns of resource utilization. It seemed that if some of these parameters could be used to identify the user activities, they could also be used to determine whether a user posed a threat to the security of the system. Our research was an effort to quantify this and included two areas. First, we performed a statistical analysis of some of our user behavior to show that a combination of these parameters was sufficient to identify user activities. Second, we developed a model for security threatening measures and developed an on-line security monitoring system. The trusted computer systems evaluation criteria, as it is called, are in the orange book. The Department of Defense states that for a secure system, the trusted computing base should contain the mechanism that is able to monitor events in the system, events that might indicate an imminent security violation and notify the system manager. It is really not sufficient just to audit past activities of the system. It is necessary to be able to detect that a possible security violation occurred and then notify the manager. If specific activities are identifiable, then unusual activities, activities that would pose a threat to the system, ought to be recognizable also. We selected an unusual activity, browsing, and sought to quantify this into a model applicable to other systems. Browsing consists of the attempts of a knowledgeable user to compromise the security of the system by performing activities that look much like activities of the system manager including coping files, searching for files, open files, files that are not protected, moving from directory to directory. Linda is describing the concept we started to work with about two years ago concerning our ability to monitor the activities of the authorized user. We felt that was a problem and we heard that mentioned several times this morning. We were not really sure what level of background information the audience would have concerning some of the details of security policies established by the Department of Defense. I want to digress just two or three minutes to look at terms and concepts associated with the security violations and threats that we are going to discuss and track. When looking at this description, we realize the key is to be able to monitor the occurrence of imminent security policy violations. We would like to provide a tool that extends the use of the monitor utility to allow the system managers to set a threshold to actively observe the VAX-26 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System performance of various users or processes on the system. The Department of Defense clearly states that in order to achieve any level of certifiable system, main areas of security must be investigated. The first one deals with external security, the second, internal security. The two previous presenters talked a great deal about the external security measures concerning physical access in communications, the problems associated with networks, the ability to protect back-up problems. Our concern is not directed toward external security, although system managers must be aware of that as a primary obligation. As far as internal security is concerned, the Department of Defense feels there are several ways in which internal security needs to be monitored. These include access controls which most of you are familiar with; we will talk about them very briefly. An idea which may be new to some of you or may be not quite as familiar as access controls involves flow controls, then the idea of inference control, which is associated with the ability of a user to go into a database, make queries, infer from those queries, and gain access he otherwise would not be authorized to use. Of course, the need for . . . in addition to those protections and all of those internal and external securities are associated with certain . . . of the system. Since we are dealing primarily with internal security, I thought a very, very brief history of the development of access control strategies would be appropriate. The earliest known access control strategy dealt with a ringed protection hierarchy. It was implemented on MULTICS operating system and at that time the idea was to separate, or segment, users from other users and users from operating systems to allow very limited communication between processes. MULTICS chose eight rings and their implementation VAX has four rings: a user ring, a supervisor ring, an executive, and a kernel. No one ring can talk to a ring that is two removed unless it goes through a user gateway in the intermediate ring. In addition to the access control ring protection, there are several other capability lists which are very popular these days. The idea of a capability list is to associate with each process a list of objects and access types allocated for those objects. As a process enters, it has a description of which objects it has access to. Of course, most of you are familiar with ACLS, Access Control Lists, which is just the reverse of that in the sense that for each object in the system there is a list that describes which processes have access to it. VAX-27 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System The concept of flow control may be new to you. The DoD specifies that all of these must be in place for a certifiable system. Access lists or access controls usually keep users from interfering with other users or from interfering with the operating system. They do not discourage or disallow a user from giving away information. That's an important concept in flow control because we are interested in maintaining the need-to-know status. A typical example is in a student or academic environment where one student will make or run a program then pass it to friends through the use of a mail utility. When the program goes through mail, all the security and protection tags are stripped and it becomes an unprotected piece of information. In a sense, that is a security violation. Some strategies for dealing with flow control. Develop authority levels for every file and then for each of those files make sure the sender and receiver have the same authority level, whether it be a classification or category. The problem with that approach is that it generally leads to a higher classification or lower classification of the entire process because everything is moved up to the highest level. In addition to maintaining flow control, one would like to be able to develop a trace of all program flow to make sure that terminates occur normally, that all loops terminate and that there is no ability to escape from the isolated domain. The fourth area that is mentioned is one of domain isolation. We heard this morning of the use of the Trojan horse, which is the writing or presenting to a user with a privilege to . . . a very innocuous looking program. I ask that system manager to run the program for me. Imbedded in that code is a piece of software that writes some information out of user space so I've gained information through using the manager's account that I would not have normally been allowed to access. In addition to those four control strategies, DoD also emphasized the need for a kernel, a secure kernel, in which all secure operations are centralized. Essentially, that kernel must be completely isolated and correct. There is a great deal of work being done at the theoretical level to prove the correctness of various types of kernels. All security operation would be performed at the kernel level. The kernel would run directly on hardware and would be completely separated from applications by an operating system emulator. In this case the application would never see the operating system. In addition to the software kernel, some hardware considerations are important: the efficient method of contact switching, the need for argument validation and the need for access types. VAX-28 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System Just a very brief list of some work that has been done beginning in 1973 to show you there are some systems around trying to satisfy these requirements. The SRI provably secure operating system . . . the SRIPSOS system deals with capabilities we just discussed: access to control strategies and a tag architecture. That specifically addresses the need for flow control. Honeywell . . . was a communications processor developed for the US Air Force based on the MULTICS ring structure. It has a secure kernel and currently has the highest DoD classification of any system available. That was developed in 1975. In 1976, MITRE and UCLA jointly developed a secure Unix operating environment that incorporates a kernel, a policy management system and an authentication process. System Development Corporation in 1976 developed KVM which is an extension of VM370. It is a VM370 with security modifications and uses the idea of security relevant and non security relevant domains, as well as a secure kernel. In 1978 MITRE developed a kernelized, secure operating system which icluuded kernel check access interprocesses, information flow, and extensive audit capabilities. The Department of Defense developed in 1972, and modified in 1978, Directive 5200.28 specifying the security requirements needed to attain various levels of classification. These have been incorporated into the orange book which was developed in 1983. They specify particularly that physical and internal security requirements must be satisfied in four environmental areas: dedicated environment, system high, controlled, and multilevel. Dedicated environment essentially is where all users have the same security clearance and the same need to know. It's a very, very restricted environment, it's ideal, primarily concerned with physical security. You have already limited the users to the information that is there. The other, you have a multilevel environment where you mix all security types, all need-to-know classifications with all manner of objects. There you are concerned primarily with internal security measures. In 1984 President Reagan signed Directive 145, thereby establishing the National Security Agency as the agency responsible for communications and computer security. This directive also established a set of vendor criteria which must be met in order to sell to the government. The certification process is managed through the Department of Defense Computer Security Center at Fort Meade. They have a two-phase process. The first phase involves direct interaction with the operating system designers. Problems associated with the operating system are resolved at this point, they go back VAX-29 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System and forth. There is no published result at this stage. When the operating system is finally submitted for certification second phase, the security classification is submitted and a penetration risk analysis is performed. Our particular study was really concerned with penetration risk analysis. A couple of very brief definitions. The definition of a secure system is a system which will control through the use of specific security features access of information such that only properly authorized individuals or processes operating on their behalf will have access to read, write, create or delete information. There were six stated requirements to satisfy those goals. Two in the area of access control and four in the area of accountability and assurance. First is that an explicit well-defined security policy is required which will enforce rules governing access of objects by subjects, by processes. Access control lists must be associated with each object under accountabilities. The requirement for individual identification bi-level, requirement for augmenting available and protected files, need for evaluation of control mechanisms and the need to protect security mechanisms from alteration. In the area of background the Department of Defense has defined four classes of internal security mechanisms, A through D. You have heard this several times this morning. It is the minimal protection, you automatically get D if you do not achieve any of the other levels. Division C is discretionary protection; it is based on security levels and need to know. There are two subclassifications, C1 and C2. I won't go through these in detail. I believe we have heard this morning that the VAX 4.3 is at a C2 level now. Division B, which is the next higher classification, has the following requirements and must enforce integrity against acts of users. We were concerned with that area -- monitor of real time activities, protection of logical data structures, access control lists, hardware detection of malfunction, proven design specs, unannounced system checks. Three areas: B1, 2, and 3, culminating the security domains. Division A, which is the highest, requires a verify design; I'm not sure that anybody really knows what that means. Right now, . . . is the only processor that satisfies the criterion and requires a mathematical proof that the model is consistent with the axioms and sufficient to support the security policy. This requires a set of verifiable, formal, top-level specifications and a trusted computing base which satisfies the top-level specifications. Linda will continue with a detailed description of our research project. VAX-30 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System First, I examined the accounting output from student activities for over a semester to attempt to quantify them into a profile. You are familiar with the output from accounting. We get a large amount of information about each user process, the record is written at the termination of each process. We are looking at peak values since it is not recorded until the process terminates. When we are looking at accounting data, we are looking at the peak working set. It would be nice to look at the working set over the life of a process. In looking at some of the monitoring data, the system manager is able to see all of the processes on the system, as well as the shared and the working set pages, the direct I/O count, the faults and the CPU time for the processes. It would be nice also to be able to see the number of images generated by these processes and, perhaps, the buffered I/O for each of these processes because that would be interesting from a security standpoint. The information provided by monitoring is hard to digest. It appears on the screen interactively or you can capture it to a file, but you accumulate a large amount of misinformation. The most effective use is usually to follow one or two user processes that you would like to investigate further. Our on-line detection routine would alert the system manager as to existing problems. It is really difficult for the system manager just to watch monitors and get that kind of information. We performed a discriminate analysis for three different groups of users to determine which of the parameters for resource utilization could be used to identify their activities. Identification was possible because we knew what their activities were. We chose a senior English class which had received instruction in word processing and did not know how to use the other features on the system, even as far as using the mail. Another group of students was involved in editing and programming with PASCAL. This was a beginning group of students and they did not know how to use the other resources. The third group was a business statistics class who were given accounts to use . . ., an interactive statistical software package. These three groups of users were quite different and we wanted to evaluate those three groups to see if their resource utilization parameters could be used to determine their activities. By looking at the means for 11,006 different log ins over a period of a semester, you can see the groups did have quite different means. Even the peak working set from accounting ranged from 895, 516, 378. As I said before, sometimes it is more useful to calculate a parameter such as the buffered I/O per image. A student may have been logged on for a long time and have a large amount of buffered I/O and, yet, the amount per image might be VAX-31 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System low or the process of time per image. We ran a discriminant analysis of this and saw that a combination of these parameters could be used to identify the activities of the user. We were very pleased with the outcome. We were able to identify a user word processing 91 percent of the time. We have this information available in thesis if you would like to examine that. Once it was established that the resource utilization could be used to identify the activity of the user, I attempted to determine how an activity might appear over the lifetime of that activity rather than just look at the termination of the process. I also attempted to look at browsing and how it affected system resources. I looked at the system manager's account, as well as some students who were involved in browsing. In order to do this, I took output captured from the monitor, recorded it in a file, and because that data was not in a usable form, I imported that into Lotus 1-2-3, parsed it into columns, and then sorted so I could examine one process at a time and look at how that process changed over its life. We looked at a number of parameters. This is just one. There is another example in the DECUS notes with another graph. We generated many of these graphs from many users for a number of parameters we determined to be critical. This particular graph shows the working set of six different users. I put these graphs together so you could see the difference between these users. The working set default was 200, the working set quota was 500, and the working set extent was 1,000. Those are the figures on the left side of the graph. The top three graphs are for users that were word processing. On our particular system, users that were word processing with this type software would quickly fault in the number of pages needed. They would always get a very large working set even if a one-word document was created in the word processor, always far above the working set quota. Then their working set would remain steady until they exited the word processor and, you can see in one of them, they would trim the working set fault and expand again if they re-entered the word processor. If a student edited the very same file, the student generated a different profile editor. The two straight lines across the middle are students that are editing. They would always be in a range below working set quota and allowed to grow, but generally would maintain a steady image in the range from 350 to 550. VAX-32 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System The bottom line shows a browser. A browser's working set looks quite different because of the trimming he experiences as he generates images. Because he generates so many images, changing his activity, changing directories, trying to type files, looking at file protections, copying files, he is constantly being trimmed. Actually, the browsing profile generally is below working set default, usually no more than working set default. Even though a browser would begin at working set default, he would be trimmed with each image generation. The maximum they ever displayed was below 300. In an academic environment using a stepwise discriminate analyses (inaudible or cut from tape when turned) implement a system for detecting browsing. We begin by looking at what kind of goals we would have. There was always the goal of little overhead. Any new feature for security is going to increase system overhead and we would like to minimize that as much as possible while realizing there would be a cost involved. The other two goals were simplicity and consistency, treating all processes alike. Two different approaches were considered. In one approach, a process creation (a shadowing process) would be created. You would have twin processes and one would constantly monitor the other process. This offers the advantage of individualized treatment because that one process could check more often for someone who was demonstrating browsing. This also means there would be an inconsistent treatment of the different processes. This would be a disadvantage because the process doing the monitoring could be lulled into a false sense of security as the process got into a word processing mode and then changed to browsing and, also, there would be overhead from the large number of processes on the system. You would be doubling the number of processes on your system. We did not implement this one, but instead implemented a single process taking snapshots of all the processes on the system. No process, therefore, is bypassed. There is consistency because every account, even the system manager's, is treated the same. The disadvantage is that this one process has to maintain information about all the other processes. We tried to address this problem. The monitoring process using the four parameters we specified hibernates, wakes up, and takes snapshots of all the processes on the system. It determines whether any of the processes might be browsing and sets a bit in a bit map if it is determined any of those processes meet the four parameters. The VAX-33 PAGESWAPPER - November 1987 - Volume 9 Number 4 Online Security Monitoring System monitoring process schedules its next wake-up and hibernates again. The monitoring process uses GET JOB PROCESS information. It obtains information about the four items that are needed: the working set size, the number of images, the fault rate, as well as the name of the image being executed by that process. If the monitoring process does determine a security problem, it will write it to OPA0, to the console. Each bit map is associated with a port, so that when the monitoring process is taking place you have a window of the activity on that port. We rotate the bits each time a snapshot is taken. If you are taking a snapshot at one minute intervals (for 32 bits), it would mean that you would have a window, or picture, of the past 32 minutes of that particular port. If any process was generated and that port was determined to be browsing, a bit would be set. There also needs to be some criteria for deciding when to notify the system manager. We decided that for our implementation every user would occasionally demonstrate behavior that might be classified as browsing: moving, changing from directory to directory, copying files, etc. We were concerned about sustained activity in this area and gave some consideration as to what would constitute enough browsing activity on that particular system to notify the system manager. Our system was set at four consecutive bits, meaning the browsing activity was detected for four minutes. The implementation did have a very low overhead since there was no interprocess communication -- that was one of the aims. A bit map only using 32 bits per port maintained all of the information. The code was written in MACRO, we used GET JOB PROCESS INFORMATION, wrote the information using QIO to the console, and all processes were treated equally for consistency. Note that the system manager forgot to log off at some remote site and some student was in that account browsing, that activity would be detected and recorded. We were able to develop a methodology from modeling different user types. Our discriminate analysis showed it is possible to identify users based on system resource utilization parameters and we implemented this with an on-line monitoring program. We need to further refine and extend our model of browsing and perhaps other security threatening behaviors. We would like to develop other profiles of other user groups, extend the work possibly to other systems and also to networks (we did nothing as far as networks) and to be able to select the optimum parameters for early detection of browsing. VAX-34 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management VAX/VMS System Performance Management Spring 1987 US DECUS (Nashville) Symposium Session V041 presented by Steve Neubauer VMS Performance Group transcribed by Ron Frederick N.I.P.E.R. P.O. Box 2128 Bartlesville, OK 74005 Good morning. The title of today's talk is "A Practical Approach to VAX Performance Management" or "How to Identify a System-Limiting Resource and Why It Is Limited." As the sophisticated system manager knows, this is the first and most important step in performance management. The resources we are going to look at are CPU, memory, and I/O subsystems. Identifying the limiting resource is important when looking at specific performance problems and a general performance strategy. We want to anticipate problems before they happen. The main objective of this talk is to present an overall methodology for identifying the limiting resource. A limiting resource is just that, a resource that limits the performance of your system. We will see later in the talk exactly what is meant by "a limiting resource." This presentation will include only the tools on the standard VMS kit. We will not talk about the layered products, VPA, or SPM. We may make passing reference to them, but they will not be the focus of today's talk. We will talk primarily about the VMS monitor utility and other DCL SHOW commands, however, this is not intended to be a monitor tutorial. If you have more detailed questions on monitoring, please bring them to the VAX campground. I'll be there today from 1 to 3 P.M. Since this is only a one hour talk, we will cover only the major points. We are not necessarily going to talk about solutions to your problems, but will focus on problem identification. This talk is really meant to get you started, to whet your appetites. The topics of the talk include preparation, steps to take before you begin a performance investigation, problem identification, and identifying the limiting resource on your system. We will then look at an investigation of the three major resources. VAX-35 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management Let's look at the things you should do before you begin a performance investigation. Collecting historical monitor data is one of the most important things you can do. This will enable you to understand your workload and know what is typical on your system. When you have a particular problem, you can look for deviations from those typical values. If you are looking at kernel mode time or compute queue, you should get a feel for what is typical on your system when performance is good. Monitor your system at system start- up. There are command files in the directory, SYS$EXAMPLES, to help you do this. These command files start MONITOR with a large sampling interval, with a 10-minute sampling interval. MONITOR is running as a background process on your system, collecting performance data. There are really two aspects to using MONITOR: collecting or recording data, and summarizing data. You should do that and look at the information in those reports on a daily basis. If you are collecting this monitor data in background, you can look at the recording files on a live basis. These files allow for multiple readers, so you can actually summarize the data from a live recording file. This command, MONITOR/INPUT equals (FILE NAME)/BEGIN equals some incremental time, will let you look at recent system usage. Sometimes historical data is not sufficient to help resolve a particular performance problems. Things slow down for a short period of time, for example, for a minute. Sometimes the 10-minute recording intervals will not enable you to focus on the particular problems and dilute the information over the entire interval. It's nice to have some command files around to invoke during problem periods. If you anticipate problems, then you can have these files ready. Hack what's in the SYS$EXAMPLES directory and replace the interval period of 10 minutes with a shorter period of time. These files will provide the finer granularity data that's often needed when evaluating problems. The examples we are going to show in this talk will be from some of these time monitor files. You should also run AUTOGEN of course. AUTOGEN generates system parameters based on your hardware configuration for typical workloads. AUTOGEN does not know about your own workload, therefore, it is important that you know these characteristics and make any necessary changes in the parameter file MODPARAMS.DAT. If you have a high level of sharing and locking on your system, for example, you may want to increase the SRP count and your lock ID table, may be your resource hash table. It's important to know your workload to know where your workload may deviate from the typical. Wherever possible, use the VAX-36 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management ED_ symbol in AUTOGEN. These enable you to specify incremental amounts of change based on what AUTOGEN calculates. AUTOGEN will make a calculation and by using these symbols you will be able to specify incremental amounts. It is good to use these so you won't override the values that AUTOGEN calculates. In some particular cases, like PAGEDYN, one particular example where a hardcoded value of PAGEDYN went in MODPARAMS.DAT may override some of the work that AUTOGEN does. Hardware problems may cause performance problems. You can use the DCL command SHOW ERRORS to see if a device is producing errors. You can use ANALYZE/ERROR to check the error logs for more information. SHOW MEMORY will show improperly configured memory on your system and any bad pages. Also, the console logs and the operator logs are useful places to check for hardware problems. I wanted to mention this now. Typically, you start looking at a performance problem, then it leads you to investigate a hardware problem. Let's move on to the major part of the talk -- identifying the limiting resource on your system. We see this particular system manager busily typing away, however he has taken the steps we just talked about. He is prepared for an investigation. You should take a top-down approach to identifying the limiting resource on your system for each major resource -- CPU, memory, and I/O. There are really two questions to ask. One is a question of capacity, the other is a question of efficiency. Determine if a particular resource has reached or is reaching capacity. You can do this with the two monitor classes: MONITOR SYSTEM and MONITOR DISK. If you find that a particular resource has reached capacity, go on to step two and see if that resource is being used efficiently. Even if you find that no resource has approached capacity, take step two to ensure the resources are being used efficiently. You may have plenty of free memory on your system, but you may have set working set sizes too small. You may be incurring page faulting or you may have some idle time, but you are spending a lot of time in kernel mode doing system operations. We are going to look at these particular issues shortly and take a top-down approach for each of the major resources and some of the examples that follow, concentrating primarily on single system performance. VAX-37 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management VAX clusters really demand a similar approach. To identify the limiting resource on your VAX cluster, focus on that resource for more detail. When summarizing monitor data on VAX cluster systems, use the multi-file summaries, especially if you are looking at disk statistics. The disk information is recorded on individual nodes. Roll that up and look at the total cluster-wide access in individual disks. You can also do live cluster monitoring starting in version 4.4 with a MONITOR CLUSTER command. This is actually a command you would use on a live basis for doing a performance investigation. You can look at problems as they happen, if they happen. This is an example of the MONITOR CLUSTER screen. Here we see an overview of the major resources of the CPU, I/O, memory, and some locking statistics. We won't discuss this in any more detail, but some of the information to be presented later is also available in this screen. This would be the first place to look when evaluating a cluster performance. Memory investigation. I chose to talk about memory first because in some sense it is the most involved resource. Even though I'm not going to get into the details of memory management, I still have a lot of things to say about memory. The capacity question, "Is there any free memory available," can be answered by looking at the free list in MONITOR SYSTEM or MONITOR PAGE. The efficiency question really boils down to: are you doing paging or swapping? In these example screens, I will focus on what's illustrated in yellow. Here we have an example of MONITOR SYSTEM in its graphical form. We see there are a little over a thousand pages on the free list where there is memory available on this system. The right-hand side of the screen shows the number of available pages outside that allocated to VMS. Memory on a VMS system can be broken down into three major areas. One area covers what's allocated to VMS (includes nonpaged dynamic memory and the look aside list -- this is the number given on the bottom of your SHOW MEMORY command; the number of pages allocated to VMS; it is also the part allocated to PROCESS WORKING SETS). What's left over is either on the free list or the modified list. The number on the right-hand side of the monitor system on the free list part of the screen represents the area dedicated to the two latter regions. Anything other than that is allocated to VMS. VAX-38 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management "Are you using memory efficiently, is the system paging." There are two types of paging to consider: system paging and process paging. First, let's look at system paging. The system working set is a fixed portion of the part of memory allocated to the VMS. This is where the page pool and page dynamic memory reside when a part of physical memory. When the system tries to access page in page pool that's not in memory, a system fault occurs. That's the SYSGEN parameter. SYSMWCNT controls the size of the system working set. It's important to run AUTOGEN in relation to this parameter because AUTOGEN adjusts the system working set based on the size of page pod. If you make any change in the system that increases page pod, these parameter rules will be increased proportionately. You should also watch the system fault rate on the monitor page screen. This is an example of MONITOR PAGE. We see that the average system fault rate here is .39 faults per second. I want you to focus on the second column on the screen -- the average column -- on most of these screens. That's usually the number we will look at. Here we see .39 faults per second. Conventional wisdom says to keep the system fault rate low, below a few faults per second, It is not clear, however, that on faster processors higher fault rates may not be intolerable, especially if these faults happen to be soft. This is really an area requiring further investigation. It's possible that the system faults may be generating lots of modified pages and flushing the modified page list. We know that a low system fault rate is good and at this point we are not ready to go against conventional wisdom. Let's look at process paging and process working sets. Setting working set parameters is one of the most important things a system manager can do so I am going to take a moment to consider them. On the lower right-hand part of the screen, we see the user authorization working set parameters, working set default (the size of the working set when you are not executing an image), working set quota (the size the working set is normally permitted to grow), and working set extent or WS extent (the size the working set can grow if there is sufficient free memory available on your system). The area between working set quota and working set extent can really be considered a low region -- you are allowed this many pages provided there is sufficient free memory available. The WSMAX SYSGEN parameter governs the maximum size any working set can grow to. The actual set size can vary at any given time between working set fault and working set extent. There is an F$GETJPI parameter, WSSIZE, which tells you the current size of your working set. We are going to show VAX-39 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management results from command procedure WORKSET.COM. This very handy command produces a good overview of memory status on your system. It's relatively easy to write your own command procedures using F$GETJPI commands and this is a very good example of one. This is an example output from the WORKSET.COM command procedure. I would like you to focus on the headings and the columns for the time being. We are going to take a look at this particular example in the context of a specific problem later and look at some of the values. This sample gives the user name process, the state the process is in, the working set extent, the working set quota, and the working set default values, which are either the user authorization values or the values that may have been changed by the working set command. The next is working set size, obtained from the WSSIZE GETJPI parameter. WSI tells the current size of the working set. The pages in the working set tell the number of pages you are actually using, the number of pages that are actually mapped and valid. It also gives the number of page faults and the image being executed. We are going to come back to this example. There are two separate considerations: setting of individual process working set sizes and setting of all process working set sizes. Make sure your processes display reasonable faulting behavior with working WSQUOTA pages in individual process working sets. Don't rely on the working set extend mechanism -- when memory gets tight on your system, the processes will not be able to grow to this value. Be sure processes display good faulting behavior with working set quota pages. The sum of active working set quotas should be less than the available free memory for all processes. This is to prevent excessive paging or swapping. Here we are talking about active processes, not all processes. You can estimate active processes by looking in either MONITOR SYSTEM or MONITOR STATES and considering only the processes not in the LEF (i.e., local event flag) or HIB (i.e., hibernate) states. Those can be considered your active processes. With this general rule, we have a little bit of slop left over for global pages. If you are really ambitious, you can look at MONITOR PROCESSES for a breakdown of private pages versus global pages. This is an example of a particular image -- it's the number of page faults versus the working set size. As we increase the working set size, eventually the page faults drop off. Theoretically, the working set quota would be set to the knee* in the curve for this particular image of about 700 pages. It is not reasonable to expect system managers to know the shape of VAX-40 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management this curve for every image, but your user guides or application manuals will give guidelines for setting working set parameters. Now we want to focus on a process that's doing a lot of page faulting. A similar procedure to identify a particular process on your system will also be used in the area of I/O and CPU. When you see high fault rates in MONITOR SYSTEM or MONITOR PAGE and want to identify the highest fault generators on the system, use the monitor processes /TOPFAULT command. Once you have identified the highest fault generators, then check to see what those processes are doing. You can do that with SHOW PROCESS/CONTINUOUS. This is an example from MONITOR SYSTEM and it's in tabular form. By using MONITOR SYSTEM/ALL you will see this form of monitor system rather than the graphical form. Here we see a system that's generating lots of page faults and very few of them are hard faults. That is very few of them are page read I/O faults. We have plenty of memory available on this system so we are doing lots of page faulting. This is a MicroVAX-II system and all the examples we have are from a MicroVAX system. A page fault rate of over 100 faults per second is generally considered to be excessive on this system. When you see those high rates, you generally would like to see who is doing the faulting. This provides a little bit more information. This is from MONITOR PAGE. We see most of the faults are from the free page list and the modified list. In this particular screen the top five items in the middle part of the screen are all soft page faults. Faults that don't require disk I/O account for the majority of soft page faults. Then we can look at MONITOR PROCESSES/TOPFAULT to see which processes fault. We see the process OPUS is generating most of the faults. This slide was played back from the recorded information. At the time we recorded this information, we didn't know which process was faulting, but we were recording the processes class. We played back the top page faulters. This is an example from the graphical form of MONITOR SYSTEM. I put this up to show most of this information is on this screen. If we had more faulters, we would have identified those on the MONITOR PROCESSES/TOPFAULT screen. On this screen, the fault bar was on a bar under the page fault rate. It's to the right of the margin bar (I don't know if this is that legible on this screen). This bar indicates the number of hard page faults on the system. Now we can look at SHOW PROCESS/CONTINUOUS and see how many pages are in the working set. When we look at this screen on a live system, we see the live page fault rate or the page fault count ticking away and we see some simulator program VAX-41 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management is being run. By looking at the WORKSET.COM command procedure, we can see this process has grown. We see what the working set parameters are -- working set extent 512, working set quota 256, working set default 128, working set size, the current size is also 512. We see this process has grown to its working extent and is using all the pages in its working set. We would like to increase the working set parameters for this process. This is the output list of this command file. Some of the things to look for when you see a process actually growing beyond the working set quota: you can determine swapping or trimming is occurring, if the number of pages in the working set are actually growing to the working set size, if the processes are actually using all the pages in the working sets. Command procedure gives you a good grasp of what's happening with respect to memory on your system. We increased OPUS working set parameters, we increased working set quota to 700. This particular system had lots of free memory and would have grown to its working set extent anyway. We increased the working set quota to 7000 and our faulting behavior -- our faulting leveled off and we see good faulting behavior. We should also check swapping in addition to paging to see if memory is being used efficiently. The level of swapping is given by the inswap rate of MONITOR IO. If you are swapping, one of the things to check for is to make sure you have enough balance set slots per processes in memory, that you are not artificially inducing swapping.****** Take a look at some examples. This is from SHOW SYSTEM and often is your first clue that swapping is occurring. It shows the number of processes that are swapping. Having out swap processes is not necessarily a bad thing. In some systems it may be desirable to have out swap processes. If you have a lot of users idle lots of the time, it may be preferable to have out swap processes. The rate of swapping given in the MONITOR IO screen is more critical to system performance. A reasonable threshold for swapping is below one inswap per second. Here we are well below that limit and don't really have a swap rate problem on this system. We can go to SHOW MEMORY and see the reason we did any swapping -- we ran out of balance set slots. We have lots of memory available, we just don't have any more slots in memory for those processes. That concludes our memory discussion. VAX-42 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management Now we will look at doing a disk I/O investigation. The main issue concerns keeping disk response times down. Response time is the time required to get data off the disks. The SPM does provide a measure of response time. If you are using that tool you could do an analysis based on response time with MONITOR. Because MONITOR does not provide a response time, we will look at I/O operation rates. This graph shows the average response times for a typical VMS I/O as we increase activity to the disk. By typical I/O's we mean those small I/O's common in most environments and with a fair amount of seeking. As we increase the operation rate, disk queues start to form, requests start waiting for other requests, and eventually response time will start to increase significantly. The knee in the curve of typical I/O's is around 25 I/O's per second. It is really workload dependent. Some workloads may be a little less, some a little more, depending on your I/O sizes and the distribution of requests across the disk. This graph compares RA60 response times to RA81 response times. The RA60 is not quite as fast seeking as the RA81 so its access capacity, the number of requests per second it is able to satisfy, is a little bit less. Typically the knee in the curve is closer to 20 I/O's per second. We begin our disk I/O investigation by looking at the MONITOR DISK command. Early in the talk I mentioned a few places to start a performance investigation were MONITOR SYSTEM, MONITOR DISK. MONITOR SYSTEM does give some indication of I/O activity, but it does not breakdown I/O rates to individual disks. We need to look at MONITOR DISK for that information. Disk efficiency is really a question of whether some I/O can be avoided or better balanced among individual disks to prevent a single disk from being a bottleneck. In this example from MONITOR DISK, we see an average I/O rate of 22 I/O's per second and a current rate around 30. We want to investigate what is happening. This is an example of the MONITOR DISK/ITEM = QUEUELENGTH. This is another place you may look to see how big your queues are. This includes the current process. We see the queue length is two, indicating we have requests waiting for other requests. You can look at either the I/O rate or the queue length. If you wanted to get fancy, you could even compute the response times using queueing theory. I guess we don't expect most system managers to get out the calculator and start doing that. When you find a heavily used disk, you want to see what is going on on that disk. Is it system I/O or is it user I/O? System I/O consists of primarily two types: memory management I/O or file system I/O. These I/O's do not show up as direct I/O's in the MONITOR I/O or MONITOR SYSTEM screen. Total disk I/O is the sum of direct I/O's plus memory management VAX-43 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management I/O's, plus file system I/O's. To see if you are in current memory-related management I/O's, find out if your page and swap files are located on your active disk. If you don't know where they are, SHOW MEMORY will show the location of those files. If they are located on a hot disk, check for paging or swapping by looking at the MONITOR I/O screen. We talked about most of those items. The disk read I/O rate or the page fault read I/O rate, the inswap rate and also the page write rate, which indicates the number of modified page writes occurring. A memory investigation can be done if you see lots of activity here, look at your working set sizes and do the things we talked about in the memory section. Keep in mind that faults incurred during image activation are page read I/O faults. The other source of system I/O is file system I/O. The monitor FCP screen is the first place to check for file system activity (FCP stands for file control primitives). The efficiency of your file system caches are next to be checked, use the monitor file system cache command to do this. This is an example from MONITOR FCP, the disk activity is given by the disk read rate, the disk write rate, and the erase rate. The erase rate on the bottom includes operations necessary to support volume high watermarking. If you don't want this security feature and you are seeing lots of erases, turn off volume high marking. Excessive disk read rates may be an indication your file system caches are not configured properly. Check the MONITOR FILE screen. Here we have highlighted the actual hit rates on your file system cache. You also want to consider the attempt rates in order to estimate or calculate the I/O operations being caused by cache misses and increase the appropriate cache sizes. The buffer supplement on performance management was distributed at the VAX System Software area. That handout has an excellent discussion of the VMS file system and things to consider there. If you see high direct I/O rates, home in on the processes doing I/O. This investigation is similar to the one used to identify the highest fault generators. MONITOR PROCESSES/TOPDIO identifies the highest I/O generators. You can see what those particular processes are doing by using SHOW PROCESS/CONTINUOUS. In this output from MONITOR SYSTEM, we see a high direct I/O rate -- 28 I/O operations per second. This is from the same example as before when all the I/O's were being generated on one disk. We see one particular process is generating most of these direct I/O's. The same information is available in MONITOR PROCESSES/TOPDIO and we could also see other processes generating I/O's on this screen. From here it is useful to see which files are being used, which files are open on the disk. This information can be obtained from the SHOW DEVICE/FILE VAX-44 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management command. See if it is possible to load balance these files, to move them around to different disks and offload the individual disk experiencing the high I/O rates. This is an example output from SHOW DEVICE/FILES. In this example we see the files being accessed by a process and we also see the files accessed by other processes. We don't see operation rates in this particular screen, but we get some ideas as to which files are being used. Often knowledge of your work load will let you know which file should be offloaded to other disks. The last area is the area of CPU investigation. The CPU controls the other resources. When we begin a CPU investigation, we may end up doing a memory investigation or disk I/O investigation. The question of CPU capacity can be answered by looking at the MONITOR SYSTEM and MONITOR MODES screens. CPU BUSY TIME, and also IDLE TIME are on those screens. Is there contention for the CPU or is there high usage in areas generally reserved for the system? Here is an example from MONITOR SYSTEM. The CPU usage is at 100 percent and the top user is the process cutter John, who is using 42 percent of the CPU. We see there is a compute queue of four; this also includes the null process. Apart from the null process, there are three computable jobs. Is this good or bad? It depends on what the typical rates are on the system and you know what the processes are doing. Are there is any background batch processes, or is this all interactive? You should be familiar with this number on your system and watch for any deviations. Get to know a typical value for your own system. Just as with memory or I/O, we can see who the top CPU users are. We won't go through an example of this particular case. This system is being used to get a breakdown of CPU time by different processor modes -- look at MONITOR SYSTEM/ALL or MONITOR MODES. We want to look for high usage in this area. Because supervisor mode is used by the command language interpreter, a high rate there may be an indication you are using lots of DCL command procedures. Executive mode is used by RMS and some other database products -- DBMS, RDB, ACMS also use the executive mode. We expect this to be higher on systems using those products than on systems that aren't. Kernel mode is used for page faulting, locking, and most of the VMS system functions. We are going to look at an example of excessive kernel mode usage. Interrupt stack time is really kernel mode time -- time that can't be charged to any process. It is time that uses device I/O's in a VAX cluster to respond to requests from other nodes. We see fairly high kernel mode usage in this example from MONITOR SYSTEM -- 44-45 percent of the CPU is being used in VAX-45 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management kernel mode. We expect this to be below 25-30 percent on most systems. MONITOR does not provide a direct breakdown of kernel mode time, that means we have to do a little bit of detective work. If you had SPM and had anticipated these problems, some PC sampling would identify this kernel mode time. Some kernel mode usage is page faulting. Is the system page faulting -- we have looked at this area before. Are you doing lots of logical name translations; this is available on MONITOR I/O. If there is lots of file system activity, look at the CPU tick rate and MONITOR FCP. We have some examples of all these screens coming up. What's contributing to this 45 percent kernel mode usage? I'm presenting some numbers based on the capacity of the MicroVAX to do these systems. They are based on the CPU time to do specific operations. You would scale these numbers appropriately for other systems. This is an example from MONITOR PAGE. The MicroVAX can do about 2000 soft page faults per second and about 400 hard page faults per second based on the CPU capacity to process page faults. By looking at the number in these screens, we see there is only a fraction of CPU being used to process page faults. Page faulting is not a problem. We looked at memory in the memory investigation earlier by looking at this particular screen to check the number of page faults occurring, looking at the kernel mode time, and then moving on to doing a memory investigation. This is an example from the monitor I/O screen. An average logical translation rate is about 7 per second; a MicroVAX2 can do approximately 1000 logical name translations per second. We see less than one percent of the CPU is being spent processing logical names. This is an example from the MONITOR FCP screen. The CPU tick rate is the number of 10 milliseconds of CPU ticks spent in the file system and on the single processor system. This can be used as the percentage of time spent in the file system. We are spending less than two percent of our time in the file system. The file system is not a problem here. Are some other areas locking? Look at MONITOR LOCK, look at DECnet activity, and also I/O activity. The time doing all these processes is spent in kernel mode. VAX-46 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX/VMS System Performance Management Here is an example from the MONITOR LOCK SCREEN. MicroVAX can do approximately 1500 ENQUEUE operations per second, including the corresponding DEQUEUE operation associated with that. So 1500 $ENQ's, plus $DEQ's, and about 5000 converted ENQUEUE operations. Locking is not a problem for this particular system. This is an example from MONITOR DECnet. We see average packet rates of less than one packet per second. A MicroVAX can handle over 300 packets per second, thus DECnet is not a problem. Direct I/O and buffer I/O are also processed in kernel mode. This is an example from MONITOR I/O. MicroVAX can handle over 300 I/O operations per second. Less than a few percent of the system is being spent in kernel mode -- so none of the things we have looked at are a problem on this system. Where is this kernel mode time being spent? The last thing we can do, or perhaps the first thing, is check the top CPU users. Kernel mode time is charged to a particular process, and we can see which processes are using the CPU. Sure enough. We have our culprit here. It is the process Oliver Wendell. Forty-five percent of the CPU was in kernel mode. He is using 80 percent of the CPU, so it is likely that process was generating most of the kernel mode usage. Not only is this process doing a lot of change mode to kernel, we see this is a privileged user, doing privilege operations. We may also find that he has raised his priorities and can use more of the CPU than other processes. Notice we can identify which process is using the CPU because kernel mode time is charged to a process. This concludes the CPU investigation part. I want to mention one other thing -- image level accounting. This is very useful for identifying individual resource use on a particular image basis. You can see which images use lots of CPU, which images generate lots of direct I/O, which images do lots of faulting, and you can sort the output from image level accounting. VAX-47 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing Converting Code for Parallel Processing Spring 1987 US DECUS (Nashville) Symposium Session transcribed by Ron Frederick N.I.P.E.R. P.O. Box 2128 Bartlesville, OK 74005 There is a very important question to ask yourself before you begin to parallel an application. Do you really want to parallel this application? Whenever you approach parallelism, be aware you are making a trade-off. You lower your overall system throughput slightly to benefit a single application and give it the quickest turnaround time possible. As an example of this, let's assume you have five VAX8650s on a cluster. If you run five different batch jobs using distributed queue through the batch jobs you will get approximately 25 times the 780 compute capacity as system throughput. Each of those individual jobs will run at the speed of one 8650 or five times the 780. By employing parallel programming, we concentrate all five of those processes onto a single job with the goal of speeding the turnaround time for that job. This slide suggests 25 times the work of the 780 on your single job. That is, of course, the theoretical maximum you could do given this particular cluster configuration, however, there are various forms of inefficiencies. You won't really get 25 times 780, other than in very rare circumstances, more likely you will average somewhere around 18 to 20. Before you begin paralleling, ask yourself if your site is compute bound as is. Do you need to get 25 times 780 overall system throughput or is the single job important enough that you want to get 20 or so times 780 system throughput to concentrate on that one job. We expect most of the paralleled applications now coming into the market place to run single stream for most of the job. It's those last minute, very time critical jobs that will be run in parallel. You have to decide this before you begin paralleling. Once you make the decision to parallel, what do we have to help you. First, our Aid Services Division offers courses on parallel programming. We have technical documentation available through our sales force. There are examples in the DECUS library on doing parallel programming in shared memory systems. We have library calls in the same package in the DECUS library to provide routines to help you call these VAX system services. VAX-48 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing Rather than calling the system services directly, these routines package them in the way they are most commonly needed and used. What does this do to the issue of VAX compatibility? Any application paralleled for, say the VAX8800, will run on every other VAX processor all the way down to the VAX Station 2000 and the MicroVAXs. Parallel programming uses only a few features of the operating system. Normally we use the ability of setting up global sections, creating subprocesses, and coordinating the activities of the subprocesses through a event flags. Those three features are found on every member of the VAX family. That same job will run on the MicroVAX as well as on the 8800 in parallel. Next, we will look at the structure of a parallel application. We are going to look at basic questions of paralleling. How much of it has to be changed, how can you estimate the efficiency, and, once you know how to estimate, how do you improve efficiency? Finally, when is it reasonable to parallel an application? How much of a program has to be changed? The best news I can give you today is, thankfully, very little has to be changed. Most of the third party applications coming to market, like Meta Software's H FIST and the like, say one to two percent of their code actually needs to be changed. We are really adding a structure to the program to control how the existing algorithm will be run in parallel in different parts of the data set. Very rarely do you have to change the fundamental algorithms of the application. You also may have to change the data structure slightly to better facilitate parallelism. I have some examples of that and a few slides. The execution flow in a single stream code is very simple as shown on the slide. The job starts on the left- hand side of the slide, continues running for some time and, eventually, completes with the right answer. In parallelism, the execution flow gets a bit more complex. The job still starts out in single stream code, but at some point it fans out into parallel sections -- those fan-out sections are the five horizontal lines -- comes back into more single stream code, fans out again in parallelism, and continues this until finally the job completes. I do have five horizontal lines on there. Only two would imply that these techniques only work for dual processors, which I do not wish to imply. These techniques work for any number of processors. If I had any other even power of two, you may infer to the next processors coming from Digital. Five is a nice safe VAX-49 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing number to get the point across without implying too much. Obviously, going from an execution flow in single stream code, like this, to the more complex parallelism execution flow will require use of controlling constructs. There are two basic types of constructs you may wish to add. One is task scheduling, which we will get to in a couple of minutes. It's a way of improving your efficiency. The second is barrier synchronization. As you can see where the lines are coming out of the work barrier synchronization, we control the transitions from single stream code into parallel sections and out of the parallel section into the single stream code. In more formal terms, barrier synchronization blocks further execution until all of the processes involved in this application have reached a certain location. Let's go back one slide, assume we are dealing with that left parallel section and that we are ready to enter into the single stream code. Let's say that single stream code in the middle is going to write a temporary file giving our results at that point. It would be very impolite for the main process to write out that answer before all the answers are calculated. Barrier synchronization ensures all the processes involved in doing the calculations in that left parallel section have completed their work before we use that data for something else. Barrier synchronizations normally are implemented by using the event flags. Event flags are provided by the operating system and are a very easy means of putting processes to sleep and waking them up later when we are ready to begin the next parallel section. There is another other decision to be made when implementing parallelism What will the last process do when it finishes the parallel section? Let's say that middle section -- the single stream code in the very middle of the slide -- was only re-initializing an array for some function that did not have anything to do with the I/O. Any processor or subprocess participating in our application could implement this function. The most efficient way to parallel this case would be to have last subprocess to complete this parallel section, then do the single stream code, and then awaken all the other processes and subprocesses at the start of the next parallel section. If, however, we were writing on a temporary file, the I/O channels would be run by the main process. In this case, the last subprocess to complete would wake up the main process. VAX-50 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing The issue of which process continues after the last process has finished the section really is a simple one. The question is what happens in that single stream code. Can any process do it? If so, for efficiency let the last process continue. If this must be done by the main process, again I/O is the usual case, you have to waken the main process. Those are really the only two issues on implementing barrier synchronization. What does the last process do when it completes and how do you implement what it does? Usually these are implemented by the event flags. There might be other, better ways for implementation in your particular case depending upon your application. Task scheduling is generally the next controlling construct added. A very inefficient way to parallel something, as we will see, (say we are on a dual processor system) is to chop the work in half and assign one-half to the main process and one-half to a subprocess. That can induce a lot of inefficiencies. The opposite of that approach is called task scheduling. Each subprocess, or the main process, dynamically determines which one will do what piece of work simply by which one is finishing up pre-existing work. Putting that again, every process allocates a piece of work to be done and whenever it finishes its own piece, comes back to allocate the next piece available for work. This sounds complex to implement. The five lines of FORTRAN on the screen usually are all that is required to implement this. Use the interlocked instruction to create what is called a critical section -- a piece of code that guarantees only one process can be in at a time. We don't want multiple processes here because we don't want to have two processes all doing task number 17 for example. You want to guarantee that one does 17 and one does 18, therefore, we use a critical section to guarantee only one process can come in at a time. The next line simply takes the shared variable that will contain the next task number, grab a local copy of it (say it is number 17), increment it for the next task, and free up the locks so the next process can come in. Then you want to make sure the number you received is still a valid task number. If there are only 100 tasks defined in this parallel section, you don't want to execute number 105. We will see that, task scheduling can return a great efficiency for the penalty of a very simple code being added to the program. There are some potential data structure changes you may wish to make and these data structures usually take two separate forms. The first one involves eliminating subprocesses that require an answer from another subprocess and the second type involves multiple subprocesses trying to write into the same shared VAX-51 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing variable at the same time. Look at the first of these, the subprocess requiring an answer from another subprocess. Let's pretend for a moment we are going to parallel the following do-loop -- just going from one to 10,000, take a location in the A array, Ai equals the next location at the same array multiplied by Bi in the end of the loop. I hope you will see later on this loop is too small to efficiently parallel directly. I'm merely going to use this as an example of a subprocess requiring an answer from another subprocess. The problem here is the "Ai plus one term" being used as input to the operation of the particular iteration. What happens if the particular iteration has already completed work. Let's look at the fifteenth and sixteenth iteration. If the sixteenth iteration is assigned to some process and has finished and modified A16, whenever the fifteenth iteration tries to access Ai+1 for that same sixteenth location, it will receive the wrong information. Subprocesses requiring answers from another process have two forms, one of which is an actual value that gets passed to the other process, but the other form is more tricky. The requirement is the knowledge that the other process has continued beyond a certain point. The fifteenth iteration has for example already read the sixteenth value of A before the sixteenth iteration can continue. Paralleling directly and putting in locks to force the fifteenth to finish before the sixteenth can continue would be very tricky here. As in a lot of cases of data dependency, There are other very simple ways around data dependency. One way relies on the realization that in the single stream code, i always goes from 1 to 10,000. Incrementing that, the Ai+1 term that is referenced always references a value in A that was there before the do-loop was even started. There is an easier way to parallel this. Rather than trying to put controlling constructs into this do-loop to prevent them stepping on each other, simply copy the A array into a temporary array and modify the original do-loop to reference the temporary values rather than the original A values. Now we have two loops that can each be run in parallel very efficiently with no data dependency. You can now run that second loop in reverse from 10,000 to 1 and it will make no difference. Every iteration will get the proper value it expects -- the original, proper value in the A array. The use of temporary arrays is a very common technique for getting around data dependency problems in paralleled code. What looks complex is the locking mechanism. You can very often get good efficiency by using temporary arrays and eliminating data dependency. VAX-52 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing The other type of data dependency is multiple subprocesses writing to a shared variable at the same time. Here is a classic case in computer science of two processes trying to do "i equals i+1" at the same time. The results are really predictable if two or more processes are trying that at the same time. It simply becomes a race condition of who has read memory, incremented it in its microcode, and written it back out. Chances are very good that race condition eventually will turn around and hurt you by giving the incorrect answers to the program. Finding areas where multiple processes could be writing to the same shared variables and stopping that from occurring are key. Pretend we are going to calculate pi to some absurd number of decimal places, like a million or so. The classic equation for this being that pi is 4 times the series 1-1/3+1/5-1/7 -- on ad infinitum until we finally complete the four millionth decimal place. We are trying to stop two or more processes from being able to write their value into the same array location, in this case array location 1,000, at the same time. To calculate this to a million decimal places we store the numbers in a million-entry array for extended precision calculation. There are three different techniques you can apply in parallel programming to eliminate this kind of problem. Not all three work in all cases. The first case involves segmenting the work to eliminate the data share. This is by far the most common way of approaching this problem and works in a vast majority of cases. In this particular case, sad to say, it won't work. What do I mean by segmenting the work? Let's say we are calculating the "1 divided by 21st" term. We could have all of the processes participating calculate "one divided by 21" out to a million decimal places and then participate in adding or subtracting from the main pi array. If this is broken into groups of 1,000 digits, the first 1,000 have to be completed before we can start to calculate the 1,001 digit. Therefore, we are really back to single stream code. Segmenting the work is not useful for us in this case because part A has to be completed before part B can begin working. Look for places where both A and B can be done at the same time if you segment the work. The second common way is to have a separate lock for output location. In this case, we will assign each subprocess a particular term in the series. One process will do the entire "1 divided by 21" out to a million decimal places. Before it updates this pi1,000, the process will access a lock, gain exclusive ownership of that lock, write the value (adding or VAX-53 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing subtracting as the case maybe), release the lock, and continue on calculating the 1,001 digit. This technique will work for an even number of variables, though if we are dealing with a million lock variables the continual locking, updating, unlocking, and moving on to the next digit will be prohibitively expensive. This method works for a small number of variables but is not good when you are dealing with arrays the size of a million. The third common method, and the one that will work quite well in this case, is for each process to have its own temporary work array with a single permission to modify the master array lock being in place. One subprocess calculates "1 divided by 21" out to a million decimal places into its own temporary array, allocates a single lock that grants it the right to modify the master pi array, does its addition or subtraction, and then frees up that lock. In this case, there is more memory to choose from. Each process must have an additional one-million element array. Paralleling this way will give you good efficiency with very little overhead. These are the three most common techniques of approaching the problem. Which of these is best suited for an application depends totally upon the application. By looking at this slide, we begin to see the degree of the original program to be modified. On the left, we show what you could consider to be the virtual address range of the original single stream code. In the center and to the right we modify it by adding the parallelism additions in the yellow column. There are various controlling constructs in the code that have to be added as the yellow shows in the vertical bar. Some of these techniques have been mentioned using temporary arrays as ways around parallelism problems. These are in the yellow box off to the right. Generally, there are more temporary arrays added to the program. If you look at the percentage of yellow versus orange, the percentage of yellow on this slide is highly exaggerated. As I suggested before in the earlier application, one to two percent needed to be added. McNeil-Schnedler's is in the same category -- about one to two percent. Abacus is the same way. We felt we used enough applications to begin to see a pattern. Very rarely, if ever, will you need to go as high as five percent addition or modification to the original single stream code. The best news is that time investment to the original single stream code for the most part is preserved. You are not throwing out the original code and rewriting it. You are merely adding parallels and controlling constructs around the algorithms that already exist. VAX-54 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing The next section is how to estimate efficiency and, as a side corollary, how to prove the efficiency. There are really four important metrics to consider. How much work is in each task we are doing the allocation on, how expensive is this task scheduling, how many tasks are there compared to the number of processors in the machine, and, finally, how expensive is the barrier synchronization concept. We will look at most of these in a few slides. How expensive is the task scheduling? Recall the five lines of FORTRAN code on the screen. The compiler will turn those into 16 to 20 VAX instructions to implement the task scheduling. By implementing this in MACRO, you can call the interlocked instructions directly and bring the number down to about six or seven. We will average this, for convenience, to 10 instructions required to perform the task scheduling overhead. The absolute number is not important. What is important is the ratio between the size of the task scheduling and the amount of work in each task. How much work is there going to be in each task? In general, the larger the task, the better off you are going to be. You can go overboard though and start to run yourself into inefficiencies by having tasks that are too large. The ratio between the task scheduling overhead and the amount of real work being allocated in that task is one of the key factors in the efficiency you receive from parallel programming. This is by far the most important thing to keep in mind. What can happen if you don't have a good ratio? The top of the slide shows the very bad situation of a high scheduling overhead. Each block refers to one VAX instruction (for convenience sake I've made them all the same size) and the two lines are the two processors in today's dual processor systems. The task scheduling for purposes of this talk will average 10 instructions. The 10 instructions of overhead are shown in the 10 yellow blocks that occur before the real work begins. The real work in this case shows as the three instructions in green. We are going to go through 10 instructions of overhead to execute three instructions of work. That results in seven instructions equivalent worth of time blatantly wasted. The process cannot execute because there is no more work already assigned to it, nor can it begin the task scheduling -- that is something that only one process at a time can do. If you mentally overlap those two lines we are running this original program, we are running the parallel program at 30 percent the speed of the original program and burning up two processing elements getting there. This is not a situation to get into when you are parallel programming. It is very important to make sure that your task size and the amount of real work compares VAX-55 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing favorably to the size of the overhead. We see a situation at the bottom of the slide where the task scheduling overhead is significantly better. Before anyone accuses me of cheating and dropping task scheduling to a single instruction, please note the scale at the bottom of the slide has changed. This new scale is one block equals 10 instructions. This shows the relative efficiency of having that 10 instructions of overhead, but now instead of only doing three instructions of real work we are going to allocate 100 instructions of real work. This shows quite graphically that just making that slight change in the program dramatically increases our efficiency from running at only 30 percent of the speed of the single processor version to now running about 1.8, 1.9 times efficiency, if not better. How do you change an algorithm to get significantly larger tasks in only three instructions? We are going to look at a matrix multiply operation, envision different ways to parallel it, and see what the results would be. This is going to be a 100 by 100 matrix multiply. The inner loop, the calculation to do a single output location, is shown there on the screen. As quick reminder, in a matrix multiply operation we multiply each of 100 elements in the highlighted row in matrix A by the appropriate 100 elements in the highlighted column B and add it into the single highlighted location in the C array. We could parallel each one of those do-loops with each iteration of the do-loop as a separate task. If you look at the number of instructions required to do the multiplication and addition, you see we are down to around three instructions. Given the average of 10 instructions of overhead, this leads us directly into the overhead problem on the top half of the slide. Clearly that is not an efficient way of paralleling. We could assign the tasks as "do all the calculations required for a particular location in C." In this case, one task would do that entire inner loop for the highlighted location in C and the next task would do all the calculation for an adjacent location in C, or somewhere else in the array. Now instead of having three instructions with the 10 instructions of overhead, we are up to about 300 instructions. Now we have one-third the scheduling of overhead shown at the bottom of the slide. That slight change in approach to paralleling leads us from the horrible inefficiency at the top of the slide to only one-third the overhead that's at the bottom of the slide. It is very important to keep the task size in mind when you are doing parallelism. VAX-56 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing There are other ways we could parallel this. We could parallel a task being one output row or column and end up with 30,000 instructions in a task. At that time you almost wouldn't see yellow any more. We could parallel it where a task is one-tenth the output matrix and be up to 300,000 or we could go overboard as shown in the next slide and simply divide the output matrix in half (if we are on an 8800 today) and have 1.5 million instructions per task. There are inefficiencies involved in this level of parallelism, the high end, but I will be showing this on the next slide. How many instructions per task do we see on actual applications? We see multiple thousand instructions. In HSPICE, the calculation for each instruction is on the order of 2,500 to 3,000 VAX instructions. Paralleling it was a natural way that the program was paralleled. We didn't have to do anything special to get it to that level. We simply looked at it and said what is a reasonable way to parallel this and that task size naturally came out of it. Simply looking at any level other than the very tight three instruction do-loop I showed you earlier often will result in task sizes large enough to drive the parallelism inefficiency down to a level that is hardly noticeable. It is very easy to get tasks of appropriate size. What is a good ratio between the number of tasks and the number of processors you can have participating in this? A one-to-one ratio as in the last slide. Simply saying "We are on a dual processor today -- let's cut the array in half and assign one-half to each side" is very inefficient. The problem here is twofold. First off, you the programmer would have to decide where that halfway point is. In something as straightforward as a matrix multiply, this is not difficult to decide, however, it is nearly impossible at programming time to know what the customer's circuit simulation is going to look like and be able to divide it in half. It is a very difficult thing to do in most circumstances. You hope computing progress will be identical for every process and subprocess involved in your application. A goal of parallel programming is to have every piece of your job that is participating in a parallel section complete that parallel section in as short a time as possible, or in as similar time as possible. VAX-57 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing If you divide the matrix in half and one half hits a half dozen page faults, that particular process (half of the array) is not going to complete at the same time as the other. While those page faults are being serviced and that half of the array is being calculated, the other processor is not doing anything. This is very inefficient for parallelism. A one-to-one ratio is clearly not good. You have to make too many assumptions, both in the program and in the computing progress of your processes. A 10 to 1 ratio is a nice figure to try for. With a 10 to 1 ratio, if you do hit some page faults or if one of your processors does go out on the compute queue for a little while, there are enough other tasks left around the processes that are running on the processors still have more work to do and you can keep your efficiency very high. It doesn't mean you have to shoehorn your program to get exactly a 10 to 1 ratio. If I were paralleling the 100 by 100 matrix multiply, I'd probably make each task an entire output column. This would give us 100 tasks or, on today's 8800, a ratio of 50 to 1. Ten to one is a nice number to shoot for; there is nothing magical that says a 9 to 1 or 11 to 1 is going to run you into inefficiency. Finally, the expense of barrier synchronization. Barrier synchronizations are implemented using the event flags as system services much of the time. As with any system service, there is little overhead in calling them. In this example there are about 500+ instructions hit whenever you do an event flag system service. You therefore should make sure your parallel section is going to be large enough to justify this additional overhead and still return good efficiency. In a 100 by 100 matrix multiply with about 3 million instructions, clearly 500 instructions of overhead will not factor into anything substantial. If you were trying to parallel a three by three matrix multiply, or a four by four, the event flag system service would utilize most of the time and would be very inefficient. Make sure the parallel section is big enough to justify the overhead of starting a parallel section. There will be times when you will not want to parallel something. That sounds like a strange way of ending my talk. I've been saying it's easy, you only have a half dozen things to watch out for and parallel programming really is easy. There are only a half dozen things to watch out for, but there are some situations which you should not or do not want to parallel. The first one simply involves the overhead consideration. If paralleling results in tasks too small relative to the overhead of scheduling the next tasks, you would not wish to parallel in that way. You might be saying, it's easy to get 100 VAX-58 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing instructions versus 10 instructions of overhead in the shared memory systems. In particular I am thinking about paralleling across the VAX cluster or, worse yet, paralleling across DECnet. Now the amount of time to allocate the next task is not 10 instructions; it can be measured in the thousands. If the amount of real work to be allocated does not scale up to the appropriate ratio and overhead is doing the task allocation, this is going to become too great. There are some cases where overhead considerations will be so high you really won't want to parallel the application in the style that you are approaching. The second consideration is the overall system throughput. There is a trade- off in parallel programming as I showed you in the example of the five 8650 cluster. You are saying I'm willing to accept slightly lower overall system throughput in exchange for a significantly better single job turnaround. In most cases I would suggest that running multiple batch jobs on the 8800 is the most efficient way of using it. Parallel programming really pays off for those critical last minute jobs at the end of the design cycle, when you are willing to trade away a few percent in throughput for this overnight job being able to run during the daytime. Finally, the third consideration for not paralleling something is called Amdahl's Law of Parallelism Paybacks. In short, this says the potential payback from parallelism is directly related to the amount of the program that can be run in parallel. Let's say we have a hypothetical program with 16 minutes of fully parallelable material and zero inefficiency calculations. There are 10 minutes of initialization code and, at the end, 10 minutes of results storing, writing out a report file, or whatever. We could parallel that parallelable computation section and not get down to 30 minutes of real time. Instead of this job dropping from 80 minutes of execution time to 40 with 100 percent parallelism over two processors, we see the execution time really drops to only 50 minutes. We will end up with a 1.6 times faster application. We have perfectly paralleled the parallelable areas, our tasks are large enough, there is zero scheduling of overhead, and we still did not achieve a 2.0 times throughput. We are still stuck with the 10 minutes of initialization code and 10 minutes of results storing. A 1.6 times speed up on an 80 minute job now taking 50 minutes is a considerable speed up and is probably worthwhile for a critical application. If this only had six minutes of calculation that we could drop down to three, our overall job time is only going from 26 minutes to 23. That is hardly worth the hassle of parallel programming. Before you begin to VAX-59 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing parallel something, be sure the process is going to spend enough time in the particular sections you want to parallel for parallelism to be worthwhile. In summary, parallel programming is doable, is doable today under version 4.x whatever at VMS, as is shown by some of these commercial applications being marketed in parallel form. It does not mandate a total rewrite of these applications, most of these programs are saying definitely under five percent. Usually one or two percent of the code needs to be modified and can return a very high efficiency. Before you ask about the performance of those third party applications, I can't answer. You have to be sure any new programming technique is applicable to the program. Be sure you are willing to make the few percent trade-off on system throughput and that you are spending enough time in the paralleled sections for truly good payback. With that I will open the floor for any questions you may have. Q: Dave Marlin, American Electric Power. There are two aspects to parallelism. One of them is what you have been talking about, performance increase; the other is fault-proof systems. You are running the same applications in parallel and comparing output. Is DEC's approach to that type of parallelism going to be enhanced in future cluster releases? A: We can't comment on future directions. Q: Is there going to be any direction on that or is DEC going to depend on the very low mean time failure of the processors to ensure that this is not really necessary. A: Answering your question would be answering in a way I can't answer. We can't comment on future directions, though basically high availability is what you are asking for. I cannot answer that. Q: In the other aspect, the performance aspect, you have two processors and, am I to utilize an 8350 or an 8000, is it going to be necessary for me to go back and rewrite a lot of my user mode applications. As I understand kernel mode, a lot of my own intensive processes cannot be used in that second processor. Will I be required to rewrite a lot of my applications or A: Rewrite when? VAX-60 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing Q: When I add the second processor or is VMS going to throw user mode processes out there. A: If you wish to take advantage of parallel programming to speed up single job turnaround, you have to implement parallel programming within it yourself. If you wish to use it as a multiple batch job compute engine, you do not have to do any reprogramming. VMS will schedule your jobs automatically on the separate processors. Parallel programming you must do yourself. Q: Right now, out of the VAX environment, in an RST environment we run 14 KXTs on a single backplane. KXTs -- an important difference. That's doing very well for us. We are anxious to get into the VAX at that level. A: I'm sure you will find that parallelism on the VAX is very easy and gives you good efficiency. Q: Nowlin Olsen, Scientific Computer Systems. How strongly do you emphasize checkpoint and restart and how is that significantly changed when going to parallelism? A: Checkpoint restart is more like a VMS question than a parallel programming question. Q: If you have a very large compute intensive job, I guess I'm asking how much emphasis needs to be applied to building in checkpoint and restart to do that job? A: You mean adding your own checkpoint and restart to a particular application? If I have a very large compute-bound application, just internal number crunching very similar to the pi application, I do my own checkpoint restarting within it. If a job is going to run for multiple days, multiple weeks, it would make sense to protect your investment. That's my personal opinion. That says nothing about where DEC's direction is going in checkpoint and restart. Q: In that level of checkpointing restart, it seems to me the complexity increases when you go into the parallel programming. A: Really, I don't believe the complexity would increase that much. Parallel applications fan out into the parallel section to compute the cycle of circuit simulation, for VAX-61 PAGESWAPPER - November 1987 - Volume 9 Number 4 Converting Code for Parallel Processing example, then come back into single stream code to do some maintenance and clean-up. I would see checkpoint restarting as something to be done in the maintenance portion in single stream code where everything is at a known state. It really wouldn't be hard to add. INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. ================================================================ Note 421.1 ReGIS to GKS/0b Conversion 1 of 5 "Mack W. Haynes, Jr." 10 lines 22-SEP-1987 09:17 -< GKS/0b - A suggestion >- ---------------------------------------------------------------- I have submitted SPR's to DEC requesting that all software supporting Regis output also support GKS/0b since Regis is now a dead product and DEC has thrown it's support behind the GKS standard. Additionally, SPR's have been submitted requesting that the DEC GKS/0b software support standard output devices such as Electrostatic plotters and Laser Printers. Many of us in the industry use these devices as standard output. I would like to request that others with similar situations make like requests to DEC. So far, DEC's response has been "We're investigating the possibility". Mack W. Haynes, Jr. Tenneco Oil Co. 1100 Louisiana VAX-62 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT MS: IFP2954 P.O. Box 2511 Houston, TX 77001 (713) 951-1118 ================================================================ Note 421.2 ReGIS to GKS/0b Conversion 2 of 5 "Bill Mayhew" 21 lines 22-SEP-1987 10:06 -< ReGIS: Dead or Alive? >- ---------------------------------------------------------------- Is there more detail about this "ReGIS is a dead product" notion? I have seen the press notices that the "ReGIS Graphics Library" is a dead product, but not ReGIS itself. The distinction is that the RGL is a distinct layered software product providing an interface to ReGIS for the applications programmer, while ReGIS itself is a graphics communications protocol embedded in the firmware of the VT125/VT24x/VT3[34]x et al., which causes a stream of bytes to be converted to a graphic image. My perception of GKS is that it, too, is an application programmer's interface, not a communications protocol. Thus, GKS could be implemented to talk to any of several device-dependent or -independent communications protocols, and that, therefore, there would need to be something like a GKS-to-Sixel software module to talk to LN03s, for instance. I am certainly not a graphics software wizard, however, and what graphics I do tends to be either directly at the protocol level (i.e. ReGIS) or depends on intervening higher-level products. Is my perception accurate? What sort of communications protocol is being advanced as a replacement for ReGIS? PostScript? Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-63 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 421.3 ReGIS to GKS/0b Conversion 3 of 5 "Bob Hassinger" 32 lines 22-SEP-1987 11:42 -< Some thoughts about GKS... >- ---------------------------------------------------------------- 1) The DEC product has not been "GKS/0b" for quite some time (that was V1 I think). Version 3.0 is in the field ("VAX GKS"). It now implements level 2c, the highest level defined in the GKS standard. 2) VAX GKS V3 supports user written output drivers so you can support what ever you like if you want to do it badly enough. It is not likely we are going to see DEC supporting too many non-DEC printer protocols I would think. V3 does support the LN03-Plus and the LN03R as well as Postscript printers in general. They do not seem to support the LN03 however. 3) There is work being done on standardized device level graphics interfaces that would more or less do the same job Regis does. The future there is not real clear to me yet. 4) As to software products that speak Regis getting a GKS interface: In general the software has to be linked to the GKS library so, in the VAX GKS case, users must be licensed for the run time library at least if not the full package. Any product that is built this way could be used by any user with the RTL to work with any supported device. The RTL license is a serious issue here however, as it is for FMS applications for example. It is also very tricky to write code that uses GKS and which produces GOOD results with all supported devices - their characteristics vary FAR too much. Regis is a MUCH simpler case because the number and type of devices and the variation in their characteristics is MUCH smaller! GKS is a big step forward but true device independent graphics is still a long way off. Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-64 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 421.4 ReGIS to GKS/0b Conversion 4 of 5 "Chris Erskine" 17 lines 25-SEP-1987 08:42 -< Differences between REGIS and GKS >- ---------------------------------------------------------------- Looking at the VT330 and VT340 terminals, I do not think you can say that REGIS is dead. DEC has just learned how to make REGIS run faster. As stated, REGIS is the device protocol and has nothing to do with GKS. This is like the Tektronix 4010 graphics protocol or the HPGL protocol that is used by other display devices. GKS is the graphics interface to the application programmer and is used to replace the different graphics that everyone had for their machine. This standard is designed that a person who writes code on a VAX with DEC's GKS package can take the same program and use the code on another machine with a GKS package. It is the device drivers which is part of the GKS system which talks REGIS. Chris Erskine 6001 Adams Rd. Bloomfield Hills, MI 48013 (313) 258-4049 ================================================================ Note 421.5 ReGIS to GKS/0b Conversion 5 of 5 "Jack Patteeuw" 15 lines 29-SEP-1987 13:23 -< More features from the VT330 >- ---------------------------------------------------------------- re: .3 "There is work being done on standardize device level graphics interfaces ..." In fact the GKS subcommittee (is it from ANSI or ISO or both ?) has proposed (and I think include in level 2c) a "metafile" format for the passing of graphics information between system (software and/or hardware). VAX-65 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT I have heard a rumor that the VT330/340 supports this metafile format directly (or will in the near future). This would mean a significant improvement in drawing speed because the CPU would (theoretically) have less layers of translation to go thru to get to the final device format. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 601.6 high-speed dialup modems? 6 of 6 "MICHAEL GRATTAN" 20 lines 3-SEP-1987 08:55 -< Check the Mileage >- ---------------------------------------------------------------- We have been using Anderson Jacobson 9631-S between our central office here in New Bedford, Mass. and our warehouse in L.A. on the dial-up network. (The 9631 is a 9600 baud sync. modem for leased or dial lines.) We are going dial-up while we wait for the leased line to be installed. Dial-up has been VERY disappointing. We have had to use the fallback speed (4800 baud) and the line quality has been so bad that the line has dropped in the middle of a session. It's a huge headache. I think that the modems are just fine. However, I would strongly caution anyone considering a high speed modem for dial_up to look at the distance involved. Local connections were fine and fast, but long distance is a killer. Murphy's nth Law of Data Communications: Line quality is inversely proportional to distance. ;-) MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 VAX-66 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 631.2 RA81 FCT File Format 2 of 2 "Offline Submission" 13 lines 29-SEP-1987 12:35 -< RA81 FCT File Format >- ---------------------------------------------------------------- The factory volume id occupies the first 64 bits of the RCT - block 0. This can be read, a block at a time, using a physical function from the area immediately following user data. (for RA81, P3 = 891072). Bill Noble Shell Canada Box 100 Calgary, Alberta T2P 2H5 Telephone: 403-232-4370 September 11, 1987 ================================================================ Note 693.18 Opening a file with NIL sharing 18 of 19 "Jack Patteeuw" 20 lines 22-SEP-1987 17:58 -< Problem solved ! >- ---------------------------------------------------------------- VMS V4.6 solves the problem ! To quote the release notes, page 2-17: "The Version 4.6 VAX C Run-Time Library supports file sharing when you use record mode to access files; you must use the ctx=rec file attribute with all file open functions. Specify the shr=xxx (ie. shr=nil in this case; jp) file attributes as appropriate." In addition ... "Version 4.6 improves stream I/O facilities in the VAX C Run-Time Library. You can now specify the mbc=xxx file attribute when opening stream files. The value for this attribute specifies the number of blocks to allocate for I/O buffer. Reads and writes are performed doing this block size." VAX-67 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT It is implied that these functional improvements are only available if VAX C V2.3 and VMS V4.6 are both installed. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 702.6 Planning an Ethernet 6 of 8 "R. Michael Dupont" 18 lines 1-SEP-1987 17:59 -< More features for less spectrum >- ---------------------------------------------------------------- We are currently using our multi-plant broadband system for video and data, and since we will be adding even more channels our spectrum space is considered scarce. We initially looked at both the Digital and Chipcom modems, but felt the 18 MHz could be better utilized. Even before Chipcom announced their new line which uses only 12 MHz, we found and tested a product that only requires 6 MHz of broadband and still gives us the full 10 MHz of baseband Ethernet. The unit also acts as a bridge, filtering local baseband segment traffic from the broadband "backbone" segment. Several months of beating on the units (BETA) have shown us the units induce no performance degradations to the Ethernet (802.3 as well) traffic. Non-disclosure prohibits my revealing any further details, but I will say the product is not from DEC or Chipcom. R. Michael Dupont EDS 2925 West Minnesota Indianapolis, IN 46241 VAX-68 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 702.7 Planning an Ethernet 7 of 8 "Chris Erskine" 23 lines 2-SEP-1987 08:53 -< A poor way to reach broadband >- ---------------------------------------------------------------- Even before Chipcom announced their new line which uses only 12 MHz, we found and tested a product that only requires 6 MHz of broadband and still gives us the full 10 MHz of baseband Ethernet. Ungerman Bass has a device called a buffered repeater h works in a 6 MHz channel. We found that it has a couple of problems. They do not do any collision detection on the broadband section of the media. This breaks part of the ethernet standard which states that the message will be transmitted since the trashed packet from the buffered repeater is dropped. UB states that it is the responsibility of the upper protocol to handle the lost packet. This is fine with ethernet not always receiving the packet but will cause some problems with DECnet on RSX machines. The minimum retransmit time for RSX is about 4 sec. I was told by DEC that this time would be fixed but so far I have not heard of the fix. I do not know if there are any other protocols which have such a long timeout value which will cause the same type of delay but I do not like to add devices which help add such a delay to the network. Chris Erskine 6001 Adams Rd. Bloomfield Hills, MI 48013 (313) 258-4049 VAX-69 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 702.8 Planning an Ethernet 8 of 8 "R. Michael Dupont" 25 lines 4-SEP-1987 17:59 -< Better (much better) than a Buffered Repeater >- ---------------------------------------------------------------- Ungerman Bass has a device called a buffered repeater which works in a 6 MHz channel. We found that it has a couple of problems. They do not do any collision detection on the broadband section of the media. This breaks part of the ethernet standard which states that the message will be transmitted since the trashed packet from the buffered repeater is dropped. We also have tried the Buffered Repeater, with the drawback of being on the same broadband channel as all of our terminal traffic (400+ sync and async combined), and the buffered repeater pulls all of those packets onto the baseband segment, along with the desired traffic from the any remote buffered repeater. The unit I alluded to before is an announced product from Applitek. It uses vector phase technology (much like the 9600 baud modems over phone lines) to squeeze 10 MHz into the 6 MHz broadband channel. They went "buffered repeat" one better by adding "Bridge" functionality to the unit. This keeps local traffic local and doesn't clutter up the broadband "backbone" connecting the local segments. The bridge can be programmed to filter if desired, but we have no wish to do so at our site. R. Michael Dupont EDS 2925 West Minnesota Indianapolis, IN 46241 VAX-70 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 719.3 BACKUP status codes 3 of 3 "Marc Lippmann" 9 lines 23-SEP-1987 10:02 -< Improve F$MESSAGE >- ---------------------------------------------------------------- One (I think) extremely valid possibility would be to allow the specification of a message file as an additional parameter to the f$message lexical function, i.e.: $ MESS = F$MESSAGE($STATUS,"SYS$MESSAGE:SYSMGTMSG") or even better, allow a list, such as $ MESS = F$MESSAGE($STATUS,- "SYS$MESSAGE:SYSMGTMSG,SYS$MESSAGE:CLIUTLMSG") Marc Lippmann PO Box 355 210 Grove Street Franklin, MA 02038 (617)528-6200 X330 ================================================================ Note 722.1 Long Distance Data Communications 1 of 1 "JIM PALMER" 23 lines 11-SEP-1987 13:05 -< Satellites and DECnet >- ---------------------------------------------------------------- We have been using a satellite service to connect DECnet nodes between here (Irvine, Ca.) and Miami, Florida for a number of years. We are running a single 9600 baud SYNC line via 2 DMF's and associated modems. The service is fairly reliable. (about 97%) uptime. However, we use to have a dedicated AT&T land line between the exact same nodes. The land line was absolutely 100% reliable, with no light speed delay. The reason that we switched was to save money. Since the DECnet traffic on that particular wire is fairly light, the satellite link is workable. VAX-71 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Our carrier is a company called American Satellite. JIM PALMER 3 BROOKDALE IRVINE, CA. 92714-3338 (714) 458-3028 ================================================================ Note 740.0 Quasi-dynamic Priority Adjustment 3 replies "Dale E. Coy (505) 667-3270" 23 lines 4-SEP-1987 14:15 ---------------------------------------------------------------- We are experimenting with using a dynamic priority adjustment routine. The basic idea is to lower the priority of jobs which are compute-bound, so that they interfere less with people doing edits, etc. Of course, there's more complexity than that. In particular, lowered priorities sometimes need to be raised again. We're using a MACRO code written a while ago, updated for VMS 4.x, but we're also looking at SMAUG from the VAX86C tape. Both our code and SMAUG use SYS$SETPRI. Very occasionally (like once a month) we see some process which should have a maximum base priority of 4 get raised to 15. Of course, nobody does anything until the process completes. Possibilities include: 1) A bug in our code which we haven't found yet, and 2) A tiny problem window somewhere in SYS$SETPRI. Before we chase too many phantoms, has anybody else seen a similar problem? Particularly with SMAUG? Comments on whether we're totally crazy to consider this will also be considered. :-} DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-72 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 740.1 Quasi-dynamic Priority Adjustment 1 of 3 "Bruce Bowler" 20 lines 8-SEP-1987 09:15 -< the culprit is $GETJPI >- ---------------------------------------------------------------- Dale, We too experimented with a 'dynamic priority adjuster' from one of the sig tapes. I don't remember which tape it came from but the program is called ZEUS. We saw a similar problem with jobs occasionally getting a boost to 14/15 and after numerous calls to DEC discovered that the problem is not with $SETPRI as I had expected, but rather with $GETJPI and the scheduler. It turns out that in order to get some of the information that can be retrieved from $GETJPI a (kernel-mode?) AST must be delivered to the target process and, due to the combined bug with $GETJPI and the scheduler, this raises the priority of the target process to that of the requesting process. We were running ZEUS (and several other process monitoring processes) at priority 14/15 in order to get (what we thought were) the most accurate readings possible. When we lowered the priority on these guys down to 6 the problem still existed but to a much less damaging extent. Interestingly enough, it appears that this is not a problem with the requesting process is run at one of the 'real-time' priorities since SPM runs at 24 and we see no inordinate priorities on our timesharing jobs. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 VAX-73 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 740.2 Quasi-dynamic Priority Adjustment 2 of 3 "Jamie Hanrahan" 20 lines 8-SEP-1987 15:54 -< It's not a bug; it's correct behavior >- ---------------------------------------------------------------- < Note 740.1 by NODE::US140424 "Bruce Bowler" >... ..is correct; however, the reported behavior of $GETJPI (the scheduler has nothing to do with it) is not a bug, but quite intentional. The reasoning goes like so: Process A does a $GETJPI on process B, which has a lower base priority. To get the info, $GETJPI sends a special kernel AST to process B. Thus, process A can't continue until process B does the AST. Process B's priority is boosted to equal process A's to avoid a potential deadlock which might be caused by having a high- priority process dependent upon action by a lower-priority one. Note that B's boosted priority will fall back to its normal range as soon as B has been rescheduled a sufficient number of times (15 times will always be sufficient). Running process A at a real-time priority (16 or above) will not cause B to get priority boosts for the $GETJPI calls. This is because a priority boost that would take a process into the real-time range is never applied. Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 VAX-74 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 741.0 750's and LAVC's 7 replies "JIM PALMER" 57 lines 7-SEP-1987 23:23 ---------------------------------------------------------------- We have just finished retrofitting our mixed network of 750's and MicroVAXes to connect via the NI/ETHERNET medium with encouraging results. Naturally, the next logical step is to configure a LAVC. According to all LAVC literature that I have, and all DEC sales reps that I have talked to, it is NOT possible for a 750 to participate as a satellite (as opposed to a boot member) in a LAVC. From an engineering perspective, I can see no technical reason why such a constraint should exist. As far as I can determine, all that would be required to boot a 750 over an ethernet would be the addition of a boot ROM and/or VMB that knows how to place a boot request message on the net. (In fact, the DEUNA has a DIP switch provision for this, indicating that some one was thinking ahead...). Albeit, some talk has surfaced regarding potential performance problems. But, then again, what NI/CI based network hasn't any? [1] This is a shame, because we have numbers of loyal, reliable 750's that could be reincarnated as gateways to Brand-X and Plain Wrap networks, batch servers, CMS library servers, etc., etc., etc. Thus I perceive this omission as purely DEC marketing oriented, concocted for reasons unknown. Now, our company, like most, does not have an infinite amount of money to spend to change out all our present VAX-11 with the latest generation of trendy hardware that comes along. And, even if we did, we would find ourselves locking horns with the logistics of such. VAX-75 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Does anyone have any information/opinion to the contrary? Or, better yet, has someone booted a 750 over NI wire? Or, better still, is this feature actually supported by DEC but not widely publicized? [1] To be sure, it probably wouldn't be a grand idea to place your share database on the slowest disk on the slowest node in the cluster.... JIM PALMER 3 BROOKDALE IRVINE, CA. 92714-3338 (714) 458-3028 ================================================================ Note 741.1 750's and LAVC's 1 of 7 "John Osudar" 8 lines 8-SEP-1987 15:21 -< 750's in LAVc >- ---------------------------------------------------------------- DEC's official position is that the only CPU's that have the capability to boot over the Ethernet are MicroVAXes. As you point out, it would require a suitable boot ROM to get this to work from a 750 -- and if DEC has such a part, they aren't selling it. A related question, that has been asked before & elsewhere, is whether you can boot a non-MicroVAX from a local disk and then have it join an LAVc as a "satellite" that has its own local disk. That appears to be feasible (though officially unsupported). John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-76 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 741.4 750's and LAVC's 4 of 7 "Dale E. Coy (505) 667-3270" 35 lines 10-SEP-1987 00:21 -< A modest proposal, and more fuel >- ---------------------------------------------------------------- We have just finished retrofitting our mixed network of 750's and MicroVAXes to connect via the NI/ETHERNET medium with encouraging results. This may not be much help, but you didn't say what your mix of hardware is... A bit better than one 750 boot-node would be two 750s. LAVC 1.2 (VMS 4.6) allows two per cluster. Then, of course, you can have multiple clusters on the same Ethernet by giving each cluster a different group number. Thus, if you have at least 1 MicroVAX per each pair of 750s..... :-) A couple of other notes on LAVC experience: 1. I recently ordered LAVC licenses, plus "Documentation and Media" (mag tape). The mag tape arrived, but no documentation. DEC's initial response was that "Documentation and Media" does not include documentation, which must be ordered separately. 2. I received this tape last week, and it's Version 1.1 - when I asked why I didn't get 1.2 (announced in June), I got a "return authorization" number, and was told to send it back and they would ship V1.2 3. Meanwhile, the local office told me that V1.0, 1.1, and 1.2 are the same thing (like a DECnet key). Unpacking the save_set seemed to bear this out. Then the local office "kindly" furnished me with a line-printer copy of the documentation for V1.2 (less illustrations, of course) which says: $ @SYS$UPDATE:VMSINSTAL LAV010 ddcu: VAX-77 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT If there's a moral in this, I haven't found it yet. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 741.6 750's and LAVC's 6 of 7 "John Osudar" 16 lines 10-SEP-1987 18:35 -< added thoughts on LAVc's >- ---------------------------------------------------------------- Incidentally: before we got our LAVc, I had wondered about what exactly happens to the satellite nodes when the boot member goes down (either via SHUTDOWN or crash). The answer is... nothing! Although the satellites cannot do anything while the boot member is down, once the boot member comes back up (to the point where it loads the MSCP server and begins serving the required disks), the satellites all mount-verify the served disks, and resume operation as if nothing happened. (It's a little strange to read the console messages, indicating that the boot node is sending a membership request to a satellite node -- but it does seem to work!) We had been a little concerned, since we wanted to add an existing MicroVAX-II to the LAVc; that node is used to run some multi-CPU-day batch jobs, and we were afraid that our 785's typical reboot-every-two-weeks behavior would impact those jobs. It doesn't; the batch jobs will wait until the 785 boot node comes back up, and then will continue running. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-78 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 742.0 LSE Support for Non-DEC Compilers 4 replies "Larry Kilgallen" 14 lines 8-SEP-1987 20:13 ---------------------------------------------------------------- A DECworld speaker giving an Ada talk today said DEC is now supporting the generation of LSE diagnostics files (.DIA) by non-DEC compilers. Presumably this means the next version of LSE. The example given in 35mm slides was for a Jovial compiler. Off-line a different DEC employee told me that the support mechanism will be a new ASCII input format for the diagnostics file because the existing binary format was so complicated. LSE will be able to read either the binary file produced by DEC compilers or the Ascii file produced by customer compilers. This will have the disadvantage of not allowing the concatenation of those Ascii files with the binary files. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 742.2 LSE Support for Non-DEC Compilers 2 of 4 "Walter R. Crosby" 15 lines 14-SEP-1987 20:16 -< Walter Crosby, How about other foreign languages? >- ---------------------------------------------------------------- Has anyone out there considered using LSE with an ADABAS/Natural type programming environment on the VAX? We have a very large Data Center that is centered around IBM 3090 Compatible MVS/XA monsters all running that environment. MIS is investigating the use of departmental processors, but is concerned about the viability of using VAXen in conjunction with the big machines, if the VAXen will give only marginal contribution to programmer efficiency. Walter R. Crosby OMIS/BSPP 1 Ashburton Place, Room 1601 Boston, MA 02108 VAX-79 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 742.3 LSE Support for Non-DEC Compilers 3 of 4 "Dale E. Coy (505) 667-3270" 9 lines 15-SEP-1987 00:20 -< Should be straightforward >- ---------------------------------------------------------------- We're not in that particular game, but have looked at integrating other stuff into LSE. Since LSE was designed to have other things added to it, it is really straightforward to do so (but don't confuse straightforward with "trivial"). For commercial products trying to sell into VAX space, the vendor SHOULD be interested in developing environment files for LSE. It's probably a 3 to 6 programmer-month job to do it elegantly. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 742.4 LSE Support for Non-DEC Compilers 4 of 4 "Larry Kilgallen" 7 lines 15-SEP-1987 07:05 -< It takes too long for DEC to do it right >- ---------------------------------------------------------------- I have seen some samples of LSE in action where it calls for (as an example) a gzorn. When one asks for expansion of what "gzorn" means, it response with the very unhelpful phrase "Fill in the appropriate value for a gzorn". I realize that this is tied up in the continuing myth of VMS inter-language compatibility, but "on-line" information should be "on-line". Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-80 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 743.0 WPS-Plus and Laser Jets 2 replies "Lee K. Gleason" 13 lines 8-SEP-1987 23:44 ---------------------------------------------------------------- I'm looking for a set of WPS-Plus printer tables for the Hewlett Packard Laser Jet+. I'd sure like to avoid the tedious process of figuring out the escape sequences and entering them via TPU. I tried to tell the manager it would be easier (for me, at least) to just buy LN03s, but he wouldn't go for it. Surely someone out there has already gone through this... Lee K. Gleason Control-G Consultants 2416 Branard #D Houston TX 77098 713/528-1859 ================================================================ Note 743.2 WPS-Plus and Laser Jets 2 of 2 "Jack Patteeuw" 16 lines 9-SEP-1987 11:48 -< They're Right Here !!! >- ---------------------------------------------------------------- The Printer Attributes (.PRA) and Printer Characteristics (.PRC) table for an HP Laser Jet (don't know what the differences are with the + model) have been uploaded to [US176598]HP.PRA and [US176598]HP.PRC. We have been using these tables for over a year and I know that several copies have been downloaded to other sites so I assume they must be correct. This tables are also on either the Spring86 or Fall86 Symposium tape under [MIVAXLUG.FORD]. Also in my directory are the tables for a XEROX 2700 (should work with 3700 from what I have been told) and for QMS 800 (should work with any QMS printer that has QUIC). If anyone has problems with any of these tables please let me know ! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division VAX-81 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 745.0 Ethernet Encryption No replies "Larry Kilgallen" 13 lines 9-SEP-1987 15:42 ---------------------------------------------------------------- In the DECworld session "Security Status and Trends" (10 am weekday mornings, today through Thursday September 17), DEC is giving a "program announcement" of DESNC Ethernet encryption. The hardware will be a box which connects up to 4 nodes to an Ethernet (in between the controllers and a single transceiver). The software will be key distribution software running on one or more (not clear if there is a limit) key distribution VAXen. In addition to the DES encryption you would expect, the eventual offering is planned to enforce that node n is plugged into port X of DESNC Y (by virtue of the fact that DECnet changes the physical Ethernet address on the controller to have the two low order bytes contain the node number). Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 747.0 Tape Mgmt Sys - (TAPESYS) 8 replies "Jan C Ostendarp" 11 lines 11-SEP-1987 02:49 ---------------------------------------------------------------- Does anyone have experience with, or a recommendation for, VAX tape management software? (i.e. TAPESYS from Software Partners, or DECUS Library software, etc.) Are there rumors circulating about DEC's intended functionality improvements in BACKUP (v5 and beyond)? The documentation I've read on TAPESYS leads me to believe they've developed a full function system well integrated with VMS backup. If you've used it or other similar products available on VAX, tells us about it please. Jan C Ostendarp Massachusetts Financial Services 200 Berkeley Street VAX-82 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Boston, MA 02116 ================================================================ Note 747.1 Tape Mgmt Sys - (TAPESYS) 1 of 8 "Larry Kilgallen" 6 lines 11-SEP-1987 20:34 -< Does TAPESYS make patches? >- ---------------------------------------------------------------- I have heard a rumor that TAPESYS patches VMS images in order to make it all work. This poses a support issue which might deter some people. Hopefully the Backup and Mount improvements outlined in Nashville for some future version of VMS would alleviate some of the need for third party vendors to go to such extremes. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 747.2 Tape Mgmt Sys - (TAPESYS) 2 of 8 "John D. Ferriby" 29 lines 16-SEP-1987 03:32 -< Mixed feelings about TAPESYS and VMS BACKUP >- ---------------------------------------------------------------- Concerning the TAPESYS product and use at our site... We have had some awful experiences with TAPESYS. Mostly with just its being a poor product with poor support and poor documentation. This experience was our initial, when we had to pull their teeth to get them to airfreight the *CORRECT* images that were not linked with debug or just plain did not work. It has been distributed to five of 130+ plants we support, and we have heard many initial horror stories. To my knowledge, it does not make any patches to VMS. If I find out they did, ohh.. well... *&^%**! On the bright side, in the last year and since the last release, life has been peaceful. It runs quietly as far as I can tell. We have one person devoted to administer/support it, but we have a large development community to support and this justifies the dedication. It does on occasion conflict with the users if, for some reason, a backup job is running during prime time. VAX-83 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT On a related VMS BACKUP note, there is a problem with backup for those people with wide spread image cycles, and that is that BACKUP does not delete files from the previous pass during succeeding restores that were deleted by the user at that time. For some time our image cycle was one month, and if a problem arose we would have to go back up to 30 days. Once in fact, that last 30 day image was bad and we had to go back 60 days and reconstruct. (*NEVER* again.) The crux of the problem is that BACKUP/INCREMENTAL does not keep track of what the entire director's contents status is, only that particular files have been modified or that they have never been backed up. John D. Ferribyþò û 2871 Troy Centry û#2010 Troy, MI 48084 (313) 362-2595 ================================================================ Note 747.3 Tape Mgmt Sys - (TAPESYS) 3 of 8 "Larry Kilgallen" 10 lines 16-SEP-1987 06:39 -< VMS Backup used to do deletions correctly >- ---------------------------------------------------------------- R.E. 747.2 - VMS Backup VMS Backup is SUPPOSED to do it right, and to my recollection at least at one point it did. The one thing it does not handle is deletions in the case where you RENAME a DIRECTORY, but in other cases restoring the full followed by restoring the incrementals (using /INCREMENTAL) in reverse order is supposed to delete files which were deleted. If you can come up with a solid counter-example, please send and SPR for the benefit of us all. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-84 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 747.4 Tape Mgmt Sys - (TAPESYS) 4 of 8 "Brian Tillman, Smiths Industries." 7 lines 16-SEP-1987 08:27 -< BACKUP will delete. >- ---------------------------------------------------------------- We use image plus incremental and our restores DO properly delete files that were deleted between backups. You must have some other problem. Perhaps you're not following the proper procedures for the restore (i.e., as Larry says, restoring the full backup and then the incrementals). I believe you must also generate a journal file of the backups in order for files to be deleted properly upon restoration. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 747.5 Tape Mgmt Sys - (TAPESYS) 5 of 8 "Bob Hassinger" 49 lines 16-SEP-1987 13:13 -< A "counter-example"... >- ---------------------------------------------------------------- VMS Backup is SUPPOSED to do it right, ... ...restoring the full followed by restoring the incrementals (using /INCREMENTAL) in reverse order is supposed to delete files which were deleted. If you can come up with a solid counter-example, please send and SPR for the benefit of us all. I think this discussion is about a problem that I did find, document, work with TSC, confirm with them, SPR, followup three times, ask about at my LUG meeting, post (here I think), and raise at the Spring Symposium in the Advanced Q&A! It has been more than half a year now and I STILL can not get the curtesy of any response at all, even one telling me I am just making a mistake or that it can not be reproduced! VAX-85 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT I did get a call from someone in a DEC location I never heard of (a local office?) who was trying to come up with a work around, NOT a FIX, for someone (he was evasive about the details). He wanted to know what I knew and how I solved it (I wonder who should be paying whom!). My case was: After an image backup a directory tree with files is deleted, then an incremental backup is done. I found that restoring the image, followed by the incremental, all done exactly as specified in the manuals, failed to delete the directory tree or the files in it. TSC confirmed this but it is still possible there is some simple problem we both missed, I don't know. There is a suspicion something real DID break in BACKUP some place along the way. I never did this kind of restore before early 87 so I am not sure if this is a new or an old problem. It turned out to be a real problem for me when the deleted trees involved hundreds of thousands of blocks on full disks! Note re: .4 - I find that individual files deleted from directories that remain on the disk ARE deleted as they should be. My problem involves deleted directory trees and the files in them. It seems to be a problem in BACKUP involving the walking of directory trees to delete the files they contain and/or a problem in the deleting of the .DIR file along with what seems to be a failure to report any problem doing these operations. I think this distinction has been the source of more than a little confusion on the subject. (BTW, in my case it is directory trees but I think the problem even shows up in the simple case of an individual directory with files in it if they are both deleted from the disk between the image and the incremental.) Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-86 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 747.6 Tape Mgmt Sys - (TAPESYS) 6 of 8 "Larry Kilgallen" 7 lines 16-SEP-1987 21:04 -< BACKUP directory deletion >- ---------------------------------------------------------------- RE: 747.5 I do believe that directory deletion is another instance of the same problem as directory renaming. I think VMS developers have stated that it has never worked. I think I have also heard VMS developers describe it as at least a known limitation. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 747.7 Tape Mgmt Sys - (TAPESYS) 7 of 8 "John D. Ferriby" 5 lines 21-SEP-1987 15:56 -< Correction to .2 >- ---------------------------------------------------------------- Our staff has closely documented this error and they are working with some folks from DECland to resolve the situation. Our situation is more accurately described by Bob in .6 than what I said in .2 John D. Ferribyþò û 2871 Troy Centry û#2010 Troy, MI 48084 (313) 362-2595 VAX-87 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 747.8 Tape Mgmt Sys - (TAPESYS) 8 of 8 "Mack W. Haynes, Jr." 10 lines 22-SEP-1987 09:10 -< Tapesys - A reply >- ---------------------------------------------------------------- I have been using Tapesys for about two years without any major problems. There have been a few typo's in the command files and a few minor bugs in some of the programs. However, I can attribute that to the fact that I receive pre-release versions of the software. The package uses a modified version of VMS backup and requires FMS be installed as a minimum. Generally, I have been very pleased with the package. Phil Jamieson, President of the company has been very receptive to suggestions and very supportive of any minor problems I have experienced. I can recommend this package very highly. Mack W. Haynes, Jr. Tenneco Oil Co. 1100 Louisiana MS: IFP2954 P.O. Box 2511 Houston, TX 77001 (713) 951-1118 ================================================================ Note 749.6 VMS 4.6 - where are you? 6 of 7 "Stuart Renes" 24 lines 24-SEP-1987 13:48 -< VMS version V4.6 experience >- ---------------------------------------------------------------- We got VMS version 4.6 the week of September 14 and have installed it successfully on three machines. Two problems that arose are as follows: 1. If you have a VAXcluster and DO NOT do a rolling upgrade AND have the logical name SHUTDOWN$INFORM_NODES defined, the upgrade will abort during the first shutdown/reboot (due to a FATAL error from OPCOM not recognizing the CLUSTER node name from the logical). VAX-88 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT This causes VMSINSTAL to abort and delete its efforts in [SYSUPD...] and you get to start over! (Admittedly this is a rare problem, but it bit me in 4.4 and I had forgotten!)... so GET RID OF THE LOGICAL PRIOR TO THE UPGRADE! 2. If you have SI Eagle disks that use a patched DRDRIVER, you cant patch the new one with the SI kit... but the V4.5/4.5 DRDRIVER seems to work fine until SI comes up with the patch. Otherwise, the upgrade works as expected. Stuart Renes AT&T Technologies, Inc. Mail Stop: 2793 3000 Skyline Dr. Mesquite, TX 75149 (214) 288-2286 ================================================================ Note 752.0 Q-bus versus BI-bus 15 replies "MICHAEL GRATTAN" 25 lines 15-SEP-1987 09:42 ---------------------------------------------------------------- We are looking at getting a mid-range VAX, and as such we saw the new VAX 3600 at DECworld. It is very nicely priced and has the peripherals that we would like. As we were originally thinking of getting an 8250, we are now discussing the merits of the Q-bus vs. the BI-bus. We see several points in each direction: The Q-bus is: 1. older and supposedly slower 2. open, lots of third party peripherals VAX-89 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT The BI-bus is: 1. new and fast 2. closed, only DEC peripherals or licensed vendors Since none of us here are real technical, can anyone point out anything that I've missed? (I'm sure there's something.) Does anyone have any thoughts on this? I would greatly appreciate any comments. Thanks. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 752.1 Q-bus versus BI-bus 1 of 15 "Brian Tillman, Smiths Industries." 9 lines 15-SEP-1987 12:27 -< One reason for BI >- ---------------------------------------------------------------- Of course, with BI, there is the added advantage of multiprocessing that the QBUS will never support. The 8250 is field-upgradable to the 8350, which is a multiprocessor and can use the SMP (symmetric multiprocessing) features that VMS 5.0 will have. If your processing loads are such that you would be able to take advantage of SMP (generally compute-intensive), would would do well to purchase the entry-level BI machine (8250), provided you didn't have an already substantial investment in other bus technology devices. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-90 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 752.2 Q-bus versus BI-bus 2 of 15 "Bill Mayhew" 26 lines 15-SEP-1987 16:24 -< MicroVAX 3500/3600 vs. VAX 8xxx >- ---------------------------------------------------------------- If your processing loads are such that you would be able to take advantage of SMP, you would do well to purchase the entry-level BI machine (8250), provided you didn't have an already substantial investment in other bus technology devices. True enough, except that for around or less than the same cost as the 8250, you get roughly 3x the CPU power _today_ in the 3000 series. Interesting tradeoff. I have also read, in the past week, that Digital has more-or-less written-off the 8250 as an entry-level machine, and now positions the 8350 as "the" entry-level BI system. I interpret what I read as a marketing posture, rather than a marketing or technical _decision_. Would anybody like to comment on the typical kinds of applications (or mix thereof) that would do well under SMP, as opposed to under a cluster, which of course can be done today (ummm... when Digital delivers 'em) with 3000-series machines? Back to the original question, some of the other considerations are: Clustering performance (Ethernet vs. CI, roughly 1:7 raw bit speed) Disk capacities with Digital disks Memory size limits (32 vs. up to 256Mb) Operating environment (office vs. "computer room") Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-91 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 752.3 Q-bus versus BI-bus 3 of 15 "Larry Kilgallen" 12 lines 16-SEP-1987 06:43 -< Consider HSC-only Features >- ---------------------------------------------------------------- At the present time DEC does not offer CI interconnect for the MicroVAX. In the past the reason has been given that the CI adapter would cost more than the MicroVAX, but it seems to me the MicroVAX 3 pricing has solved that problem. So if you want either of the HSC-based features: 1. HSC-backups (boo) 2. Volume-shadowing (yay) now or in the future, that should make you choose a non-Qbus machine. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 752.4 Q-bus versus BI-bus 4 of 15 "M. Erik Husby" 22 lines 16-SEP-1987 09:24 -< Other features to consider >- ---------------------------------------------------------------- Some features of MicroVAX III to consider. When the memory boards are available, you will be able to support 64megs of memory in one. You will be able to do SMP with the MicroVAX III because it is not strictly a Q-BUS machine like the MicroVAX II is. DEC has some products in the works which will make use of that feature. To me the decision on whether to go 8000 class or MicroVAX III class will depend on the type of processing you want to do. If you envision a shop where you have a lot of people doing word processing, electronic mail, moderate size business type computing, and moderate amounts of disk space then a MicroVAX VAX-92 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT III should be sufficient. It can grow in to a LAVC. If you need a lot of disk space and a lot of cpu crunching power, look closely at the 8000 class machines. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 ================================================================ Note 752.5 Q-bus versus BI-bus 5 of 15 "Bob Hassinger" 9 lines 16-SEP-1987 10:03 -< How about an HSC with NI interface? >- ---------------------------------------------------------------- At the present time DEC does not offer CI interconnect for the MicroVAX. ... Question: Rather than looking for a CI interface for the MicroVAX, why not look for an Ethernet (NI) interface for the HSC? In smaller clusters that might be a viable option that would be much cheaper. Are there technical problems with this? Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 752.6 Q-bus versus BI-bus 6 of 15 "Walter R. Crosby" 10 lines 16-SEP-1987 18:10 -< 3600 vs. 8XXXxxx >- ---------------------------------------------------------------- In some benchmarks, that I have seen, the indication is that the additional 8350 processor does absolutely no good for typical business data processing applications. Unless you're willing to go with the big bucks for 8500 or larger, it would appear that you would be best off with the 3600 for business data processing. VAX-93 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT The lesson of DECWorld appears to be that if you want to do number crunching, you're better off with VAXstations galore! Walter R. Crosby OMIS/BSPP 1 Ashburton Place, Room 1601 Boston, MA 02108 ================================================================ Note 752.7 Q-bus versus BI-bus 7 of 15 "Jamie Hanrahan" 15 lines 16-SEP-1987 19:25 -< multiprocessing will be better under V5 >- ---------------------------------------------------------------- The benchmarks referred to have all been done under VMS's current asymmetrical multiprocessing scheme. Things will work much better under 5.0. In general, if you have two or more processes (other than NULL) in the COM state a lot of the time, the second processor in an 8350 WILL help, and will add about 0.8 of a processor to your machine. (And there's the potential for adding yet more processors; the developer in charge of SMP said that in their tests they found that the 8200 chassis can support at least 4, and usually 5 8200 cpus before it runs out of bandwidth for I/O! Think of a 5 mips VAX in an 8200 footprint... of course, whether DEC will sell us those processors is another question; they'd prefer we buy 8500s and up...) Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 VAX-94 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 752.8 Q-bus versus BI-bus 8 of 15 "Jack Patteeuw" 24 lines 18-SEP-1987 17:34 -< My 2 cents >- ---------------------------------------------------------------- It is obvious that the 3000 series has "temporarily" surpassed the 800 series in the VAX line. However, please note the "hole" left in the 8000 series number between the 83xx and the 85xx ! If the the CVAX chip set is placed on the BI bus it would make a wonderful 8400 !! I agree with 752.3. The big differences between the the 3000 and the 8000 series are: 3000 8000 ---------- ------------------------ Disk 4 255 (via CI) RAM 32M-128M(?) 128M(BI)-256M(Nautilus) SMP Don't think so Just around the corner So if you feel that you will need to grow into lots of disk or RAM stay with the 8000 series but wait for future announcements for a bit if you can. I really don't expect DEC to support SMP on the QBus. After all it (multiprocessing) is the biggest reason they invented the BI bus. Rumor also has it that their 3D high end graphics machine will be BI based, not QBus as all previous graphics workstations. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-95 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 752.9 Q-bus versus BI-bus 9 of 15 "Frank J. Nagy" 15 lines 19-SEP-1987 10:15 -< Figure in Software License $$$$s >- ---------------------------------------------------------------- At one point we were looking at an 8200 vs MicroVAX (with the idea of growing the MicroVAX into an LAVC). We ended up with the MicroVAX because of the software costs. The layered product costs (VAX C, VAXSet, DTR32, CDD, TDMS, RSM) for the 8200 added up to more than the MicroVAX hardware+software. This was unexpected by us; we figured that an 8200 was approximately a 780 so the software license costs should have been about the same. Noooooo... The software licenses for the 8200 was about the same as for an 8650! So now we have LAVCs and workstations on the way to add to the LAVC core (dual MicroVAXes). Best decision we made! MicroVAX 3000s are probably in our future also, but not at the current system configurations and costs. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 752.11 Q-bus versus BI-bus 11 of 15 "Bill Mayhew" 17 lines 21-SEP-1987 10:48 -< 3000 vs. III vs. 8000 >- ---------------------------------------------------------------- re: .9, software license costs... It seems to me that software license prices are going to be one of the TOP incentives for people to get into LAVCs (why pay 8xxx series prices for layered products that may be used by <10% of your people, when you can buy 'em a whole LAVCed machine with the licenses for around the same price)... unless/until Digital comes up with some sort of per-user layered product license pricing scheme. I have heard rumors of such, but I would not want to be in charge of administering it...! VAX-96 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 752.12 Q-bus versus BI-bus 12 of 15 "GREG P. SCHULZ" 6 lines 27-SEP-1987 11:01 -< EXTRA CPU FOR VAX 3XXX >- ---------------------------------------------------------------- What about the extra backplane slot on the new VAX 3xxx systems. Is this slot fact or fiction. I heard that this slot was capable of supporting a second CPU board. If fact, does this mean that multiprocessors are in the future for the Q-BUS??? If Fiction, oh well... The new VAX 3xxx should make for nice "departmental" systems where the department is not to large... GREG P. SCHULZ BURLINGTON NORTHERN RR ISS LOC 3 176 E 5TH STT ST. PAUL, MN 55164 612 298-7344 ================================================================ Note 752.13 Q-bus versus BI-bus 13 of 15 "Jamie Hanrahan" 10 lines 27-SEP-1987 20:08 -< uV3 multiprocessing? Maybe >- ---------------------------------------------------------------- It is certainly technically possible for the MicroVAX 3 series to support multiple CPUs in the future. The fact that there's a Qbus in that box has nothing to do with it; the machine is no more a Qbus machine than the uV2 is. Sure, their I/O bus happens to be a Qbus, but so what? What's important is whether or the processor/memory bus can support multiprocessing. Of course, this does not consider marketing concerns; I wouldn't be a bit surprised if a dual-processor uV3 would be too good to be sold for a while. Jamie Hanrahan VAX-97 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 ================================================================ Note 752.14 Q-bus versus BI-bus 14 of 15 "Dale E. Coy (505) 667-3270" 5 lines 27-SEP-1987 22:28 -< It's advertised as Dual-CPU >- ---------------------------------------------------------------- The VAXserver 3602 is "a dual-CPU version of the VAXserver 3600". As implied by the name VAXserver, the target market is for use as a LAVC boot node. Given the very sketchy information available, it's hard to figure out exactly what this incarnation of multiprocessing really is. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 752.15 Q-bus versus BI-bus 15 of 15 "Bill Mayhew" 5 lines 28-SEP-1987 17:29 -< Dual-bus, too, I think >- ---------------------------------------------------------------- The info I have on the 3602 says that the 2nd CPU is a "compute server" for the network and a backup, as boot node, to the primary CPU. It's not *totally* clear, but I have the impression that the 2 CPUs live on separate Q-busses. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-98 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 754.0 RTAn: Response on Slow Lines 11 replies "Steve Duff" 5 lines 16-SEP-1987 01:59 ---------------------------------------------------------------- Is anyone aware of any magic that will improve the "burstiness"/ response latency on RTAn: network terminals when on a relatively slow (9.6Kb) circuit loaded with other traffic (file transfers, etc.). The problem is most annoying with character-QIO programs such as editors, spreadsheets, etc. Steve Duff Software Factory 2401 E. 17th St. Suite 190 Santa Ana, Ca. 92701 (714) 752 2972 ================================================================ Note 754.1 RTAn: Response on Slow Lines 1 of 11 "M. Erik Husby" 10 lines 16-SEP-1987 09:31 -< No magic possible >- ---------------------------------------------------------------- COnsider the fact that, I believe, the DECnet packet overhead is 64 bytes. Therefore your single character QIO programs really require 65 bytes of DECnet data. And if the program is doing its own echo, then another 65 bytes are required to display the character. Consequently, your 9.6kb circuit is really closer to 300baud if only one RTAn: terminal is using it. You may want to rethink your hardware configuration. Perhaps terminal multiplexers would be more appropriate. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 VAX-99 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 754.2 RTAn: Response on Slow Lines 2 of 11 "Jamie Hanrahan" 38 lines 16-SEP-1987 19:54 -< you gotta wait your turn >- ---------------------------------------------------------------- (I'm sure I answered this question once before. Fairly recently, too. Don't recall where, though.) The problem is that you're competing with other packets for the line, and you have to wait your turn. Look at it this way: Suppose your line buffer size is 576 bytes, and a file is being transferred on it (file transfers tend to use the full buffer size), and you're doing single-character terminal I/O through the same line at the same time. Now, every time you type a character, there will be (on average) 288 bytes still to be sent of the packet that's currently being sent, so the packet containing your character will have to wait an average of 1 sec 8 bits 288 bytes -------------------------------------------------- 9600 bits 1 byte 288/1200 sec, or about a quarter of a second, to get sent down the line. And that's assuming no multibuffering, only one file transfer in progress at a time, etc. If the file sender keeps just one more packet waiting behind the current one (I believe FAL does this), your average wait goes up to about 3/4 of a second (one and a half packets' worth). A smaller line buffer size would improve remote terminal response, but at a large cost in throughput for other network traffic. You can't reduce the buffer size on just this line; you'd have to drop the size of the buffers used throughout your network. (Mr. Husby is correct in general that the DECnet overhead for the remote terminal protocol cuts severely into the line's capacity, but it isn't nearly as bad as 64 bytes/packet. I don't know the numbers offhand, but I have watched such packets going past on a line analyzer, and I seem to recall that it's more like 20 bytes per packet. I believe he may be thinking in terms of LAT protocols.) Jamie Hanrahan Simpact Associates VAX-100 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT 9210 Sky Park Court San Diego, CA 92123 619-565-1865 ================================================================ Note 754.3 RTAn: Response on Slow Lines 3 of 11 "Bob Hassinger" 19 lines 21-SEP-1987 12:45 -< Network protocols for terminal traffic... >- ---------------------------------------------------------------- The recent discussion here has seemed to suggest that DECnet (and LAT?) tend to send single characters in individual packets. I would be interested in knowing more about what really does happen (i.e. the protocols). We use a statistical terminal multiplexer network here to support some remote terminals (made by Digital Communications Associates). It so happens it uses DDCMP to send it's packets although it's network has nothing to do with DECnet, etc. The interesting part is that it uses an algorithm to wait a while, maybe one or two tenths of a second, before sending a packet. That way it can save up as much traffic as possible and put it all in one packet. Some times the traffic is all to or from one port, other times it is an accumulation of traffic on a number of ports. This makes much better use of the available network band width. My impression is that this is common practice. Any inputs?? Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-101 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 754.4 RTAn: Response on Slow Lines 4 of 11 "Brian Tillman, Smiths Industries." 20 lines 22-SEP-1987 12:12 -< Sounds like what a server does. >- ---------------------------------------------------------------- Terminal servers also buffer input from the terminal lines where it can. Only one virtual circuit is maintained from the server to a service and all traffic between the server and that service go through this circuit. If several terminals are connected to the same service, input from all those terminals gets placed in the same packet (provided the input occurs within the keep-alive window) and the packet gets shipped out. The LAT software running on the service then sorts out the destinations for the various inputs. Likewise, the same happens in the other direction. The VAX LAT bundles all output for a particular server into a single packet (again, provided the output is ready to go between keep-alive timer expirations) and the server sorts it out and sends it to the proper port. The keep-alive timer modifies this a little. A packet goes out when it's full OR when the keep-alive timer expires, whichever comes first. This can result in empty, or near empty packets, but usually this isn't too much of a problem if the server's ports are busy. It's even less of a problem in the DECSA servers or the soon to be DECserver 500. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-102 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 754.7 RTAn: Response on Slow Lines 7 of 11 "Larry A. Cannell" 14 lines 24-SEP-1987 19:04 -< Bizarre DECserver response >- ---------------------------------------------------------------- Has anyone ever had a problem communicating with a server when you do the following: 1. SET HOST to another system 2. run NCP 3. connect to a DECserver 4. do anything(such as SHOW SERVER) When I did this the server stopped and wait periodically when it was outputting something to the screen. I typed SHOW SERVER and about three quarters of the way down it stopped and wouldn't start until I hit a key. Larry A. Cannell 8649 Wayside, Apt. 8 Brighton, MI, 48116 (313)322-7272 ================================================================ Note 754.8 RTAn: Response on Slow Lines 8 of 11 "Steve Duff" 33 lines 25-SEP-1987 04:26 -< Misc. comments >- ---------------------------------------------------------------- A few miscellaneous notes: o The technical discussion aside, the problem the way I am seeing it is that that the DDCMP data layer apparently provides no way to prioritize input, as for example, is done in most statistical multiplexors (DECnet is a software stat mux.) I suppose that was really my original question, and it appears to have been answered with a resounding no. One can of course resort to a hardware mux, which is probably desirable for other reasons, but that doesn't speak very well for RT. o The points about packet overhead and queueing latency are valid, but packet overhead itself shouldn't change response under loads. (Packet overhead is a fixed quantity.) If the DECnet slotting had a prioritizing mechanism, to penalize background sources (such as file VAX-103 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT transfers), latency wouldn't be an issue either. This may seem picky, but consider what VMS would be like if all batch and interactive jobs had to execute at the same priority. When an asynchronous DDCMP line gets loaded, interactive SET HOST response through some applications can go from OK to unbearable. o The DECSERVER parameter that controls outbound packet flush is the CIRCUIT TIMER, not the keep-alive timer. o I have had exactly the same problem with lockup when connecting to DecServer 100s over RT: devices, and it drives me nuts ("can you stop my process please"...) It appears to be affected by the relative baud rate mismatch between the two ends, but I have never been able to make it work reliably, and would dearly love to have a solution. I am curious as to whether it happens with DSV200s, which would indicate whether to suspect the ucode in the 100s, or RTPAD (my guess), or a problem in DECnet itself. Steve Duff Software Factory 2401 E. 17th St. Suite 190 Santa Ana, Ca. 92701 (714) 752 2972 ================================================================ Note 754.9 RTAn: Response on Slow Lines 9 of 11 "Chris Erskine" 21 lines 25-SEP-1987 08:24 -< 2 Comments >- ---------------------------------------------------------------- 1 way to get out of the character mode bursting for items like the editors is to not use the editor on the remote system. There are folks who say you should never use SET HOST. The way that this can be done is to do something like: $ EDIT NODE"USER PASS"::LOGIN.COM or $ SET DEFAULT NODE"USER PASS"::SYS$LOGIN: $ EDIT LOGIN.COM VAX-104 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT If you have proxies enabled, you do not have to supply the username and password. Towards the terminal lockup, I have seen the same problem in other areas. We use DECserver 200's and DECSA's. When using Reverse LAT and tying into a second LAN through the terminal server, I have had the same problem. I also do not know where the real problem is and have not taken time to analyze the E-net packets to see what is happening in them. Chris Erskine 6001 Adams Rd. Bloomfield Hills, MI 48013 (313) 258-4049 ================================================================ Note 754.11 RTAn: Response on Slow Lines 11 of 11 "John Burnet" 46 lines 28-SEP-1987 15:27 -< RTPAD problems and NCP CONNECT NODE >- ---------------------------------------------------------------- On the subject of various RTPAD bugs... the following problems are reported in the latest Systems Dispatch (9/87) as known bugs: 1. RTPAD suppresses null characters, hangs if it receives an XOFF request without receiving a matching XON, and exits with SS$_BADESCAPE if it sees a bad escape sequence. 2. RTPAD buffers incoming data in the virtual address space of the process running it. Therefore, if you press control-s (xoff) while a large amount of data is coming down the line to your system, RTPAD will buffer the incoming data in your v. a. space rather then sending the remote system an xoff. This may result in the process using up its page file quota if you wait long enough before pressing control-q. If the quota is set high enough, the system may hang due to a shortage of page-file space. 3. Buffer overflows (SS$_DATAOVERUN) may occur if the terminal line you're using has a small (read "normal size") typeahead buffer. /ALTYPEAHD is recommended. VAX-105 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Re. SET HOST and NCP CONNECT NODE: I have noticed that when you SET HOST to a system and use NCP CONNECT NODE or CONNECT VIA, the effective echoing speed for terminal reads is about two characters per second. That's 20 baud or thereabouts. :-) Is this because each character is sent in a separate CTERM packet, or what? Is this the fault of RTPAD, NCP, or both? Re. Note 754.10 RTAn: Response on Slow Lines The second was that I have a bad habit of doing a NCP CONNECT NODE servername and then issuing CONNECTS from the command port. I was told that this is most definitely NOT SUPPORTED and can lead to all sorts of bizarre behavior. I think that what they meant to tell you is that connecting to a host and then doing an NCP CONNECT NODE or CONNECT VIA isn't supported. Just connecting to a service (even the same host) from the remote console port *is* supported. See the *DECserver 100 Operations Guide*, pp. 3-6 through 3-8. Specifically, on p. 3-8 the manual says that you can enter the CONNECT command to use network services. The only restriction is that only one session can be active from the remote console, while up to six are possible at the other ports (1-8). John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 ================================================================ Note 755.0 MS-DOS floppy disks? 8 replies "Alan E. Frisbie" 5 lines 18-SEP-1987 16:17 ---------------------------------------------------------------- Does anyone know if a program exists to read/write MS-DOS floppy disks (1.2 MB, AT-type) on an RX33? Alan E. Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065 VAX-106 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 755.1 MS-DOS floppy disks? 1 of 8 "MICHAEL GRATTAN" 17 lines 21-SEP-1987 05:02 -< Don't think so... >- ---------------------------------------------------------------- Does anyone know if a program exists to read/write MS-DOS floppy disks (1.2 MB, AT-type) on an RX33? To the best of my knowledge, no. I believe the formats of the diskettes (i.e. tracks, etc.) are incompatible. Thus the reason for DECnet DOS, which works pretty well for shooting files from a PC to a VAX. (But then of course, so does Kermit!) If your really into hardware, there are numerous third party products which plug into a VAX that emulate a PC and as such come with their own diskette drives to work with. I guess it all depends on how many $$$ you want to spend. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 755.2 MS-DOS floppy disks? 2 of 8 "JEFF KILLEEN" 4 lines 21-SEP-1987 09:06 -< RX33 OK >- ---------------------------------------------------------------- The RX33 is 100% hardware compatible with the IBM AT drive. The RX50 is *NOT* compatible with any IBM drive. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 VAX-107 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 755.3 MS-DOS floppy disks? 3 of 8 "Bill Mayhew" 47 lines 21-SEP-1987 13:15 -< Half a loaf... >- ---------------------------------------------------------------- re: .0 I thought I had just the thing for you: a program called VMSFLX, which is in the public domain, and which was originally written to allow the reading of MS-DOS RX50s from a Rainbow on a MicroVAX. It will read Rainbow RX50s on a MicroVAX with an RX33, and I _thought_ it would also read MS-DOS RX33s (from a VAXmate or IBM AT), but it seems it only comes "close". You can successfully do a DIRectory of an MS-DOS RX33 (which, as mentioned earlier, is supposed to be identical to an AT's 1.2Mb floppy). But, attempting to read or write a file causes the program to run on forever. I am theorizing that there may perhaps have been a difference in the disk structure between 2.11 MS-DOS (which the Rainbow runs) and 3.x MS-DOS (which VAXmates and ATs typically run). It looks to me like the thing just isn't detecting end-of-file properly, though it also appears to be picking up improper data in some cases. The source code for the program is available, and should serve as a reasonable starting point. (The fact that you can do a DIR would suggest to me that there are no major technical obstacles.) Unfortunately, the source is in VAXELN Pascal, so you'd need that in order to make any changes. The program was written by someone named Kris W. Barker, and was found on DEC's MARKET system, which was (until mid-summer) a DECsystem-10-based repository of all manner of interesting MS-DOS and CP/M public-domain software, along with most every incarnation of Kermit known to man. Unfortunately, MARKET is no more. VMSFLX is available on Compuserve's VAX Forum, and probably on various Rainbow FIDO bulletin-board systems. Or, if you think it will do you any good, I will be happy to send you a floppy with the sources, documentation and executables if you promise to send me one back once you solve the RX33 problem {grin}. Based on some notes in the documentation, I think the author may be/have been a DEC employee, and may still be involved in updating this program, as well. VAX-108 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT If you want the floppy, drop me MAIL on this system with your address and let me know if you care if it comes on an RX50 or an RX33. Incidentally, the program also professes to *write* MS-DOS floppies from VMS. I haven't tried this. There is another option, which is sort of the long way around the horn. I have seen on various P/D systems a file called RX50.ARC, which is said to contain software required to use RX50s on an IBM AT. I don't know whether you can *write* RX50s this way, or just read them; but if the former, then you could use RX50.ARC to produce RX50 floppies, which should be readable by VMSFLX in its present form. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 755.4 MS-DOS floppy disks? 4 of 8 "Terry Kennedy" 30 lines 26-SEP-1987 23:31 -< An easy hack... >- ---------------------------------------------------------------- Here is some more info - 1) The IBM At's 1.2 Mb drive has a different layout than the 360Kb diskette found on XT's. There is a 'media identifier' byte in the boot block. The hack to the code should be trivial to support 1.2 Mb PC-DOS disks on the RX33. I don't have the necessary hardware to test the mods, (nor ELN), but if you send me the code I'll be glad to tell you what to modify. 2) The RX50 disk drive is a 96-TPI, 80-track, single-sided drive. There are 10 512-byte sectors per track, with a 2:1 interleave. With some suitable gyrations to some of the more obscure drive status signals, you can use either a Shugart 460, a Tandon TM100-4, or a Teac FD-55F disk drive as an RX50. The NEC uPD765 (Intel 8272) disk controller chip in a PC/XT can read and write the RX50 format, but cannot FORMAT the disks. However, a Central Point Copy II PC Option Board and a pair of VAX-109 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT the above-mentioned floppies can be used to copy the format from a 'real' RX50 diskette to any 96-TPI blank diskette. [After all, copy protection is just another oddball format] Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 757.0 DECWORLD 87 3 replies "Jack Patteeuw" 64 lines 18-SEP-1987 18:14 ---------------------------------------------------------------- Here is a quick run down of what I saw at DECWorld for those of you who didn't make it (and are so isolated that you don't read ANY trade journals) MicroVAX 3000 A new family of VAX processors mounted on the Qbus. The VAXStation 3500 is packaged in the the new BA213 box and support two RA70 disk and one TK70 tape along with 4 MS650 8 megabyte memory boards. The 3600 will also hold a RA82 or similar disk. These systems come in three configurations. Plain MicroVAX, VAXStation (add the 3200 which uses the old BA23 and can only have 16 MBytes), and VAXServers which are boot nodes/compute servers for LAVC's. One special configuration is the VAXServer 3602 which is a fully redundant system (hope it has separate power cords for when you kick one out of the wall :-} !) Note the 3500 and 3600 support 4 memory boards as opposed to 2 in the BA23 and BA123. The MS650 boards have faster (100ns) RAM than the MS630 of the MicroVAX II. The memory controller will support 1 megabit RAMs whenever DEC (or third party) starts to build them for a maximum of 128 MBytes. RA70 5.25" 280 megabyte disk. Uses KDA50 controller and is only 5.25" disk to be dual ported ! Very high density per square inch of medium. VAX-110 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT TK70 296 megabyte tape cartridge. Media has same form factor as TK50 (and can read but not write to a TK50) but DEC recommends new cartridge. More lights to tell you the status of the tape/drive and when you can lift the handle ! BA213 Not really new but first BIG intro. This chassis will eventually supercede the BA123. Old QBus cards will have to be retrofitted with "handles". DECnet System Services 3 new layered products. Distributed name service (similar in concept to a network wide logical name table), Distributed Queue Service (to print to remote printers) and Distributed File Service (remote mount of a disk, faster than DAP). The name service will probably be bundled into DECnet Phase V when it comes out. NOT ANNOUNCED !! CXY08, CXA16, CXB16 New QBus Async mux for BA213. CXY08 is RS232 compatible (with modem control), CXA16 is DEC423 and CXB16 is RS422. 8, 16 and 16 ports respectively. VMS Services for MS-DOS Now bundled (no charge) into DECnet-VMS. Buy DECnet-DOS, hook up and go !! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-111 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 757.1 DECWORLD 87 1 of 3 "Dale E. Coy (505) 667-3270" 10 lines 18-SEP-1987 22:40 -< Thanks >- ---------------------------------------------------------------- VMS Services for MS-DOS Now bundled (no charge) into DECnet-VMS. Buy DECnet-DOS, hook up and go !! Thanks for all the info. The VMS Services is particularly interesting (and a smart move for DEC). Is this bundled at 4.6? Now, since I have it on order, I wonder if they'll charge me. I'll take bets. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 757.3 DECWORLD 87 3 of 3 "Jack Patteeuw" 5 lines 22-SEP-1987 17:19 -< Not in 4.6 >- ---------------------------------------------------------------- re: .1 VMS Service for MS_DOS is **NOT** included in the 4.6 distribution kit. A separate distribution of DECnet-VMS will be made in the "future" that will include this functionality. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-112 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 761.0 DM11B or DH11 drivers needed. 1 reply "Tom Lynch" 5 lines 28-SEP-1987 12:23 ---------------------------------------------------------------- Does anyone have a driver for DM11B or DH11? They are coming from a decommissioned PDP so we are looking for public domain or very cheap software. Any reason why I wouldn't want them on my 750? Tom Lynch Univ. of Wisc. ISC 1500 Johnson Drive Madison, Wi. 53706 (608)2636792 ================================================================ Note 761.1 DM11B or DH11 drivers needed. 1 of 1 "Larry Kilgallen" 9 lines 29-SEP-1987 00:21 -< DH11 Hardware Incompatibility >- ---------------------------------------------------------------- Back when the 780 came out the word was that the DH11 (low overhead output device for the PDP-11 front end on PDP-10's) did not meet the tighter specifications for the 780 Unibus. So we waited for DMA output. My recollection is that the DMF11 was released about the same time as the 730, and if that is the case it would seem to indicate that the 750 Unibus specification is too tight for the DH11 as well, since the need for DMA output would not have seemed so desperate when the DMF came out. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-113 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT ================================================================ Note 762.0 Seven/Eight bit terminal options changing No replies "Larry A. Cannell" 6 lines 28-SEP-1987 19:08 ---------------------------------------------------------------- Does anyone know why a SET TERMINAL/INQUIRE will take a terminal set to eight bits and make it seven bits? This doesn't show up when you do a SHOW TERMINAL(so VMS still thinks that you are an eight bit terminal) but if you look at the terminal setup you will see that it has changed. We've found this problem with VT2xx and most recently VT3xx terminals. Larry A. Cannell 8649 Wayside, Apt. 8 Brighton, MI, 48116 (313)322-7272 ================================================================ Note 763.0 VT320 Character Cell Terminal 2 replies "Larry Kilgallen" 23 lines 29-SEP-1987 00:33 ---------------------------------------------------------------- From the July/August DEC publication DESKTOPics I got today (you see, software isn't the only thing they ship slowly) comes this description of VT320 features: "The user-configurable escape key option allows the user to generate a tilde (~) or an escape character when the tilde key is pressed. They keyboard selectable < > Greater Than/Lesser Than symbols set-up function, similarly, allows the user to send the Greater Than/Lesser Than characters, or the tilde, when the brackets (Enter) key is pressed." Well, I got lost in the semantics of the latter paragraph. I am glad they didn't think the ways they had closed the door on sales to TECO users was limited to the escape key, but none of the various semantic correction techniques I have tried lead to a conclusion that they have put the angle brackets back over the comma and period. It's ok, I probably wouldn't like the feel of the LK201 keyboard anyway. VAX-114 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Does anybody have one of these beasts? Can you tell us how the angle bracket substitution really works? Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 763.1 VT320 Character Cell Terminal 1 of 2 "Larry Kilgallen" 5 lines 29-SEP-1987 00:59 -< Unless you just want it for LOCAL mode... >- ---------------------------------------------------------------- Note that you have to buy the International Version of this terminal to get a built-in 25-pin RS232 connector, the North American version has something they call a DEC423 connector (part of DEConnect wiring schemes, perhaps?) with a "25-pin adapter for most standard U.S. modems". Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 763.2 VT320 Character Cell Terminal 2 of 2 "Terry Kennedy" 11 lines 29-SEP-1987 01:59 -< Testing, testing... >- ---------------------------------------------------------------- Does anybody have one of these beasts? Can you tell us how the angle bracket substitution really works? I have a pair on order for evaluation purposes (student bash-proof testing) and when they come in I'll let you know. By the way, it seems that DEC's direction in terminals is aimed against the academic market - what could you possible steal off of a VT52? [not that you'd want anything, anyway] From VT220's we are now missing keyboards. With 320's we can now look forward to losing the modular cord connecting the terminal to the 'DEC432 RS-232 adapter'. Phone cords are a hot item in the dorms, it seems! Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 VAX-115 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT (201) 435-1890 * * VAX-116 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX System SIG Committee List VAX System SIG Committee List As of June 24, 1987 CHAIR (CORE) Susan T. Rehse Lockheed Missiles & Space Co. O/19-50, B/101, P.O. Box 3504 Sunnyvale, CA 94088-3504 VICE-CHAIR (CORE) WORKING GROUP COORDINATOR Ross Miller Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 SYMPOSIA COORDINATOR (CORE) Jack Cundiff Horry-Georgetown Technical College P.O. Box 1966 Conway, SC 29526 COMMUNICATION COORDINATOR (CORE) Don Golden Shell Oil Company Westhollow Research Center P.O. Box 1380, Room D2158 Houston, TX 77251-1380 LIBRARIAN Joseph L. Bingham Mantech International 2320 Mill Road Alexandria, VA 22314 LUG COORDINATOR (CORE) Dave Schmidt Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 VAX-117 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX System SIG Committee List SYSTEM IMPROVEMENT REQUEST (CORE) Mark Oakley Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2669 SYMPOSIA COORDINATOR, ASSISTANT David Cossey Computer Center Union College Schenectady, NY 12308 PRE-SYMPOSIUM SEMINAR COORDINATOR HISTORIAN Jeff Jalbert J C C P.O. Box 381 Granville, OH 43023 PRE-SYMPOSIUM SEMINAR COORDINATOR (ACTING) June Baker Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 COMMUNICATIONS, ASSISTANT David L. Wyse Professional Business Software 3680 Wyse Road Dayton, OH 45414-2539 VOLUNTEER COORDINATOR Elizabeth Bailey 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35661 NEWSLETTER EDITOR Lawrence Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-118 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX System SIG Committee List SESSION NOTES EDITOR Ken Johnson Meridien Technology Corp. P.O. Box 2006 St. Louis, MO 63011 CAMPGROUND COORDINATOR Kirk Kendrick Shell Oil Company 333 Highway G, MS D-2146 Houston, TX 77082-8892 PAST CHAIR Marge Knox Computation Center University of Texas Austin, TX 78712 ADVISORS: -------- Joseph Angelico U.S. Coast Guard Detachment National Data Buoy Center NSTL Station, MS 39529-6000 Art McClinton Mitre 1820 Dolley Madison Blvd. McLean, VA 22102 Al Siegel Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 WORKING GROUPS: -------------- COMMERCIAL Robert Boyd GE Microelectronics Ctr. P.O. Box 13409, MS 7T3-01 Research Triangle Park, North Carolina, 27709-3049 VAX-119 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX System SIG Committee List FIELD SERVICE Dave Slater Computer Sciences Corporation 6565 Arlington Blvd. Falls Church, VA 22046 INTERNALS Carl Friedberg Seaport Systems, Inc. 165 William Street, 9th Floor New York, NY 10038-2605 LARGE SYSTEMS INTEGRATION Leslie Maltz Stevens Institute of Technology Computer Center Hoboken, NJ 07030 LIBRARY Glen Everhart 25 Sleigh Ride Road Glen Mills, PA 19342 MICROVAX Ray Kaplan Pivotal, Inc. 6892 East Dorado Court Tucson, AZ 85715-3264 (602) 886-5563 MIGRATION AND HOST DEVELOPMENT VAXINTOSH Jim Downward KMS Fusion Incorporated P.O. Box 156 D Ann Arbor, MI 48106 MULTIPROCESSOR Eugene Pal U.S. Army CAORA (ATORCATC) Fort Leavenworth, KA VAX-120 PAGESWAPPER - November 1987 - Volume 9 Number 4 VAX System SIG Committee List NETWORKS Bill Hancock P.O. Box 13557 Arlington, TX 76094-0557 REAL-TIME PROCESS CONTROL Dennis Frayne McDonnel Douglas 5301 Bolsa Aveneu Huntington Beach, CA 92646 Larry Robertson Bear Computer Systems 56512 Case Avenue North Hollywood, CA SECURITY C. Douglas Brown Sandia National Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185-5800 SYSTEM MANAGEMENT Steve Tihor 251 Mercer Street New York, NY 10012 VAXCLUSTER Thomas Linscomb Computation Center University of Texas Austin, TX 78712 PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA To register for on-line submission, dial (in the United States): (617) 262-6830 and log in with the username PAGESWAPPER. PAGESWAPPER - November 1987 - Volume 9 Number 4 INPUT/OUTPUT Submission Form Tear out or photocopy reverse to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - November 1987 - Volume 9 Number 4 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - November 1987 - Volume 9 Number 4 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Mark D. Oakley Battelle Columbus Division Room 11-6-008 505 King Avenue Columbus, Ohio 43201-2369 USA