CHAPTER VAX PAGESWAPPER - March 1986 - Volume 7 Number 8 Licensing of Software - A Problem for All of Us VAX-3 Editor's Workfile . . . . . . . . . . . . . . . VAX-5 New Michigan VAX LUG . . . . . . . . . . . . . . VAX-8 Letters . . . . . . . . . . . . . . . . . . . . VAX-9 Converting Files to FORTRAN Carriage Control . VAX-12 Trials of Switching to VAX 11/730 DECnet . . . VAX-15 The MicroVAX Working Group is Alive! . . . . . VAX-16 VAXclusters - A Generic Point of View . . . . VAX-19 How Large is a LARGE Cluster? . . . . . . . . VAX-38 VMS V4 SCREEN MANAGER . . . . . . . . . . . . VAX-40 THE FALL 1985 DECUS US SYMPOSIUM Version 1 . . VAX-55 THE FALL 1985 DECUS US SYMPOSIUM Version 2 . . VAX-65 VAX System SIG Committee List . . . . . . . . VAX-70 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-73 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-75 System Improvement Request Submission Form . . VAX-77 VAX Systems SIG Spring 1986 SIR Ballot . . . . VAX-79 PAGESWAPPER - March 1986 - Volume 7 Number 8 General material for publication in the Pageswapper should 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. Please do not submit program source, as that is better distributed on the VAX SIG tape. 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. Featured Next Month A transcript of the VAX question and answer session from the European DECUS symposium. Hear Andy Goldstein say "There are no known problems with the current VMS V4". More important, learn the context in which he said it! VAX-2 PAGESWAPPER - March 1986 - Volume 7 Number 8 Licensing of Software - A Problem for All of Us Licensing of Software - A Problem for All of Us Ross Miller VAX SIG Co-Chair and Working Group Coordinator All of us are faced with problems of licensing in one form or another, whether we are producing software or on the other end being the user trying to license the software from someone else. Our industry has not gotten a good grasp on how to handle licensing - to define it, control it, and enforce it with the myriad of associated problems. The time is right for all us to get involved and to air our two cents worth on what we see the problems are and to make suggestions for improvements. Many other groups have wrestled with the issue without any major _____ degrees of success. I believe the time is right for the DECUS __ ___________ ____ _______ _________ ___________ community in conjunction with Digital Equipment Corporation to tackle this problem and set a precedent for the entire industry. If we allow only one member of the community to do the definition of how this problem should be resolved then it will _________ __ be lop-sided. We need all parties - both the producers of ________ _____ __ ________ software and the users of software to become involved. The major portion of this issue, I suspect, will have to be resolved within the next 6 to 12 months. There will be other issues that will have to continue to be worked on after that period of time but the major thrust will be over within that 6 to 12 month period. I'm writing this article to encourage response - whether it be by phone or preferably , in written format. I would like each of you to sit down and take a few minutes and in whatever format respond with what you see the problems are from your circumstances and what you would like to see done to resolve the problem. It should be noted at this point that pricing must be kept totally separate from the issue of how to license and how to define use. Pricing is an economic issue, not a matter of licensing policy. Here are the major issues as I see them: Whatever comes out of changes in licensing policy these things must be preserved: _ _____ __ ________ ___ ___ _______ 1. A sense of fairness for all parties __ _______ ___ _____ __ ________ 2. To protect the value of software - there are no free lunches. Whenever software is getting ripped off revenue base is being destroyed and you cannot continue to support and develop that product. Therefore all of us are losers in the end. VAX-3 PAGESWAPPER - March 1986 - Volume 7 Number 8 Licensing of Software - A Problem for All of Us _________ ___ ___ __ ___ ____ __ ______ 3. Encourage the use of the tool as needed Frequently we're afraid to put a piece of software up on a machine because it's so expensive to put it on that machine for only one or two users or occasional users of the software. ______________ 4. Enforceability - we don't want to be placed in a difficult, compromising situation with the software and our users. ______ __ _____ __ _ _____ ___ ___ _______ 5. Should be start of a model for all systems _______ ______ __ ________ _ ____ ___ ______ ________ 6. Improve method of managing a pick and choose software ___________ environment (i.e., look at using software building blocks with checks for revision problems). Basis for Licenses: From a meeting held in Anaheim discussing the issue of licensing, the following basis for licensing was discussed: ______ __ _____ a. It should be based on the number of users for interactive software - therefore it makes no difference wither this is running on a personal computer or a large clustered environment. ____ _________ b. Work performed for non-interactive jobs (e.g., batch jobs that are compiling and are therefore non-interactive but do run faster on bigger machines. ___________ c. A combination of the two above. _________ ___ d. One price for the unlimited use of machine and the person who is licensing the software can do whatever they want with the software on the machine. A footnote to the above - it was strongly recommended that some form of leasing the software be provided. I would also suggest that the licensing may affect many areas such as the need for new hardware implementations to ensure the enforceability of licensing policy. We must keep in mind the need of sites for flexibility in reconfiguring their systems, therefore you may have a machine that's part of a cluster at one point in time and then remove it from the cluster to run alone. In another situation you need to be aware of the fact that for failsoft conditions I might have software running on one machine but that machine may fail and I need to quickly and easily move the load to another machine and this would dictate that the licensing would temporarily go to the new machine. VAX-4 PAGESWAPPER - March 1986 - Volume 7 Number 8 Licensing of Software - A Problem for All of Us Please review the thoughts in this discussion as to what the impacts might be in your shop. If there are areas that have not been touched upon, help us to understand those areas. Don't delay - please sit down and write a response as quickly as possible. Forward this response to: Ross Miller Online Data Processing, Incorporated N. 637 Hamilton Spokane, WA 99202 A copy of all written responses will be forwarded to the DEC Internal Task Force on Licensing. Editor's Workfile by Larry Kilgallen, Pageswapper Editor The Dallas-Fort Worth LUG - has some prolific writers in their newsletter, and in this issue of the Pageswapper we are passing on to you some of their thoughts on clusters, screen management and the Fall 1985 DECUS Symposium in Anaheim. The wealth of information we get from LUG, working group, and individual contributors is a prime reason for the small print you get in the Pageswapper (and other DECUS newsletters). As we get more information to publish, the pages must be paired up in order to be able to deliver a newsletter at a price of 35 dollars per year. My presumption has been that Pageswapper readers would prefer more information rather than larger type, but let me know if I am wrong. Don't Forget to Vote - The System Improvement Request list is in last month's issue, and the ballot is reprinted at the end of this issue. Photocopies of the form are quite acceptable; it is your membership number which validates the ballot as being yours. By the way, if you don't vote, well, whatever it is that you wanted to see on your VAX, I am going to get all my friends to vote AGAINST it!!! Truth in Publishing - I was quite impressed to get a postcard from Digital Review correcting a table of benchmark times in an issue I had just received. Considering that the items being benchmarked (CPUs) were all from the same manufacturer (DEC), there was obviously VAX-5 PAGESWAPPER - March 1986 - Volume 7 Number 8 Editor's Workfile not a problem where one company complained it had been unfairly treated with respect to its competitors (although some have said that different parts of DEC sometimes behave like separate companies). Perhaps Digital Review sent out the correction postcard thinking it might win them accolades. Well, there is mine. DEC Electronic Store update - And on January 22 I finally got my Pascal documentation, six months after placing the order. I was so overjoyed that I called the Electronic Store to see if there was anything else I wanted to buy. The phone rang and never answered. Wondering about this, I called the (voice) help line and was assured that the Electronic Store is still operating, but that "if all the lines are busy, you just get a ringing signal". That is not the protocol as I remember it from grammar school. One final note on the topic, both times I actually did get packages from the Electronic Store, the pink "customer packing list" was made out in handwriting rather than by machine. So although computers may keep us all employed, it takes a human to make something happen. LAT-11 ? What is that? As little as a year ago I remember a DEC salesman at a client site pushing LAT-11 terminal servers as an adjunct to a cluster. The clients bought the cluster but not the LAT-11, and now they can be grateful. Customers who did buy LAT-11 software (which can be installed on a variety of PDP-11s) have recently been told that DEC will not be providing Version 2.0 of the terminal server software for LAT-11 customers. Likewise for ANY future versions of the software; the LAT-11 is considered a "mature" product. My own impression of the DEC terminal server software in general is that it is "adolescent", with no support of outbound connections and at least one severe flaw in the load balancing logic. The DEC position seems to be purely a marketing decision (they would rather sell you a new PDP-11 in the DECSA box than have you use an existing one which used to run RSTS). Indications are that many sites inside DEC are happily using what would have been the Version 2.0 LAT-11 software on their own LAT-11s. When you buy something from a small company, you always have to ask, "Will this company be around to support it next year?" It would appear that when you buy something from a large company you have to ask, "Will this company want to bother supporting it next year?" VAX-6 PAGESWAPPER - March 1986 - Volume 7 Number 8 Editor's Workfile Life is not all bad - Today I went (as presumably lots of readers in other cities did) to the DEC 8x00 announcement, and what they described looked good. If others agree with my good feelings about what will be available, presumably the DEC order-taking department will hear about it. I was interested to read a "letter to the editor" in the weekly newspaper "Computerworld" criticizing the paper's characterization of Fall DECUS symposium participants as feeling negative toward DEC. I don't think those attending symposia are typically down on DEC, but in defense of journalists I can see how someone would get that impression. I don't think it should be the function of DECUS activities to serve as a DEC cheering section. We have DEC processors, for better or for worse. Most of us feel it is better, but there is always room for improvement. We want to be able to talk to those who are stuck on IBM machines and tell them that our documentation orders are always filled immediately, that our salesperson always has the answer, that we can stand the two day waiting period for 8800 orders to be delivered, but that we have been programming DEC machines so long that we remember once talking to a user who claimed to have found a bug in VMS. That blissful (no pun intended) state will be approached more certainly by discussion the sore points than by masking them. VAX-7 PAGESWAPPER - March 1986 - Volume 7 Number 8 New Michigan VAX LUG New Michigan VAX LUG Debby Bolton Mathematical Reviews 416 Fourth Street Ann Arbor, MI 48106 This is an announcement to let everyone out in VAXland know there is a new VAX LUG (the paperwork is in the mail?!) in Detroit, Michigan. The meetings are informal - our only rule is: no ties. Subjects discussed range from the latest SPR submitted to hints and kinks to any topic of the evening. We also try to have at least one main topic per evening where everyone is welcome to contribute their thoughts, ideas, and experiences. Some of the topics suggested to date are: crisis management, the latest from DECUS, system management, the MicroVAX. A DEC field engineer keeps us up on the latest changes, upgrades, etc. We have a software bank (rather than a library) where we encourage people to deposit their neat programs as well as withdraw other programs. We meet on the second Tuesday of every month, barring DECUS, at the Lawrence Institute of Technology in Southfield. John Grden is our host. Jim Fisher is our chair and Lea Ann Kantner is our vice-chair. Anyone interested in VAXes is welcome to attend. For more information or directions, you can call Jim Fisher at 313-995-6366 or Lea Ann Kantner at 313-641-4138. VAX-8 PAGESWAPPER - March 1986 - Volume 7 Number 8 Letters Letters Peter Bendall European Molecular Biology Laboratory Notkestr 85, 2000 Hamburg 52 West Germany 21. January 1986 In Answer to Larry Kilgallen's notes on the European Symposium. "Thank you both for Coming". Sorry Larry, you missed the point. 100 percent of my SIG were present at that business meeting (!) and added to that every single one of my SIG officers is a volunteer officer too! I bet you can't beat THAT at a US Symposium. More seriously, the European VAX SIG is an administrative body set up to coordinate the VAX SIGs in all the European Chapters. The members are the SIG chairmen of the National VAX SIGs. If there were too many of us, or the national VAX SIGs were only small, we would have to elect a steering committee from our number but, as yet, we have everyone on the committee. So that explains the "Business meeting" which is open like a law court but is fully legal even if no one but the committee come along (even if the audience have a vote when they are interested). But you made a valid point. If you (an unbiased reporter) didn't realise, what sort of chance has the average man to understand? Now I was going to write an Abstract for the Business meeting this week anyway. Thanks Larry, and best wishes to everyone. Peter Bendall VAX-9 PAGESWAPPER - March 1986 - Volume 7 Number 8 Letters State Natural History Survey Division Illinois Department of Energy and Natural Resources Natural Resources Building 607 East Peabody Drive Champaign, IL 61820 October 14, 1986 RE: Merged DECUS Newsletters Dear Mr. Kilgallen, I am writing regarding the recent decision to merge the DECUS newsletters. From my vantage point, it is a major turning point for DECUS. A broad range of information is being made easily accessible to ALL members of DECUS. The will streagthen the society by broadening the knowledge of all members who subscribe and thus help unify the diverse membership. I have little doubt that readers will start offering solutions in areas that they never before considered - it is impossible to resist browsing through the other newsletters once they are sitting in our hands. May I suggest that editors and readers stop complaining about this turn of events and start to take advantage of it? Yours sincerely, Douglas B. Quine, Ph.D. Associate Biophysicist xc: BUSINESS APP, DAARC, GRAPHICS, EDUSIG, HMS, Languages & Tools, Large Systems, NETWORK, Personal Computers, RSX, Site Management & Training, RT Editor's reply- While we appreciate getting this and all letters, I don't believe the Pageswapper has contained complaints about the format from either the editor or the readers. There were some comments from me at the start just to explain that the system of attributing months to the Pageswapper's was changing, but I think some discussion of the facts of distribution is typically needed. My conviction was reinforced at the Anaheim Symposium when one member told me his company library had stopped putting the Pageswapper on the shelves. On further discussion, it turned out he had not known to look for a thick white volume!!! VAX-10 PAGESWAPPER - March 1986 - Volume 7 Number 8 Letters W. B. Langoon CERL Kelvin Avenue Leatherhead, Surrey England The issue of the Pageswapper containing the Fall 1985 SIR ballot was not delivered to European readers until December 1985, well after the 4 November deadline for casting votes. Therefore the most important improvement in the SIR ballot is to ensure your readers receive the ballot form in good time to cast their votes. The best way of achieving this would be to improve the distribution of the Pageswapper itself. Editor's reply- Faster distribution outside the US is certainly a worthy goal, although it should be noted that distribution of the September issue inside the US was beset with problems as well (from different sources). One problem I know of in the European distribution a few months ago was that European DECUS had to wrestle with whether they wanted to take the combined US Chapter newsletters and break them out again to match traditional distribution patterns, or face converting their whole mechanism to match what had been done in the US. Ultimately, electronic distribution might be helpful. We might have a chance to do that with the Pageswapper within a few months (since each issue is already totally machine-readable for SIG tape distribution). What I am thinking of is just point-to-point transmission from the States to Europe, for reduction to paper and normal distribution from there. It might be nice in theory, but one implementation problem is that neither I nor the US Chapter VAX SIG can afford to pay for a monthly transatlantic phone call as long as it would take to transmit the Pageswapper. There would also be the problem of deciding who gets it in Europe (National SIGs, European SIG, some individual with a good track record for delivery etc.). Given the previous constraint that I can't pay for transmission, it might be easy just to say whichever designee(s) place the phone call(s) get(s) to pick up the Pageswapper. I also don't know whether there are any European modems which talk to US modems, but I do know that the rates charged for Packet network intefaces by common carriers in the US place the financing of that out of sight as well. Looking at Stateside communications, I would like to consider getting some more timely responses to I/Os by having "answerer's" log in to a machine and try to respond before the I/O even hits the press. That would provide us with at least some of the answers being printed right after the corresponding VAX-11 PAGESWAPPER - March 1986 - Volume 7 Number 8 Letters questions. If there is anyone out there (who can pay for phone calls to Massachusetts) who might want to participate in such an effort (and knows some answers), drop me a note. Converting Files to FORTRAN Carriage Control Edgar Whipple Physics Division Lawrence Berkeley Laboratory Berkeley, CA 94720 January 9, 1986 Abstract This article describes a fix for the problem of FORTRAN carriage control characters (in column 1) not being interpreted when a file is printed on VAX/VMS. The Problem From time to time, one comes across a file that has FORTRAN carriage control characters in the first column, but when the file is printed on VAX/VMS, the characters are not properly interpreted. Rather, the carriage control characters are merely printed in column 1 ! This happens when the file does not have the "Fortran carriage control" record attribute, which is what tells the print symbiont to interpret column 1 as carriage control information. (The record attributes may be determined from the output of the DIRECTORY/FULL or ANALYZE/RMS commands.) This problem typically occurs when the file is transferred from a non-DEC computer via some means that doesn't set the record attribute correctly. VAX-12 PAGESWAPPER - March 1986 - Volume 7 Number 8 Converting Files to FORTRAN Carriage Control A Solution What we would really like to do is merely to change the appropriate record attribute field in the file header. To my knowledge, there is no VMS system utility to do this, but the desired effect may be accomplished by combining two existing system utilities. The process consists of using the CREATE/FDL utility to create an empty file with the correct record attributes, then using COPY/OVERLAY to transfer the contents of the old file into the new file. The following command procedure performs these operations in a reasonably transparent manner and with suitable output file defaulting: $!+ $! File name: $! CONVERT_TO_FORTRAN_CARRIAGE_CONTROL.COM $! Created: $! 9-JAN-1986 10:53 by Edgar Whipple, Physics Division, LBL $! Description: $! Convert specified file to FORTRAN carriage control $!- $ in_file = p1 $ out_file = p2 $! $! Prompt for in_file and out_file if either is missing. $! Pick up related fields for out_file from in_file, $! except force a new version. $! $ check_in_file: $ if in_file .nes. "" then goto in_file_present $ inquire/nopunctuation in_file "_Input: " $ goto check_in_file $ in_file_present: $ if out_file .nes. "" then goto out_file_present $ inquire/nopunctuation out_file "_Output: " $ out_file_present: $ out_file=f$parse(out_file,,in_file)- - f$parse(in_file,,,"version")+";0" $ in_file=f$search(in_file) $! $! Create the new file with the appropriate attributes. $! $ create/fdl=sys$input 'out_file' record carriage_control fortran $! $! The "incompatible attributes" message should be ignored, $! if it occurs, since this is precisely what we intend ! VAX-13 PAGESWAPPER - March 1986 - Volume 7 Number 8 Converting Files to FORTRAN Carriage Control $! $ copy/overlay 'in_file' 'out_file' $! $! End of CONVERT_TO_FORTRAN_CARRIAGE_CONTROL.COM Discussion One would expect that the CONVERT utility could perform this operation simply and directly with a command such as: $ CONVERT/FDL=SYS$INPUT in-file out-file RECORD CARRIAGE_CONTROL FORTRAN ^Z However, CONVERT does not understand that the characters in column 1 are, in fact, the FORTRAN carriage control characters. What it does is to provide a space character as the FORTRAN carriage control, and copy the record as is (in particular, leaving column 1 alone). A system utility to manipulate the file header directly could accomplish the desired effect without the overhead of creating a new file, which incurs unnecessary I/O and disk space overhead. However, it might not be possible to create a utility of sufficient generality that wasn't also too dangerous. VAX-14 PAGESWAPPER - March 1986 - Volume 7 Number 8 Trials of Switching to VAX 11/730 DECnet Trials of Switching to VAX 11/730 DECnet Arthur McClinton Mitre Corporation Last summer the Testbed for Automated Flight Services (TAFS) decided that they had outgrown their PDP 11/34 workstation configuration and it was time to switch over to VAX 11/730's as graphics workstation machines. It came at a very convenient time as DEC was just into the start of their hot and heavy trade up program. It did not take long to get the order through the Mitre management, and even less time for the VAX 11/730 to arrive. Next field service came out and moved all of the components from the PDP 11/34 to the VAX 11/730. With much fear I questioned whether I would get the operating system to boot from the RK07's that had been moved from their accustomed place on the trusty 34. I must admit that I questioned my good senses when I learned that the local field office had ordered a R80, just in case the promise of the upgrade folks turned out to be false. I did however manage to copy the VMS 3.6 system pack from another VAX 11/730 onto an RL02 and then copied it onto an RK07. Surprise of surprises the system booted. I, however, did not have time to get DECnet up before taking on the responsibilities of the care and feeding of a VAX 11/785. There the machine sat, VMS 3.6 running happily but not being able to communicate with the rest of the network. The users, however, were not slowed in the development of software. So with no pressure for the time being I allowed the local field service people to make their claims that it is software not hardware that is keeping the link from coming up. About the first of March, however, we started in earnest desiring to get the link up. Let me describe the symptoms that we were experiencing at this time. The VAX 11/730 has two DMC-11's: one connected to a DV-11 on an IAS system and one connected to a VMS 4.1 system. Both links are 9600 baud links to local computers thru synchronous null modems. DECnet in both cases makes it as far as starting. All calls to field service are treated with "it can not be hardware as it runs the standalone diagnostics." Placing DECnet in controller loop back, however, results in neither DMC seeing the host machine. Remembering that DMC's are noted for having power problems I convinced the local field service to upgrade the BA11K box power supplies. No success. Next a major discussion with the boss of the unit resulted. DMC's were swapped out like candy suckers being handed out in the children's ward of the local hospital. Field Service claimed that must have a bad version of DECnet. I stuck to my guns that could not be bad. VAX-15 PAGESWAPPER - March 1986 - Volume 7 Number 8 Trials of Switching to VAX 11/730 DECnet Finally DEC called in the big guns. District reviewed the facts, ran the standalone diagnostics, ran DECnet, and then ran the on line diagnostics under VMS. At this point they proudly announce that on Monday, the local rep would bring out new jumper cables and everything would work correctly. I really doubted their ability to isolate it to this level, but when Monday morning rolled around, so did my local DEC service man with two new jumper cables and both DMC's started working again (first time since the move). Not to be outdone my local hardware guru announced that he should have remembered that the on-line DMC diagnostics are much newer than the standalone. I still stick by the adage that the best DMC diagnostic is DECnet. We think that the bad DMC jumper cables resulted in DEC replacing over 15 DMC's, 1 upgraded power supply, 5 memory controllers, and at least 2 RK711 controllers. Not a bad score for a pair of 4 inch long cables which can not be bad because "see we get the same result when we swap them". The MicroVAX Working Group is Alive! by Ray Kaplan PIVOTAL, Incorporated VAX SIG MicroVAX Working Group C-Chair NLO Southwest Regional LUG Coordinator (and Other Sundry Sins) With every one of the wavering steps associated with fledgling organizations, the VAX SIG MicroVAX Working Group took its first steps at the Anaheim Symposium. What are VAX SIG (Special Interest Group) Working Groups, you ask? They are the heart of the VAX SIG! Working groups are the focus of that special interest specific energy that keeps DECUS the vital, energetic source of technically cogent information that it is. Our VAX SIG chair, Marge Knox (University of Texas), has expressed an interest in keeping an energetic, involved collection of SIG working groups alive to serve as centers of VAX SIG activity. VAX SIG Steering Committee member Ross Miller is the volunteer manager who heads up the VAX SIG Working Group efforts, providing guidance for all of the VAX SIG Working Group chairs. Currently, the VAX SIG working groups span a range of interest from Clusters (headed by Bob Boyd from GE) to us, the new kid on the block - MicroVAXes (headed by co-chairs Ray Kaplan of PIVOTAL, Incorporated, and Barbara Dow-Pleines of Magic One). Working Groups include such diverse VAX interests as VAXELN (headed by Bob Robbins of Array Computer Consultants), VAX Security (headed by Doug Brown of Sandia Labs), and VAX System Management (headed by Susan Rehse of VAX-16 PAGESWAPPER - March 1986 - Volume 7 Number 8 The MicroVAX Working Group is Alive! Lockheed Missiles). This is a report on the VAX SIG MicroVAX Working Group's fledgling steps. At the Anaheim Symposium, the MicroVAX Working Group held its first meeting. Joe Angelico (US Coast Guard), the VAX SIG Symposium on-site scheduling person provided us with a BIG meeting room. Thanks, Joe. At the start of the meeting, some 500 people were there for the formation meeting of what was to become the MicroVAX Working Group. At the outset of the meeting, Barbara Dow-Pleines took the microphone to tell the assembled audience that since DECUS is a volunteer organization, everyone that was at the meeting was expected to participate in the meeting. Shortly after Barbara's introductory remarks, most of the people left. "What, nothing for free here?", they were heard to say on their way out. Since my economics professors always told me that there was no such thing as a free lunch, I figured I was safe in hanging around to help make sure that there would be a MicroVAX oriented group for me and my MicroVAX oriented interests to cling to. It worked out just fine. Invest a little, get back a lot! DECUS works great in that respect. Works less than best, otherwise. The first order of business was to tell folks what the Working Group was all about. Simple enough: To serve as a focal point for VAX SIG MicroVAX oriented energy/interest/input to DIGITAL. That includes things like generating MicroVAX specific articles for the VAX SIG Newsletter (the PAGESWAPPER), gathering the necessary energy to make sure that Symposium sessions of interest are presented, and gathering input to DIGITAL about MicroVAXes are but a few examples of the sorts of things that your MicroVAX Working Group can do. This ALL happens by VOLUNTEER ENERGY. In Anaheim, the Working Group had a MicroVAX User's Panel, consisting of Bill Hancock on networking issues, Bob Robbins on realtime issues, Dave Schmidt on performance and big disks, and Ray Kaplan on portable MicroVAXes. (My MicroVAX almost has more American Airlines frequent flyer miles on it than I do!). It went well, and seemed to be well received. During the Working Group meeting in Anaheim, an attempt was made to settle on what Symposium sessions would be attempted for Dallas. The remainder of the folks broke into groups to decide what they wanted to hear about in Dallas. The sessions that ended up being scheduled are a result of having available speakers and demonstrated interest in the topic. As a result, the MicroVAX Working Group sponsored sessions for the Dallas Symposium include: KDA50 and RKDX3 MicroVAX Subsystems VAX-17 PAGESWAPPER - March 1986 - Volume 7 Number 8 The MicroVAX Working Group is Alive! MicroVAX Hardware and Software Hints and Kinks VMS and MicroVMS, the Differences MicroVAX Users Panel Strategies for Putting Boards in the Unibus/Qbus MicroVAX Based ALL-IN-1 Non-VAX Users Migrating to MicroVAX Large Disks on MicroVAX Introduction to MicroVAX System Management While the MicroVAX Working Group will not SPONSOR it, there will be a VAX SIG MicroVAX Working Group MOTIVATED one-day Pre-Symposium Seminar in Dallas entitled "Managing your MicroVAX". In short, the MicroVAX Working Group has been busy. Busy, but not without YOUR help and input. Should we be doing something that we are not? Should we be sponsoring things that we are not? In the end, everything that DECUS is depends on VOLUNTEER energy. YOUR volunteer energy. At the very least, that begins with your input to the process. Going further, that includes your energetic contribution to and influence of MicroVAX oriented VAX SIG activities. Help us keep this MicroVAX orientation alive, won't you? As co-chairs of the VAX SIG MicroVAX Working Group, we will look forward to hearing from you! Ray Kaplan Barbara Dow-Pleines PIVOTAL, Incorporated Magic ONE 6892 East Dorado Court 1971 Mount Pleasant Road Tucson, Arizona 85715 San Jose, CA 95148 (602) 886-5563 (408) 274-8403 Call us, write to us, contribute your experiences to the PAGESWAPPER, BUT, for heavens sake, DO SOMETHING besides just read this article. I mean VERY simply: take the time to put some of your experience down on paper! Know what I mean? Happy VAXing! Ray VAX-18 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View VAXclusters - A Generic Point of View by Mike Drabicky Sohio Petroleum Company Two Lincoln Center 5420 LBJ Freeway Suite 900/LB03 Dallas, TX 75240 NOTE This article was originally published in the November 1985 DFWLUG Newsletter from the Dallas-Fort Worth Local Users Group. This article covers VAXClusters from a generic point of view. It discusses the benefits one derives from a cluster, the reasoning that went into developing a cluster, its hardware and software components and the general organization within a cluster. Let's begin by examining the impetus for developing clusters. First, we'll look at the reasons why DEC developed the cluster concept. Then, we'll cover the benefits of VAXClusters over other computer systems. *INTRODUCTION* DEC has been building computers for many years now. During that time, they've discovered a variety of problems with computer systems. Such things as fault tolerance, a reasonable growth path and information sharing have been problems for years. The VAXCluster is their response to these types of problems. There are many benefits to be derived from VAXClusters. These include: o Incremental system expansion Everyone always seems to outgrown their computer systems. No matter how much processing power or disk storage you have, users are always in search of more. As such, DEC needed to provide a growth path for their customers that would be both easy and flexible yet not make their customer's current hardware obsolete. VAX-19 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View o Greater system availability No matter how much processing power or disk storage you have, it does you little good if you can't use it. When systems are down, your business suffers. This means that the machines need to be available 100% of the time if the business is to prosper. o Greater data sharing When you grow beyond one processor, your users still need to access the information on the "other" machine. And all at the same time. If you've ever tried to access information over a network, you soon realize that this is both slow and cumbersome at best. Thus, information sharing was a major concern that had a strong influence over where the sharing and synchronization mechanisms were put within the overall cluster design. o Broader cost/performance range With everchanging technology, customers needed to be able to add or substitute newer hardware for the old without disturbing the rest of the cluster. This required new gear to be plug compatible with the old. This, in turn, lead to a tight, rigid architecture among the components. Customers needed to be able to plug in a variety of processors and peripherals to fit their particular computational needs. o Preservation of current investment Clusters had to preserve the hardware currently in place. DEC couldn't afford to alienate their customers by having them scrap their current hardware and software investment. Thus, anything new had to be an upgrade to existing hardware already in place. These were the primary goals outlined for the VAXCLuster project. Keeping these considerations in mind, lets look at the characteristics of the VAXCluster design that resulted from these goals. Prior to VAXClusters, there were only two types of multi-cpu architectures: tightly coupled and loosely coupled. In designing the VAXCluster, DEC examined the good and bad points about these different architectures. The end result was a design that took advantage of the good inherent in the existing designs while eliminating their disadvantages. Let's look at the characteristics of these systems and see where clusters fit into the scheme of things. VAX-20 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View o Booting characteristics Tightly coupled systems, by in large, boot or fail together. This results from their sharing some rather intimate hardware. If one processor detects an error, it typically reboots to clear the condition. In the process, it will also cause to other members to reboot as well so that they come up with a "clean" version of the software. Loosely coupled system, on the other hand, boot and fail separately. This is the case today as with, for example, a DECnet network: systems come and go all day long with little to no effect on the other nodes running in the network. If you happen to be working on that remote node when it crashes, it will, quite naturally enough, have a pronounced affect on you. But, by in large, there is negligible effect on the other nodes within the network. With VAXClusters, you are most like that of a loosely coupled network: nodes may come and go pretty well as they please. If you loose a node within a cluster, the other nodes continue working with virtually no effect upon them. o System management In a tightly coupled system, all processors are managed under a single management domain. All processors are managed as if they were one. The policies on one machine are the same on the others. You run the same copy of the operating system on all nodes. This means that the users have the same rights, files, protections and so on no matter what node they run on. In contrast, loosely coupled systems have independent management domains. Each is managed as a separate entity with its own rules, policies and regulations. In general, there are a variety of machines and operating systems, connected via networks, covering large geographic areas. Here, VAXClusters follow the tightly coupled systems. The cluster was designed to be managed as a "single" system under a single system management domain. The designed also assumed adaquate physical security. The results was that there is no authentication of cluster messages within the operating system. The other nodes assume their partners are being honest with them and take them at their word thereby simplifying the design and increasing thruput. VAX-21 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View o File system Tightly coupled systems have an identical copy of the file system. This stems from them booting from the same copy of the operating system. And, realistically, from the design point of view, it would be most difficult to handle such a system with different file systems. Loosely couple systems have a variety of file systems. While it is certainly possible that they are all the same, it is most likely that they are not. For example, even if all nodes were VMS systems, the odds of all of them being at the same release level of all software is small. The most likely case, then, is that of a variety of operating systems, each with their own particular file managers. VAXclusters here follow the tightly coupled systems. The nodes within a cluster will normally boot the same copy of the operating system and, thereby, the same copy of the file manager. What VAXClusters add is a lot of low level locking and synchronizations so that the file system appears uniform throughout the cluster no matter what node you happen to be running on. o Expansion Tightly coupled systems are generally limited to about 4 nodes. Beyond the 4th node, memory access problems and physical constraints usually prohibit adding more processors. While you can physically add them, you run into problems like memory and bus contention as more and more processors vie for the same hardware resources. You also find that you lose a large portion of your processor's power to overhead involved in talking with the other nodes in the system. Loosely coupled system have, in essence, infinite expansion. If you want to add another processor or two, then you do so with little effect on the other nodes within the network. An example of this is the engineering network within Digital: it already has 3000 nodes on it and is still growing. A VAXCluster is most like the loosely coupled systems: you can add processors as needed with little effect on the other nodes within the cluster. Currently, there is an architectural limitation of 16 nodes within the cluster, but that should be lifted soon. This growth potential is one of the clusters greatest advantages. With hardware that is available today, your cluster can have anywhere from 1 to 75 MIPS of processing power. It can also have from 0.5 to 160,000 Mb of disk storage. VAX-22 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View This lattitude provides a performance/storage range that surpasses almost anyone's needs in today's computing marketplace. And once the 16 node architectural limitation is lifted, you'll be able to increase all these numbers by many times. Bear in mind that this performance range does not consider any faster processors or higher capacity disk drives that may be forthcoming. All in all, you have a tremendous growth potential so that you can fit the cluster to your application today yet be assured of a reasonable growth path tomorrow. o Geography Tightly coupled systems normally must exist within the same computer room and typically within the same cabinet. They share busses and memory, neither of which are well suited for communications over long distances. Interprocessor communications occur at memory speeds, typically in the milli- to microsecond range. And since they communicate at these high speeds, you cannot space them too far apart or the time delays over these busses will become unacceptable. In contrast, loosely coupled system can span the entire world. Here, interprocesor messages can take on the order of seconds to exchange. They use communications lines, microwaves and satellites to send their messages. But while they talk with one another, there is little else that they share. Their hardware, busses and memory are their own. The communications merely serves to exchange information among them. VAXCluster fall inbetween. Communications among cluster member is at a very low level within the operating system. It occurs in the milli- to microsecond range rather than in seconds as with a network. Also, much of the "clusterness" is buried within the operating system in contrast to a network where the communications tend to be much higher and mostly separate from the operating system. These, then, are the benefits of the VAXCluster. They represent items that the users want and quite justifiably need. Keeping these benefits in mind, let's look at the parts that make up a cluster. We'll start first with the hardware, examining each major component and defining its role within the cluster. We'll then look at the software and how it makes use of the cluster hardware to create the VAXCluster. *VAXCLUSTER COMPONENTS* VAX-23 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View In its simpliest sense, a VAXCluster is made up of hardware and software. This, of course, is much the same as with any computer system. The hardware allows the cluster to exist; the software makes it do useful work. Let's begin first by looking at the hardware that makes up a VAXCluster. *Hardware* There are four major components of the VAXCluster hardware: o Computer Interconnect o Hierarchial Storage Controller o Disks and Tapes o Star Coupler Let's look at these individually and see what role each plays within the VAXCluster. *Computer Interconnect* The CI is a 70 MBit bus that links together the other components of the cluster. It consists of the CI780 adaptor and 4 coax cables. The adaptor provides the intelligence, the cables the communications path. The cabling also provides for redundant paths, an "A" transmit/receive and a "B" transmit/receive. Normally, the CI selects path A then path B on an alternating basis for its messages. Each path can handle the full 70 Mbit transfer rate so that, with 3 or more nodes, you will effectively get a higher bandwidth as more and more dual cable usage comes into effect. The CI uses a serial packet oriented protocol with 32-bit CRC error checking. Packets are "broadcast" to all nodes on the cluster. The CIs on each node check the contents of the messages and either provide the requested service or information, or discard the package as appropriate. The CI itself is really quite intelligent. It has a 2901 microprocessor on board that does almost all of the work for the host. For example, it can do the virtual to physical page mapping since it has access to the system's page tables. This means that the host can provide the CI with a virtual address and it will handle all of the virtual to physical address translations. The controller can also do block data transfers. This means that the host can set a virtual address, block number and size then leave it up to the CI to handle the transfer. The CI, in turn, does the virtual to physical mapping, the scatter-read gather-write operation, message passing, error handling, formatting and so on, all on the board, without host intervention. By doing such housekeeping chores on board, it relieves the host to do useful work. VAX-24 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View *Hierarchial Storage Controller* The HSC50 forms the basis for the storage system on a cluster. It is an intelligent mass storage subsystem with its own microprocessors on board. It has an F-11 microprocessor as the main processor with up to 14 2901 microprocessors that handle the the CI and the disk/tape channels. It supports any of the RA type disks or TA type tapes. Each of the 2901 microprocessors can "see" into each of the disks so that, at any point in time, it knows just where the disk's heads are positioned. And with the radial connections, this means that there can by multiple operations proceeding in parallel. Compare this to the old MASSBUS disks that were daisy chained. Here, only one disk could be transfering at a time which severaly limited the usefulness of the MASSBUS when there were many large disks in the configuration. The HSC50 can support up to 6 simultaneous data transfers and 24 simultaneous seeks (one transfer per disk channel, 4 disks per channel). It can also have up to 1024 I/O requests pending at any one time. This high concurrency allows it to do a variety of optimizations such as seek reordering, seek optimization and rotational fragmentation. With as much going on at once as there is within an HSC50, what happens when it fails? Normally, you set up your disks dual ported between two HSC50s. If one of them should fail, VMS will start using the path to the other HSC50 for its I/O. This failover is totally automatic. The users, in fact, will never see it. At most, you'll experience a 15 second delay while the host reconfigures the path to the disk. Your operation will then proceed as if nothing had happened. This, then, does much towards keeping your disks available even during an HSC failure. It should be emphasized that the HSC50 is a disk/tape server, not a file server. While there are many arguments pro and con on this issue, there were three major considerations why DEC went the disk/tape server route. Let's consider each of these to see why they chose as they did. First, a file server seemed an extrodinarily difficult design. Particularly troublesome was the handling of file server failures. Since the sole knowledge of what files were opened, what records were being read, what files were being deleted would lie within the file server itself, a failure on its part could potentially corrupt many disks. Then, to maintain the availability of the cluster, VMS would have to switch to a "hot standby" to keep the file access flowing. This means that there would have to be a constant information exchange between the primary file server and its backup. DEC decided that the CI traffic caused by this along with the complexity of the design was just too much to handle. VAX-25 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View Second, a file server would be a potential bottle neck. Any node wanting to access information on a file thru that server would have to wait on requests from the other nodes accessing files on that server. Since there could potentially be many files opened at one time, it didn't see reasonable to expect the file server to handle all the requests without forcing some requestors to wait. Using the disk server method, they spread this knowledge of the files and records throughout the cluster thus minimizing the potential bottleneck problem. And third, the CI traffic would increase dramatically with a file server over that of a disk server. Typically, a file access is for many small records, say in the 20 to 100 character range. Each of these records would have to be packetized and sent out over the CI. Contrast this to a disk server. The disk accesses tend to be in the 2 to 8 block range. This means that each VMS system would cache many disk blocks for a single read request. Subsequent records would then come from the cache rather than over the CI and the disk server. Here, CI packets would tend to be in the 1000 to 2000 character range. Since communications systems get better thruput with larger transfers, the disk server was the method of choice. *Disks and Tapes* Let's turn our attention to the disks and tapes for a minute. Any disk or tape connected thru the HSC50 is accessable to any node on the cluster. Thus, instead of having, say, 10 disks on one system, 5 on another and 20 on a third, you can have all 35 available to all systems. Similarly, with tapes, you no longer have to buy a tape drive for each system since the TAs are available to all nodes. This considerably simplifies the management of the systems plus make life much easier on the users. Data is accessable from any nodes; tapes are available for backups or restore from anywhere. That's fine for now. What about the future? Suppose DEC decides to come out with a new RA disk that is, say, 10 times faster and 100 times the capacity and 1/10th the cost of the current generation of disks? Because the disk conforms to the RA disk architecture, the new disk will plug right into the HSC50 and it'll be immediately available for your applications. Plus, you will access it the same way that you do now which means there are no changes to your current software. Since this also holds true for the TA style tapes, your investment in both hardware and software is protected. *Star Coupler* Finally, let's examine the Star Coupler. The Star Coupler is the hub of the cluster. All nodes, whether they are processors or HSCs, connect to it. It is a totally passive device. There is no on/off switch, no electricity, no circuit boards. It is VAX-26 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View just a transformer that sends a copy of the messages that it receives out to all other nodes. It's MTBF is currently rated around 20 years and we do, of course, pay a monthly maintenance charge on it. The Star Coupler has a radial configuration. This was done for several reasons. One, it makes the addition or removal of nodes easier. You can do this online without disturbing the other nodes within the cluster. The Star will eat the transients so that the cluster continues to work even while you are making configuration changes. Contrast this to node additions within a multidrop architecture like Ethernet or a ring network. For Ethernet, you must be very careful where and how you drill the cable less you disrupt the entire network. In the ring network case, it is impossible to open up the ring to insert a new member without disrupting nodes currently using the ring. This radial configuration makes it quite nice since you can remove a failing piece of hardware from the cluster and still allow the other nodes to carry on as if nothing had happened. The Star Coupler is limited to 45 meters maximum distance from the Star to a node. This comes from the design of the cluster and the time it takes for the messages to propagate throughout the nodes. Given a maximum of 16 nodes and 45 meters, you can determine any node's "slot time" on the CI bus. Therefore, the CI does what's known as deterministic arbitration meaning that every node is guarenteed a certain time on the bus. This is in contrast to something like Ethernet's CSMA/CD which is more a random access kind of architecture which allows any node to hog the Ethernet cable whenever it wants. Under heavy loads, the CI degenerates into a round robin scheduling algorithm where each node then gets 1/16th of the available time on the bus. *Software* We've just looked at the hardware that makes up the VAXCluster. While hardware is nice, without the software to make use of it, it is almost useless. So let's look at the software that make up the VAXCluster. The components of the VAXCluster software are: o Distributed file system and RMS o Distributed lock manager o Connection manager o Disk/tape class drivers o Mass storage control protocol o System communications services o CI port driver As with the hardware, we'll look at the characteristics and purpose of each part of the cluster software. VAX-27 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View *The Distributed File System and RMS* The distributed file manager is new for VMS V4. In prior versions, there was one file manager for the entire disk. Whenever you wanted to do a disk I/O request, you queued up a series of ASTs to the F11ACPB process. Since synchronization resulted from the single threaded nature of the file manager process, you could wait a long time for an I/O request to complete if you had a slow disk being served by the F11ACPB process or if there were lots of users requesting lots of disk I/O. Under VMS V4, the file manager has become procedure based. It is now part of your process so that it runs whenever you need it to run. It achieves its synchronization via the lock manager rather than by the "single threadedness" under VMS V3. And, since the lock manager is now clusterwide, file access is also possible clusterwide. *The Distributed Lock Manager* The distributed lock manager is the primary synchronization mechanism used at the process level within VMS. It works clusterwide so that users can lock objects on both local and remote nodes. It also allows locking down to the record level so that you do not have to lock the entire file in order to update it while others are accessing it. *The Connection Manager* The connection manager is the cluster watchdog. It looks after things like cluster membership, concerns itself about quorum, and, in essence, defines and coordinates the cluster. Without this coordination, life in the cluster would be impossible. The coordination is partially achieved via the lock manager, but mostly via the quorum algorithm. Now, much as has been said about quorum. The connection manager, for example, maintains it, the system hangs if you lose it, and it prevents the dreaded "partitioned cluster". What exactly is it and how does it affect life in the cluster? The quorum concept comes from the legislature. A legislative body needs a quorum to conduct business. This means that there must be a majority of the members present before any laws can be passed. Without this, the minority could decide something that the majority might be against. Thus, if the legislative body does not have quorum, it must wait until enough members are present to reach quorum before it can do its work. Similarly, quorum in a cluster works the same way. The quorum is always set to be a majority of the cluster members. For example, if there are 5 members in your cluster, then quorum is VAX-28 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View set to 3 for, if you have 3 members present, then you can conduct your business. If you lose quorum, then the business of the cluster must stop. Why, you say? Let's look at an example. Suppose that you had 4 members of your cluster and quorum set to 2. You first boot one processor then a second. Together, they have quorum so off they go, reading and writing disks, happy as can be. Then you boot up the 3rd and 4th nodes. Suppose then can't find the first two (for whatever reason) yet they find each other. They too have quorum so they form a second cluster. They too start to read and write disks, happy as can be. What you now have is a partitioned cluster. The problem arise in that disk sharing is not coordinated between the two clusters. This means that two systems can be writing different information into the same disk block at the same time. The results of these rogue nodes running around, splattering bits on the disk here and there, will be a corrupted and unusable disk. This coordination problem is also the case where you have a VMS V3 system running on the same cluster as VMS V4 systems. Since they cannot coordinate access to the disks, a disk mounted writable under the V3 and V4 systems at the same time or you will rapidly corrupt the disk. *Disk/Tape Class Drivers* The disk class drivers handles all RA type disks, whether connected via the CI port driver or the UDA port driver. The tape class driver handles the TA tape drives connected via the CI port driver. Class driver, port driver? What is all this nonsense? What ever happened to that good, old fashioned device driver of yesteryear? Well, here's what it's all about. When you stop to think about it, a disk is just a set of randomly addressable blocks with an upper limit. That is really all that the operating system needs to know about a disk. It, in truth, cares not about the particulars of cylinders, tracks or sectors, nor does it care about revectoring of bad blocks, head offset positioning and the host of other error recovery techniques. In the past, there was a different disk controller for each type of disk. The RK controller had its own set of controller and error registers as did the RP disks as did the RM disks as did the RL disks. Since each set of CSRs was different, there needed to be a disk driver for each type of disk. DEC then asked themselves, "Why?". Don't all disks read and write blocks? Don't they all use the same recovery techniques? Since all that is true, why should we have to write separate disk drivers for each? Can't we have a common interface to all disks so that we don't have to write a separate disk driver for each new disk that comes along? VAX-29 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View The answer was, really, quite simple: standardize the disk interface to the system. With a standard interface, they only needed to write one disk driver. The disks themselves would adhere to this standard thereby making the addition of new disks relatively easy. The disk class driver, then, is one part of this idea. It handles the requests particular to a type (eg, RA) of disk. All RA class disks will adhere to the RA disk standard so that, when it comes time to plug the disk into the system, the software people do not have to write another disk driver just to access the new disk. The second part of this standardization is the port driver. While the class driver handles the particulars of a class of disk, tape or whatever, the port driver handles the particulars of the port that actually communicates with the device. For example, there is currently a CI port driver (PADRIVER.EXE) and a UDA-50 port driver (PUDRIVER.EXE). The PA driver talks to devices connected thru the CI, the PU driver to devices over the UDA-50. The port driver, then, serves to isolate the communications portion of the disk or tape driver from the driver code itself. With this concept in mind, consider what happens if DEC adds a new disk or tape class. All that they need do is write the driver for that class and they are done. The communications is already in place with the port driver. On the other side of the coin, suppose that they come up with a new interconnect architecture. Here, all that they need do is write a new port driver and viola, the disks are all ready to go. They would not have to disturb the disk driver itself. This class/port driver concept, then, benefits them with greater productivity from their programmers (fewer drivers to write), better reliability (less of the system to change when adding new devices) and greater flexibility to grow and change the interconnect or device hardware. *Mass Storage Control Protocol* The MSCP server makes locally connected disks available to the other nodes in the cluster. It, in essence, acts like a reverse disk driver, turning your VMS machine into an HSC. Requests that come to it via SCS are transformed into an IRP which, in turn, is placed into the driver's normal I/O request queue. The disk driver will eventually dequeue that request, service it, and pass the results back to MSCP. MSCP turns the request around and sends it back to the originator with the results of the request along with and data that the originator might have asked to be read. VAX-30 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View As an aside, it is interesting to consider the origin of the MSCP server. When DEC was first bringing up the cluster, they needed a way to test out the new cluster code. The HSC50s weren't ready at the time, so they developed the MSCP server to give them "clusterlike" access to locally connected disks. This allowed them to debug their code before all the hardware was actually in place. *System Communications Services* The SCS layer provides a guarenteed message deliver service. Messages will get to their destination or the sender will be told why such a message couldn't be sent. This corresponds roughly to levels 3 and 4 of the ISO model for communications. It also provides a homogeneous layer for doing reads, writes and so on across the cluster. It is the level that allows VMS to isolate the user from the hardware that actually implements these connections. *CI Port Driver* The CI port driver is responsible for a variety of things. First, it's responsible for reliable packet delivery. It makes sure that the packets it sends out indeed reach their destination correctly. Second, handles the CI hardware itself, fending both errors and interrupts as they occur. Third, it is responsible for configuring the cluster. Periodically, it goes out and polls the other nodes on the cluster asking "Who and what are you?". Using the responses it gets back, it builds a map of the cluster members that it then uses to control how messages are sent. Fourth, it along with SCS handles message flow control. The CI protocol is a conservative flow control mechanism that throttles the senders so that the receivers do not exceed their capacity to store the messages. And finally, it along with SCS provides for connects to other members. This layer sends the status back to the upper layers on the results of messages sent by those layers. There are a couple of additional points to be made about the CI. To begin with, it has no knowledge of the packet's contents. This allows the upper layers to change the contents as needed and still have the delivery mechanism work. Next, there is no direct $QIO interface: you must come thru SCS to get to it. This helps to shield it from changes further up in the system. It also minimizes that amoung of error checking it must do since it can trust requests from SCS. And finally, the CI port driver roughly corresponds to levels 1 and 2 of the ISO model, those being the physical and data link layers. *VAXCLUSTER CONFIGURATIONS* We have just reviewed the components of a VAXCluster, both VAX-31 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View hardware and software. The hardware is very fast and quite intelligent. The disk servers can handle a tremendous amount of concurrent processing. And, the interconnect for getting that information back is both extremely fast as well as reliable. The software, then, glues all this together to make up what we call the VAXCluster. Keeping all this in mind, let's grow a VAXCluster. We'll start first with a typical configuration in the precluster days as well as review the problems associated with such a configuration. Then, we'll add the VAXCluster components to see how they affect the configuration. Finally, we'll grow the cluster both with more processor power as well as more disk storage just to see how this can be done. *Precluster Configuration* Let's begin with a typical precluster configuration. Our examples consists of 5 processors, some local line printers, plotters, tape drives and other such devices. We have tied all these processors together via DECnet over an Ethernet cable. What we have is a loosly coupled network of autonomous processors. What are some of the problems associated with such a configuration? To begin with, you must use the network to access files on remote systems. This really isn't too bad since, from the user's point of view, all that you have to do is put the node name in front of your filenames and you've got access to the file that you want. However, in practice, there is the problem with ease of access and response times. In terms of access, it just isn't quite the same as having a local disk. Special previsions must be made in the software to do remote file access. Then, even if these provisions have been made, you still must go thru a network to get at the file. This access time is at least 100 times slower than disk access speeds. In addition to that, you have to have another processor help since you're going thru DECnet. So, while network access works, it is slower and more costly on your CPU and your patience. Then there's the problems of tape drives. A tape drive on a local node is not easily accessable from a remote node. Also, a remote disk is not easily accessable for things like backup to a local tape. Thus, you need at least one tape drive per system. What happens when that drive breaks or someone else is using it while you need it? And what about the cost of additional tape drive(s)? Considering these first two points, you soon discover a third problem: how do you grow and manage this configuration? To grow, you must replicate expensive hardware as well as provide additional power, air conditioning, cabling, communications, maintenance. As if this weren't bad enough, you now have VAX-32 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View another system to manage with its own disks, tapes, processing load and characteristics. All in all, this is both expensive and time consuming. Even with the additional processor, you run into a fourth problem: availability. Nobody likes to be without their computer. So what do you do when "your" machine dies that has "the" program that you need? Or if it's up, what do you do when it's overloaded? If poor response time is the bane of the system manager, then it is the undoing of the users. After all, don't users always wait until the last minute to do their work then demand top priority to get it done? And finally, there's the problem of software. Not only is licensing a problem, there's something even more basic than that: where is it? After all, you've installed it on one system, why isn't it available on the others? Here, you must install it once per system. That, in turn, eats up both your disk space and time of which there is precious little to begin with. These problems are all real and difficult to solve. You must then ask yourself: "Can you live within the non-cluster bounds?". Sure, if you have to. Most assuredly, anything can be made to work given enough time, money and people to do the job. The problem is that it is really painful. Wanting to avoid this misery, let's look at what a VAXCluster can do to help out this situation. *Initial VAXCluster Configuration* To convert the existing configuration to a VAXcluster, you'll have to add a Star Coupler, some HSC50s, convert your tapes to cluster tapes and add a CI to each processor. Note that we have protected our current investment since we've only added or upgraded existing hardware. So you take a few weeks to add all this new hardware in. But what does all this buy you? First of all, the disks and tapes have become accessable from any cluster node. In fact, the disks and tapes all appear to be local to each node on the cluster. This means that programs do not have to be rewritten to use the network: they simply have a logical name changed to make them look for their data in a different place. Secondly, managing the cluster becomes much easier. For example, all systems can now boot from the same disk. This means that software installs need only be done once per cluster, not once per node. And, since software licences are much cheaper for the 2nd thru nth nodes of the cluster, your programs can now run in more places. This, in turn, help tremendously for both availability as well as turn around. Programs that can be run on any processor in the cluster, will. And finally, replicated software need no longer be replicated. It can all exist on one disk that any node within the cluster VAX-33 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View can use. The end result of all this is better response to the users making them happy, better use of the company's computer resource making management happy and an easier time managing it making the operations people happy. *Adding More Processing Speed* Now that your cluster is in place, your life should be great. Right? You've done all the right things, everyone is happy, the world is great. But then, things being the way they are, you soon find that you've outgrown your processors. What do you do now? Now that the cluster is here, you have two choices. You can one, add another processor, or two, upgrade an existing processor. Either will help solve your problem. The choice will depend on such things as floor space, power, air conditioning and software licensing. If you add another processor, that's all that you add: no disks, tapes or other such major peripherals. It's not that you can't add, say, another stack of RA81s, it's just that you don't have to. All that you need is the processor and its 4 cluster cables. If you upgrade a processor, that could means something like a 780 to 785 upgrade where you swap the processor itself, or change the processing box as with a 780/785 to 8600 upgrade. In either case, the inconvenience is minor compared to what you'd have had to do in the non-cluster case. Once the hardware has been upgraded, you're back in business with more processing power, minimal downtime and no software changes. *Adding More Disk Storage* Now you've got your MIPS up. As soon as you do that, you run out of disk space (and this is only Monday...you've still got the rest of the week to go). So what do you do here? Well, this is even easier than upgrading a processor. Go talk with your friendly neighborhood DEC salesman, buy a stack or two of RA81s, some disk cables and a disk requestor for your HSC. When they arrive, plug them it and they are immediately available to all nodes in the cluster. That puts your disk capacity back up to where it belongs again. Mind you, it won't last long but, at least for the moment, you've taken care of the problem. *Adding More Tapes* Tape drives are analogous to disk drives: if you need more, just add them in. There is currently a limitation as to how many tape drives can be active on one HSC, but that should soon be lifted. Most likely, you had enough drives to begin with left over from your conversion. But if you need more, then just go ahead and add them. Once there, all nodes in the cluster will have access to them. VAX-34 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View The only real difference here is that of a master/slave drive. Tape drives with a formatter are called masters, those without, slaves. You can hook up at least three slaves for each master, the slaves, naturally, being a tad cheaper than the masters. So, if you need tapes, by all means, just go ahead and add them: the entire cluster will benefit from it. *RESULTS OF THE VAXCLUSTER DESIGN* So far, we have looked at the hardware and software components of the cluster. We have also gone thru several upgrades of a clustered system. There is a tremendous growth potential and configuration lattitude available on the VAXCluster. Now let's turn our attention to the results of the VAXcluster design. We will touch upon the I/O system, some VMS services and utilities, the common system disk and logical names. Each plays an important role within the cluster. Let's see what that role is. *VAXCluster I/O System* The main thrust of the I/O system design was to provide the user with a homogenious and consistent view of the disks and tapes no matter what processor they're using. We've already considered some of the design that went into this. The end results are really quite nice. For example, all disks appear as local to each processor. This "local disk" concept is easily understood by the users and has a tremendous benefit in that software does not have to be changed. This single file system, applied consistently clusterwide, is one of major benefits to be derived from the VAXCluster. Additionally, since the file manager is now part of each process, there is a good deal more concurrency in file/record access than before. This helps the performance of your I/O bound applications. *VAXCluster System Services and Utilities* When you consider the dramatic change in philosophy introduced by VAXClusters, you begin to appreciate the work needed to make all this happen. VAXClusters affected almost every portion of VMS, from the executive thru the utilities. With such a wide ranging effect, you would expect to find that many of the system services do not yet take advantage of the cluster. DEC's philosophy was to do those that would yield the greatest return first, then tackle the others as time permitted. This would get the cluster out the door and give them time to work in other areas later. Currently, device allocation, broadcast, OPCOM, REPLY and the job controller take advantage of the cluster. The distributed job controller is a perfect example of a facility that uses the VAX-35 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View cluster. The developers set up a shared RMS file to handle all the queuing requests. Then, by using the lock manager, the job controller was able to both coordinate access to this file as well as signal the other job controllers when there was work to be done. This resulted in clusterwide print and batch queues. Jobs can be submitted from any node and run on any node, adding much to the flexibility of VMS. DEC implemented these types of facilities since they gave the greatest benefit to cluster users. There are, however, other services and facilities which do not take advantage of the cluster. These include process control, error logging, accounting, event flags, logical names, mailboxes and writeable global sections. Take process control as an example. To get the status, change priority, stop, or otherwise manage a process, you must be on the node where that process is running. You must do a SET HOST via DECnet and log onto that process' node in order to affect it. It would be much easier to control it from the node you're currently using. Thus, there are other areas where DEC is working to increase cluster functionality and thereby make it easier to use. *The Common System Disk* Keeping your software up to date has always been a problem. There never seems to be enough time to handle all the daily emergencies as well as keep the systems running. And with a 5 to 10 node cluster with 5 to 10 systems all needing updating, there are only two chances that you'd be able to get to them all: slim and none. Realizing this, DEC developed the common system disk for VMS V4. One of the results of VMS V4 was the distributed file manager. It would allow processes on any cluster node to read or write most any file on any disk. This gave the developers the key they needed to create the common system disk. To do so, they defined a couple of rules: one, the disk had to be on an HSC; two, it could share around 2 to 6 systems; three, almost all files were shared except the node specific ones; four, software updates need only be applied once; and five, they recommended it for large disks. With the hard part done, they then set up the directory structure. For this, they wanted to maintain the rooted directories started in VMS V3. Each system would have its own system root, its own data files and shared images, libraries, help and the like. Thus, the files for a particular system would exist on the specific part of the directory structure; those common to all nodes would exist on a common directory structure. VAX-36 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View To implement this, they created the top level [V4COMMON] directory. It contains subdirectories for all the common files. Thus, within this directory you will find subdirectories like [V4COMMON.SYSEXE], [V4COMMON.SYSMGR] and [V4COMMON.SYSERR]. They then added the [SYSx.SYSCOMMON] directory to the normal system tree and were done. In fact, the file V4COMMON.DIR and [SYSx]SYSCOMMON.DIR are the same file. Thus, with the distributed file manager in conjunction with a little file magic, they were able to implement a common system disk. *Logical Names* Seeing as all this would be confusing for the users, the developers decided to throw caution to the wind and add search lists to logical names and really confuse the issue. This would make life a lot easier for applications referencing system files. Were it ever necessary to change the logical that pointed to the files, the applications could remain the same since VMS would handle the logical names translations for it. A search list is nothing more than a multivalued logical name. For example, the command $ DEFINE - $_ SYS$SYSROOT - $_ $1$DUA3:[SYS9.],$1$DUA3:[SYS9.SYSCOMMON.] sets up a logical name called SYS$SYSROOT that is equivalent to either $1$DUA3:[SYS9.] or $1$DUA3:[SYS9.SYSCOMMON.]. When RMS creates or searches for a file, it will try to do it with the first value of the logical name. If that fails, it will then try the second. If that fails, it will try the third, fourth and so on, until it either succeeds or runs out of equivalence strings. With this, DEC was able to do the following definitions: $ DEFINE SYS$SPECIFIC $1$DUA3:[SYSx.] $ DEFINE SYS$COMMON $1$DUA3:[SYSx.SYSCOMMON.] Note that the [SYSx.] is the node specific part of the system directory tree. The [SYSx.SYSCOMMON] is shared with all other nodes on the common system disk. These definitions in conjunction with the distributed lock manager and file system allowed DEC to create the common system disk. *SUMMARY* We have looked at VAXClusters from the generic point of view, considering first the hardware then the software. From there, we converted a non-clustered system into a clustered one. Once clustered, we then grew it by adding both processing power and VAX-37 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAXclusters - A Generic Point of View disk storage. We finally concluded with some of the results of the VAXCluster design. All in all, the VAXCluster is one of this most innovative ideas ever to hit the computer world. The wealth of benefits and flexibility of its design assure it a place in the computer world for many years to come. How Large is a LARGE Cluster? Pageswapper Editor Comment Nate Mann of General Electric in Louisville Kentucky compiled this list at the Anaheim symposium by posting a chart in the campground for members to fill in. The results in many cases show the size of clusters. In certain cases (barring field tests we have not dreamed of) they show the problems VAX people have adding numbers to total 16 or less. Type of Node Storage Nodes 750 780 785 8600 8650 HSC RA60 RA80 RA81 TA78 4 2 2 6 8 2 4 2 22 3 2 1 2 10 4 1 5 55 11 1 4 1 1 2 2 40 6 1 2 3 20 1 5 3 1 1 2 5 2 5 2 1 2 20 1 8 2 2 2 2 12 2 5 2 1 2 6 1 8 1 3 1 3 27 3 VAX-38 PAGESWAPPER - March 1986 - Volume 7 Number 8 How Large is a LARGE Cluster? 7 7 2 24 5 3 1 1 1 12 38 1 8 3 4 5 52 1 15 1 6 1 7 2 50 4 6 2 1 1 2 22 2 3 2 1 2 3 1 14 1 3 5 1 4 30 2 4 1 1 1 1 12 5 3 2 5 5 2 8 5 1 2 2 12 12 1 3 2 1 1 4 2 56 8 8 2 2 2 18 4 6 4 2 18 4 3 3 12 15 1 8 3 1 4 45 4 6 2 1 3 4 24 2 10 1 2 3 4 1 42 8 1 2 3 2 4 20 24 4 11 1 4 1 3 2 2 42 VAX-39 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER VMS V4 SCREEN MANAGER An Architecture Overview by Kevin Klughart Dallas Semiconductor 4350 Beltwood Parkway South Dallas, TX 75244 NOTE This article was originally published in the November 1985 DFWLUG Newsletter from the Dallas-Fort Worth Local Users Group. *WHAT IS SCREEN MANAGEMENT?* Screen management is simply the control of the random access terminal screen which has become the workhorse of the interactive environment on all VAX/VMS systems. By "control", we typically mean hardware control of things such as cursor position, character attributes, character set, etc. Several significant issues arise when implementing any type of screen management architecture: 1. Not all terminals have the same capabilities. Some interactive terminals are blessed with multitudes of character sets, video capabilities, and other advanced features. At the same time, other terminals may have nothing but very limited cursor movement and screen control functions. The goal of any good screen management system is to allow access to as many of the advanced terminal features as possible, while simulating them on lower-functionality terminals if at all possible. 2. Not all terminals respond to the same control sequences to perform the same logical function. Since terminals may be purchased from many different manufacturers, there is no guarantee that they will conform to any common standard with respect to what character sequences need to be sent to the terminal to perform a given function. For example, a VT52 and a VT100 both have the hardware capability to clear the screen with a simple control sequence, but the sequences are VAX-40 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER DIFFERENT for both terminals. This point was and continues to be true even though there now exist ANSI standards which describe the logical screen function in terms of a specific character sequence. 3. It is inefficient for each application program to generate its own screen management environment. For many years this is exactly what was done: applications which required use of any of the terminal hardware features had to design and code their own hardware specific screen control subroutines. 4. There are required logical functions that NO terminal supports. These MUST be simulated via hardware and for the sake of efficiency it would be very advantageous to have support from the operating system as well as some form of runtime system. Examples of this include field validation, creation of "windows" or "ports" on the screen for viewing of multiple screens of data, and the support of a great number of terminals from a common application program as in order entry systems. All of these examples illustrate cases in which the screen management tools are such significant coding efforts as to warrant operating or runtime system support. *SCREEN MANAGEMENT HISTORY* To realize how far the screen management support within VMS has progressed within the last several years, a brief history of screen management within Digital operating systems is in order. *RSX Ancestry* No talk about VMS can fail to mention the influence that RSX has had on the development of several of the major concepts behind the foundations of VMS. Screen management under most PDP-11 operating systems (including RSX) has been determined solely by the application software which exercised complete control over the hardware environment. In these systems, the limited size of the processor address space discouraged support of large and robust runtime subsystems. In short, code space was so tight in many cases that screen management was embedded internally if at all. *VMS V1* As originally shipped, VMS did not include ANY screen management software. All basic primitive functions related to terminal hardware functions had to be implemented via user-coded calls to VAX-41 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER QIO system services. This required a reasonably sophisticated knowledge of VMS system services, hardware specific terminal control sequences, the VMS procedure passing mechanisms, and a thorough reading of the VMS I/O user's guide. Even with all of this work, the resulting program was typically hardware (VT100) dependent and did not reflect support for any other class of terminal, such as hardcopy devices. In addition, typical implementations of screen management software at this level were very inefficient and in many cases language specific (i.e., only callable via COBOL). *VMS V2* When VMS V2 was shipped, there was included a new and relatively unheralded SCR screen management package within the VMS RTL. This basic terminal screen subsystem included the following functionality: o Capability to add support for additional terminals (with the addition of user-written MACRO routines). o Basic screen control functions including erasing, positioning the cursor on the screen, displaying text, at any position on the screen, and controlling basic character attributes (bold, blink, underline, reverse video). o Support for BOTH high level languages (FORTRAN, COBOL, and BASIC, etc.) as well as a highly efficient MACRO32 interface. The high level language interface assumed call-by-reference, whereas the MACRO32 interface assumed call-by-value for all numeric subroutine parameters. While this package proved to be of great benefit to both systems and applications programmers, it fell short of providing truely generic support for all terminal types and lacked any higher level screen control functions such as windowing. In addition, supporting non-standard terminal types was relatively difficult and time consuming. These facts combined to severely limit the use of this package in very sophisticated screen applications. *VMS V3* Although VMS V3 included major functional changes to the operating system, no substantial improvements were made to the SCR screen management facility within the RTL. However, there were growing requests from the Decus user community for the following: VAX-42 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o Improvements to the screen subsystem to support a wider range of ANSI terminal functions, as well as an expanded emulation subsystem for those terminals which did not posses these ANSI functions. o Major functional improvements to the EDT editor to support user-defined terminal types, multiple windows, and other screen related enhancements. These two items may seem of a totally different nature, but in fact they are closely related. To provide a higher order EDT style editor it was necessary for Digital to first address deficiencies within screen management both at a runtime system level and at an operating system level. The operating system level support was addressed via additions to the VMS terminal driver system in one of the point releases of VMS V3. This support was provided primarily for the FMS forms management system, but was in fact a first step at migrating screen management software from the application level to the operating and runtime system level. *VMS V4* With the advent of VMS V4, Digital made a strong commitment to the support of a general purpose, highly functional, extensible screen management facility which includes the following features: o Total dissociation between the physical terminal screen and the logical display which is addressed by the application program. In other words, the hardware dependencies of screen management have been totally removed from consideration when designing screen applications. This was a severe limitation in the V2 SCR RTL package, which still required a reasonable knowledge of the VT100 hardware. o Standardization of "logical" versus "physical" screen commands. This is consistent with the Digital philosophy of isolating hardware related functions from their logical counterparts. For example, erasing a terminal screen is a logical function which has a physical counterpart which is a terminal control sequence. o Sophisticated display and window control commands which allow multiple logical screens to be present on one physical output screen. This also includes support for multiple physical output screens, which has applications in situations where one program controls a great number of terminals. VAX-43 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER *BASIC SCREEN MANAGEMENT ENTITIES* The basic entities of the V4 SMG routines include the following: o Pasteboards A pasteboard is a virtual map of a physical terminal screen. It contains as many rows and columns as there exist on the physical terminal. Its characteristics (screen width, character set, character attributes) can be controlled by changing its characteristics. Application programs do not write directly to the pasteboard, but rather PASTE whole display regions on the pasteboard. Therefore, the pasteboard can be thought of as simply a bullitin board on which notes (displays) are placed. o Virtual Displays A virtual display is a rectangular region to which user application programs may write text. The difference between a pasteboard and a virtual display is that the pasteboard is by definition constrained by the physical limitations of the terminal to which it is associated, whereas a virtual display may be of any size deemed necessary by the application program. For example, it is possible to create a virtual display of 10 rows by 30 columns or 30 rows by 900 columns. A virtual display does not appear on the pasteboard until it has been PASTED on the pasteboard. The PASTE operation takes the origin (1,1) of the virtual display and places it at some absolute location on the pasteboard. Once this operation occurs, the portion of the virtual display which falls within the pasteboard region will be visible to the user at the terminal. o Virtual Keyboards A virtual keyboard is essentially a logical input device associated with a specific virtual display. Since each virtual display could have an independent area for user inputs, it is possible to display a multiple number of virtual displays on a pasteboard and input data to each virtual display from the terminal keyboard. As you can see, the basic conceptual items involved in screen management include just three items: pasteboards, virtual displays, and virtual keyboards. However, the significance of these structures is that the runtime screen manager system completely controls the relationship between these logical VAX-44 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER entities and the physical terminal, releasing the application programmer from this burden. It should be noted at this point that the backbone of the screen management facility is the functions which are applied to virtual displays. Pasteboards and virtual keyboards are used to a much more limited extent than virtual displays, in which most of the screen output occurs. *PASTEBOARD PRIMITIVES* o SMG$BEGIN_PASTEBOARD_UPDATE - saves, or batches, all output to a pasteboard until a matching call to SMG$END_PASTEBOARD_UPDATE is encountered. o SMG$CHANGE_PBD_CHARACTERISTICS - lets you change the width, height, and background color associated with a pasteboard. o SMG$CONTROL_MODE - controls buffering, minimal updating, whether the screen is cleared when the pasteboard is deleted, and whether tab characters are used for screen formatting. o SMG$CREATE_PASTEBOARD - creates a pasteboard and returns its assigned pasteboard-id. o SMG$DELETE_PASTEBOARD - deletes a pasteboard. o SMG$DEL_TERM_TABLE - terminates access to TERMTABLE.EXE and frees the associated virtual address space. o SMG$END_PASTEBOARD_UPDATE - ends update batching for a pasteboard. o SMG$ERASE_PASTEBOARD - erases a pasteboard; that is, it clears the screen. o SMG$FIND_CURSOR_DISPLAY - returns the identifier of the most recently pasted virtual display that contains the physical cursor. o SMG$FLUSH_BUFFER - flushes all buffered output to the terminal. o SMG$GET_BROADCAST_MESSAGE - determines whether a message has been broadcast to the pasteboard and returns the message. o SMG$GET_CHAR_AT_PHYSICAL_CURSOR - returns the character at the current physical cursor position. VAX-45 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o SMG$GET_NUMERIC_DATA - accesses TERMTABLE.EXE and returns the numeric sequence that causes a terminal to perform a specified operation. o SMG$GET_PASTEBOARD_ATTRIBUTES - gets pasteboard attributes and stores them in the pasteboard information table. o SMG$GET_TERM_DATA - accesses TERMTABLE.EXE and returns the character sequence that causes a terminal to perform a specified operation. o SMG$PUT_PASTEBOARD - accesses the contents of a pasteboard. o SMG$RESTORE_PHYSICAL_SCREEN - rewrites the screen image as it was at the time the SMG$SAVE_PHYSICAL_SCREEN routine was called. o SMG$SAVE_PHYSICAL_SCREEN - saves the contents of the screen so that a later call to SMG$RESTORE_PHYSICAL_SCREEN can restore it. o SMG$SET_BROADCAST_TRAPPING - enables or disables the trapping of broadcast messages. o SMG$SET_OUT_OF_BAND_ASTS - either enables or disables the trapping of out-of-band characters. o SMG$SET_PHYSICAL_CURSOR - moves the physical cursor to the specified position on the physical screen. o SMG$SNAPSHOT - writes the current pasteboard buffer to the file or hardcopy terminal specified by pasteboard-id. *Virtual Display Primitives* o SMG$ALLOW_ESCAPE - enables or disables SMG parsing of escape sequences which are output to a virtual display. o SMG$BEGIN_DISPLAY_UPDATE - saves, or batches, all output to a virtual display until a matching call to SMG$END_DISPLAY_UPDATE is encountered. o SMG$CHANGE_RENDITION - changes the video attributes for all or part of a virtual display. o SMG$CHANGE_VIRTUAL_DISPLAY - lets you change the dimensions, border, and video attributes of a virtual display. VAX-46 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o SMG$CHECK_FOR_OCCLUSION - checks to see whether a virtual display is covered by another virtual display. o SMG$CREATE_VIRTUAL_DISPLAY - creates a virtual display and returns its assigned display id. o SMG$CURSOR_COLUMN - returns the virtual cursor's current column position in a specified virtual display. o SMG$CURSOR_ROW - returns the virtual cursor's current row position in a specified virtual display. o SMG$DELETE_CHARS - deletes characters in a virtual display. o SMG$DELETE_LINE - deletes lines from a virtual display. o SMG$DELETE_VIRTUAL_DISPLAY - deletes a virtual display. o SMG$DRAW_LINE - draws a horizontal or vertical line. o SMG$DRAW_RECTANGLE - draws a rectangle. o SMG$END_DISPLAY_UPDATE - ends update batching for a virtual display. o SMG$ERASE_CHARS - erases characters in a virtual display by replacing them with blanks. o SMG$ERASE_DISPLAY - erases all or part of a virtual display by replacing text characters with blanks. o SMG$ERASE_LINE - erases all or part of a line in a virtual display. o SMG$GET_DISPLAY_ATTR - returns attributes associated with a virtual display. o SMG$HOME_CURSOR - moves the virtual cursor to the specified corner of a virtual display. o SMG$INIT_TERM_TABLE - initializes the TERMTABLE database for the terminal named, so that subsequent calls to SMG$GET_TERM_DATA can extract information and command strings for that terminal. o SMG$INIT_TERM_TABLE_BY_TYPE - initializes the TERMTABLE database for the terminal named, so that subsequent calls to SMG$GET_TERM_DATA can extract information and command strings for that terminal. VAX-47 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o SMG$INSERT_CHARS - inserts characters into a virtual display. o SMG$INSERT_LINE - inserts a line into a virtual display and scrolls the display. o SMG$INVALIDATE_DISPLAY - marks a display as invalid and causes the entire display to be redrawn. o SMG$LABEL_BORDER - supplies a label for a virtual display's border. o SMG$LIST_KEY_DEFS - returns the definition (equivalence string) associated with a specified key in a specified key table. o SMG$LOAD_KEY_DEFS - loads a file of key definitions (DEFINE/KEY commands) into a specified key table. o SMG$MOVE_VIRTUAL_DISPLAY - relocates a virtual display on a pasteboard and preserves the pasting order. o SMG$PASTE_VIRTUAL_DISPLAY - pastes a virtual display to a pasteboard. o SMG$POP_VIRTUAL_DISPLAY - deletes a specified virtual display and all displays that were pasted on the specified pasteboard after the specified virtual display. o SMG$PUT_CHARS - overwrites characters in a virtual display with the text you specify. o SMG$PUT_CHARS_HIGHWIDE - writes double-height, double-width characters to a virtual display. o SMG$PUT_CHARS_WIDE - writes double-width characters to a virtual display. o SMG$PUT_LINE - writes a line of text to a virtual display. o SMG$PUT_LINE_HIGHWIDE - writes lines with double high/double wide characters. o SMG$PUT_LINE_WIDE - writes a line of double-width text to a virtual display. o SMG$PUT_VIRTUAL_DISPLAY_ENCODED - lets you write a string that has multiple video renditions to a virtual display. VAX-48 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o SMG$PUT_WITH_SCROLL - writes a line of text to a virtual display and scrolls the display if necessary. o SMG$REPAINT_LINE - repaints a series of lines on the current screen. o SMG$REPAINT_SCREEN - repaints the current screen after non-SMG I/O has occurred. o SMG$REPASTE_VIRTUAL_DISPLAY - moves a virtual display to a new position on the pasteboard. The pasting order is not preserved. o SMG$RETURN_CURSOR_POS - returns the current virtual cursor position in a specified virtual display. o SMG$RING_BELL - sounds the terminal bell or buzzer. o SMG$SCROLL_DISPLAY_AREA - scrolls a rectangular region of a virtual display. o SMG$SET_CURSOR_ABS - moves the virtual cursor to the specified position in a virtual display. o SMG$SET_CURSOR_REL - moves the virtual cursor the specified number of rows and columns from the current virtual cursor position in a virtual display. o SMG$SET_DISPLAY_SCROLL_REGION - creates a scrolling region in a virtual display. o SMG$UNPASTE_VIRTUAL_DISPLAY - removes a virtual display from a pasteboard. *Virtual Keyboard Primitives* o SMG$ADD_KEY_DEF - adds a keypad key definition to a table of key definitions. o SMG$CANCEL_INPUT - immediately cancels any read-in-progress that was issued by SMG$READ_COMPOSED_LINE, SMG$READ_KEYSTROKE, SMG$READ_STRING or SMG$READ_VERIFY. o SMG$CREATE_KEY_TABLE - creates a table for key definitions. o SMG$CREATE_VIRTUAL_KEYBOARD - creates a virtual keyboard and returns its assigned keyboard-id. VAX-49 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o SMG$DEFINE_KEY - performs the DEFINE/KEY command you provide. o SMG$DELETE_KEY_DEF - deletes a key definition from a specified table of key definitions. o SMG$DELETE_VIRTUAL_KEYBOARD - deletes a virtual keyboard. o SMG$DISABLE_UNSOLICITED_INPUT - disables the invocation of AST routines for unsolicited input. o SMG$ENABLE_UNSOLICITED_INPUT - detects unsolicited input and calls an AST routine in response. o SMG$GET_KEY_DEF - returns the key definition for a specified key. o SMG$READ_COMPOSED_LINE - reads a line of input composed of normal keystrokes and equivalence strings. o SMG$READ_FROM_DISPLAY - reads a line of text from a virtual display. o SMG$READ_KEYSTROKE - reads a keystroke and returns that keystroke's terminator code. o SMG$READ_STRING - reads a string from a virtual keyboard. o SMG$READ_VERIFY - reads a sequence of characters and verifies the sequence. o SMG$SET_KEYPAD_MODE - sets the terminal's numeric keypad to either numeric or applications mode. o SMG$SET_DEFAULT_STATE - sets and/or returns the current default state for a key table. *GETTING STARTED* One of the most difficult aspects of the SMG screen manager is determining where to start in the design cycle when using it. Although not totally generic, the following flowchart should help in designing this package into application programs. 1. Create a pasteboard on which to work by calling SMG$CREATE_PASTEBOARD. VAX-50 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER 2. Create a virtual display by calling SMG$CREATE_VIRTUALDISPLAY. This step may be repeated as necessary for each "window" that the application program wishes to write to. 3. For each virtual display, optionally create a virtual keyboard for data entry by calling SMG$CREATE_VIRTUAL_KEYBOARD. Many applications will only require one keyboard input channel. 4. Paste the virtual display on the pasteboard by calling SMG$PASTE_VIRTUAL_DISPLAY. This associates a physical origin for the virtual display on the pasteboard (terminal screen). 5. Write to the virtual display using the necessary SMG virtual display output routines. 6. When done with a virtual display, call SMG$UNPASTE_VIRTUAL_DISPLAY to remove the display from the pasteboard and then SMG$DELETE_VIRTUAL_DISPLAY to delete the display. 7. When done with the pasteboard, call SMG$DELETE_PASTEBOARD to delete the pasteboard structure. As you can see, implementing the SMG routines is easy, especially if higher level languages are used. *MISSING FEATURES* Although Digital has provided a very functional screen management system under VMS V4, there are several deficiencies: o Documentation was somewhat deficient in the initial V4.0 SMG release. Several routines were omitted from the documentation, and in some cases the documentation was simply wrong. In addition, the naming conventions used within the runtime system were not consistent. For example a single line on the terminal screen might be referred to as a ROW, LINE, ROW-NUMBER, LINE-NUMBER, etc. This was somewhat confusing and hampered the generation of a suitable MACRO32 interface to the SMG routines. o No support for down-line loading of VT220 user-defined keys. VAX-51 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o No support for terminal LEDS for VT100 terminals. o No support for single-width, double-height characters (this feature exists on some brands of DEC-clone terminals). o No support for changing the ORDER in which displays are pasted on the screen. In some cases it would be useful to temporarily bring one virtual display to the "foreground" of the screen for inspection and then return it to its original position in the display list order. This and other similar changes to the display list organization cannot be done within the current architecture. The workaround is for the application program to keep track of the display order internally and UNPASTE and rePASTE the display list in the desired order. o No support for the insertion of device specific control sequences in output streams. In some cases when talking to an "almost-DEC" compatible terminal it is useful to emit control sequences without the screen manager getting in the way or interpreting these sequences. There appears to be no way to do this using current SMG calls. o No support for call-by-value arguments. As stated previously, the VMS V2 SCR screen manager allowed MACRO32 programmers to call screen routines with all numeric arguments passed by value. This was extremely useful feature which was omitted from the VMS V4 SMG screen package, which caters exclusively to higher level languages which use call-by-reference by default. The result of this omission is a substantial coding burden for MACRO32 programmers. o No support for logical windowing functions such as GROW, SHRINK, MOVE, SCROLL LEFT/RIGHT/UP/DOWN at the user-interface level. It would be very useful in some circumstances to have the runtime system maintain the virtual displays on the pasteboard, with the terminal keyboard keys being used to allow scrolling and other window control functions without application intervention. As currently implemented, these functions must be fully supported by the application program. o No support for more than one border label per virtual display. It is not currently possible to border a virtual display and label each of the four sides with a different text label. Only the last border label command is accepted by the SMG routines, with all other border sides being blanked. VAX-52 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o No support for additional character sets. The only supported character set in V4 SMG calls is the standard ASCII character set. o No support for dynamic character set definitions in the VT220 terminal line. The VT220 supports a dynamic character set definition facility. This is not currently supported by the SMG routines. o No support for auxiliary or printer ports attached to the terminal. o No support for answerback messages from the terminal. o No support for detection/modification of terminal setup features. *IMPLEMENTATION HINTS AND KINKS* Several hints can be of great use when designing applications around the SMG screen manager: o Use structured display lists. When one application requires that many virtual displays be generated for a single pasteboard, it is often expedient to create a linked list of all virtual displays to be created/pasted and then drive this structure via a loop mechanism when the program is first initialized. This saves the separate creation/paste code for each virtual display to be generated, as well as providing a concise structure which may later be modified to move, pop, or repaste the displays on the pasteboard. o When using the keypad to drive screen options, use of the VAX-11 CASE machine instruction is very useful. Consider the case in which you wish to provide support within an application for the VT100 and VT200 series terminals. By using the SMG routine SMG$READ_STRING or SMG$READ_KEYSTROKE, it is possible to trap a single key entry as a terminator code from 0 to 511. This read termination code can then be used as an index for a computed GOTO (CASE) instruction which vectors to the routine to process the keystroke. GOLD and BLUE key entries, when used as key modifiers, can be saved as needed to modify the action of the action routine. This method is particularly attractive because it involves only one machine instruction rather than some lengthy comparison or search operation, and at the same time can be modified to support any class of present or future terminal type. VAX-53 PAGESWAPPER - March 1986 - Volume 7 Number 8 VMS V4 SCREEN MANAGER o Make good use of the occlusion capabilities of the screen manager so that little used displays are normally covered, but can be restored as needed for viewing. A prime example of this is a status return area, which may be 24 or more lines in length, but normally is occluded to show just one or two lines of text. VAX-54 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 THE FALL 1985 DECUS US SYMPOSIUM Version 1 December 8-13, 1985, Anaheim, California by Bill Hancock, CSP Consultant 2510 Limestone Ln. Garland, Texas 75040 NOTE This article was originally published in the January 1986 DFWLUG Newsletter from the Dallas-Fort Worth Local Users Group. This symposium was not as active as most due to a paucity of announcements of new products by Digital prior to the symposium. Still, there was some lively discussion about current DEC products and some hints as to soon to be announced products. It should be noted that, contrary to previous Digital practices, there was little discussion concerning new products or products in engineering. This is due to a rash of legal problems Digital has been involved in lately as well as the legal offices at DEC being more paranoid than normal considering the depressed computing industry. This summary is not meant to be all-encompassing. Its purpose is to cover the more pertinent items discussed at the symposium for informational and planning purposes. *VAX/VMS* *VAX 8650* There were several sessions concerning the announcement of the VAX 8650 product (announced on December 4th). Basically, it is the same, architecturally as the 8600 processor with the following features: o 44% increase in throughput over the 8600 (approx 6 X 780 speed) o Ability to support 68Mb of main memory o Upgradable from the 8600 (in a manner similar to the 780-785 path) VAX-55 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 *MicroVAX II* MicroVAX II was enhanced by the following: o KDA50 MSCP disk controller - Allows connection of MSCP disks (RA-series) to the MV II o New configurations - 1Gb single cabinet configuration - 2Gb dual cabinet configuration - Expanded Q-Bus capabilities o Support of Elan on MicroVAX II systems *VAX-11/780* A reduced cost version of the 11/780 will be introduced to take advantage of reduced hardware costs as well as move older technology. *VAX-11/785* 256K memory support was announced that allows a 785 to utilize up to 64Mb of main memory. *8600* Ultrix support for the 8600 was announced as well as use of 256K memory for a total support of up to 68Mb of main memory. *VAX Peripherals* The following peripherals were announced as supported on VAX systems: o 4-high disk cabinets for RA-series disks o TA81 - a cluster-compatible TU81 low-cost 1600/6250 streaming tape o TK50 support for UNIBUS VAX systems *Ultrix-32 V1.2* Ultrix V1.2 continues support of BSD V4.2, but also is compatible with UNIX V5.0. Also, DECnet Ultrix V1.0 was further discussed (it was covered in New Orleans). *VAXStation 5XX Color Graphics Workstation* An advance-development stage high-resolution color graphics workstation was demonstrated in the exhibit hall. While details are sparse, the station was impressive and worked well. VAX-56 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 *Workstation V2.0* V2.0 of the VAXStation software was announced (supported in VMS V4.3). Also, the UIS program interface will be documented in the V2.0 release. *VMS V4.3* V4.3 is mainly bug fixes and uVMS modifications. It is currently in the software distribution center and should be shipping now. V4.3 and V4.4 will NOT support volume shadowing or journaling. The most constant answer was "...probably in Dallas." *New Version Definitions* Even numbered versions will be major upgrades to VMS (new features, enhancements, bug fixes). Even number versions will also be re-mastered kits (a complete installation can be performed from an even number kit and will not require the previous numbered kit. Odd numbered versions will be engineering updates and fixes only (no major enhancements). Digital is concerned that new enhancements need not wait until a new major release of the operating system before usage (release the functionality as it arrives or is available). Also, they do not want to do another V3.7-V4.0 upgrade again in the future due to the difficulty and effort involved. The general idea is to make upgrades predictable on a four month cycle (4 months, maintenance; 8 months, major upgrade). Digital is also concerned about software licensing. Dick Mahoney, VMS Product Manager, stated in the VMS Update Session that "...with the dropping cost of software, Digital needs to keep its profitability from other sources. The most logical place is in software and that is where you will see increases...in the future." This can easily be interpreted as DEC is going to find newer ways to charge for upgrades as well as enhanced-cost software licenses as new releases are made available in the future. *VMS V4.4* VMS V4.4 was announced with few enhancements, most of them being in the lock manager to support (in the future) volume shadowing and journaling functions. Some of the items in V4.4 included: o On MicroVAX systems, V4.2 must be installed FIRST with the user key installed BEFORE V4.3 is installed. This problem will be fixed in "...a future release." o Full support for shared files (any type of sequential file; in previous versions, only fixed 512-byte sequential files were supported as sharable). VAX-57 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 RM0SHARE.MAR recoded in BLISS-32 for V4.4. o Improved file and global buffer section locking performance which means reduced lock manager utilization o New lock mode (NL) for "no-locks" o Better visibility in file locking examination (Shared File Synchronization Block - SFSB): SDA> SHOW PROCESS/RMS=IFB (Get SFSB address from IFB$L_SFSB_PTR) SDA> READ SYS$SYSTEM:RMSDEF.STB SDA> FORMAT/TYPE=SFSB address o New lock feature: APPEND LOCK to speed appending operations and reduce locking operations o Support for IEEE 802.3 Ethernet (co-existence with V2 Ethernet) o Printer support on terminal servers (see below section on networks) o Node names in a cluster (one node name for entire cluster- ALIAS) ALIASes for each participating node: NCP> SET EXECUTOR ALIAS ADDRESS 1.234 NCP> SET EXECUTOR ALIAS NAME HANNA NCP> SET EXECUTOR ALIAS INCOMING ENABLED ! or DISABLED Object using ALIASes for OUTGOING/INCOMING connects: NCP> SET OBJECT MAIL ALIAS OUTGOING ENABLED NCP> SET OBJECT PHONE ALIAS INCOMING DIABLED o Node databases in a cluster (one DECnet database for entire cluster) The database is split into two databases: SYS$SPECIFIC:[SYSEXE]NETNODE_LOCAL.DAT SYS$COMMON:[SYSEXE]NETNODE_REMOTE.DAT Conversion done during upgrade and is NOT manadatory. Define executor name on one node is an implied define of the node name on the others NCP> DEFINE EXECUTOR NAME YOGI implies NCP> DEFINE NODE 1.230 NAME YOGI Executor address MUST be defined first. Download information is seen by all sharers. VAX-58 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 o Improved processing of downline system load requests (for terminal servers, etc...) o Pipeline for DMR11 satellite links o Support for new Ethernet UNIBUS adapter (DELUA) o ACL has been re-written and is now TPU based o A GOSUB function has been added to DCL o Sort will allow descending key sorts o Cluster operations: - Mount verification is enhanced and speeded up - Improved cluster monitoring (SHOW CLUSTER) - Enhancements to MONITOR for cluster operations and analysis - VAX Information Architecture support (A1, etc...) *VAX Performance and Coverage Analyzer (PCA)* PCA is a new Digital product for analyzing VAX process performance. It is NOT a system performance analyzer. Basically, it is linked into a program that has been compiled with the /DEBUG option and allows the collection of performance data during the running of the process. Demos looked interesting and seemed fairly easy to use for the average programmer (not to be used for users not familiar with basic programming skills). *Discontinuation of Support for RL02 System Disks on 11/730 Systems* Digital announced a cesation of support for RL02's as system disks. The RL02 will still be supported as a data disk, but it was felt that VMS is getting too big for the smaller disks and cannot be supported on the smaller disks. A side comment was also made that as VMS grows, older technologies and smaller systems will be dropped as necessary for positive future growth of VMS. What this means is not clear other than DEC clearly intends to drop support for some VAX systems as the VAX line grows. A statement was also made that the 11/725 poses a severe problem as the RC25 disk is not large enough for a systems disk. What this means is not clear, but 11/725 owners with RC25's should be watchful. *HSC50 Upgrades* HSC50 upgrades are currently thought of as an FCO operation to be administered by field service. It is thought that HSC software could be distributed much in the same manner as operating system and layered product software. As a result, future releases of HSC software may be subjected to software VAX-59 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 licensing agreements and support contracts. *Networking Products* *IEEE 802.3 Support* A new line of products were announced to support the IEEE 802.3 Ethernet specification. Basically, there are the following new products: o DELUA UNIBUS Ethernet adapter - Single hex board - 8 amps power draw, 5.5 average (DEUNA 16-20 amps) - Reduced heat generation - Supports IEEE 802.3 - 80Kb RAM for buffering - 4.0 Mbit/sec performance o H4005-A and H4005-B Tranceivers (one with "heartbeat" for V2, one without) - Physically much smaller - Tappable via special handtool (much more efficient than the drill method used on H4000 tranceivers) o DEMPR Thinwire (RG58 coax cable) multiport repeater support - 8-thinwire coax hub station - 29 daisy-chained stations per segment - 232 stations per DEMPR - Standalone or connected to regular Ethernet cable - High-performance - IEEE 802.3 support o DESTA Thinwire Station Adapter - 15-pin D-connector and BNC connector to thinwire Ethernet o DEBET LANBridge 100 - Connects two Ethernets together allowing reduced traffic routing - Uses coax or fiber interconnection between Bridges VAX-60 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 - Store and forward capability - Provides IEEE MAC support (all 802 series of specs provide for MAC support which can be interpreted as future support for additional 802 series networks in the future) - Dynamically learn end stations locations - Protocol independent - Allows increase of maximum node-to-node distance - Allows more nodes per total network Digital stated a three phase approach to implementation of the IEEE 802.3 program as follows: 1. IEEE 802.3 product generation 2. Future release of operating systems (device driver modifications) 3. Future release of DECnet *LATplus for VAX Systems Using Terminal Servers* LATplus is an enhancement to the LAT software package that is used on host VAX systems in the terminal server environment. Terminal servers must be running V2.1 and DECServer-100's must be running V1.2 (there was no mention of LAT-11, but the current supported version is V1.1). Additionally, VMS V4.2 or later must be running on the host system. At present, LATplus is an additional package but will be bundled into the LAT software package. As such, there is no order number and will be released to LAT users as soon as publicly available. LATplus provides the following capabilities: o Printers connected to terminal servers may be identified by server-name and port-name on VMS service nodes o Printers connected to the Ethernet Terminal Server product may also be offered as services o Printers may be shared by service nodes (multiple systems may access a single printer on a given terminal server. The terminal server keeps a FIFO queue of print requests and prints the requests in a round- robin fashion as the requests are serviced. A special print symbiont is used for this operation and is not compatible with current print symbionts or user-written symbionts.). o Hardcopy terminals can be set up as printers and/or interactive terminals o PASTHRU mode (data transparency except XON/XOFF) and PASSALL mode (total data transparency) are new modes (for probable async DECnet support in the future). These can be accessed by programs on the server. VAX-61 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 o BREAK control can now be specified as local, remote, or disabled o Inactivity timers can be specified (no activity, user is logged out) o Service passwords now supported (set up as a service parameter) *DECnet-DOS V1.0* DECnet-DOS is an asynchronous implementation of DECnet for the PC-DOS/MS-DOS environment. DECnet-DOS is supported on the following machines: o IBM PC, XT (under PC-DOS) o Rainbow 100, 100+, 190 (Rainbow MS-DOS) Features of DECnet-DOS include: o Low connection cost o File transfer capability (also, directory, print, etc...) o Transparent task-to-task capability o Virtual terminal support (CTERM protocol emulates VT102) o Looks like a Phase IV end-node o Allows async DDCMP functions o Full MODEM control o Provides synchronization with MS-DOS I/O o C and assembly language compatible (implemented in C) o Currently supports only V2.0 DOS I/O calls o Uses DECnet DAP for file access o Ultrix-compatible socket access o Allows virtual disk access and virtual printer access on host systems o Network management features (NCP on PC) o NTU for network testing Possible futures that were discussed (located in the session notes): o Ethernet support o IBM AT and PC-DOS V3.1 support o Automatic installation o SETHOST mutiple session support o MAIL o MS-NET compatibility and capabilities o IBM PC network emulation o Workstation servers o ISO protocol support VAX-62 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 *OTHER ITEMS OF INTEREST* *Languages* Several sessions were held on VAX Pascal V3.0. Also, VAX RPG was heavily talked about, but nothing new for the most part. *EIA 423 Support* Selected interfaces will be supporting EIA 423 (the old RS-423) for increased distance and speed. *P/OS V3.0* P/OS V3.0 was shown to mixed reviews. Most knowledgeable users were underwhelmed and not pleased with the new version. Complaints of bugs and incomplete features were made by quite a few people. P/OS V3.0 supports the Ethernet interface. *Rainbow RD31 Support* Support for the RD31 Winchester disk was announced as well as other personal computer directions (see below). *Packaging and Documentation* Discussion from various entities within Digital showed a MAJOR concern over the expense of documentation and packaging of system distributions/updates. Apparently the V4.2 upgrade was extremely expensive for Digital and general solutions needs to be found to the escalating documentation cost problem. *PC Directions* Various sessions on PC directions were evident and discussion was raised about some obvious future systems from Digital called the PCXX and VAXMate. The PCXX is purported to be an IBM clone with "enhancements" and VAXMate is anyone's guess (no one would say much about it). Also, some discussions were held on printer servers, disk servers, and other capabilities necessary for PC support in the VAX and networked environment. *Digital Escalated Release of New Products* Digital management personnel claimed that over 300 new Digital products have been announced in the last year. Also, a chart showing VAX announcements over the last nine years was interesting. In the first three years, one VAX was announced. In the next three year period, 2 new VAX systems were announced. In the last three years, six new processors have been announced. Digital expressed concern that there were an increadible number of new product announcements and that the number was escalating rapidly. VAX-63 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 1 *Industrial Macintosh Workstation* At a session on the theoretical VAXintosh (an architecture under development by a group of highly qualified DECUS members), a company called J.A.M.E.S. announced that a processor system called the Industrial MAC would be announced in February. This announcement was substatiated by Apple personnel in the audience and was claimed to satisfy 90% of the desired items on the wishlist, such as: o Split-session terminal access o Host-programmability of remote unit o VAX-based hosting of applications o Low per-terminal cost o Host-directed access to terminal primitives and host-emulated terminal primitives o Multi-networking capability (LAN, async, etc...) o Voice interconnectivity o Graphics compression o File format conversion capability for support of popular formats (such as SYLK, DIF, DCA, and others) *Product Retirement* Some comments were made by Digital management personnel about product retirements. Apparently, DEC is in the process of retiring a number of their existing older products and have some concerns about how to approach the user base. On what products are going to be retired, they would not elaborate. *Summary Comments* The general impression given by most knowledgeable Digital personnel was that there are going to be a SUBSTANTIAL number of announcements of new products between now and the Dallas symposium (in April, 1986). As a result, there was some unusual tight-lippedness at Anaheim, but some hints were dropped that DEC was going to make some fairly eye-raising announcements in the very near future. VAX-64 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 2 THE FALL 1985 DECUS US SYMPOSIUM Version 2 by Mike Drabicky Sohio Petroleum 5420 LBJ Freeway Suite 900 Dallas, TX 75240 NOTE This article was originally published in the January 1986 DFWLUG Newsletter from the Dallas-Fort Worth Local Users Group. The Fall 85 DECUS symposium was a curious mixture of the old and the new. For the old, there seemed to be the same talks that DEC has been giving the last 4 or 5 symposia dealing with clusters, the lock manager, the connection manager, tuning clusters, troubleshooting clusters and so on. The information presented here was essentially the same as that given at previous symposia. Thus, the old. For the new, there was the VAX 8650 and its performance, CHAEPnet and the new Ethernet transceivers, the new Bridge 100 for big Ethernet networks and some news about VMS V4.3 and V4.4. Let's begin by looking at some of the new things. First the word on VMS. In case you haven't noticed, starting with VMS V4.0, DEC embarked on a new strategy for VMS distribution. As much as practical, DEC will forevermore banish the pain and agony of a V3.7 to V4.0 upgrade. Any of you with your own or third party software who lived thru this know exactly what I mean. The only word for it is disgusting, particularly if you live in a production oriented world. In its place, DEC will use the n.odd releases for bug fixes and the n.even releases as enhancements along with the bug fixes. Their goal with the philosophy is to make it easier to upgrade your systems with each release breaking little to no code. All of us who have lived thru major O/S upgrades applaud such action. It shows that DEC is at least listening to our moans and groans about living and loving their systems. In theory, this should be quite a boon to those of us who must manage systems. But in practice, I doubt that they'll be able to continually do it. There's bound to be another IPL$_SYNCH change lurking in a future release that will break lots of software. But at least DEC is moving in the right direction! VAX-65 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 2 Just for the sake of the record, VMS V4.3 went to SDC roughly the week of the symposium. That means the you should start receiving your distributions in January 1986. VMS V4.4 is due to start customer ship in Spring. DEC is trying to stage these releases at 4 month intervals. Their problem is that more frequent releases, while fixing bugs faster, means a lot of extra work for system managers, plus a lot of extra work for SDC. Thus, they are doing their best to make the releases predictable to the benefit of all concerned. What's new with VMS V4.4? Actually, not a whole lot more than with VMS V4.3. This is in keeping with DEC's new release policy. I found a couple of things of interest: volume shadowing and additional cluster support. Controller based volume shadowing should be available with this release of VMS. It may have to wait until VMS V4.6 but they are currently shooting for the V4.4 release (their comments were: "You'll be in Dallas before you see volume shadowing). That will please those of us running a common system disk on a cluster that, up to now, has been a single point of failure. Not only that, it will also increase the performance since the HSC50s will read from which ever member of the shadow set is closest to the requested block. They will also support shadow sets of volume sets along with all the failure recovery, disk addition and so on. If you think about that for a while, it gets a little weird. While on the subject of volume shadowing, DEC in Colorado Springs has done a good deal of performance measurement on HSCxx based shadowing. In essence, they've found that each additional member increases the I/Os per unit time by about 95% or so of the RA81's capacity. So, if a single RA81 can do about 35 I/O requests per second or so, a dual RA81 shadow set can handle around 65 to 70, three around 110 and four around 150 requests per second. And all of this is without any changes or interventioby VMS. Although future disk products will undoubtably allow seeks in the 15 to 20 msec range, you can get a good deal better thruput right now by using shadow sets at the expense of multiple RA81s. Additional cluster support comes from DECnet now allowing a cluster to have a name in much the same way that a node has a name. You can assign each member in your cluster the same alias. Once done, people can send mail, phone, create objects and the like to that alias and not to a particular member of that cluster. This is another step in DEC moving towards homogenious clusters, where a node of the cluster is just a place to do processing and the users don't care in particular which node runs their applications. As time goes on, DEC will allow you to run your cluster from one node rather than having to log into each node to handle node specific problems as you must do now. VAX-66 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 2 Those of you waiting on journaling, rollback and recover will have to wait until at least VMS V4.6 or V4.8. They are having problems doing a proper job of it and rather than release this support before its time, they are trying to do it right. That makes it 1987 before we'll see those features so necessary in commercial and production oriented shops. There were several new items in the networks area: CHAEPnet, IEEE 802.2 and 802.3 support, new Ethernet transceivers, and the new Bridge 100 for big Ethernet networks. CHAEPnet (as people are calling it) will allow you to make Ethernet networks using the much less expensive CATV cable in place of the current expensive orange Ethernet cable. This cable is much more flexible which helps considerably in cable routing. And its lower cost will make Ethernet networks much easier to afford as well as install. In order to use this new cable, you naturally need a new transceiver. Here, DEC is offering a new H4000 and a H4005 (I believe those are the correct numbers). The H4000 replaces the current H4000 but has a much easier tap mechanism than the old one. The H4005 is new and for use with the lower cost coax cable now supported. Although not officially announced, I do recall hearing word that there will be a new Ethernet adaptor around shortly that is a single hex height board and much lower power comsumption than the current DEUNA. With VMS V4.4, there will also come support for IEEE 802.2 and 802.3. Basically, the only difference is some additional information in the packet header that is not present in Ethernet. Both Ethernet and the 802.x protocols can be run over the same DEUNA and wire simultaneously. DECnet, however, will still continue to use the Ethernet version of the protocol. This move is one of several afoot at DEC to become more OSI complaint as industry starts to move towards networking standards. Finally, there is the new Bridge 100. It replaces the DEREP repeater in functionality but has the additional feature of being a traffic cop. For example, if you have several repeaters in an extended Ethernet network, you may find that you are having cable capacity problems or delays caused by the size of your network. Since every message must go to every inch of cable, you have to put up with unacceptable delays when you only want to go to the processor 5 feet away from the one you're running on. To get around this, you can replace, one for one, your DEREPs with Bridge 100s. The Bridge 100 will filter your messages, keeping the local message from ever getting out to the rest of the network. Thus, if you've got groups of processors in different areas, you can cut a good deal of your network traffic by installing a few Bridge 100s in key places. There's more on this in a session summary a bit later on. VAX-67 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 2 Session Summary Whenever you attend the symposium, you'll take in many, many sessions. It's far more difficult that you think to take notes on them all, and then report on them once you get back to the real world. I have included several below on a variety of subjects. For all of these sessions, I have summarized the salient points made by the speaker. As such, these are my impressions of the session and not necessarily those of the speaking. While I have naturally tried to be as accurate as possible, there may be omissions or errors. So don't take all this stuff too literally but just consider it given in good faith from the scribblings during a hectic week. Tradeoffs in Extended Ethernet Configurations by Rick Grahams (DEC) When you first start out with an Ethernet network, you'll most likely have a dozen or two nodes (at most) in it. In such cases, you rarely have problems since the network size is small. But as you start to add nodes that are geographically dispersed, you start having a host of problems with the network. Problems such as bandwidth, number of stations, cable lengths, network configurations, access delays, reliability, availability and maintainability all haunt you. Typically, you do not have a network manager. Thus, there is no one around to handle your telecommunications problems. The solution to this type of problem is to extend the LAN via a bridge. The advantages are increased size, overall capacity, number of stations and traffic isolation. It works with different technologies including base and broadband, fiber, CSMA/CD, token and so on. On the negative side, there are the store-and-forward delays, congestion on the bridges as well as the LANs and the lost "mutual exclusion" found on most current LANs. The bridge itself is smart in a variety of way. First and foremost, it "learns" over time. You do not have to program it as to which nodes are on which side of the bridge. When it receives a message for an unknown node, it sends it out to all nodes. When it finds out which side of the net that the node lives on, it remembers for the next message. Thus, it serves to automatically segment your LAN traffic. Second, if it doesn't have any traffic for a given node over a period of time, it drops that node from its 8000 node database. And finally, since it operates at the data link layer in the OSI model, it is transparent to all your applications. VAX-68 PAGESWAPPER - March 1986 - Volume 7 Number 8 THE FALL 1985 DECUS US SYMPOSIUM Version 2 In summary, its feature include: o Replaces repeaters thereby giving more bandwidth to each LAN segment. o Shorter CSMA/CD lengths have shorter access times o Is a one for one replacement for a repeater (DEREP) o The bridge is not the bottleneck o Management counters help position bridges within LAN o Spanning tree algorithm allows warm standby o Length restrictions are based on protocol times and extended net performance o Does not create bandwidth, just makes better use of it TPU Update by DEC With VMS V4.4, you will now have a new TPU. There will be a new section file format similar to a .EXE file. This section file can be installed shared and thereby reduce overall memory usage. EVE, an example editor that uses TPU, can now also be installed shared. It was reduced from 241 to 215 pages of which 180 are read only. With this new TPU, you will have key maps. These are groups of keys which you manipulate as a whole. Each group can be given a name. Several can also be grouped into a list and associated with a buffer. Thus, you key definition work faster and can be buffer specific. Also new is a loadable screen updater. TPU has been split into two images: TPU.EXE and TPUSHR.EXE. This will allow TPU to support other terminals and give better windowing routines for these variety of terminals. Overall, TPU is much improved. There is now a much shorter startup time with TPU and its section file installed. They have also restructured the section files so that they take up much less disk space. And finally they have improved the overall quality of the product. As a final note, for those of you looking for EVE PLUS, it went to the DECUS library on November 11th. You should hear about it in the next DECUScope. The first distribution should be in the mid-January time frame. VAX-69 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAX System SIG Committee List VAX System SIG Committee List As of January 8, 1985 Osman K. Ahmad - Large Systems Integration Working Group Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616 Joe Angelico - Assistant Symposium Coordinator US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA 70130 Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 June Baker - Advisor Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 Bob Boyd - Commercial Working Group GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709 C. Douglas Brown - Security Sandia Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185 Jim Caddick - VAXcluster General Datacom Strait Turnpike Middlebury, CT 06762-1299 Jack Cundiff - Symposium Coordinator Horry-Georgetown Post Office Box 1966 Conway, SC 29526 VAX-70 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAX System SIG Committee List Tom Danforth - Handout Editor Woods Hole Oceanographic Institute Woods Hole, MA 02543 Jim Downward - Migration and Host Development, VAXintosh Working Group KMS Fusion Incorporated 3941 Research Park Drive Ann Arbor MI 48106 Jane Furze - Campground 3830 West Cochise Phoenix, AZ 85064 Dennis Frayne - Real Time/Process Control Working Group McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals Working Group In House Systems 165 William Street New York, NY 10038 Don Golden - Communications Committee Representative c/o Shell Oil Company Westhollow Research Center Post Office Box 1380, Room D2132 Houston, TX 77001 Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693 B. Hancock - Network Working Group Dimension Data Systems, Incorporated 2510 Limestone Lane Garland, TX 75040 (214) 495-7353 Jeffrey S. Jalbert - Historian J C C Post Office Box 381 Granville, OH 43023 614-587-0157 Ray Kaplan - MicroVAX Working Group Pivotal Incorporated 6892 East Dorado Court Tucson, AZ 85715 VAX-71 PAGESWAPPER - March 1986 - Volume 7 Number 8 VAX System SIG Committee List Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 Art McClinton - Advisor MITRE 1820 Dolley Madison Boulevard McLean, VA 22102 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Eugene Pal - Multiprocessor Working Group US Army CAORA (ATOR-CAT-C) Fort Leavenworth, KA Susan Rehse - System Management Working Group Lockheed Missiles 3251 Hanover Street Palo Alto, CA 94301-1187 Bob Robbins - Advisor Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Working Group Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA David Schmidt - LUG Coordinator, Hardware Working Group Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 D. Slater - Artificial Intelligence Working Group Institute for Defense Analysis 1801 North Beavregard Street Alexandria, VA 22314 VAX-72 PAGESWAPPER - March 1986 - Volume 7 Number 8 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 484 Caption: Ditto Foreign Tape Copy Message: Can anyone suggest a method for doing a bitwise copy of a tape with protection for bad spots on the target tape. This comes up in a requirement for making copies of IBM, UNIVAC, PRIME and DEC20 tapes on a VAX. IBM has a DITTO program but we couldn't use that to copy VMS BACKUP tapes (tested prior to /INTERCHANGE mode) and there may be similar problems going the other way. Contact: Edward E. L. Mitchell Mitchell and Gauthier Associates 290 Baker Avenue Concord, MA 01742 Telephone (617) 369-5115 Date: November 21, 1985 INPUT/OUTPUT 485 Caption: Executing a CLI command from within a program Message: Users stay inside my suite of programs for hours on end, and have often asked to be able to do "SET DEF", "SHOW QUEUE", etc. without leaving and re-entering. I know of LIB$DO_COMMAND to execute CLI at the end of a program, but does anyone know how to execute CLI whilst still inside? You can simply hit control C, return to CLI, type "SET DEF", etc. and "C" to re-enter the program, why not via a subroutine? With spawn, you can only "SET DEF" the sub-process, not your own process. VAX-73 PAGESWAPPER - March 1986 - Volume 7 Number 8 INPUT/OUTPUT Contact: Pete Edwards CadCentre Limited High Cross Madingley Road Cambridge, DB3 0HB, England Telephone UK 223 314848 ext 218 Date: January 16, 1986 Pageswapper Editor Response System (RMS) service SYS$SETDDIR, documented on page RMS-115 of the VMS V4.0 documentation, changes the directory portion of your default from a program. Set the logical name SYS$DISK (in the proper mode) to change the device portion. Emulating SHOW QUEUE would take a complicated series of $GETQUI calls, but it may not be worth it since you do not have the context problem there which you have with SET DEFAULT. Most functions work well from a subprocess, and supported methods for dealing with any others vary depending upon exactly what what function you are performing. VAX-74 PAGESWAPPER - March 1986 - Volume 7 Number 8 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 PAGESWAPPER - March 1986 - Volume 7 Number 8 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 - March 1986 - Volume 7 Number 8 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 - March 1986 - Volume 7 Number 8 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA PAGESWAPPER - March 1986 - Volume 7 Number 8 VAX Systems SIG Spring 1986 SIR Ballot VAX Systems SIG Spring 1986 SIR Ballot DECUS membership number __________________ (six digits) Our site uses the following VAX models (check all that apply) 8600 ____ 11/782 ____ 11/780,11/785 ____ 11/750 ____ 11/730,11/725 ____ MicroVAX ____ We use VAX's in the following applications (Check all that apply) Business EDP ____ Software Development ____ Education ____ Computer Science Research ____ Data Acquisition/Control____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Telecommunications _____ Other ____________________________ I support the following as the most important System Improvement Requests. (List from zero to fifteen SIR's): SIR Number: ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- I oppose the following SIR's as detrimental. (List from zero to five SIR's): SIR Number: ---------- ---------- ---------- ---------- ---------- Mail to: Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, OH 43201 To be counted, you ballot must be received by April 1. PAGESWAPPER - March 1986 - Volume 7 Number 8 VAX Systems SIG Spring 1986 SIR Ballot Tear out or photocopy reverse to vote on SIRs Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA