CHAPTER VAX PAGESWAPPER - December 1987 - Volume 9 Number 5 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 LUG News . . . . . . . . . . . . . . . . . . . . VAX-4 Sending Your People to DECUS Symposia . . . . . VAX-5 Handling of Known VAX/VMS Security Problems . VAX-16 VAX System SIG Committee List . . . . . . . . VAX-19 VAX/VMS Security . . . . . . . . . . . . . . . VAX-24 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-29 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-107 System Improvement Request Submission Form . . VAX-109 PAGESWAPPER - December 1987 - Volume 9 Number 5 To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. Articles for publication in the Pageswapper can be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters and the number of text lines per page should not exceed 48 (these limits are particularly important for sample commands, etc. where simple text justification will not produce a meaningful result). Please do not submit program source, as that is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations (or other meetings) as they are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides to get the content across to a wider audience than is able to attend. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - December 1987 - Volume 9 Number 5 Editor's Workfile Editor's Workfile DECUS US Chapter National Symposia As this issue of the Pageswapper arrives in your mailbox, some of you will be at the National Symposium in Anaheim, or else will have someone else from your site attending. Some of you will not. The article by Beau Williamson this issue will let those of you with no symposium contact know a little about what you are missing. Those of us who do attend certainly feel we are getting our money's worth, and it is too bad that some site never send representatives. It is certainly _n_o_t the case that the DECUS Symposium needs your business. The ups and downs of attendance figures are enough to drive the organizing committee batty, but that is just a matter of anticipating how much of everything to plan. Even the less well attended symposia have many more attending that some might want, but the reason is the wealth of information available only through that channel. So if you are not going to Anaheim this December, start thinking about Cincinnati the week of May 16-20. Future of the VAX Architecture I thought one of the most interesting comments from DECworld was at the 10 am session entitled "The Digital Difference" (who, in their right mind, would go to a session with that title?). The catch phrase the speaker used was "User Apparent Architecture" to describe introduction of RISC hardware techniques in support of the CISC VMS instruction set. There was an attempt to portray such a trend as being merely "internal organizations that reduce considerably the instruction complexity", with discussion reminiscent of the internals discussions when Venus (8600) was released with its myriad of E-boxes and M-boxes etc. VAX-3 PAGESWAPPER - December 1987 - Volume 9 Number 5 Editor's Workfile The best hope for the future I heard, however, was the statement: "We have a responsibility to see that over all time your existing programs run." Let's hope that is taken as a true responsibility, unlike what happened to compatibility mode when the Scorpio (82xx, 83xx) and Nautilus (85xx, 87xx, 88xx) VAX processors were announced. Correction Lawrence M. Baker, author of "Selectively Printing the Message-of-the-Day File" in the October Pageswapper (Volume 9, Number 3) sends along a correction to the command procedure shown in his article. Near the bottom of page 10, the line $ login_time = F$GetJPI("","LOGINTIM") should be moved one statement higher, before the branch to PRINTTEXT. Larry Kilgallen Pageswapper Editor LUG News A newsletter from the MIVAXLUG earlier this year outlined an impressive technique for LUG meeting agenda selection. The steering committee watched a pre-presentation by a third party vendor and THEN decided to invite the vendor to speak at a LUG meeting. This seems like it might be the answer to many of the "qualification" issues of making sure a would-be presenter makes the talk sufficiently technical and non-commercial. By the way, MIVAXLUG has their (open) steering committee meet 45 minutes before the start of the regular LUG meeting. VAX-4 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia Sending Your People to DECUS Symposia The Return on Investment A cost/benefit analysis for Managers considering sending people to a DECUS Symposium by G. Beau Williamson Rockwell International, CTSD M/S 406-280 1200 N. Alma Rd. Richardson, Texas. 75081 (214) 996-5547 This article originally appeared in _L_o_n_g_w_o_r_d_s, the newsletter of the Dallas-Fort Worth Local Users Group. " " The biggest and most commonly made mistake is to send people to DECUS without any clear-cut goals. --- The Author (1986) Times are tough for many companies today; with declining oil prices, the trade deficit, stiff competition from overseas and the economy in general in a decline, its not uncommon to find that your department's budgetary belt has been cinched up one or two notches tighter by upper management. When this happens a good manager rolls up his/her sleeves, loosens the collar and really begins to earn the title "Manager" by making budget adjustments that will maximize department productivity. A good manager knows that managing a department (and its budget) requires consideration of both short-term and long-term goals. He/she knows that "Managerial Myopia" is a disease that tends to be fatal in managers and that a certain amount of investment in the future in terms of planning _a_n_d dollars is necessary if the department is to continue to be productive (not to mention the manager's job security). VAX-5 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia If you are one of these managers that is faced with the decision to budget for the cost of sending one or more of your people to the DECUS Symposia then this article is for you. We will analyze the myths, costs and "return on investment" of sending people to DECUS just as you might analyze a prospectus being offered by an investment firm. We will also cover some ways that you can minimize your costs and maximize your returns when you send people to DECUS. In the end, you should have a better idea as to what your department's "return on investment" will be if you send people to DECUS. MYTHS Before we go any further, lets resolve some myths about DECUS Symposia and try to get a better idea as to what DECUS is all about. Once we have a clear picture of what happens at a Symposium, we can get a better handle on what your department's benefits will be by sending people to DECUS. Myth 1 DECUS Symposia are week-long boon-dogles where attendees go to party at their company's expense. Actually, most DECUS Symposium attendees work an average of 12-14 hour days at a Symposium. Many attendees arrive at the convention center an hour early each day for the Continental breakfast and to meet with other attendees to discuss common problems and ideas. From breakfast, the attendees start going to the various sessions which beginning at 9AM and continue on into the night; often until midnight. Attendees sometimes skip lunch in order to attend sessions that span the lunch period. During one Symposium held at the Las Vegas MGM Grand Hotel a couple of years ago, the hotel and casino staff was overheard grumbling that "these `DECUS' people are not spending any time in the casinos or going to the shows and its really hurting our business." It turns out that the attendees were more interested in the sessions than the Blackjack tables. VAX-6 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia Myth 2 We can learn the same amount of information at a local 1 week DEC training class. DEC training classes are generally geared as an introduction to the subject being taught and are excellent in that capacity. However, if you have specific problems to be solved and also need direct communication with the software development team from DEC that wrote a particular package, DECUS is the place to go. For about the same price as you would pay to send your people to a DEC training class, your people can get much more detailed information on a much broader range of information by attending DECUS. At any one time at DECUS, your people will generally find more than one session scheduled that addresses some area of interest to your department. If a person attends one session and finds out in the first 5 minutes that it's too elementary or too advanced, then they can quickly move to another session. This is a typical "good news, bad news" situation. The good news is there is generally more than one session of interest that you can attended at one time; the bad news is there is generally more sessions and information to be had than one person can handle. (Many managers send more than one person to DECUS in order to cover everything.) Myth 3 DECUS only consists of sessions where other DEC users present papers on their research. True, a major part of a DECUS Symposium is the exchange of information and ideas by DEC users via the formal sessions but it doesn't stop there. Many of the presentations are by the various DEC software development teams that have developed or are developing the software package you may be using. Attending these advanced technical presentations is often the only way to get this information and is frequently worth the cost of the entire trip. Some of these sessions are of a "Question and Answer" nature where attendees may ask the developers technical questions about the software. This cannot be done anywhere other than at a DECUS Symposium. VAX-7 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia Besides the sessions, there are the "Campgrounds" sponsored by the various special interest groups where attendees can go to discuss and work on problems in specific areas of interest; "Birds-of-a-feather" meetings scheduled by groups of attendees to address a single major common problem, issue or need; hospitality suites sponsored by the special interest groups where attendees often gather over cocktails with DEC developers and marketing personnel to discuss future products in an informal setting. All off which provide an excellent opportunity to exchange information, work on problems and make technical contacts with others for contact by phone when future problems arise. Finally, the exhibit hall provides attendees with demo systems that offers attendees the opportunity to sign-on and evaluate new systems and software about to be released. COST What does it cost to send someone to DECUS? It's not as expensive as you might think. First of all, if you plan ahead, pre-register and make airline reservations in advance you can save several hundred dollars. (DECUS usually arranges special airline discounts with one of the major airlines if you purchase your tickets in advance.) Let's look at the cost for a typical one week trip to DECUS. ITEM Low High Airline Tickets $250 $450 Hotel Accommodations (5 nights) $400 $550 Meals $100 $125 Cabs, Buses $ 20 $ 40 Registration Fees $400 $500 TOTAL $1170 $1665 RETURN ON INVESTMENT HISTORY VAX-8 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia Just like any prospectus, it is impossible to guarantee what your exact "return on investment" will be by sending people to DECUS. However, like a good prospectus, we can show some past history to backup our estimates as to what the returns will be. NOTE The following cases are true. The names of the people in these cases have been changed to protect the innocent. CASE 1 Jerry is the System Manager of a VAX system for a large Aerospace Engineering company. At the end of a session at a recent DECUS Symposium, Jerry asked a question of a speaker about a problem with disk to tape backups that he was having. It seems that Jerry's shop has limited resources when it comes to backups and daily backups were costing a lot of money in terms of operator overtime. It turns out that the speaker was unable to answer the question but as is typical in many DECUS sessions, another user stopped Jerry after the session for a short discussion about Jerry's question. It turns out that this user had experienced the same problem and had found a solution which he offered Jerry. (This sort of thing happens quite often at DECUS.) Once he returned home, Jerry found that the solution shortened the backup time by enough to save his company $6,000 per year in operator overtime charges. Annual Savings in overtime $6000 Cost of Trip to DECUS (approximately) $1500 RETURN ON INVESTMENT (approximately) $4500 VAX-9 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia CASE 2 David is a Senior Systems Programmer at a large VAX computing center for a electronics firm in Texas. While at the last DECUS Symposium, David presented a paper on the software his department was writing. At the end of the session, one of the VMS developers stopped David and mentioned that although the software David's department was writing would work fine under the version 4.x release of the VMS operating system, it would not work under the future version 5.0 release. The VMS developer spent some time with David explaining how David's software could be structured in a slightly different fashion in order to make conversion to VMS version 5.0 easier. Armed with this information, David returned to work and changed some of the software's design to plan for the future conversion to VMS version 5.0 when it was released. It was estimated that this will save David's company 2-3 man months of programming effort when version 5.0 came out. This works out to be a savings of anywhere from $14,000 to $21,000. Savings in programming cost $14,000 -- $21,000 Cost of Trip to DECUS (approximately) $1500 RETURN ON INVESTMENT $12,500 -- $19,500 CASE 3 Tony is a Senior Systems Engineer for a large Telecommunications company. While in the design stage of a product built around a particularly new model of a DEC computer, Tony attended a DECUS Symposium in order to learn more about the new computer. Tony's company was planning on purchasing a certain combination of DEC hardware interfaces and expansion cabinets for this new computer in order to build the product they needed. At DECUS, Tony learned that DEC was about to introduce a single hardware interface card that appeared to accomplished all of functions that they needed. After discussions with the hardware developers there at DECUS, Tony was able to determine that the single hardware interface card would in fact, perform all of the VAX-10 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia functions of the costly combination of interfaces and expansion cabinets that his company was originally planning to use. The difference in the cost of the single hardware interface card and the combination of hardware originally planned was $20,000. Savings in hardware cost $20,000 Cost of Trip to DECUS (approximately) $1500 RETURN ON INVESTMENT $18,500 Cases such as the these are the norm, not the exception. A _w_e_l_l _p_l_a_n_n_e_d trip to a DECUS Symposium will generally not only pay for itself, but provide significant savings, cost reductions and increases in productivity. MINIMIZING COST --- MAXIMIZING RETURN If you do plan to send people to DECUS, you will want to take steps to get the most "bang for your buck". The best way is, of course, to minimize the amount of money you spend sending people to a DECUS Symposium while maximizing the amount of information that is gathered. ESTABLISHING GOALS The first thing to do is to decide ahead of time what sort of information your people and your department needs to learn by attending the Symposium. The biggest and most commonly made mistake is to send people to DECUS without any clear-cut goals! Before you pack your people off to a DECUS Symposium, be sure that they have a list of goals to be addressed while at the Symposium. Prior to each Symposium, a schedule of the sessions along with the abstract for each session is mailed out to all DECUS members. Be sure to review this schedule with your potential attendees in order to identify those sessions that are of major interest to your department. Next, use the checklist that follows to help you and your people establish some goals for the VAX-11 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia the Symposium. Once you have listed these goals, you will be in a much better position to predict what your return on investment will be if you send people to the Symposium. 1. Make a list of any specific hardware or software problems that you need addressed. While at the Symposium, have your attendee(s) seek solutions to these problems as follows: (a) Attend any appropriate "Q & A" sessions and ask about these problems. (b) Attend any other sessions that appear to address topics in the area of your problems. (c) Seek other users with similar problems in the Campgrounds (post the problem on the bulletin board) and if appropriate, in Hospitality Suites. (d) Ask questions about your problems of the personnel manning associated exhibits on the exhibit hall floor. They may not be able to answer your questions directly but they can generally direct you to a specific person at the Symposium (usually a DEC developer) that can answer your questions. (Your attendee can make contact with this person via the Symposium's Message Board.) 2. Make a list of any new software packages that you are considering for use in the near future. While at the Symposium, have your attendees gather information about the performance, ease-of-use, known problems and the opinions of current users of the software package. In order to do this you should ask your attendee(s) to: (a) Attend any sessions on these software packages. Some may be introductory in nature while others may be more advanced. Consult the session abstracts to determine which is more appropriate. Have your attendee(s) pay particular attention to the question and answer segment at the end of each session. VAX-12 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia (b) Visit the exhibit hall and get some "hands-on" experience with the package on the demo machines. Your attendee(s) can run a canned demo of the software package or try it out on their own. 3. Make your attendee(s) aware of possible areas of future hardware expansion for your system. While at the Symposium, have your attendee(s) gather information on any hardware, performance data, upgrade kits, etc. that may be appropriate. This can be done by: (a) Attending sessions announcing new hardware products that are applicable. (b) Attending sessions covering the performance, features, etc. on any applicable hardware. (c) Visiting the exhibit hall and gathering literature on any appropriate hardware. It's also worth mentioning that, although not a part of the DECUS Symposium, the DEXPO Symposium is always held at the same time and in the same city as the DECUS Symposium. DEXPO is a show of third-party vendors who market DEC compatible hardware and software products. If you are planning to purchase new hardware and/or software you should have your attendee(s) take the time to go to the DEXPO show. Free shuttle buses are always provided from the DECUS convention center to the DEXPO show. Your attendee(s) will be registered for the DEXPO show at no charge by showing their DECUS registration badge at the door. Once you have established goals for your attendees, make sure that they understand that they will be expected to report on what they learned. Knowing this, attendees should obtain applicable "Session Notes" and supplement these with their own notes in order to produce an effective report on what was learned. VAX-13 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia CUTTING COSTS Again, be sure to plan ahead. Determine the minimum number of people that need to attend based on the goals previously set. If your department is doing much software development or is responsible for maintaining a large system of many users and running many applications you will probably find that your list of goals is quite long and you may want to send more than one person in order to adequately cover all areas of interest. Next, pre-register and purchase airline tickets early. Pre-registration can save $200 or more while most airlines offer substantial (anywhere from $100 to $300) savings in fares if tickets are purchased in advance. (DECUS frequently arranges for discount fares to the Symposium with a a major airline.) Hotel reservations (and any required deposits) should also be made early. This will allow you to select the more inexpensive hotels before they fill up. Shop around for your hotel rates. Some companies have better discount rates than are offered through the DECUS housing bureau so be sure to compare prices. (Remember, DECUS runs a shuttle bus service between all hotels listed in the DECUS housing information. If you place your people in some other hotel than the ones listed in the DECUS housing information, you will have to provide for some other form of daily transportation to and from the convention center for your people.) Finally, try to avoid the temptation to send your people to the Symposium for only a couple of days to cut costs. This is particularly true if the airline tickets are very expensive. However, if this is the only way to squeeze the trip into your budget (this is usually true if you didn't pre-register and make reservations in advance), then by all means go ahead. Just remember that your planning and goal setting will be even more critical in order for your attendees to cover all bases in only a couple of days and get a decent return on your investment. AFTER THE SYMPOSIUM Ask your attendees to put together a single, short trip report VAX-14 PAGESWAPPER - December 1987 - Volume 9 Number 5 Sending Your People to DECUS Symposia that identifies the major goals accomplished and any other major items of interest that were learned. The report doesn't need to go into great detail; it simply needs to identify what was learned. Be sure your attendees make any "Session Notes" and/or individual notes from sessions available to others that have need of this information. If the amount of information gathered warrants it and you have many other people in the department that need exposure to the information, you may wish have your attendees make a short presentation on what was learned. This "Debriefing" allows those that didn't attend the opportunity to ask questions and learn from those that did attend. SUMMARY To send or not to send your people to a DECUS Symposium can be a difficult decision if you are faced with a budget so tight that you can play it like a percussion instrument. However, we have outlined some very good reasons for sending your people and some excellent ways to establish specific goals to be achieved by attending. These, in turn, can be used when attempting to justify the expense to upper management. Hopefully all of this will enable you to make a better decision as to whether or not you should send your people to DECUS. Good Luck with your investments! VAX-15 PAGESWAPPER - December 1987 - Volume 9 Number 5 Handling of Known VAX/VMS Security Problems Handling of Known VAX/VMS Security Problems Proposed Position Paper on Digital's Handling of Known VAX/VMS Security Problems By Ray Kaplan PIVOTAL, Inc. P.O. Box 32647 Tucson, Arizona 85751-32647 During an informal and unplanned discussion at the Nashville Symposium, the VAX/VMS product management heard the concerns of many customers about how DEC handles the distribution of patches for VAX/VMS security problems that are discovered. Given the now millions of lines of code that make up VAX/VMS and its utilities, there are bound to be bugs that cause serious security problems from time to time. There was talk that DEC had met with a group of "government" VAX users from "high risk" sites as recently as the San Francisco Symposium and were told in no uncertain terms that those customers were quite satisfied to have such patches shipped as part of the next regularly scheduled update to the operating system. Interestingly enough, this point of view was not espoused by ANY of the people in the informal gathering in Nashville. On the contrary, most of the gathering was quite clear in their insistence that they wanted to receive such VAX/VMS patches in as expedient a manner as possible. As this interesting dichotomy unraveled, some people even suggested that they would be willing to temporarily sacrifice some VAX/VMS functionality to promptly get a temporary patch if they could be assured that such a patch fixed the known security problem. Others were absolutely appalled at such a suggestion, insisting that a correct patch should be distributed by a special mechanism with speed as its predominate feature. As you might imagine, the free wheeling, energetic discussion covered quite a bit of ground and, certainly, no conclusion was reached by the group, despite the many good ideas that were discussed. VAX-16 PAGESWAPPER - December 1987 - Volume 9 Number 5 Handling of Known VAX/VMS Security Problems The discussion died away, everyone went home from Nashville and the patch was eventually distributed by both the "standard" patch distribution mechanism and by way of the TSC if you called and made a case for your immediate need of the patch - all well after a good many of us had heard of the problem via the various well developed non-DEC information channels that surround us here in VAXland. It did not do my heart any good to see news of this V4.5 security problem in Digital Review magazine before we had anything official from DEC to go on. Seems that the official policy is not to talk about a security problem - even if they know about it. Guess that I have never received any sort of official word from DEC about this problem aside from the cover letter that came with my patch saying that my operating system would be "compromised" if I did not install the patch immediately. And what of the machine that "slipped off maintenance" for a very brief time due to a paper work snafu? "The patch was exception ordered for you", they say. What do I do in the mean time? Thank goodness for my non-DEC friends who found the problem a long time ago! As an interested DECUS member, a part of the VAX SIG Security Working Group, a VAX/VMS "owner/operator" and an active VAX/VMS consultant I am going to put together a "position paper" on the distribution of information about known VAX/VMS security problems. Despite what you might think, this is not a simple problem and I feel that a properly written position paper needs to be written in order to insure that DECUS members feelings and ideas in this matter are properly represented to DEC. I feel that such a paper should be a thorough and complete dissertation on the subject, incorporating as many points of view and as many possible solutions as possible. For your information here are a few thoughts on the matter to get you started: While everyone is agreed that the distribution of such important patches should be on some sort of "fast track" inside of the normal software engineering - quality control - manufacturing - and - distribution channels inside of DEC. Given that, how should such a patch be distributed? One suggestion is a special "express service" delivery. Since mine came via 2 day Federal Express some 90 days after I first heard about the problem, I wonder if the problem is not making the patch available quicker rather than delivering it quicker. Federal Express is very VAX-17 PAGESWAPPER - December 1987 - Volume 9 Number 5 Handling of Known VAX/VMS Security Problems reliable, and I am sure that my patch was shipped no more than a few days before I got it. How about if the local DEC office delivered the patch through their Software Services unit? Questions there are how many more people would DEC have to hire to service this "temporary need" and would you be willing to pay an increased cost for such a service? How about if DEC sent out a nice note via some high priority mechanism telling each site that there was a patch to be picked up from the DSIN service that the TSC offers? Questions here seem to revolve around the fact that some people have Basic Software Service for their VAX/VMS that does not include DSIN. There are many more points of view that I haven't listed Including, I suspect, yours! If you have an interest in helping me with this project or have specific thoughts on the matter, please send them to me. Send mail to me at user US124022 on the Pageswapper "Input/Output" system, send mail to me at username KAPLAN on DCS, send mail to me at username KAPLAN on DECUServe or, simply, write to me at the above address. This is neither a joke nor an opportunity to "flame on" at DEC. It is serious business, and absolutely deserves a moment or two of your time. Please take some time to give me your specific written thoughts on the matter so I can include your point of view in the position paper. Happy VAXing! Ray VAX-18 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX System SIG Committee List VAX System SIG Committee List As of June 24, 1987 CHAIR (CORE) Susan T. Rehse Lockheed Missiles & Space Co. O/19-50, B/101, P.O. Box 3504 Sunnyvale, CA 94088-3504 VICE-CHAIR (CORE) WORKING GROUP COORDINATOR Ross Miller Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 SYMPOSIA COORDINATOR (CORE) Jack Cundiff Horry-Georgetown Technical College P.O. Box 1966 Conway, SC 29526 COMMUNICATION COORDINATOR (CORE) Don Golden Shell Oil Company Westhollow Research Center P.O. Box 1380, Room D2158 Houston, TX 77251-1380 LIBRARIAN Joseph L. Bingham Mantech International 2320 Mill Road Alexandria, VA 22314 LUG COORDINATOR (CORE) Dave Schmidt Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 VAX-19 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX System SIG Committee List SYSTEM IMPROVEMENT REQUEST (CORE) Mark Oakley Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2669 SYMPOSIA COORDINATOR, ASSISTANT David Cossey Computer Center Union College Schenectady, NY 12308 PRE-SYMPOSIUM SEMINAR COORDINATOR HISTORIAN Jeff Jalbert J C C P.O. Box 381 Granville, OH 43023 PRE-SYMPOSIUM SEMINAR COORDINATOR (ACTING) June Baker Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 COMMUNICATIONS, ASSISTANT David L. Wyse Professional Business Software 3680 Wyse Road Dayton, OH 45414-2539 VOLUNTEER COORDINATOR Elizabeth Bailey 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35661 NEWSLETTER EDITOR Lawrence Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-20 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX System SIG Committee List SESSION NOTES EDITOR Ken Johnson Meridien Technology Corp. P.O. Box 2006 St. Louis, MO 63011 CAMPGROUND COORDINATOR Kirk Kendrick Shell Oil Company 333 Highway G, MS D-2146 Houston, TX 77082-8892 PAST CHAIR Marge Knox Computation Center University of Texas Austin, TX 78712 ADVISORS: -------- Joseph Angelico U.S. Coast Guard Detachment National Data Buoy Center NSTL Station, MS 39529-6000 Art McClinton Mitre 1820 Dolley Madison Blvd. McLean, VA 22102 Al Siegel Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 WORKING GROUPS: -------------- COMMERCIAL Robert Boyd GE Microelectronics Ctr. P.O. Box 13409, MS 7T3-01 Research Triangle Park, North Carolina, 27709-3049 VAX-21 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX System SIG Committee List FIELD SERVICE Dave Slater Computer Sciences Corporation 6565 Arlington Blvd. Falls Church, VA 22046 INTERNALS Carl Friedberg Seaport Systems, Inc. 165 William Street, 9th Floor New York, NY 10038-2605 LARGE SYSTEMS INTEGRATION Leslie Maltz Stevens Institute of Technology Computer Center Hoboken, NJ 07030 LIBRARY Glen Everhart 25 Sleigh Ride Road Glen Mills, PA 19342 MICROVAX Ray Kaplan Pivotal, Inc. 6892 East Dorado Court Tucson, AZ 85715-3264 (602) 886-5563 MIGRATION AND HOST DEVELOPMENT VAXINTOSH Jim Downward KMS Fusion Incorporated P.O. Box 156 D Ann Arbor, MI 48106 MULTIPROCESSOR Eugene Pal U.S. Army CAORA (ATORCATC) Fort Leavenworth, KA VAX-22 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX System SIG Committee List NETWORKS Bill Hancock P.O. Box 13557 Arlington, TX 76094-0557 REAL-TIME PROCESS CONTROL Dennis Frayne McDonnel Douglas 5301 Bolsa Aveneu Huntington Beach, CA 92646 Larry Robertson Bear Computer Systems 56512 Case Avenue North Hollywood, CA SECURITY C. Douglas Brown Sandia National Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185-5800 SYSTEM MANAGEMENT Steve Tihor 251 Mercer Street New York, NY 10012 VAXCLUSTER Thomas Linscomb Computation Center University of Texas Austin, TX 78712 VAX-23 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX/VMS Security VAX/VMS Security Number next in a series - July, 1987 by Ray Kaplan PIVOTAL, Inc. P.O. Box 32647 Tucson, Arizona 85751-32647 HACKERS!!!! Yes, it is true. There are hackers in the world. Some people hack at golf, tennis, baseball, and - of course - computing. This group of citizens of the planet include people like my friend JD who is a hot rodder and my friends who are phone phreakes. 'Course, there is a side to the definition of hacker that is a bit sinister. In recent years, especially, there has been an alarming increase in the number of folks who are on the "dark side" of the "pure interest" in technology that drives most of us hacker types. These criminals (by contemporary definition of the word hacker) are of some worry to the "legitimate" computing community since a lot of their aims seem to be causing damage to information systems and the data that they contain. Now, don't get the idea that I have absolutely NO use for this dark side of the hacker ethic (see earlier versions of this column)! While this is an interesting and controversial topic of discussion that warrants exploration, you'll have to stay tuned for future versions of this column where I'll explore this idea in more detail since we have precious little space here in Pageswapperland. (Speaking of the precious space here in the Pageswapper, you should understand that unless enough people subscribe to the collection of DECUS SIG Newsletters that you are now reading, it just might go away! Have you done your best to insure that enough people are subscribing? If not, go find someone else who is not already a subscriber and get them to VAX-24 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX/VMS Security subscribe to the DECUS SIG newsletters. This has got to be the best bargain in the DEC publication world!) While you await my defense of the dark side of hacking, how 'bout a little reading? Hurrah!!! Since my mailbox has been active with requests for the book that I reviewed for you last time, I take it that you are interested in more? After all, since this is the only feedback that I have had on this column, I guess that the "writing on the wall" says that I should continue in the same vein. So here goes .... Buy This Book Yes, another one! As I wander around teaching VAX/VMS security and getting involved with people's VAX/VMS security problems and with the larger world of computer security in general, I note that there seems to be a lack of practical literature on the subject, specifically - hacking. While I have had limited success in my search for VAX/VMS specific literature, I have discovered a lot of good general computer security literature dealing with hacking recently. "The Hacker's Handbook, An Insider's Guide to Modems and Telecomputing" by Hugo Cornwall is a good example. On a recent stroll through Stacy's Bookstore (more on this in a moment), I spotted this interesting little jewel. In his preface, Cornwall reminds us that his original "Hacker's Handbook" (1985) preceeded Out of the Inner Circle and Hackers (mentioned in previous columns in the Pageswapper), and points out that this hacking is a "recreational sport" these days. The sport of hacking. Hmmm. In his first chapter, First Principles, Cornwall dances through his early exploits of his hacking on the British Prestel service and reminds us the we should "never accept any hacker anecdote to be completely truthful" (including his?). VAX-25 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX/VMS Security Next, he takes a very quick walk through telecommunications starting with a brief history of computer to computer communications, the telephone network, error correction, protocols and networks. The 15 page tour 'de force through hacker's equipment includes brief descriptions of the computer itself, serial ports, terminal emulators, modems, and test equipment. Since we are only up to page 35 so far, you can see that this little handbook moves right along in its brief presentation of its material. Chapter 4 discusses on-line hosts, news services, financial services, business information, universities, banking, electronic mail, government computers as targets. He points out some ideas roughly associated with each one and interestingly enough points out some of the laws which would be broken in hacking these systems as well as mentioning many company, organization and service names in the process such as Lockheed, NASA and Dialog. Since each section is only a few paragraphs long, they just have enough space to introduce each system type. In admonishing would-be hackers to "go learn it yourself", his Chapter 5 is a guide to the resources that a hacker has at their disposal. The bulletin boards section even contains a list of bulletin boards to call. Interestingly enough, none of the DEC specific trade magazines are mentioned in his list of research materials. His Hacker's Techniques chapter introduces the methodology and gives hints on instincts, phone tricks, logging on, passwords, hardware and software tricks and operating systems. Since the chapter is only a few pages long, you can imagine that its treatment of operating systems is little more than the different prompts that can be expected and some anecdotes about some attacks and investigations. Chapter 7 and 8 are short introductions to networks and Videotex, with the concentration on packet switching and the British Prestel Videotex system as you might imagine. He concludes with a quick look at radio links and the future of hacking in which he contends that hacking can't be stopped by tougher legislation, fear of punishment, or tougher security measures. VAX-26 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX/VMS Security Appendices contain a nice little glossary, a section on trouble shooting, an computer alphabet chart, a summary of modems and services, a mention of the RS232 and V.24 CCITT standards, a radio spectrum listing, and a little flow chart for a port finder. This turned out to be a good light overview of hacking for the uninitiated, but not much depth here for the professional computer person except to see what a beginner in this hacking game might start with. There is absolutely no VAX/VMS specific information in it at all. 'Course, this book is intended as an introduction to hacking, after all. Besides being an interesting curiosity for your bookshelf, you might consider investing in it for your boss. You know, the one that won't give you the time that you need to make sure that your machine and his data are secure? The Hacker's Handbook, revised edition 1986 by Hugo Cornwall, ISBN 0-912579-06-4 E. Arthur Brown Company 3404 Pawnee Drive Alexandria, MN 56308 In the back, there is another "hacker book" advertised. The Computer Underground by M. Harry is said to include discussions of "Hacking, Crashing, Pirating, and Phreaking" within the context of "knowing how computer criminals work and how you can do to protect yourself". Since I have not read it, I can't recommend it, but for the prices involved, I say, "buy both of these for your shelves." Couldn't easily find any information on a group purchase of these books, but they are cheap enough that you can easily afford them. Go To This Store! One of the more interesting book stores that I have been in is the Stacy's chain in California. They advertise "the largest selection of technical, computer, business, and medical books in the west". I believe it. They have locations in San Francisco, Palo Alto and branches in Richmond and Modesto. Sorry, no mail order (drat). Go visit, but take along some money! VAX-27 PAGESWAPPER - December 1987 - Volume 9 Number 5 VAX/VMS Security Where do you buy what you read? Say, what is your favorite technical bookstore or favorite technical book club? I volunteer to do a listing if you'll send along information on what you read and where you get it. 'till next time, Happy VAXing! Ray VAX-28 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. ================================================================ Note 585.16 Anyone use defrag programs? 16 of 24 "John Burnet" 24 lines 30-SEP-1987 13:16 -< More Rabbit-7 notes >- ---------------------------------------------------------------- Thanks for the report on Rabbit-7 (Dopter). We went ahead and bought copies for several of our VAXen, and have had no problems so far. However, I just heard about serious problems (system crashes) caused by running Rabbit-7 with non-DEC drivers and controllers--in this case, Emulex controllers with Fuji drives. Apparently the program is corrupting UCBs. Also, I learned from the link map that most of Dopter is written in VMS Fortran. If we had known these two things before we took the plunge, I think we would have shopped around a little more. Please, no pro-Fortran flames... I *like* VMS Fortran, but I don't think that it's an appropriate language for coding something like a disk optimizer. I myself have done a lot with structures, pointers, dynamic memory allocation, etc. in VMS Fortran, but doing serious systems programming in that language seems a little foolish, even masochistic. Oh yes, the link map also shows that there's a psect (in this case, a Fortran common block) named DEFAULTS, and it shows that there's *also* another common block named DEFUALTS. I suspect that the thing still has a bug or three lurking in its depths... I'm not running it again on our disks until I get an explanation from Raxco of the common-block misspelling. VAX-29 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 ================================================================ Note 585.17 Anyone use defrag programs? 17 of 24 "John Burnet" 7 lines 30-SEP-1987 15:00 -< P. S. to last note >- ---------------------------------------------------------------- Oh yes, the link map also shows that there's a psect (in this case, a Fortran common block) named DEFAULTS, and it shows that there's *also* another common block named DEFUALTS. According to Raxco, this is deliberate, not a typo; there are actually two common blocks with the intended different spellings. Sure looked fishy to me when I looked at the link map... John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 ================================================================ Note 585.18 Anyone use defrag programs? 18 of 24 "Peter A. Lynn" 33 lines 5-OCT-1987 16:00 -< VERY wascally Wabbit >- ---------------------------------------------------------------- I am running a MicroVAX II with an Emulex QD32 disk controller and Fuji M2333 disk drives (this looks like an RA81 to the MicroVAX). I got a demo copy of Rabbit-7 and ran it twice. Both times, the system crashed with the bugcheck PGFIPLHI. I sent a copy of the crash dumps to DEC, who told me (if I remember correctly) that a UCB chain pointer was pointing to paged memory, which is a no-no. Needless to say, Rabbit-7 got returned. VAX-30 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT I had trouble with another product, too. I tried SQUEEZPAK using a spare RD53 as a scratch device. The RD53 started logging many hard errors (not SQUEEZPAK's fault) and the file that was being SQUEEZed got clobbered. The recover feature did not recover the file because the control file is kept on the ailing scratch device (!!! :-( !!!). If the scratch device fails, SQUEEZPAK can't recover the file being processed. Period. This was enough for us to decide to stick with BACKUP and restore under STAND-ALONE. The worst fear is that, since the compressors handle every file on the disk and no one is going to do a BACKUP/COMPARE after every compression, we could lose a file and not know about it for months. Whenever I got a demo disk compressor, I first called up the developer and asked what the steps in the process to compress a file were. I was astounded that most of the products I reviewed did not copy the file, verify it, and only then play with the header structure. Can anyone explain to me the justification for modifying the header before the new copy is written and verified? It sounds like attempted suicide to me. Peter A. Lynn Instinet 757 3rd Ave. 15th floor New York, NY 10017 (212) 310-9500 ================================================================ Note 585.19 Anyone use defrag programs? 19 of 24 "Brian Tillman, Smiths Industries." 3 lines 7-OCT-1987 14:13 -< It's a concern to us all. >- ---------------------------------------------------------------- If one can believe the ads, Diskeeper V2.0 addresses your concerns. It supposedly (according to the vendor) makes the copy and verifies it, then "renames". Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-31 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 585.20 Anyone use defrag programs? 20 of 24 "Peter A. Lynn" 10 lines 11-OCT-1987 19:50 -< Sounds good to me, but... >- ---------------------------------------------------------------- To .19 (re Diskeeper): I talked to their developers and was very happy with the description of the compression process. However, the other experiences here were sufficiently bad that word came down from on high: "BACKUP and restore." I hear and obey! Also, our new system manager starts tomorrow, and I go back to the 9 to 5 of development (anyone believe that?). Dare I hope that DEC will provide such a utility in the near future, and that it will be bug-free? One out of two? Peter A. Lynn Instinet 757 3rd Ave. 15th floor New York, NY 10017 (212) 310-9500 ================================================================ Note 585.21 Anyone use defrag programs? 21 of 24 "Brian Tillman, Smiths Industries." 5 lines 12-OCT-1987 12:39 -< Let's hope they're worthwhile. >- ---------------------------------------------------------------- There will be three sessions at DECUS on Monday evening starting at 7:15 and lasting 'til 9:30. These sessions will be back-to-back in the California A room. The sessions are entitled "Online Disk Defragmentation", "VMS Defragmentation Products", and "VAX Disk Compression Products". Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-32 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 585.22 Anyone use defrag programs? 22 of 24 "Linwood Ferguson" 36 lines 22-OCT-1987 08:01 -< Defrag - Emulex maybe at fault >- ---------------------------------------------------------------- running a MicroVAX II with an Emulex QD32 disk controller... crashed with bugcheck PGFIPLHI... UCB chain pointer [messed up] We had a similar problem, NOT in a defrag program, but just during production. Dec dialed in (having said they had seen this recently) and said that many Emulex controllers run at BR5 instead of BR4 (like good little Dec controllers are suppose to, I suppose), and that if the arrangement of your bus puts these at the end (like Dec controllers) the "BR Driver can interrupt itself, sometimes". Ours resulted in a "corrupted UCB" also. Their suggestion was to move both emulex controllers to the front of the bus in front of everything else. I've been waiting for a convenient time to try this, but did confirm from the Emulex technical documentation that both the QD21 and QD32 we have use BR5, so CSC may have been on the right track. Also, we have seen this only when the disk was logging a few errors in the same time span, so it may be this happens only during some error recovery or error logging phase. That's a guess, Dec didn't mention it. So maybe, just maybe your rabbit had a reason. Maybe. We also desperately want a defrag program, and just haven't worked up the nerve to try one. It's so easy to hold up one that fails and say "see", but its not possible to prove, or even be reasonably assured that "it works". We're considering setting up a test system, CHECKSUM'ing every file on the disk, defrag, and re-CHECKSUM'ing them nightly (after the backup!) for a month or two. But then on day 61 do you trust it go into 'unsupervised' production? Most of our production systems couldn't afford the time required to do this kind of extensive checkout continually. See above - maybe they'll have something in Anaheim. P.S. If you don't know about CHECKSUM, it's a very useful but undocumented utility in VMS. CHECKSUM returns a checksum in symbol CHECKSUM$CHECKSUM, and can be used for comparing files between nodes, etc. to see if they are completely identical. Linwood Ferguson VAX-33 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 585.23 Anyone use defrag programs? 23 of 24 "Larry Kilgallen" 9 lines 22-OCT-1987 11:50 -< Controller BR Level *MUST* be Correct >- ---------------------------------------------------------------- RE 585.22 Emulex Controller discussion: I don't know what BR level the subject controller has, or what device driver it uses (what controller from DEC it emulates?), but the two *have to* match. It is an absolute of VMS driverdom that the driver must contain an accurate accounting of what IPL level (corresponding to BR level) the device uses for interrupts. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 585.24 Anyone use defrag programs? 24 of 24 "John Burnet" 11 lines 27-OCT-1987 16:55 -< Does CHECKSUM take file headers into account? >- ---------------------------------------------------------------- Note 585.22 by NODE::US190747 "Linwood Ferguson" We're considering setting up a test system, CHECKSUM'ing every file on the disk, defrag, and re-CHECKSUM'ing them nightly (after the backup!) for a month or two. Be careful how you interpret the results. As far as I know, CHECKSUM doesn't take the *file header* contents into account. Having the "before" and "after" checksums match is no guarantee that the program hasn't trashed any file headers. John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-34 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 660.32 Applications software standards 32 of 32 "Offline Submission" 74 lines 10-OCT-1987 10:36 -< Additional Suggestions >- ---------------------------------------------------------------- I have the following additional suggestions for 3rd party software suppliers. (They could also apply to DEC). All software installation procedures, procedures which use the VAX/VMS INSTALL utility, login procedures, etc. must be written and supplied to the customer in well commented DCL. Such procedures must not be written in compiled languages with calls on system services. The product must be supplied with printed instructions on installing it. These must include: Approximate disk space requirements, both net and maximum required during installation. Approximate time taken to install it. Privileges needed. A detailed list of contents. This should describe the purpose of each file. This should include information saying which files are essential, which may be discarded and which are only required during the installation of the product. A simple installation check-out procedure should be included. The product should not require images to be installed (i.e. with the VAX/VMS INSTALL utility) in order to allow multiple concurrent users of the product. The product must not assume it has the directory to itself, either when it is installed or when it is run by a user. E.g., command such as $ DELETE *.XYZ;* should be avoided. The product should not assume the directories in which it is stored have particular names or are in a specific place, e.g., that they are outer level directories. Logical names for the device containing the product should be avoided; instead logical names for the directory containing the product or the files VAX-35 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT themselves should be used. Preferably the product will use the VAX/VMS exception message utility. If it is used then the facility number and name must be unique. (DEC apparently offers a registration service which aims to ensure this). There is sometimes confusion between SYS$UPDATE:VMSINSTAL, the VAX/VMS INSTALL utility and adding a new product or new version of an existing product. The product release notes, etc. should make it plain which they are referring to when they use the term "install". The product must not require the user, when running it, to have write access to the directories containing the product. W. B. Langdon CERL Kelvin Avenue Leatherhead Surrey KT22 7SE ENGLAND Telephone: 0372 374448 Date: September 22, 1987 ================================================================ Note 663.28 Comments on the SPR process 28 of 30 "Jack Patteeuw" 30 lines 23-OCT-1987 15:34 -< SPRs still no better !! >- ---------------------------------------------------------------- I just finished reading NOTE 727.8 an I see we have another victim of the SPR Process !! This has been a recent frequent discussion at our LUG meetings for the past couple of months. As a matter of fact, or local DEC representative has tried to find out from inside DEC just what is going on. Basically, the people in the "trenches" know there is a problem in getting "useful" information back to the customer in a "timely" manner. There cries (screams?) seem to be ignored by their superiors while we the customer are not getting the services that we are paying for. I think it is time that we the grass roots start a "Dear Ken" letter writing campaign. Or VAX-36 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT maybe or DECUS leadership (hello out there wherever you are) will bring this up with it's next discussion with DEC. In the mean time I will leave this little grenade for people to drop. Ann Symes (617-493-6951) is in charge of DEC's SPR Administration Group. If you have received an inappropriate response or haven't received one at all I would call her and complain loud and long. Also fill out that little "quality control card" that comes with your SPR response (at least it used to). These are like little bombs in themselves in that they go directly to the supervisor of the group who sent out the original response. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 663.29 Comments on the SPR process 29 of 30 "Larry Kilgallen" 25 lines 23-OCT-1987 17:00 -< Don't Hassle Ann Symes on Quality Issues >- ---------------------------------------------------------------- She and her co-workers have been most helpful about *tracking* SPRs for at least the past 7 years. That is a valuable service for those of us who really need a response. They will track down an overdue SPR and get it moving again. Do your fellow DEC customers (e.g., DECUS members) a favor and don't spoil the tracking capability by mass calling about the quality of answers. That is too big for a central administrative office to handle. There is no way for SPR administration to judge the quality of answers that go out. A more structured approach would be to get DEC to institute some feedback mechanism whereby the scores on the little white cards reflect back on the groups which generate the answers (be it Colorado or Spit Brook). I know, for instance, that the yearly customer survey on Field Service quality is taken *very* seriously by field offices, and is important in their employee VAX-37 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT rating scheme. I do not believe SPR responses have similar significance to those who generate them. It is up to DECUS to pressure DEC into making it so. How about SPR quality as the "theme" of the next (next not already designated, that is) symposium? Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 663.30 Comments on the SPR process 30 of 30 "Bill Mayhew" 38 lines 24-OCT-1987 14:48 -< Central Admin is not the problem >- ---------------------------------------------------------------- I strongly agree about not hassling the central administrative office folks. I have repeatedly found them to be not only friendly, but cooperative, "on our side", and actually able to use appropriate cattle prods to get otherwise-dormant SPRs moving. They are, as Larry commented, not really able to do anything about the quality of the responses, which is not their fault... _but_ I would argue that there _should_ be a quality control officer of sorts, located in that office, to use those same cattle prods in other ways. My experience with the quality control cards has been that they have no effect. I (unfortunately, often) send the cards in with dismal "grades" and nothing happens. (I also send 'em in with good grades, when merited.) It may not be widely known yet, but Software Services and hardware Field Service have been rolled together into one organization. That means the same unit manager who we talk to about Field Service is the guy we talk to about software services issues. Unfortunately, it seems that they (the managers) are not properly equipped with resources (access to manpower, and understanding of the bureaucracy) to help much, yet. I agree, ON THE OTHER HAND, that this is a _very_ serious problem, potentially a mine field for DEC, that is not being appropriately addressed. A layered product software manager recently explained to me how it is that the responses from Colorado are so often so inadequate: they are, quite frankly, under-supplied with resources, both machines and people. Too VAX-38 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT often, problems get referred back to the engineering support teams where they tend to evaporate, because the engineering support teams are not on the front lines and are too distanced from the day-to-day battles we all face with DEC software. This situation is beginning to show its face to the outside world, too. Witness, Datamation's (10/1/87) article, "Users Report Service Problems with Digital's High-End Systems", which discusses both hardware and software failings. I fear that Digital's massively inflated ego, developed over the past two years when IBM basically left itself open to attack, is going to prevent the company from recognizing the problems it faces... which means that Digital's market-gaining position will be in serious trouble, REAL SOON NOW. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 680.9 Looking for DEC PCFS Experiences 9 of 13 "Dale E. Coy (505) 667-3270" 28 lines 10-OCT-1987 02:37 -< Recent experience with PCFS >- ---------------------------------------------------------------- Chris: I would be interested in more details on your tricks. We are running PCFS on a cluster having the connections made to the cluster alias, not a given VAX node. There is mention in the manual that users sharing a writable directory must "boot from the same service node". Of course, this may not apply in your situation, but did you worry about it? To address the original topic, we selected PCFS because we believe(d) that it is the technically best, and best integrated, stuff available. I just brought it up, and I'm very impressed. One day to get it all installed and bring up one VAXMate, half a day to bring up an IBM PC as the next node. I estimate a couple of more weeks to feel really comfortable with it and find out most of the little tricks, and then a few months for it to become "second VAX-39 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT nature". My only big gripe is that the documentation is both poorly organized and very non-technical. It is good at telling you step-by-step what to do, but never tells you the effect or "why". As far as I can tell, the attitude is "you don't need to understand". Much like VMSINSTAL, except there's lots more to do (and you can - at last - buy a book on VMSINSTAL). DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 680.13 Looking for DEC PCFS Experiences 13 of 13 "Chris Erskine" 35 lines 16-OCT-1987 14:05 -< Alias trick >- ---------------------------------------------------------------- Chris: I would be interested in more details on your tricks. We are running PCFS on a cluster having the connections made to the cluster alias, not a given VAX node. There is mention in the manual that users sharing a writable directory must "boot from the same service node". Of course, this may not apply in your situation, but did you worry about it? I assume that the trick you are talking about is the cluster alias. We move the images into the common directory but allow the log go to the specific directory. The only other step that we did is to enable the alias inbound connections in NCP for PCFS. Towards the writable directory, we are not using common directories outside of the system ones which are read only on another disk. (Change the UAF to do it.). I have noticed the the PCFS developers are like a lot of DEC people who do not know how to run on clusters. The PCFS command files do things like force the logical SYSUAF to be in SYS$SYSTEM by defining it for themselves without checking for a SYSUAF already being defined elsewhere. VAX-40 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT I also wonder about defining all of my printer queues in the UAF file. This makes queue management fun. You get to: 1) Define the queue. 2) Define the queue in the printer table for ALL-IN-1. 3) Create an entry in the UAF which is the name of the printer. 4) Explain to the auditors why the printers have user accounts. Chris Erskine 23 S Holcomb Clarkston, MI 48016 (313) 524-8836 ================================================================ Note 690.10 New to VMS 10 of 18 "MICHAEL GRATTAN" 14 lines 13-OCT-1987 05:12 -< Nobody tells me anything! >- ---------------------------------------------------------------- I would like to thank all you who took the time to respond. I have taken your comments and suggestions to heart and also to my system. I notice that many of you speak about getting VMS upgrades and notices of necessary patches, etc. I haven't heard of any such animals at all. Is this because I am working with am OEM? Can I get this information from DEC? I feel like I'm on the outside of the candy store looking in! :-) Thanks. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 VAX-41 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 690.11 New to VMS 11 of 18 "Jack Patteeuw" 12 lines 13-OCT-1987 09:32 -< There is no free lunch ! >- ---------------------------------------------------------------- Have you ordered software update service ? This comes in three "flavors". Self Maintenance which means you get distribution of new software release and the "right" to submit SPR's. Basic Maintenance adds Telephone support service. DECSupport adds someone from DEC actually installing the software (but not necessarily making it work) and (supposedly) a higher priority of telephone support. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 690.12 New to VMS 12 of 18 "Larry Kilgallen" 6 lines 13-OCT-1987 09:52 -< Some People Aren't Allowed to Buy Lunch >- ---------------------------------------------------------------- By dealing through an "OEM", I think he is referring to the arrangement where the OEM holds the software licenses and receives all upgrades and may dole them out as the OEM sees fit. The people in physical possession of the machine *can't* order upgrades because technically they don't have a license. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-42 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 690.13 New to VMS 13 of 18 "JEFF KILLEEN" 36 lines 13-OCT-1987 23:51 -< OEM'S AND LICENSES - THE TRUTH! >- ---------------------------------------------------------------- By dealing through an "OEM", I think he is referring to the arrangement where the OEM holds the software licenses and receives all upgrades and may dole them out as the OEM sees fit. The people in physical possession of the machine *can't* order upgrades because technically they don't have a license. This coming from a DEC OEM and I guarantee you no matter what you heard this is the straight story. When DEC sells a software license to an OEM the *INITIAL* title for the license goes to the OEM. When the OEM sells you the system with the license the OEM is suppose to give a sub-license. This is a document that states you own the license. IF YOU HAVE NOT RECEIVED A SUB-LICENSE FROM YOUR OEM YOU HAVE NO LEGAL STANDING WITH DEC!!! The OEM must give you this sub-license. If the OEM refuses to give you the license call your local Digital sales office and ask to speak to the branch sales manager - make sure you get the branch manager and not a salesman. There was a large, now bankrupt, DEC OEM in the Boston area who was selling systems and charging for software licenses - the only problem was the OEM was not buying software licenses from DEC. The other item you should get from your OEM is the original "DEC order number" the license was purchased under. If you have that number (plus your sub-license) you will always be able to prove you have a valid license. Once you have a valid license you can order software update services - however you may still want to obtain these through your OEM. Depending on your OEM's policies he could sell you the services for less than DEC. Also your OEM *MAY* be able to provide better service than the local office or TSC. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 VAX-43 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 690.14 New to VMS 14 of 18 "Lee K. Gleason" 14 lines 15-OCT-1987 00:25 -< Whither comes the sub license? >- ---------------------------------------------------------------- When DEC sells a software license to an OEM the *INITIAL* title for the license goes to the OEM. When the OEM sells you the system with the license the OEM is suppose to give a sub-license. This is a document that states you own the license. IF YOU HAVE NOT RECEIVED A SUB-LICENSE FROM YOUR OEM YOU HAVE NO LEGAL STANDING WITH DEC!!! I've wondered about this for a LONG time. Is this "sub license" a document from DEC, or does it originate purely from the OEM? Lee K. Gleason Control-G Consultants 2416 Branard #D Houston TX 77098 713/528-1859 ================================================================ Note 690.15 New to VMS 15 of 18 "JEFF KILLEEN" 6 lines 15-OCT-1987 09:28 -< FROM THE OEM TO YOU >- ---------------------------------------------------------------- I've wondered about this for a LONG time. Is this "sub license" a document from DEC, or does it originate purely from the OEM? All the paperwork comes from your OEM. DEC gives him standard forms he is suppose to fill out and give you. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 VAX-44 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 690.16 New to VMS 16 of 18 "MICHAEL GRATTAN" 9 lines 15-OCT-1987 10:14 -< Time to put the boots on... >- ---------------------------------------------------------------- All the paperwork comes from your OEM. DEC gives him standard forms he is suppose to fill out and give you. Thank you very much for your assistance. I have not received any license paperwork or upgrade/patch notices from my OEM. I suppose now I'll have to put on my hip boots and wade through all the rhetoric. :-{ MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 690.17 New to VMS 17 of 18 "JEFF KILLEEN" 8 lines 15-OCT-1987 18:43 -< QUESTION >- ---------------------------------------------------------------- Thank you very much for your assistance. I have not received any license paperwork or upgrade/patch notices from my OEM. I understand the license comment - but I don't understand the "upgrade/patch notices" comment. Your OEM has to give you a "sub-license" but does not have to give you updates unless you pay him. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 VAX-45 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 690.18 New to VMS 18 of 18 "MICHAEL GRATTAN" 15 lines 16-OCT-1987 07:19 -< We're paying the $$$ >- ---------------------------------------------------------------- I understand the license comment - but I don't understand the "upgrade/patch notices" comment. Your OEM has to give you a "sub-license" but does not have to give you updates unless you pay him. We are paying for software support from our OEM. To me that includes updates. (At least TELL me that there is an update available, and I'll agree to pay more if necessary to get the update. We haven't been told anything! What gets me PO'd is to think that I would not have heard about ANY of these problems, fixes and upgrades if I didn't log in here regularly. I would think that if they were really interested in our business that they would keep all communications flowing, instead of just sending monthly invoices.) MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 717.9 CR to Fortran Carriage Control 9 of 9 "Offline Submission" 14 lines 20-OCT-1987 11:30 -< CR to Fortran Carriage Control >- ---------------------------------------------------------------- the Spring 1980 DECUS tape contained the program "carriage" and subroutine "error" which does an excellent job of converting a file in either direction. If you do not have these sources, I can supply them. Gerson H. Cohen NIH Building 2, Room 312 Bethesda, MD 20892 Telephone: 301-496-4295 Date: October 13, 1987 VAX-46 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 721.5 SET UIC from an image 5 of 6 "John Burnet" 23 lines 8-OCT-1987 19:11 -< Sorry about the preceding bum steer >- ---------------------------------------------------------------- Re. < Note 721.4 by NODE::US124053 "John Burnet" (myself) > (Published on page VAX-53 of October 1987 ^&Pageswapper\&, Volume 9 Number 3) By the way, remember that you can effectively "install" a command procedure with privileges by disallowing world access to the procedure and installing with SYSPRV an executable image which simply uses lib$spawn to run the procedure in a subprocess. Well, it's not quite that simple, unfortunately... I should have tested this before I wrote the reply. Seems that what lib$spawn uses as the new process' CTL$GQ_AUTHPRIV mask is the parent's CTL$GQ_PROCPRIV, not CTL$GQ_CURPRIV. (And, as someone has pointed out either here or on DECUServe, the parent's PROCPRIV is also written into the child's AUTHPRIV... so the subprocess can actually have fewer authorized privileges than the parent.) So any privileges which are turned on during image activation as a result of installing the image with those privileges don't make it to the subprocess. One fix at least is pretty obvious... install with SETPRV the image which will be spawning the process in which DCL will be run, and have the image turn on the necessary bits in PROCPRIV or DEFPRIV or whatever is necessary. I haven't had the time or the need to play with it any further, though. John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-47 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 727.8 RUNOFF .REQUIRE limitation?? 8 of 8 "Kevin Angley" 49 lines 21-OCT-1987 10:36 -< A brilliant response from DEC >- ---------------------------------------------------------------- The bug that RUNOFF does not properly deassign channels still exists in 4.6. I finally received a "response" to my SPR, which is included in the text of my followup SPR - which is reproduced below: SPR REPORT VMS V4. RUNOFF (4.6) 21-OCT-1987 Resubmission of SPR ICA-09369 Description: I am resubmitting this SPR in the hopes that this time it will fall into the hands of someone who knows slightly more about VMS than how to spell it. It seems that after ten weeks, I could have received a better answer than the attached. The problem: RUNOFF does not close out .REQUIRE files properly, leaving a channel in use. So, when the number of .REQUIRE's approaches CHANNELCNT (around 128), it cannot open another require file. In our application, we use .REQUIRE files to include formatting commands, so there may be hundreds in a large document. After ten weeks, I received the following answer from some bright spark: "This is a restriction in RUNOFF. The number of .REQUIRE files allowed in a source file is based on the operating system parameter, open file FILLM quota. In order to increase the number of allowed .REQUIRE files, you will need to modify the authorize utility and increase the FILLM quota per user basis." VAX-48 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT The problems with this answer: 1) If there is any such restriction in RUNOFF, it is not documented. 2) FILLM is NOT an "operating system parameter." 3) If you had read the SPR that I sent, I explained that it had nothing to do with the number of files open at a time (i.e. the .REQUIRES were single-streamed and not nested). Therefore, FILLM is irrelevant. 4) "Modify the authorize utility"???? That's an interesting approach to fixing a RUNOFF bug! Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 741.9 750's and LAVC's 9 of 9 "Terry Kennedy" 27 lines 10-OCT-1987 01:21 -< DELQA, DEQNA revisions >- ---------------------------------------------------------------- Rumor has it that the New Ethernet controller on the 3000 series "is much better, and incurs far less overhead than the DEQNA" (unnamed DECworld 'expert'). Anyone know why or how? Or more importantly if? You are speaking of the DELQA - it is essentially to the DEQNA what the DELUA was to the DEUNA. It implements MOP (the LAVC hardware-level load protocol) in hardware, as opposed to having the host CPU doing it. READ THE 4.6 RELEASE NOTES ON ETHERNET CORRUPTION! Sounds scary. Anyone have any more details? Or know what kind of performance decrease we get by turning on the 'data integrity' feature? I suspect it does CRC's, and since the MicroVAX is pretty poor on CRC's, I bet it makes a difference. VAX-49 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT The DEQNA has ben plagued with problems. This one is related to a problem when the Q-Bus address space is full (4 Mb) or when there are 'thousands and thousands' of Ethernet packets (un-mentionable DEC source). The rev which (supposedly) corrects it is J4. As of this date, there are NO J4 boards available. DEC is still shipping H4's. I called my sales representative and said forget it - I want a DELUA. She agreed and it is now on order. Perhaps you can do the same if you just got yours, otherwise wait for J4 and call Field Service to swap it (make sure you keep your old address PROM). Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 752.17 Q-bus versus BI-bus 17 of 19 "Jack Patteeuw" 31 lines 7-OCT-1987 11:33 -< Clarification on the 3602 >- ---------------------------------------------------------------- The VAXserver 3602 is is nothing more than two 3600 sharing a common system disk (via LAVC). The first machine is the boot node of the LAVC and the second machine should be look at as a "hot" stand-by and compute server. If the first machine crashes the second machine can take over because the disk is dual ported and connected to both machines so that it can fail over. Up to four disks can be supported in this configuration. It is important to note the a "VAXserver" is meant to be a compute server for a LAVC or group of VAXmates/PCs. The VAXserver can only be purchased with a **SINGLE USER** license. I sincerely doubt that you will ever see two CPU's on the Q-bus for the following reasons. As mentioned before the 3000 series (and the MicroVAX II) only use the Q-bus for I/O. All CPU/memory transfers are done on something call the Private Memory Interconnect (PMI) which in fact is the ribbon cable on top of the CPU board going to the memory boards. I think PMI also uses some of the signals on the C and D connector. (See the Microcomputer Products Handbook from DEC, Copyright 1985, chapter 52.) The BA23 and BA123 boxes contain backplanes with the C and D connector only wired on the first three slots (see page 56-3). The BA213 backplane has the VAX-50 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT first five slots wired for C and D connectors (that's why a 3500/3600 can have 32 Mbytes or 4 memory boards and the MicroVAX II/3200 can only have 16 Mbytes or 2 memory boards !) To my knowledge, the PMI has no capability to support multi-processors. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 760.3 VMS 4.6 Installation Experiences 3 of 16 "Dale E. Coy (505) 667-3270" 32 lines 30-SEP-1987 02:30 -< A few FLAMES >- ---------------------------------------------------------------- The problem with upgrading small MicroVAX systems turns out to be a prohibition against UPGRADING a system which has a common cluster disk structure (V4COMMON / SYSn.SYSCOMMON) if the disk is not at least RD54 size. Of course, you can do a virgin install of VMS 4.6 and THEN convert the structure. Also, anyone with a "tailored" system will apparently have to do a virgin install of 4.6 FLAME ON I'm getting extremely tired of DEC not supporting new DEC peripherals properly for AGES after they come out. An example is VT300 terminal support. The VT300s came out this spring, unsupported by VMS... 4.6 was announced as supporting them, but now, in September, it doesn't fully do the job. For example, GETDVI doesn't know about DECCRT3. There are lots of other examples. Even a giant company should be able to coordinate better than this. FLAME OFF VAX-51 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Things which we had to "hack" to support VT300s: All-In-1 A1WPSPLUS_LOGIN.COM DECMail (Atlanta says there's no way to get it to handle VT300s, but a sys$mangler can do anything). Of course, some local stuff: SHOWME (modified from the DECUS tapes), color-terminal managers, etc. By the way, can anyone suggest a LOGICAL reason why DEC would make a VT340 which handles text colors differently from DECs VT241? DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 760.4 VMS 4.6 Installation Experiences 4 of 16 "Kevin Angley" 11 lines 30-SEP-1987 23:24 -< Status report on VMS 4.6 >- ---------------------------------------------------------------- Status report: I attempted upgrading MicroVMS 4.5 to VMS 4.6 - you're right - if you previously had cluster common structure on your disk (and there's no reason not too), he will not upgrade an RD53 system disk. But ... nothing a well placed "GOTO 29" in KITINSTAL.COM wouldn't fix. (the restriction, I believe, is so you won't use an RD53 as a LAVC boot disk, but that's not my intention). For other reasons, I decided to just copy my cluster common system disk down and use that (with conditionals in startup, etc.). Will let you know. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-52 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 760.5 VMS 4.6 Installation Experiences 5 of 16 "M. Erik Husby" 10 lines 5-OCT-1987 13:42 -< DECnet problems with some VMS 4.6 kits >- ---------------------------------------------------------------- I do not have VMS 4.6 yet but feel that I should pass on some information we received from our Digital Software Sales Support. Apparently some VMS 4.6 kits where made with a corrupt version of DECNET. Installing this kit will cause your network to fail. You can contact your local office to determine if your kit is one of the bad ones. We found this out when we started asking why we had not gotten our update kits. As an OEM, we should get the kits before our customers do. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 ================================================================ Note 760.6 VMS 4.6 Installation Experiences 6 of 16 "DAVID JENSEN" 15 lines 5-OCT-1987 14:57 -< more 4.6 problems... >- ---------------------------------------------------------------- It seems that there is a problem with the DEBNA/DEBNT device driver (ETDRIVER) in 4.6. Since installing 4.6 on our 8530, I have been unable to connect to my terminal servers. I get a message saying INSUFFICIENT DYNAMIC MEMORY (tho I have oodles free) or NO I/O CHANNEL AVAILABLE. I was told by the Networking folds that Engineering wasþò working on a fix... no word since. Something to think about. DAVID JENSEN COORS PACKAGING COMPANY PO BOX 1501 GOLDEN, CO 80401 VAX-53 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 760.7 VMS 4.6 Installation Experiences 7 of 16 "Jack Patteeuw" 21 lines 7-OCT-1987 13:24 -< Problems with 4.6 >- ---------------------------------------------------------------- We have had two problem with 4.6 on our 11/780. First during the installation procedure, VMSINSTAL would abort with "device not available" (or something like that). It turns out that the kit was turning off OPCOM before doing the @SYS$SYSTEM:SHUTDOWN which of course uses OPCOM to put the shutdown messages out. (I wonder why this was not a problem with anyone else ?) The problem was solved by starting OPCOM and then doing the shutdown. FLAME ON Second, VMS Engineering **BROKE** the YFDRIVER (that's the one used by DHU11's). If you have /DMA set (which is why you bought the DHU11, right?) and in fact you are doing a DMA transfer to the terminal controller and you press ^Y (now who would ever do that?) the process hangs ! The solution is (according ti Colorado Springs) is to turn of DMA mode or to restore YFDRIVER from V4.5. Gee, what ever happened to Quality Control ! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-54 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 760.12 VMS 4.6 Installation Experiences 12 of 16 "Linwood Ferguson" 28 lines 9-OCT-1987 22:45 -< Database, what Database (CSC on weekends) >- ---------------------------------------------------------------- 760.6 DEBNA/DEBNT (ETDRIVER) Problems 760.7 YFDRIVER problems Reading the above in the middle of installing 4.6, I called CSC in Colorado and asked specifically about these, and generally about other problems. I was told (5 minutes ago, so my memory is fresh): 1) These are not in our database (I suppose you guys must have been talking to a different Digital?). 2) There is a VMS 4.1 (yes, that's 4.1, not line noise) problem in the YFDRIVER that causes hangs. 3) There is nothing else in 'his database'. 4) Quote "I only work on Friday evenings and the weekends, and nobody tells me anything" End-quote. Guess I'll call back on a non-weekend. But don't these guys share databases? Or are these databases just big stacks of yellow stick-on notes around someone's cubicals. That's what this conversation sounded like. Well, 4.6 is booting as a cluster as I write this. I guess I'll know in a bit whether I need to send CSC a few stickem notes. Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 VAX-55 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 760.14 VMS 4.6 Installation Experiences 14 of 16 "Jack Patteeuw" 30 lines 13-OCT-1987 09:09 -< Problems with OPCOM during 4.6 upgrade >- ---------------------------------------------------------------- re:.7 Burn me once, shame on you! Burn me twice, shame on me! I was burned on this while going to 4.4 and it got me again going to 4.6 ! Whatever you do with TTY_DEFCHAR (and/or TTY_DEFCHAR2) make certain that you **NEVER** (repeat **NEVER**) turn off BROADCAST!! If you must turn off BROADCAST on user terminals do it in SYS$MANAGER:SYSTARTUP.COM. The problem is as follows: During a normal boot, SYS$SYSTEM:STARTUP.COM does a SET TERM/PERM/BROADCAST on OPA0: before starting up OPCOM. This way OPCOM is guaranteed to have a device to put it's messages on even if no one is logged in (or has done a REPLY/ENABLE). However, during a VMS upgrade (such as 4.4 or 4.6) VMSINSTAL re-boots the machine several time, all of them being a MINIMUM boot (which means of course that SYS$SYSTEM:STARTUP is not run). So when SYS$SYSTEM:SHUTDOWN is run to go to the next phase there is "NO DEVICE AVAILABLE" to print the shutdown message on (because I disabled it in TTY_DEFCHAR!) There are (of course) no warnings about this in the upgrade notes so be aware !! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-56 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 760.15 VMS 4.6 Installation Experiences 15 of 16 "Jack Patteeuw" 5 lines 13-OCT-1987 09:13 -< YFDRIVER 4.5 better than 4.6 ! >- ---------------------------------------------------------------- re:.12 We are currently running VMS 4.6 with the YFDRIVER from 4.5 and the problems with ^Y and ^O causing the process to hang have all gone away ! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 760.16 VMS 4.6 Installation Experiences 16 of 16 "G. Del Merritt" 29 lines 22-OCT-1987 19:00 -< 4.6 TUDRIVER bug for tape drives with caches >- ---------------------------------------------------------------- I haven't seen this one mentioned yet, so here's a VMS 4.6 bug. We have an 8200 (not important) and a TU81+ (important). Apparently and old 4.4 bug has been reintroduced that will require you to have PHY_IO before you write to a tape with an onboard cache. I noticed it when I tried to do a BACKUP. I operate as moderately unprivileged as a rule (my fingers fumble *just* often enough) and I after typing something like: $ BACKUP/LOG *.BAR TAPE:FOO/SAVE I got a message that went something like: %BACKUP-F-BADPARAM, bad parameter value -some other message that I don't recall offhand I tried re-initializing the tape and mounting a bunch of different ways. Same result. As a last resort, I turned on all privileges and then everything was cool. VAX-57 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT I called Colorado, gave them the full story, and they indicated that this is a known bug. They said that it had existed in 4.4, was fixed by 4.5, and then *unfixed* for 4.6. There was (as of my last call about two weeks back) no fix yet, but "... maybe you could go back to the old TUDRIVER... otherwise, call back again in a few weeks." The bug affects TU81+'s and (maybe) TK50's. Because we operate in a sort of lab environment, and because I removed privilege from users ASAP when I started here (paranoid new system mangler), I decided to INSTALL BACKUP with PHY_IO. If this sounds like a bad plan, let me know, but I didn't want to give back all those privileges. This way, they never had to be told, and everything worked swell. (By the way: I also had to INSTALL ENCRYPSHR.) G. Del Merritt 55 Walkers Brook Drive Reading, MA 01867 ================================================================ Note 763.6 VT320 Character Cell Terminal 6 of 12 "Kevin Angley" 27 lines 6-OCT-1987 21:38 -< First kid on the block with a 320? >- ---------------------------------------------------------------- I have a VT320 on my desk now ... and I am not too impressed. Its basic flaw is that the character generator's use of the available cell is horrible. Characters come off looking like the IBM logo - you know, where you can see separations between the pixels. I hope this is just one maladjusted terminal ... I have another one scheduled to be shipped 10/24 and then I will have a basis for comparison. Larry, the <> ,. ~ options are in the setup but I haven't tried them out. The options are something like ,, send <, or ,, so I guess you would just have to have new key caps to get whatever you want. VAX-58 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Most everything I could tell you about it is in Digital News review 10/5/87, but I did want to react to the quality of the character presentation. The review says better character quality than a VT220. Not on mine! There is no adjustment for keyboard angle, and the tilt swivel is almost a must. The power cord (US) model is not detachable (which means I had to crawl behind my desk to swap out the trusty power cord that came with a VT100 several generations ago). I might consider buying international just to get the detachable cord and a DB25 like the good Lord intended. It's not a bad little terminal ... but I want my CIT 220+ back. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 763.9 VT320 Character Cell Terminal 9 of 12 "Jonathan M. Prigot" 17 lines 20-OCT-1987 15:37 -< My $0.02 >- ---------------------------------------------------------------- I have a VT320 that we paid real money for. It's different. The keyboard is the standard LK201 that you've come to know and loathe. Me, I'm adaptable and have no problems with it. The LEDs are green (told ya it was different.) Through ignorance I ordered the white phosphor. It arrived after a week. The "paper-white" phosphor doesn't do anything for me or against me. It sits low on my desk, so I agree that it requires the terminal stand (on order for three days now.) The tilde, angle bracket, period, comma keys are remappable, but if you do, you have to figure how to show the remapping. Overall I like the terminal, but I can't get emotional about it. I guess the part that most appeals to me is the cost to purchase and the cost to maintain. Jonathan M. Prigot W.R. Grace & Company VAX-59 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT 55 Hayden Avenue Lexington, MA 02173 617-861-6600 x2148 ================================================================ Note 765.0 UDA-50 revision question 6 replies "Terry Kennedy" 5 lines 30-SEP-1987 01:35 ---------------------------------------------------------------- I am having a problem with my RA81's attached to a UDA-50 controller. On power-up, the VAX logs two 'bogus' errors. Is this a revision problem? Field Service says this is 'perfectly normal'. Of course, they said that about my TU78 as well (it was missing 11 ECO's). Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 765.1 UDA-50 revision question 1 of 6 "M. Erik Husby" 4 lines 30-SEP-1987 16:44 -< Bogus errors are "normal" >- ---------------------------------------------------------------- If "perfectly normal" means every UDA50 does it, then yes that behaviour is perfectly normal. All our VAXes with UDA50's do it. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 VAX-60 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 765.2 UDA-50 revision question 2 of 6 "Kevin Angley" 3 lines 30-SEP-1987 23:28 -< Normal abnormalities >- ---------------------------------------------------------------- Ditto. The phantom errors are indeed normal. This is on of the few times when field service claim of "normal" errors is correct. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 765.6 UDA-50 revision question 6 of 6 "Almon Sorrell" 4 lines 14-OCT-1987 22:24 -< look in the error log >- ---------------------------------------------------------------- If you look at these 2 "errors" in the ERRLOG file, you'll see that they are initialization messages. Why the MSCP and TMSCP drivers can't decline to increment the UCB error count is beyond me. Almon Sorrell Westinghouse Electric Corp PO Box 746 MS 1615 Baltimore Md 21203 VAX-61 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 767.0 DF100-RM/DF124-AM problems? No replies "Bill Mayhew" 28 lines 3-OCT-1987 11:32 ---------------------------------------------------------------- We've all heard of "null modems"... A client just attempted to install a brand-new DF124-AM 2400-baud modem card in a DF100-RM rack-mount unit that has been in service for some time (and has 3 DF112 cards already in it). The DF100-RM was powered down during the implant surgery. When powered back up, it did not come up -- evidently the power supply lost its lunch. Removing the DF124-AM again does not help. The client believes the DF124 zapped the power supply, but I have some problems with that idea since the three output voltages are reportedly independently fused and none of the fuses are blown. I am inclined to attribute this incident to coincidence. (I have also pointed out to the client that according to the DF100 literature it is not necessary to power down the DF100 to insert or remove a modem card, and that obviously powering it down was his first mistake, but he is not buying that argument, for some reason {grin}). Total current draw by the modules appears to be well within the limits of the 100-RM. Has anyone had any similar problems? (Solving the problem is compounded by the fact that the client chose not to put the 100-RM on a service contract, and the DECmailer price for "repairing" it is about 90% of the price of a new one... my warning to anyone else trying to save pennies by keeping selected options off the service contract is to watch the self-maintenance prices _very_ closely -- the same client got burned when some VRTS1 DECtouch CRTs (VR241's with touch-sensitive screen overlays) needed service, only to discover that they have silently disappeared from the DECmailer program altogether.) Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 VAX-62 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT 617-237-0238 ================================================================ Note 772.0 RMS Relative File Locking Problem 1 reply "Offline Submission" 47 lines 6-OCT-1987 18:12 ---------------------------------------------------------------- I have SPR'ed the following problem with VMS V4.5: PROBLEM: If a $FIND is performed on any record (except record 96) in a Relative File specifying ULK as the (only) locking option, and then a $GET is performed on the same record specifying RLK and ULK, then RMS "loses" the first lock and instead establishes a lock on record 96! DIAGNOSIS: The cause of this problem is easily located in the microfiche. To perform the second lock, routine RM$LOCK is called with the record number in R1 (masquerading as the bottom two words of the RFA). As there is already a lock on this record, the routine branches to 60$ which checks to see if the new lock is the same as the old lock. If not (as in the above example) then it calls the local routine DEQUE to dequeue the old lock and release the Record Lock Block (RLB) and branches back to 12$ which calls GET_RLB to create a new RLB for the new lock. GET_RLB sets up the Record Lock Block from the information in R1 (and elsewhere). Unfortunately R1 has been corrupted by the routine DEQUE which issues a $DEQ system service without first preserving R1 (ouch!). As it happens, a successful $DEQ operation always sets R1 to 96 - hence the above problem. CURE: As a temporary fix we have rewritten our code to use a different locking mechanism. We would hope that this bug would be fixed in the next release of RMS. Phil Stephensen-Payne Performance Software Limited 41 Campus Road VAX-63 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Listerhills Science Park BRADFORD, BD7 1HR West Yorkshire, United Kingdom Date: September 10, 1987 ================================================================ Note 772.1 RMS Relative File Locking Problem 1 of 1 "Linwood Ferguson" 12 lines 9-OCT-1987 22:10 -< Rel File Problem - Lock during Fail >- ---------------------------------------------------------------- A possibly unrelated problem with Relative files we discovered in a poorly designed Cobol program is that if you repeatedly do writes (not rewrites) to a relative file with an already existing key it locks that record in spite of failing. The folks at CSC confirmed this in Macro (I was too lazy, we just rewrote the program so it didn't do it this way) and claim that you can't release the lock (we were running out of ENQLM). We seem to release the look just find with UNLOCK (i.e. SYS$RELEASE). They will SPR it. I guess we all know what that means by now. Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 773.0 DHV11 Throughput on a MicroVAX II 2 replies "Offline Submission" 19 lines 6-OCT-1987 18:12 ---------------------------------------------------------------- I have a single CRT at 19.2 kb on a DHV11 on a MicroVAX II. What is the maximum DHV11 throughput in characters per second? Shouldn't it be approximately 1900 characters per second? At best, I can get only 1000 characters per second or so. VAX-64 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT The CRT is not the problem. Also, I tried SET TERMINAL/DMA and I set the system parameter DMASIZE to 5 characters, but no cigar. Steve Murphy Loral Systems Group 1210 Massillon Road Akron, OH 44315 Telephone: 216-796-2774 Date: September 17, 1987 ================================================================ Note 773.1 DHV11 Throughput on a MicroVAX II 1 of 2 "Dale E. Coy (505) 667-3270" 13 lines 6-OCT-1987 22:31 -< Curious >- ---------------------------------------------------------------- Maybe somebody else has some insight into DHV11s, but you've got my curiosity going. Hope you don't mind a couple of questions about your problem: 1. What kind of non-DEC terminal are you using to accept your 19.2 data? (or do you have a VT300 of some kind)? 2. How are you timing the "characters per second"? Hope you account for CR, LF, and any controls which may be in the data stream. 3. What number of bits, stop bits, and parity are you using? DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-65 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 773.2 DHV11 Throughput on a MicroVAX II 2 of 2 "Terry Kennedy" 26 lines 10-OCT-1987 01:10 -< Some thoughts... >- ---------------------------------------------------------------- What is the maximum DHV11 throughput in characters per second? The DEC literature states (EK-DHV11-TM-001, pg. 1-1) 'o Total module throughput of 15000 characters per second'. Of course, anything near 10% of that in a real-world application would be just dandy. The CRT is not the problem. Are you sure? Disconnect the pin that the terminal sends on (either 2 or 3, depending on the phase of the moon). If the terminal drops characters, it can't keep up. You'd be surprised! Also, I tried SET TERMINAL/DMA and I set the system parameter DMASIZE to 5 characters, but no cigar. If the terminal is in non-DMA mode, overhead is about 15-20% worse than a DZ-11 (yes, worse!). This is because the data has to go through the microprocessor and buffers to get out the UART. The overhead in setting up the DMA transfer causes you to lose up to about a DMA size of 20. Try 32 or 64 characters and you should see a big improvement. Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 VAX-66 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 774.0 DEBNT Driver Receive Buffer Limit 2 replies "Larry Kilgallen" 34 lines 10-OCT-1987 10:55 ---------------------------------------------------------------- The ETDRIVER supplied with VMS V4.5 (the only one with which I have tested and also the only one for which I have microfiche), apparently has hard-coded a limit as to how many receive packets it will accept at the same time. I ran into this with non-DEC software which could only set up a channel for the first of its three Ethernet Protocols on one particular machine. The same code executing for the second and third protocols resulted in the error SS$_INSFMEM on the IO$_SETCHAR call which was to set up the receive packets. If the same non-DEC software was run *without* starting the myriad of Ethernet-using DEC software on this particular machine, it ran fine. Looking at VMS V4.5 microfiche frame 0548 E4, I find cell ET$W_NO_RCVBUF_QUOTA, containing hex 1A. It seems to be the limit I am hitting, and is in a list of what are commented as being "Tunable Driver Parameters". The comment says "if you have more memory on your system, you may want to increase this parameter". Presumably the tuning tool for changing this "parameter" is the PATCH utility! Has anyone gotten any official response from DEC as to why they are limiting Ethernet use in this way? Note that if one runs many different Ethernet protocols over what is nominally supposed to be a shared driver, this limit becomes not a limit of how many receive buffers each protocol may specify, but, in fact, how many protocols may share the driver! Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-67 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 774.1 DEBNT Driver Receive Buffer Limit 1 of 2 "Chris Erskine" 10 lines 15-OCT-1987 15:26 -< We were told to patch it >- ---------------------------------------------------------------- This sounds just like something that we went through at a site that I support. CSC gave the FIELD ENGINEER a patch for the ETDRIVER which he then did on one machine and rebooted all systems in the cluster. I was lucky that the patch utility writes to the SPECIFIC directory and not common. The patch that he put in broke the driver. This occurred just as I was leaving the site so do not know if they got it fixed but I was told that the patch was to increase the buffers Chris Erskine 23 S Holcomb Clarkston, MI 48016 (313) 524-8836 ================================================================ Note 774.2 DEBNT Driver Receive Buffer Limit 2 of 2 "Larry Kilgallen" 12 lines 24-OCT-1987 08:02 -< Resolution is Possible >- ---------------------------------------------------------------- One site reports the problem was fixed by the following three steps (or some subset thereof): 1) Upgrade to VMS V4.6 2) Upgrade to DEBNA from DEBNT 3) Have Field Service apply a magic "patch to VMS". (Before this, the DEBNA would not work *at all*, so it is clearly something more than simply patching that offending limit cell in ETDRIVER.) Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-68 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 775.0 Again a Reminder to Install IMPPAT010 15 replies "Larry Kilgallen" 11 lines 11-OCT-1987 16:42 ---------------------------------------------------------------- As had been rumored, DEC has sent out a letter reminding people to install the security patch (IMPPAT010) on VMS V4.4 and VMS V4.5 systems. Apparently a lot of sites did not take a hint from the use of the term *mandatory* in the letter originally accomplishing the patch. For this system (the one where Pageswapper submissions are accepted), *two* copies of the latest letter were received, with identical mailing labels. Is this strictly a local phenomenon, or were duplicates of the latest letter received nationwide - worldwide - intergalactically? Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 775.1 Again a Reminder to Install IMPPAT010 1 of 15 "Dale E. Coy (505) 667-3270" 5 lines 11-OCT-1987 22:24 -< DSIN, too. >- ---------------------------------------------------------------- DSIN has been putting up a "new" FLASH message about this about every 2 weeks. Recently there was a FLASH FLASH message which sounded really desperate. I'd venture to say that half of the "library" of FLASH messages on DSIN is now composed of this message. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-69 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 775.2 Again a Reminder to Install IMPPAT010 2 of 15 "Brian Tillman, Smiths Industries." 2 lines 12-OCT-1987 12:34 -< Just a few! >- ---------------------------------------------------------------- We received at least a dozen of the mandatory update letters, all with identical mailing labels. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 775.3 Again a Reminder to Install IMPPAT010 3 of 15 "Terry Kennedy" 6 lines 13-OCT-1987 03:37 -< Label madness >- ---------------------------------------------------------------- We received at least a dozen of the mandatory update letters, all with identical mailing labels. Must be the same system that prints the labels for the software updates - I've gotten 5 F77/RSTS V5.2 kits & 3 VAX FORTRAN V4.7 kits so far! Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 VAX-70 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 775.5 Again a Reminder to Install IMPPAT010 5 of 15 "Kevin Angley" 10 lines 15-OCT-1987 10:30 -< A little late for us >- ---------------------------------------------------------------- I received two. Must have used sales' mailing list. The info was a dollar short and a day late - I am now on 4.6, so it is a mute point. But I had not heard of this patch before (other than the notes on the VAX Campground board at Nashville). Can we stop playing like children and discuss the details of that security problem??? After all, the hackers already know it. Only those of us who trust DEC for software support and information were not made aware of it. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 775.6 Again a Reminder to Install IMPPAT010 6 of 15 "Larry Kilgallen" 16 lines 15-OCT-1987 15:56 -< But did you receive the original FIX? >- ---------------------------------------------------------------- If not, raise hell with your LOCAL software support. The problem, like most security problems, is that a malevolent individual can gain access to your VAX in a fashion you have not authorized. The ultimate result can be any of the gamut of security hazards: unauthorized disclosure, unauthorized modification, denial of service (to legitimate users), or theft of service, depending upon the proclivities of the malevolent individual. We will NOT discuss the details in this forum of how to be malevolent. The short term defense is to install the fix as supplied (if you are running VMS V4.4 or VMS V4.6). The long-term fix for your particular case is to pester DEC (or your own receiving department) to find out WHY you did not get the fix. Larry Kilgallen Box 81, MIT Station VAX-71 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Cambridge, MA 02139-0901 ================================================================ Note 775.9 Again a Reminder to Install IMPPAT010 9 of 15 "Bill Mayhew" 6 lines 17-OCT-1987 21:28 -< Two reminders are better than none! >- ---------------------------------------------------------------- Well, then there are those of us (under 1-year software warranty on 2000-series machines) that have received *neither* the update, *nor* the letter reminding us to install it. I do get reminded periodically when I log into DSIN about it, however... and yes, I am running 4.5 to start with. Siiiiggghhh... Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 775.13 Again a Reminder to Install IMPPAT010 13 of 15 "Brian Tillman, Smiths Industries." 1 line 21-OCT-1987 18:44 -< More and more and... >- ---------------------------------------------------------------- We just got three more. Total now stands at 16! Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-72 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 775.14 Again a Reminder to Install IMPPAT010 14 of 15 "Larry Kilgallen" 2 lines 21-OCT-1987 20:30 -< You probably have more than one VAX >- ---------------------------------------------------------------- Four have been received so far for the single machine which is used to accept Pageswapper input. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 775.15 Again a Reminder to Install IMPPAT010 15 of 15 "Dale E. Coy (505) 667-3270" 3 lines 21-OCT-1987 23:37 -< 10,000,000 >- ---------------------------------------------------------------- Would you believe that Publisher's Clearinghouse is going to..................... DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 777.0 Datatrieve Plots on LXY No replies "Offline Submission" 12 lines 13-OCT-1987 10:50 ---------------------------------------------------------------- Does anyone know of any available software to translate a Datatrieve plot file for printing on an LXY (Printronix P600) printer? Patrick Murray Axem Resources Incorporated 7800 East Union Avenue, Suite 1100 Denver, CO 80237 Telephone: (303) 740-9000 Date: July 16, 1987 VAX-73 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 778.0 DEQNA VICTIM No replies "CHUCK MCMICHAEL" 36 lines 13-OCT-1987 10:58 ---------------------------------------------------------------- Last week, our facility was hit with a power outage. When we brought the systems up, our terminal servers would connect to our MicroVAX regardless of the command. Example: Local> CONNECT VAX750 Local -010- Connection to VAX750 established as session 1 Username: USER1 Password: Welcome to VAX/VMS version V4.4 on node MICROV . . . $LOGOUT USER1 logged out at 10-OCT-1987 10:46:29.15 Local -011- Session 1 disconnected from VAX750 Colorado Springs immediately suspected the DEQNA had been jolted into promiscuous mode and was grabbing everything on the network. We had took the MicroVAX offline and the Ethernet was back to normal. Replacing the DEQNA solved the problem. If this happens to you and you want proof the DEQNA's at fault, set your terminal server port to privileged and run the following test at the "LOCAL>" prompt: LOOP AA-BB-CC-DD-EE-FF LOOP AA-BB-CC-DD-EE-FF HELP FULL ASSISTANT 01-02-03-04-05-06 If the first test is successful and the 2nd fails, you've got a berserk DEQNA. Both tests should fail on a normal Ethernet (unless you defy the 16**12 odds and actually have a device with the fake address used above). CHUCK MCMICHAEL PITTSBURGH CORNING CORP 800 PRESQUE ISLE DR VAX-74 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT PITTSBURGH PA 15239 412-327-6100 ================================================================ Note 779.0 Problems with the new LAT Symbiont 2 replies "Howard W. Pinsley" 36 lines 13-OCT-1987 16:55 ---------------------------------------------------------------- We have just upgraded to 4.6 and were looking forward to the new multi-threaded print symbiont. Unfortunately, we are having problems with it. The two problems seem to be: a) Jobs aborting with SYSTEM-F-ABORT. Operator messages of JBC-E-WRISMBMBX SYSTEM-W-MBFULL b) Jobs just hanging in printing state. Colorado admits to having some problems but they are not very specific about what they are or how to deal with them. They think the mailbox problems might be related to the number of queues per symbiont. We run 130 lat print queues and they seem to have been divided amongst 5 symbiont processes. One of their suggestions is to create multiple copies of the symbiont and reinitialize the queues on more than 5 symbionts to lower the queue/symbiont ration. As of this writing, I have not attempted this. One other point. We used to have a similar problem (I'm not sure what the exact symptoms were) where the Job Controller was running into a buffered I/O limit. We bumped the quota for the job controller (by modifying STARTUP.COM) from 100,000 to 200,000. This did correct the old problem. When we went to 4.6 it overwrote STARTUP.COM and hence our job controller is back to the 100,000 limit. We had hoped that it wouldn't matter anymore since there are no longer 130 separate symbiont processes to communicate with. Right now we are putting it back to 200,000 to see if this corrects the problems. If not, I guess we will have to try the multiple symbiont kludge. If that fails, Colorado tells us we might have to go back to 4.5 (just the Lat stuff). VAX-75 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Is anyone else going as crazy with this as I am. Howard W. Pinsley 145 West 79th. Apt 11D New York, NY 10024 ================================================================ Note 779.1 Problems with the new LAT Symbiont 1 of 2 "John Osudar" 23 lines 15-OCT-1987 17:47 -< Comments >- ---------------------------------------------------------------- Some comments: First of all, since LATSYM uses the shareable print symbiont code (SMBSRVSHR) effective with VMS V4.6, it must call PSM$PRINT (the main entry point in SMBSRVSHR), at which time it passes the maximum number of streams (queues) as an argument. It would make more sense to figure out where this number is stored in the image and patch it, than to make multiple copies of the image and change all of your queues to use /PROCESS=LATSYM1, LATSYM2, ..., LATSYM999999. This shouldn't be too hard to do. (Once I get 4.6 up on my systems, I will figure out how to do it; if you haven't gotten a better solution by then, I'll post the patch as a reply here.) Second, your comments about STARTUP.COM reminded me that DEC tells you NEVER to modify STARTUP.COM -- but the right thing to do is to create a modified copy with a different name (e.g. STARTUP_LOCAL.COM) and then use SYSGEN's SET/STARTUP command to set the new file as your startup file. Whatever DEC then does to STARTUP.COM won't destroy your modified copy -- and you can then decide what you want to do after the upgrade has been completed. I believe that with V4.6 of VMS, there's an AUTOGEN symbol that can be put into MODPARAMS that will let you specify the startup filename in a well-documented manner. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-76 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 779.2 Problems with the new LAT Symbiont 2 of 2 "Brian Tillman, Smiths Industries." 29 lines 21-OCT-1987 18:36 -< Others have problems, too. >- ---------------------------------------------------------------- The following has been copied from the DECUServe system. It points out that this is not an isolated problem. We never did install the V4.6 LAT software, because the functionality of LATplus v1.2 is incorporated into it. This caused all terminal servers whose ports had the MODEM attribute to be mapped to LAT ports with the DIALUP attribute, necessitating us to enable DIALUP access for all users in the UAF. We didn't want this, so we just put LATplus v1.0 with patch on our V4.6 systems. <<< DECUSV::DUA0:[NOTES$LIBRARY]VMS.NOTE;1>>> -< Welcome to the VMS support conference!>- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Note 86.0 V4.6 LATSYM bug No replies DECUSV :: NORTON 14 lines 19-OCT-1987 13:36 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - After upgrading to V4.6, our terminal server print symbionts started dying with a "-PSM-F-BADLOGIC, internal logic error detected at PC 0000CC4F" error. Restarting the queues involved helped for a while. CSC server team says this is a known bug with no patch yet. The work-around is to get LTDRIVER.EXE, LATSYM.EXE, and LATCP.EXE from the V4.5 system image backup tape and run them instead. This seems to help, but now the header and trailer pages are garbage; the burst page and the printed files' text are OK. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-77 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 780.0 Observe Software for VAX/VMS 2 replies "Offline Submission" 15 lines 13-OCT-1987 21:03 ---------------------------------------------------------------- I am looking for VAX/VMS software which will allow me to view and interact with a user's terminal session. This must work on DECserver 100 ports. What I have found so far has been limited and pricy. This could be valuable for training and other remote user support. Brad Smith O.H. Materials Corporation 16406 US Route 224 East Findlay, OH 45840 Telephone: (419) 423-3526 x4270 Date: October 8, 1987 ================================================================ Note 780.1 Observe Software for VAX/VMS 1 of 2 "John Osudar" 18 lines 15-OCT-1987 17:59 -< what we use... >- ---------------------------------------------------------------- We use Clyde Digital Systems' CONTRL package. It works with LAT terminals as well as "regular" terminals. Previous versions of this software had some "minor" problems when used with LAT terminals (e.g. for non-LAT terminals, if the user logs off, it leaves you connected to the physical terminal; for LAT terminals it would do the same -- but when the user logs off, the LAT terminal goes away. Unless you did an immediate exit from CONTRL, without typing any other characters, it would try to send the input through the LAT terminal that's not there. This causes your console terminal to print lots of stack dump and makes your users very irritated as they wait for the system to reboot...) We have version 2.5 field test 6 of CONTRL running now, and it has fixed this problem -- when the LAT terminal goes away, CONTRL now exits automatically. We have used this software for some time now (a couple of years, counting previous releases) and have been quite satisfied with it. I don't know the current price for CONTRL; contact Clyde, Inc. (in Orem, Utah). John Osudar Argonne National Laboratory VAX-78 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 780.2 Observe Software for VAX/VMS 2 of 2 "Mark Oakley" 18 lines 17-OCT-1987 20:57 -< PBS Software >- ---------------------------------------------------------------- We use Precision Business Systems OBSERVER and ADVISOR software. OBSERVER let's you watch what comes to another terminal's screen. ADVISOR does everything the OBSERVER does, plus lets you enter commands on behalf of the terminal you are watching. I'm not sure whether LAT terminals can be "observed" and "advised". These products have performed well and are reasonably priced. I suggest you contact PBS for more information if you are interested. Their address is: Precision Business Systems 33 Rector St. New York, NY 10006 (212) 425-0200 Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 VAX-79 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 783.0 VS 3x00 > single user license 4 replies "Almon Sorrell" 8 lines 14-OCT-1987 23:04 ---------------------------------------------------------------- Does anyone know what the real scoop is with the VS 3x00 and licensing limits. We heard the same rumor at DECworld that the single user license is "enforced in hardware". The same day we had a DEC manager tell us that was false, and that later we would be able to buy upgrade licenses. Other than the usual hooks in Loginout, what could they possibly do that is hardware enforced. Assuming that Loginout was made to see a SID that said I'm not a VS, would the enforcement crumble? Almon Sorrell Westinghouse Electric Corp PO Box 746 MS 1615 Baltimore Md 21203 ================================================================ Note 783.1 VS 3x00 > single user license 1 of 4 "Larry Kilgallen" 3 lines 14-OCT-1987 23:25 -< Enforcement is based on SID >- ---------------------------------------------------------------- Thus the single user license for the VAXstation and VAXserver is really "enforced in software", based on what it learns of the hardware on boot. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-80 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 783.2 VS 3x00 > single user license 2 of 4 "Jack Patteeuw" 2 lines 15-OCT-1987 12:02 -< Does any one know ... >- ---------------------------------------------------------------- Can a the VMS license for a VAXStation (be it a II, II/GPX, 3200 or 3500) be upgraded to a multi-user license ? Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 783.3 VS 3x00 > single user license 3 of 4 "Larry Kilgallen" 4 lines 15-OCT-1987 16:02 -< No Upgrades from VAXstation 3x00 Licenses >- ---------------------------------------------------------------- The current plan is that VAXstation IIIs and VAXserver IIIs are NOT amenable to upgrade. As noted before this is implemented in software and therefore the possibility of policy change exists. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 783.4 VS 3x00 > single user license 4 of 4 "Bob Huckins" 2 lines 16-OCT-1987 19:10 -< Reply to .2 >- ---------------------------------------------------------------- Re .2: I believe you can upgrade GPX systems to 8 user, but then you must pay the regular MicroVAX II license fee (QZxxx). Bob Huckins Nuclear Data Instrumentation Div. Golf & Meacham Rds. Schaumburg, IL 60196 312-884-3659 VAX-81 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 784.0 In search of a modem 15 replies "Kevin Angley" 22 lines 15-OCT-1987 10:55 ---------------------------------------------------------------- In the old days, a man would go out and buy a 300 baud modem that had an on/off switch and a place to plug in a cable. It would auto-answer and work like a champion. Nowadays, "intelligent" 1200/2400 baud modems have a two dozen dipswitches and "commands" and a users' manual over 100 pages long (I'm not lying). Even if I had the time to figure out that I need to send an ATS0=1 command to the damn thing, some seem to go back to factory settings on power cycle. Can someone recommend a care-free 2400 baud modem that works well on a VAX/VMS system? The requirements are: 1) It must be 2400 baud auto-answer. 2) It must go from box to being connected in under 10 minutes, and you should never have to dick with it again. 3) If it does do MNP (with a cooperating modem on the other end), it must do so transparently in every way. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-82 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 784.1 In search of a modem 1 of 15 "Jack Patteeuw" 32 lines 15-OCT-1987 12:20 -< Try Racal-Vadic >- ---------------------------------------------------------------- I strongly recommend the Racal-Vadic product line. I agree with you whole heartedly that "intelligent" modems are a pain in the a__! I have had so many problems with "huh-what"loops it's not funny anymore. We have purchased several Racal-Vadic 2400VP modems for calling into our VAX from home and they have been set up by several computer novices in under 5 minutes ! The unit has exactly 5 buttons on the front: DATA to initiate data transfer if you have dialed with an external phone (like the red button on the phone of the old Bell 212A). Dial through the keyboard is also available. SPEED to select between 300/1200/2400 ANS to place in auto-answer mode SYNC as opposed to async LOOP for loopback testing The User's Guide is over 100 page, but looks to be fairly well written. The reason it is so long is because this unit supports all Racal-Vadic commands as well as "AT" commands!! Despite the length of the manual if is DEFINITELY a "plug in and go unit" ! And, yes it does MNP !! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-83 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 784.2 In search of a modem 2 of 15 "Dale E. Coy (505) 667-3270" 15 lines 15-OCT-1987 12:50 -< Another vote for Racal-Vadic >- ---------------------------------------------------------------- Another vote for the VADIC 2400 line. We use 2400s from home, and dial out from the system using a rack-mount chassis equivalent (also from Racal-Vadic, but I forget the numbers). They have been essentially trouble-free. HOWEVER - don't ask for total transparency in all cases. If you have your MNP stuff set up to TRY for error correction, it's totally happy if the other end doesn't have it - but the other end may not be happy. Example: on the OASIS system which uses a DEC 2400, I always get one login failure at the connection because the receiving end interprets things "wrong". You can always turn off error correction, of course. I am about to get a VA2400 module for VAXNET debugged, if anybody needs it. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 784.4 In search of a modem 4 of 15 "JEFF KILLEEN" 18 lines 15-OCT-1987 19:06 -< NO FREE LUNCH >- ---------------------------------------------------------------- 3) If it does do MNP (with a cooperating modem on the other end), it must do so transparently in every way. There is no such thing as a guaranteed transparent MNP modem - other than to turn MNP off. CASE 1 - A very noisy line and no flow control VAX-84 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT For MNP to work on a very noisy line you have to turn on flow control (XON/XOFF). The reason why is at some point the incoming data will exceed the modem's buffer. If you leave flow control off to achieve a transparent link you will drop data. CASE 2 - A modem with flow control on If you turn on flow control the first time you do a binary transfer ^Q and ^S will cause untold problems. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 ================================================================ Note 784.5 In search of a modem 5 of 15 "Bob Hassinger" 5 lines 16-OCT-1987 02:57 -< New DEC modem... >- ---------------------------------------------------------------- I just saw an announcement of a new DEC modem - 2400 baud and MNP - "Scholar-Plus" I think. In theory this should be the most direct way to a working system (I said *in theory*). Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 784.6 In search of a modem 6 of 15 "Jamie Hanrahan" 18 lines 16-OCT-1987 20:06 -< flow control *can* be transparent >- ---------------------------------------------------------------- 3) If it does do MNP (with a cooperating modem on the other end), it must do so transparently in every way. There is no such thing as a guaranteed transparent MNP modem - other than to turn MNP off. VAX-85 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT For MNP to work on a very noisy line you have to turn on flow control (XON/XOFF)...the first time you do a binary transfer ^Q and ^S will cause untold problems. Is there something wrong with RTS/CTS flow control? It was my understanding that the DEC terminal drivers won't send data unless they see CTS (on lines that support modem control and are recognized by VMS to be connected to modems). Ed Cetron has done considerable research in this area; I'll upload his exposition (from Usenet) after posting this note. Look in [US194066]MODEMCTL.TXT... Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 ================================================================ Note 784.7 In search of a modem 7 of 15 "JEFF KILLEEN" 9 lines 16-OCT-1987 23:31 -< YES AND NO ON RTS/CTS FLOW CONTROL >- ---------------------------------------------------------------- Is there something wrong with RTS/CTS flow control? It was my understanding that the DEC terminal drivers won't send data unless they see CTS (on lines that support modem control and are recognized by VMS to be connected to modems). If the devices at both ends have RTS/CTS flow control this is the answer. *HOWEVER* not all DEC devices and interfaces support it. The DZ11 for example. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 VAX-86 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 784.8 In search of a modem 8 of 15 "Frank J. Nagy" 21 lines 17-OCT-1987 13:24 -< Microcom AX2400c modems: pseudo-4800 baud >- ---------------------------------------------------------------- We are using Microcom AX2400c modems; we have a bank connected to the Micom port selector at the lab, mine is connected to my Mac+ at home. It took me a few minutes to set it up and that was it (I use my Mac frequently as a terminal emulator to our LAVC). The AX2400c has MNP class-5 (or is it class-6) which does automatic (and transparent) data compression to give an effective throughput of 4800 baud - makes it quite possible to do full-screen editing from home :-)) (BIG grin). The error correcting is very reliable, if the phone line is *real* bad (and we have them around here), the connection might be dropped but otherwise its as smooth as glass. The RS232 connections (Mac-to-modem or modem-to-Micom) are set for 9600 baud; the modem will automatically fall back from 2400 with MNP (can also handle all MNP classes below its own), to 2400 w/o MNP to 1200 to 300. Without changing setups, I've used to modem to talk to a Fido system on a Rainbow at 1200 baud with no problems. The only problem is that we were plagued for quite awhile with infant mortality problems. I'm on my 3rd modem, some others in my group went through 4-5 modems and yet others still have the first one! However, those problems seem to be over since no modems have gone back for repair in the last few months. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 VAX-87 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 784.9 In search of a modem 9 of 15 "Bill Mayhew" 35 lines 17-OCT-1987 21:58 -< The Scholar is flunking... >- ---------------------------------------------------------------- Re: .5 I agree, in theory, the new Scholar-Plus (DF242 I think) modem should be the most direct way. However I have severe doubts about DEC's abilities in the modem area. I've been using the plain Scholar on my system here and including one in each system we sell for remote support. They are *buggy* and have been since day one. Digital finally came out with an FCO which amounted to a ROM change that provided a less-than-satisfactory work-around to the problem. In most cases they work OK but it is not difficult to freak them out. There are fundamental design flaws in the product, methinks, and Digital shows no interest in correcting them. We still continue to use them, though, since our end users are extremely computer-naive and they are, at least, DEC-serviced. Then there were the preceding products: the DF112, whose autodialer failed to pay attention to the idea that '#' is a valid Touch-Tone (tm) signal, but rather usurped it for the autodial protocol, and is therefore incompatible with just about everything including other DEC modems; and the DF03, possibly the most noise-ridden 1200 baud modem ever made. I have no problem with the data transmission of the DF224 Scholar, by the way; it does better than many others I've tried. The autodialer problem is enough to drive you berserk, however. Also, you cannot configure it into true "quiet" mode with no responses -- highly desirable for auto-answer environments. I'm not sure we're ready for MNP yet. I keep hearing too many horror stories about dropped data blocks, etc; since there are many "levels" of MNP, it seems that configuring MNP modems properly requires knowledge of (and access to) both ends of the circuit, for genuine reliability. This is only an impression, though, and I am willing to be taught otherwise {grin}. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 VAX-88 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT 617-237-0238 ================================================================ Note 784.13 In search of a modem 13 of 15 "Brian Tillman, Smiths Industries." 4 lines 21-OCT-1987 18:58 -< To Kevin >- ---------------------------------------------------------------- We use both Racal-Vadic VA4224E and Microcom AX9624c modems. Both work quite reliably, but the Microcom is more "plug and go" once the switches are set. MNP class 6 works fine, even with DECnet. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 790.0 For DECMail Users 4 replies "Dale E. Coy (505) 667-3270" 3 lines 20-OCT-1987 01:10 ---------------------------------------------------------------- If anybody cares (we do), DEC is about to announce (this month) that DECMail is being "retired", and will be supported only until 28 March 1989, on VMS 4.6 and 4.7 only (NOT 5.0) DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-89 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 790.1 For DECMail Users 1 of 4 "Larry Kilgallen" 3 lines 20-OCT-1987 10:35 -< And its Replacement? >- ---------------------------------------------------------------- At one point there was discussion of a possible All-In-1 option which would emulate the DECmail user interface (including editor). Has this been dropped? Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 790.2 For DECMail Users 2 of 4 "Terry Kennedy" 8 lines 20-OCT-1987 18:15 -< Apparently not >- ---------------------------------------------------------------- It apparently has been dropped. The announcement indicated that ALL-IN-1 as the suggested (only) replacement, but it had no mention of a customized version. Also, it said 'for additional details and pricing information, contact your Software Services person'. Whenever I see this, I know it means 'you're not going to like it'. I haven't yet asked what the trade-in deal (if any) is. Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 VAX-90 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 790.3 For DECMail Users 3 of 4 "Alan B. Hunt" 6 lines 20-OCT-1987 21:00 -< REPEAT of TOPS-20? >- ---------------------------------------------------------------- I know there are several enhancements planned for VMSmail in V5 from some lecture somewhere. I wonder if many of the features of DECmail are being "bundled"? They bundled the "fancy" mail system on TOPS-20 about a year ago. Might we hope for a repeat? ALAN B. HUNT 26803 BERG RD. #301 SOUTHFIELD, MI 48034 ================================================================ Note 790.4 For DECMail Users 4 of 4 "Dale E. Coy (505) 667-3270" 40 lines 20-OCT-1987 22:26 -< Neither rain nor.... >- ---------------------------------------------------------------- I seriously doubt that any part of DECMail will be bundled with anything (see below). It would be possible to put a screen-oriented, user-friendly (?) interface around VMS mail, but I don't look for that either. A better "call" interface to VMS mail - probably. The problem with DECMail, as I understand it, is that it's written in MUMPS. There are blessed few MUMPS programmers around in DEC, and none of these are interested in enhancing old, non-structured, heavily-patched code. Besides, being MUMPS-rooted, DECMail does it's own file handling. Therefore, it can't be run across a cluster. A tremendous pain. There is only one support specialist at Atlanta who knows ANYTHING about it (aside from folks who have been promoted), and he's not too happy being "stuck". It would not really be reasonable for DEC to keep it on the books much longer, since they do have a solid replacement product. VAX-91 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT We might expect to see a stand-alone mail product like the one in ALL-IN-1 (mini-A1), which at one time was called MAIL-PLUS. ALL-IN-ONE mail runs quite nicely, for the most part. We have stayed with DECMail (although we have A1) because of the "for the most part". For instance, parts of our organization have traditionally used "employee number" as Username. DECMail had a really neat way of letting you address mail to COY instead of having to remember 082768 (or US166993 or...). There are some problems in this, and other areas, with ALL-IN-1 mail --- some of which may be corrected by DEC, because even DEC has the same problems internally. Larry: ALL-IN-ONE mail has two "faces", selectable on a per-user basis, which change the way the menus look. One of these has always been a very close look-alike to DECMail. In this case, "for the most part", I think DEC is taking a reasonable attitude. Now, how big a trade-in can you get for your 6-year-old mailbox????? DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 791.0 Autogen on a MicroVMS System No replies "Offline Submission" 16 lines 20-OCT-1987 11:29 ---------------------------------------------------------------- I was somewhat upset also (like L. Baker, Pageswapper 9/3) to find that the autogen on my 16 MB, 2-RA81 system was being so inhibited by the parameters in the file SYS$SYSTEM:VMSPARAMS.DAT. I renamed the file so that autogen would not find it and now have full functionality of my MicroVAX II. This seems to be a simpler approach. Gerson H. Cohen NIH Building 2, Room 312 Bethesda, MD 20892 Telephone: 301-496-4295 Date: October 13, 1987 VAX-92 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 793.0 What happened to SIRs? 4 replies "RICHARD GILBERT" 6 lines 21-OCT-1987 16:38 ---------------------------------------------------------------- At DECUS in Nashville I spent some time writing System Improvement Requests and dropping them in the box. I didn't see any of my efforts in the last SIR ballot. Is somebody editing the SIR's before the ballot? Did the SIR box in the VAX campground get emptied into the waste basket? RICHARD GILBERT PRINCETON UNIVERSITY GAS DYNAMICS LAB PRINCETON, NJ 08544 (609) 452-5130 ================================================================ Note 793.1 What happened to SIRs? 1 of 4 "Larry Kilgallen" 21 lines 21-OCT-1987 17:25 -< Would you believe "next time"? >- ---------------------------------------------------------------- I believe it is the case (Mark Oakley can confirm) that during the week at Nashville various working groups were organizing the SIR's that had been received up to the start of symposium week. If your submission was any time after the first day of the Symposium, the working groups already had their workload (the Symposium is their only chance to get together), so those submitted during the week are for the NEXT ballot (the ones which will be organized by working groups during the Anaheim Symposium). An obvious question would by why SIR's must be processed by any committee at all. One answer is to avoid duplication and increase clarity, but another is to ensure expression in the best possible framework. Over the years various working groups have learned a good deal about the best way to express requirements to DEC, and they use that expertise in preparing SIR's for final publication. That experience applied to the wording will likely more than make up for the six month delay you perceive. Besides, there is no way to make all the working groups (that is you) stay in Nashville for another week after the Symposium! VAX-93 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 793.2 What happened to SIRs? 2 of 4 "Mark Oakley" 26 lines 22-OCT-1987 23:05 -< A word about SIR process >- ---------------------------------------------------------------- Approximately 6 weeks before a symposium, I mail the SIR submissions that I have received to the various working groups and folks who have volunteered to review SIR's. These people edit the SIR's, combining SIR's that express similar ideas, splitting SIR's that express multiple ideas, polish the grammar, etc. I ask that they return the SIR's to me during the symposium. Immediately after the symposium I put the next ballot together and send it to Larry for publication in the Pageswapper. Thus, a SIR submitted during the Nashville symposium will not appear on the ballot until after the Anaheim symposium. I appreciate all of those folks who took the time to submit an SIR. If any of you feel that your SIR was lost or that an edited SIR failed to capture your idea, please let me know. Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 ================================================================ Note 796.0 VAX 7xx support beyond VMS 4.6 7 replies "Rytis T. Balciunas" 8 lines 26-OCT-1987 11:35 ---------------------------------------------------------------- Various rags have said that the VAX 782 will not be supported by DEC beyond VMS 4.6. Some of our local DEC distributors are publishing the "rumor" that NONE of the VAX 7xx series processors will be supported past VMS 4.6!!!! I HATE rumors... Our sales people in Pittsburgh know nothing about this, Colorado is playing dumb... Anyone out there know if there is any substance to this rumor???? VAX-94 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 ================================================================ Note 796.2 VAX 7xx support beyond VMS 4.6 2 of 7 "Kevin Angley" 2 lines 27-OCT-1987 11:00 -< 750's forever! >- ---------------------------------------------------------------- I wouldn't worry about VMS support for 78x or 750's. There are more of those out there than any of those new-fangled BI thangs. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 796.3 VAX 7xx support beyond VMS 4.6 3 of 7 "Rytis T. Balciunas" 8 lines 27-OCT-1987 11:55 -< Further ramblings.. >- ---------------------------------------------------------------- I agree, but DEC has been known to throw some curves - witness the licensing fury last year (and how the user community got it turned around, something we should not have had to do with a "trusted" vendor!). By the way, I've got a 2-year old LOADED 785 that I just clustered up with an 8350 - HSC's STINK for the price that one has to pay - that is running our entire business. I intend to keep it that way 'till its "wheels" fall off! RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 VAX-95 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 796.4 VAX 7xx support beyond VMS 4.6 4 of 7 "JEFF KILLEEN" 1 line 28-OCT-1987 00:30 -< TAPS FOR THE 782 >- ---------------------------------------------------------------- The ONLY processor in question is the 782 JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 ================================================================ Note 796.5 VAX 7xx support beyond VMS 4.6 5 of 7 "Alan B. Hunt" 4 lines 28-OCT-1987 23:18 -< Retirement? >- ---------------------------------------------------------------- Don't let folks confuse you with the retirement of the 7xx line. This is true. At least the 78x series is retired which means you won't be able to buy a new one from DEC. Lot's of used ones out there. Look out for the 86xx series to be retired next. ALAN B. HUNT 26803 BERG RD. #301 SOUTHFIELD, MI 48034 ================================================================ Note 796.6 VAX 7xx support beyond VMS 4.6 6 of 7 "Rytis T. Balciunas" 17 lines 29-OCT-1987 07:20 -< Retirement vs. DEATH >- ---------------------------------------------------------------- Retirement is half the picture - many "retired" people are MORE active the some WORKING people I know...The issue is whether or not DEC will continue to support the "retired" processors...Although we are a small shop, I want my investment in the machines protected for their projected lifetime (Financial gurus here define lifetime as 10 years). Our president would be one of the people highly upset if his $300,000 investment is made useless by a policy such as this... And by support I mean parts for the old gal, knowledgeable field service engineers, and an operating system that keeps her alive VAX-96 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT as long as she has electrons coursing through her wires.... I know that DEC still supports the good ol' PDP-8s, but this is only because of the screaming by their users. What I really am looking for from DEC is a public commitment to support the 7xx line and the 86xx line as long as VMS is a viable operating system.... RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 ================================================================ Note 796.7 VAX 7xx support beyond VMS 4.6 7 of 7 "Larry Kilgallen" 56 lines 29-OCT-1987 08:19 -< Negotiating Conditions of Retirement >- ---------------------------------------------------------------- The cases in the past where support has been decommitted have in some cases involved solid technical issues and in some cases involved market politics. a) VAX-11/730 processors in a dual-RL02 configuration simply do not have sufficient system disk space to support future versions of VMS. True, VMS and DEC layered products have become a lot more memory-hungry since the days when VMS would run in 1/4 megabyte of memory, but that has paralleled a strong increase in memory capacity. I think the same is true of disks. Conventional wisdom for non-stabilized 11/730 sites is to start looking at MicroVAXen anyway, given the performance difference. b) LAT-11 was decommitted for what I see as purely political reasons, with perhaps a bit of field service considerations thrown in. If everyone is able to use their old PDP-11s as terminal servers (or PDP-11s they bought new for the purpose in some cases) how will DEC sell new boxes? VAX-97 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT c) CDD Programming Interface was withdrawn, as I understand it, because DEC wanted to retain the ability to change the calling spec in the future. The previous comment about user reaction is certainly key. The number of sites which cared about items b and c above was miniscule. The number of 782's in the field may also be a consideration. Note that at the Nashville Symposium the VMS Product Manager announced in a room of 2000 people that he would like anyone with a 782 to come see him after the session! Imagine the crowd he would have had if he had called for 780 owners! Also at Nashville (or perhaps it was the San Francisco symposium) DEC asked for users to generate comments on how they felt DEC should handle software support for older hardware models. If you did not go to the Symposium and are hearing this request for comments the first time now, it is the fault of those of us who did attend, and particularly those who have a communications responsibility in the VAX Systems SIG organization. We probably need more good *reporting* of such symposium discussions in the Pageswapper (any volunteers?). I would expect some sort of white paper from the Hardware Working Group of the SIG regarding long-term support issues, and further comments should be added after you read that. The nature of retirement indeed is subject to user comment, but remember there are a *lot* of 780s out there, with no tremendous incompatibility as there was between the way the 782 and the 83xx/8800 handle dual-processing. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-98 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 798.0 VMSINSTAL, LAT, Software Protection 8 replies "Alan Medsker" 20 lines 26-OCT-1987 14:01 ---------------------------------------------------------------- Does anyone out there know where I can get reasonably good documentation on the VMSINSTAL "utility"? As far as I know, there is no DEC manual describing it. I seem to remember an article in the PageSwapper a couple of years ago, but I don't have back issues from that long ago. Same as above for DEC's LAT protocol? On a totally unrelated topic... My company is about to release a VAX-based product, and we are currently trying to figure out what to do about software protection i.e. preventing unauthorized use of our software. Our PC product uses a "security block" that plugs into a serial port on the PC and is queried by the software occasionally. This is a good solution because it doesn't get in the user's way and is hard to break. Can't do that on the VAX because we're not guaranteed access to a serial port. Any thoughts, experiences (good OR bad) etc.? Also, I've heard that some MicroVAX IIs don't have unique SID numbers, which would make it hard to use that for software protection. How does everyone else do this? Alan Medsker Viewlogic Systems, Inc. 275 Boston Post Road West Marlborough, MA 01752 (617) 480-0881 ================================================================ Note 798.1 VMSINSTAL, LAT, Software Protection 1 of 8 "M. Erik Husby" 11 lines 26-OCT-1987 14:15 -< Need to roll your own >- ---------------------------------------------------------------- You will need to build in your own authorization scheme for now. Not only do the MicroVAXes not have unique SIDS but the same is true for the 750's and 730's. VAX-99 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT I have received hints from DEC employees in the know that DEC is developing some per user licensing software for their own products. The hint implied that this would be available to software developers such as my company. Again, only hints so far. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 ================================================================ Note 798.2 VMSINSTAL, LAT, Software Protection 2 of 8 "Larry Kilgallen" 8 lines 26-OCT-1987 20:30 -< AA-HB12A-TE >- ---------------------------------------------------------------- The document is called "VAX/VMS Developer's Guide to VMSINSTAL". The last time I looked, the DEC Bookstore in Bedford Massachusetts (nearer to you than to some people) had it in stock. Remember that the microfiche rendition of VMSINSTAL has *comments* (removed from the machine-readable version to improved execution speed). Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 798.3 VMSINSTAL, LAT, Software Protection 3 of 8 "Dale E. Coy (505) 667-3270" 1 line 26-OCT-1987 22:30 -< None is enough >- ---------------------------------------------------------------- Re: software protection. First, seriously consider NONE. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-100 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 798.4 VMSINSTAL, LAT, Software Protection 4 of 8 "MICHAEL GRATTAN" 6 lines 27-OCT-1987 07:55 -< Trust Thine Customer >- ---------------------------------------------------------------- Re: software protection. First, seriously consider NONE. I second that! Protection is an enormous headache for us (an end user.) We have NOT purchased software because it is protected. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 798.5 VMSINSTAL, LAT, Software Protection 5 of 8 "Kevin Angley" 14 lines 27-OCT-1987 10:49 -< It didn't work for video tapes, it won't work for software >- ---------------------------------------------------------------- I third the motion for no software protection. Sell only to those you can trust. We are currently hassling with a vendor of ASIC design tools because at each revision, they try some new scheme of protecting their software. We inevitably lose valuable design time after an upgrade while they scratch heir heads and say, "Gee, what's a cluster common system disk" or "What do you mean the SYSID changed when you installed new microcode?". On your basic VAX there is no guaranteed way of identifying the CPU uniquely without risk that it will change. No way. No how. Don't even try it. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-101 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT ================================================================ Note 798.6 VMSINSTAL, LAT, Software Protection 6 of 8 "Terry Kennedy" 22 lines 28-OCT-1987 19:06 -< A bad copy protection idea >- ---------------------------------------------------------------- Regarding software protection, agreed - none is the best. However, if your management won't agree with that, there are steps you can take, just as I can decide to not purchase your software. Current thinking is that the Ethernet physical address PROM can be used on those processors where the SID is not unique. However, I would point out to you (and to DEC), that anyone with more than a passing interest can program duplicate address PROMs. As long as the duplicate address is not on the same Ethernet, your software will never know it's been had. I mention this to point out that the effort spent coming up with these schemes is better spent on adding useful features to your product, so people will want to buy your latest version. I am told it took some committee about three months to code the code for Ethernet address-based security, and here we see a way around it developed while I was composing this reply. Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 798.7 VMSINSTAL, LAT, Software Protection 7 of 8 "Larry Kilgallen" 28 lines 29-OCT-1987 07:17 -< The Problem with PROMs >- ---------------------------------------------------------------- On most VAX processors, if the end user's Ethernet adapter develops hardware problems, they swap out the entire adapter and the Ethernet address goes along with it. Imagine the screams from users who can't run your software just because they have their machine repaired. VAX-102 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT On the MicroVAX 2000 things are different (I am told) because the ROM containing the Ethernet address is actually on the motherboard. The Ethernet card can be replaced and the address will remain the same. Of course if DEC decides to replace the motherboard to fix a problem the address will change. In either of these cases it might be possible to salvage the address ROM from the old board (unless that is where the problem is), depending on how it is installed (sockets or solder), but you are now depending on the relationship between an arbitrary representative of your software customer and an arbitrary DEC field servant to remember that your software requires special things be done to the hardware. Most software companies are better off staying far-far away from details of their customer's hardware arrangement. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 798.8 VMSINSTAL, LAT, Software Protection 8 of 8 "Larry Kilgallen" 25 lines 29-OCT-1987 07:24 -< Copy Protection Through Banners >- ---------------------------------------------------------------- What some vendors do (OMSI Pascal was the first place I saw it) is to make a custom banner used in the output: for Node ABC or on the screen if that is more appropriate to the nature of the product. Now absent a thorough reverse engineering job to defeat this (and *very* few would-be cheaters will go that far), every user of the software is informed as to where it belongs. Every cheater must worry that someone from their own organization will snitch. Every corporate lawyer will worry about lawsuits if they see something amiss. The best part is that if your contract allows (as most do) running the software on another machine during the time the licensed machine hardware is failing, it just works. There is no technical magic -- everyone in the company can use the "Hey Charlie" protocol to learn that indeed node ABC has been getting double error halts for three days and that is why software VAX-103 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT licensed to ABC is running on DEF. If the transposition of software persists beyond the downtime, cheaters again must worry that someone will tell. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 801.0 Questions from DEC 4 replies "G. Del Merritt" 8 lines 27-OCT-1987 14:40 ---------------------------------------------------------------- Does DEC normally call you up to ask you what software/hardware you have on/for your system(s)? For two of of our several Vaxen, field service and or sales support has inquired, and I'm perplexed. Are they trying to be helpful? Are they trying to track down "stolenware"? Why don't they have it on file themselves? Am I just being paranoid? We have been talking with them recently about acquiring new software (e.g. - LISP, PLI, VAXset, NOTES), so maybe they're just trying to get a better picture of what we do. G. Del Merritt 55 Walkers Brook Drive Reading, MA 01867 ================================================================ Note 801.1 Questions from DEC 1 of 4 "Larry Kilgallen" 19 lines 27-OCT-1987 17:50 -< Would you believe they forgot? >- ---------------------------------------------------------------- Supposedly they keep track all along, but perhaps someone dropped the ball at some point. I would give them several points for trying; many times in the past DEC records have been vastly out of date with no apparent effort to correct it. The one precaution you might take is to make sure it is really DEC making the call. Several scams could be run with such a call as a base. VAX-104 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT I have heard that DEC will be making an effort to keep more accurate records about such things in the future. On top of that, consider the business of the security patch discussed elsewhere in this conference. DEC found itself in the position of wanting to mail notification (at least) to the keeper of *every* VMS machine, regardless of whether it was still under contract or not. And in sufficiently large end-user situations, nobody in the customer organization knows where all the MicroVAXen are either! Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 801.2 Questions from DEC 2 of 4 "Rytis T. Balciunas" 13 lines 28-OCT-1987 12:01 -< More on DEC questions.. >- ---------------------------------------------------------------- Once a year DEC Field Service comes in to do an equipment audit. I have ->NEVER<- been asked over the phone - it's always our engineer that comes in.... I second the motion on knowing who is calling, especially if they ask for dial-up telephone numbers. One way to keep the DECkies honest is to ask for the system contract number (if you are under maintenance) or system serial number. That puts the onus on the caller. I have had one late-night caller claiming to be Colorado Support Center with an "urgent" on-line patch to our 785. The caller could not provide me a DEC # on our systems....Turns out someone out there got my number and had some idea of what system we use.... Bottom line is healthy paranoia keeps your butt covered.... RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 * VAX-105 PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT * PAGESWAPPER - December 1987 - Volume 9 Number 5 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA To register for on-line submission, dial (in the United States): (617) 262-6830 and log in with the username PAGESWAPPER. PAGESWAPPER - December 1987 - Volume 9 Number 5 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 - December 1987 - Volume 9 Number 5 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 - December 1987 - Volume 9 Number 5 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Mark D. Oakley Battelle Columbus Division Room 11-6-008 505 King Avenue Columbus, Ohio 43201-2369 USA