PAGESWAPPER Editor's Workfile by Larry Kilgallen, Pageswapper Editor I seriously considered not sending this issue for publication because there were virtually no submissions. In the end, however, it seemed that the money you are paying for the Subscription Service is in fact spent on production and postage, so it is there to bring you the monthly issue which is our goal. Additionally, for the four (4) people (out of 3300 subscribers) who did send I/O submissions, I feel we owe them a timely publication of their questions. 1 PAGESWAPPER - October 1983 - Volume 5 Number 4 In this issue... In this issue... Editor's Workfile . . . . . . . . . . . . . . . . . 1 In this issue... . . . . . . . . . . . . . . . . . . 2 Whither DEC, or wither DEC . . . . . . . . . . . . . 3 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . . 6 LUG Meeting Reports . . . . . . . . . . . . . . . . 8 INPUT/OUTPUT Submission Form . . . . . . . . . . . 10 System Improvement Request Submission Form . . . . 12 General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 Preference is given to material submitted as machine-readable text (best is Runoff source). Please do not submit program source, as that is better distributed on the VAX SIG tape. Material for "The DBMS Monitor" section of the Pageswapper (pertaining to VAX-11 DBMS) should be sent to: Julie Llewellyn United Technologies Microelectronics Center 1365 Garden of the Gods Road Colorado Springs, CO 80907 Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter, MRO2-1/C11 Attention: Publications Department One Iron Way Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. 2 PAGESWAPPER - October 1983 - Volume 5 Number 4 Whither DEC, or wither DEC Whither DEC, or wither DEC by Phil Anzel, Banner Associates, Incorporated Post Office Box 550, Laramie, WY 82070 NOTE Phil is co-editor of LUG*NOTES, the newsletter of the Rocky Mountain VAX LUG, where this article first appeared. Plenty of room for speculation, watching the personal computer, semiconductor, and super-minicomputer markets blossom. And DEC has lost one of its fountainheads, C. Gordon Bell. Where are they going? I recently spoke with a friend who freelances, designing microprocessor-based equipment. He had long been a true believer in DEC, but has been faced with the cost of staying with DEC chip sets as compared with chip sets from other manufacturers. Vendors like Zilog, Intel, Motorola and now National Semiconductor are coming out with chip sets, evaluation modules, and compilers for small systems that blow DEC's LSI-11 chip sets out of the water (in terms of both price and performance) for small applications. DEC has trouble selling its products in the commodities market. It is losing grould rapidly in the small systems and embedded systems marketplace. Internal DEC politics appear to be one part of DEC's problem (for example, RT11, which is DEC's most popular operating system, does not have EDT because of political considerations, and now the separate small bus groups (QBUS, CTBUS, UNIBUS) are competing for design resources). Excessive research/development/marketing ramp-up costs appear to be another part of the problem. I spoke recently with another friend, Bob, who works in one of DEC's advanced research groups. He had some interesting observations about DEC's current products and directions. Bob spoke of the high hopes based on the Professional series, calling the hardware a real wonder, and the original software (the P/OS) a real dog. The operating system had basically been designed by a team operating in isolation from the rest of the world. The menu concept was a good one for only a limited number of applications, and it ate up too much of the machine. And this box was to be for DEC in the early 80's what the VAX was for DEC in the late 70's. The project has been a slow starter, and a very expensive one at that. DEC has now cleaned 3 PAGESWAPPER - October 1983 - Volume 5 Number 4 Whither DEC, or wither DEC up the user interface (escape is permitted to DCL, applications may be developed directly on the Professional, etc.) and improved upon the performance (the system is now shipped with more memory). The product now looks like a real winner, is a pleasure to use, and may yet come to DEC's rescue. Look for it to get the J-11 chip, and perhaps be the container of the single-user VAX chip set. Now if only someone could read a crystal ball the way C. Gordon Bell did a decade ago... That remains to be seen. DEC is running about two years behind the market, and has not recently demonstrated a flexible response to changing market conditions. DEC retains a tremendous advantage in its VAX systems and in its networking software. With price cutting of the 730 (probably due to an impending product announcement), DEC may be able to hold off some of the competition from Motorola MC68xxx-based systems. Now if only DEC would dump their current advertising agency and get the one that IBM uses... More Miscellany - DECdirect DECdirect is so easy to order from. But do not count on quick deliveries or easy problem resolution. The ordering number is rarely busy, the customer service number is rarely available. Recently the computerized order / inventory system was down for a week. The ordering personnel were quoting availability / delivery data which had little relation to stock-on-hand / expected-shipment data. Maybe IBM could sell them a reliable inventory / order-entry system. Datatrieve-32 We are still learning to use the native-mode DATATRIEVE. Just this week we received DTR-32 version 2.0 and it appears that a number of our previous objections to limitations in the product may have been lifted. Installation will have to wait until after payroll time, but we are looking forward to a much improved product. One of our major complaints about DTR-32 has centered around performance and access lists. For small record collections, like most of ours, the old compatibility-mode DTR (PDP-11/VAX DTR) is a screamer, but the native-mode DTR is noticeably slower. Calls to other sites, all of whom used large record collections, had only good things to say about the native-mode product. It looks like DTR-32 carries with it a large startup overhead burden. (This is the IBM approach to hardware sales; sell the software, and let it create the demand for faster/larger hardware system). And those blasted access list procedures are a nightmare in disguise. 4 PAGESWAPPER - October 1983 - Volume 5 Number 4 Whither DEC, or wither DEC Under version 1.3 of DTR-32, you could not directly edit domain, record, port, or table definitions. To modify these, you had to EXTRACT/re-DEFINE the entities and then recreate all access list entries. This proved to be a major task when multiple UICs and multiple usernames had different access rights. Some of this has been cleaned up by version 2.0, but the Installation Guide/ Release Notes remains silent on the subject of access lists. DTR works nicely with the new hierarchical dictionary structure that was introduced with the Common Data Dictionary (CDD). Too bad that the DTR user cannot delete directory nodes (even if equipped with the proper access rights). The user must learn to use another package, the DMU (Data Management Utility?). The DTR/CALL interface is a welcome addition. DEC has given the applications designer access to powerful data manipulation facilities. Now if only the temporary ports (created with the "DECLARE PORT") could be defined by referring to existing record definitions, instead of requiring redefinition of current structures. The EDT interface Lurking behind the new DTR and the immediate mode BASIC is the interface to all of EDT. It would sure be nice to have this interface documented (much as the routines to access the SORT and LIBRARIAN utilities are documented). The Common Data Dictionary (CDD) Gone are those happy-go-lucky days under PDP-11 DTR, where any user could create his own private data dictionary, free from the fetters of the corporate schema. Now all must conform, and authority, and access, is handed down from the controller of SYS$SYSTEM:CDD.DIC. It makes private, casual use of DTR a thing of the past. Didn't the illustrations of the new "VAX Information Architecture" show the CDD underlying all layered languages? Where is the FORTRAN access? The COBOL access is a kludge (record structure is picked up at compile time). This compile-time access is ok for static data-structure environments, but if we had static data-structure environments, then we wouldn't need a common data dictionary. Wishful thinking: RTL routines to query/update record structure, perform data file maintenance (redefine record structure, copy data from old-format file to new-format file), ability to treat access list data as ordinary data, et cetera. 5 PAGESWAPPER - October 1983 - Volume 5 Number 4 Whither DEC, or wither DEC Coda Enough of that. We are not about to trade in our system or software for that manufactured by X. Feels good to shake your fist at the sun now and again. INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 197 Caption: Want program for multivariate analysis Message: Wanted: Program for multivariate analysis of categorical dependent variables to run on VAX-11/780. I am searching for an AID, THAID, SI-CHAID-type program to run under VMS on the VAX-11/780. So far I have encountered programs that run only on IBM-compatible machines. We may be able to translate Fortran source code if the details of any IBM-dependent subroutines are specified. Contact: Kathleen McDonnell Academic Computing Center Claremont Graduate School Claremont, CA 91711 (714) 621-8174 Date: August 26, 1983 INPUT/OUTPUT 198 Caption: Lots of Terminals Message: Want to get in contact with anyone who has hooked lots (>64) of active terminals to a VAX (either directly or through a front-end). Also interested in sites with Telenet/Tymnet experience. 6 PAGESWAPPER - October 1983 - Volume 5 Number 4 INPUT/OUTPUT Contact: Don Rubin S. E. T. Incorporated 10676 High Beam Court Columbia, MD 21044 (301) 982-1818 Date: August 30, 1983 INPUT/OUTPUT 199 Caption: Editor for non-DEC terminals -- REPLY TO I/O # 170 Message: We have a screen-oriented text editor that runs under VMS for non-DEC terminals. It can take an optional terminal definition file to alter the input/output protocols. It has been in wide use since 1978. If you want a free copy then call or write to the contact (see below). Sample of terminals supported, ANSI terminals, Hazeltines, LSI ADM3A, Lexidata 2410, HP terminals and many others. Contact: Steven Choy Harry Diamond Labs 2800 Power Mill Road Adelphi, MD 20783 DELHD-IT-R (202) 394-2917 Date: August 31, 1983 INPUT/OUTPUT 200 Caption: Magnetic Tape Software Message: We need a program which will format/write a mag tape in a variety of ways. By this we mean that the tape can be written in ASCII or EBCDIC, any length record, and labeled or unlabeled. We have a VAX 11/750 operating under VMS with a TE16 tape drive. Contact: Bill Jawish 703 Giddings Avenue, Suite U-3 Annapolis, MD 21401 (301) 268-0030 Date: September 8, 1983 7 PAGESWAPPER - October 1983 - Volume 5 Number 4 LUG Meeting Reports LUG Meeting Reports o Rocky Mountain VAX Local Users Group - June 1983 From LUG*NOTES, the RMVLUG Newsletter The meeting was hosted at the Air Force Academy in Colorado Springs. Many Thanks to our Air Force members Don Ravenscroft and Randy Rushe for a terrific meeting room and a grand tour of the Air Force Computing Facilities and Flight Simulation Laboratory!! 1. RMVLUG Business There was a discussion of the economics of LUG newsletter publication and how to pay for it. Ray Bovet noted that RMVLUG elections are scheduled for December and he will be unable to assume the Chairmanship for a third term. 2. Review of Fall 82 Decus VAX Tape 3. Review of PortaCalc - from the Fall 82 DECUS tape Dave Ross (Colorado Air Pollution Control Division) led an in-depth discussion of the PortaCalc spreadsheet software included on the Fall 82 DECUS tape. PortaCalc was originally written in an ancient dialect of FORTRAN (67??) so that it could be ported to a variety of older as well as newer machines. Dave spent many hours repairing the code and modifying routines so that spreadsheet variables do not disappear completely (as they did in the original version!!) Dave concluded that the software now works reasonably well and functions as an OK substitute for the more expensive commercial versions, but that many other modifications could be made to provide additional functions and improve the efficiency of loading/storing spreadsheet variables. He asked for volunteers to help work on future enhancements. 4. Review of Spring DECUS Meeting 5. DEC liaison Report 8 PAGESWAPPER - October 1983 - Volume 5 Number 4 LUG Meeting Reports 6. Airfares to Fall DECUS in Las Vegas (from Rocky Mountain states) (As is usually the case, the above topics were reported in much greater detail in LUG*NOTES, the RMVLUG newsletter from which this outline was taken. I have left out those details which are location-specific or deal with material already covered by other Pageswapper articles.) o BAYVAX LUG (San Francisco area) - August 11, 1983 From VOX VAX, the BAYVAX LUG Newsletter We held our last meeting Thursday, August 11 in the auditorium of Bldg 57 at Lockheed in Sunnyvale. Its a VERY nice facility. Next time I'll get a little less lost in the parking lots. After an introduction for the new attendees, Dave Johnson/Lockheed spent an hour talking about system services and their use. Probably the most used system service is the $QIO and $QIOW. Much of the discussion following the talk was concerned with the IO synchronization mechanisms (AST routines and event flags). Two key items were: 1. The symbolic definitions should always be used and are accessible from the high level languages (INCLUDE '($xxDEF)' in Fortran and the inheritance mechanism in Pascal). 2. Read the manuals paying attention to "address of ..." and "value of ..." since the manuals mean EXACTLY what they say. Following Dave was Julie Nichols/DEC talking about the "All-In-1" software product. It's basically a method for driving layered (and system) software through menus instead of the DCL command language. (Very nice for non-typists!) Following Julie was Ralph Parrish/Lockheed showing how the "All-In-1" has been customized to form the software basis for the Milstar program. We adjourned for lunch at 12:20. A select group returned for a hands-on demo of Ralph's customized "All-In-1" at 1:30. 9 PAGESWAPPER - October 1983 - Volume 5 Number 4 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: PAGESWAPPER Editor, DECUS, MRO2-1/C11, One Iron Way, Marlborough, MA 01752, USA 10 PAGESWAPPER - October 1983 - Volume 5 Number 4 INPUT/OUTPUT Submission Form Tear out to submit an I/O item PAGESWAPPER Editor DECUS, MRO2-1/C11 One Iron Way Marlborough, MA 01752 USA 11 PAGESWAPPER - October 1983 - Volume 5 Number 4 System Improvement Request Submission Form System Improvement Request Submission Form SIG ref no. _________ Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ Circle application area(s) most closely related to yours (OEMs circle end use): Transaction Processing Business EDP (accounting) Program Development Systems Development General Timesharing Student Timesharing Shared Small Applications Shared Large Applications Process Control Word Processing Large Simulation ________________________________________________________________ System Configuration: CPU Model: System Disk: Memory Size: Average User Load: Operating System: Version: ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description (include justification and expected usefulness): Use additional pages if required Completed SIR should be returned to: Gary L. Grebus, Battelle Columbus Laboratories, 505 King Avenue, Columbus, Ohio 43201, USA 12 PAGESWAPPER - October 1983 - Volume 5 Number 4 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories 505 King Avenue Columbus, Ohio 43201 USA 13