PAGESWAPPER Editor's Workfile . . . . . . . . . . . . . . . . . 3 More on VMS Timekeeping . . . . . . . . . . . . . . 3 Just A Modest VMS Proposal . . . . . . . . . . . . . 6 (THE (LINKED LIST)) . . . . . . . . . . . . . . . . 7 AUTOCONFIGURE for the MASSBUS Adapter . . . . . . 18 Bug Fix for SDSU_Ask_List . . . . . . . . . . . . 25 Letters . . . . . . . . . . . . . . . . . . . . . 27 VAX System SIG Committee List . . . . . . . . . . 30 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 33 INPUT/OUTPUT Submission Form . . . . . . . . . . . 43 System Improvement Request Submission Form . . . . 45 PAGESWAPPER - April 1985 - Volume 6 Number 10 General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters. Please do not submit program source, as that is better distributed on the VAX SIG tape. Material for "(THE (LINKED LIST))" section of the Pageswapper (pertaining to Artificial Intelligence) should be sent to: Terry C. Shannon Technical Editor THE DEC* PROFESSIONAL Magazine 921 Bethlehem Pike Springhouse, PA 19477 USA (215)-542-7008 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 USA 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. 2 PAGESWAPPER - April 1985 - Volume 6 Number 10 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor This month we see a new section added to the Pageswapper, produced by the Artificial Intelligence Working Group. A look at the Spring 1985 (New Orleans) symposium schedule will show artificial intelligence sessions sponsored by three different SIGs: Structured Languages, Data Management, and VAX Systems. A working group is the DECUS mechanism for handling a topic which crosses SIG boundaries such as this one. Many who serve on DECUS committees feel that with the growth of interest in artificial intelligence the AI working group will "graduate" to becoming a separate SIG unto itself in the next few years. Such a step, however, requires active volunteer support, so if AI is of particular interest to you support Terry Shannon with your articles and support the AI working group in their other efforts as well. More on VMS Timekeeping E. I. DuPont DeNemours * Company Engineering Department, Louviers Building Wilmington, Deleware 19898 January 29, 1985 Mr. Larry Kilgallen PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 Dear Mr. Kilgallen: Many thanks to Don Golden of Shell Oil for his December 1984 PAGESWAPPER proposal on VMS timekeeping. Now that he has opened the forum for discussion, I would like to add my emphasis as to the nature and seriousness of these problems for those who work in the "read time" world, and to press for a more comprehensive solution. To be frank, this is for us the most severe shortcoming in VMS, and I believe that it causes similar, though perhaps more readily tolerated, difficulties in many other applications. 3 PAGESWAPPER - April 1985 - Volume 6 Number 10 More on VMS Timekeeping Over the past 20 years we have struggled valiantly to overcome these problems at the user level. This has been expensive and not always completely successful. As long as we continue to solve them at the user level, they remain a serious impediment to effective use of DEC's fourth and fifth generation software products in our applications. In order of importance to us, the problems are: o VMS time does not increase monotonically and predictably. It thus cannot be used to: - Determine the initiation of critical control actions at a specific desired time. Foul-ups in this area twice each year (taking a critical action an hour early or late) cannot be tolerated because of their serious safety and economic consequences. - Reliably identify when events have occurred. Foul-ups in this area are tolerated, although they often receive high visibility with plant management. - Index information for fast retrieval by time-of-day. The impact of redundant times in the fall is much worse than the creation of an extra hour in the spring. It can destroy indexing or search schemes in catastrophic ways. - Reliably compute elapsed times for control or for performance evaluation. o VMS time cannot handle users from multiple time zones on the same machine. It is most aggrevating to users in another time zone when they must deal with a foreign time in all their reports, displays, entries, etc. DEC's sensitivity to the needs of a networking product have not extended into this area. o VMS time cannot be displayed unambiguously. I would gladly exchange hundredths of seconds of precision for an EST, EDT, etc. option in the ASCII representation. o Quadword or "date" data types, arithmetic, and indices are not supported uniformly throughout the DEC software product lines. Since time is a key variable in virtually every record of our applications, this is an impediment to taking full advantage of DEC's software products. o Time and delta time (signed or unsigned) formatting options are not varied enough or supported uniformly throughout the DEC software product lines. For 4 PAGESWAPPER - April 1985 - Volume 6 Number 10 More on VMS Timekeeping example, was it a Freudian slip that VMS excludes the possibility of a signed delta time (some organizations actually want to track their overruns on time related goals as well as their underruns)? I support Don Golden's suggestion for a VMS maintained time zone, but hope it could be carried further. It does address the most serious problem of time discontinuity but leads to undesirable anomalies in time translation. For example, immediately after a time zone change, the displayed value of every stored time in the system changes by one hour. You no longer have a reasonable idea of when things really occurred. A solution would be to carry a zone number with each time value so that it could be properly translated for display. Finally, a unique "current zone" could be maintained for each user to be supplied along with VMS time should he request it, or used as the default zone in his time translations. At first glance, it seems that all these features could be made optional and invisible to current applications. I truly believe almost any new application would employ them with delight. We anxiously await full quadword/time/signed delta-time display, arithmetic, and indexing support for such products as FORTRAN, Datatrieve, TDMS and RDB. I have little doubt that there are many more facets to this problem. Let's hear more from you developers and users who have gotten in the habit of cleverly scheduling your vacations to avoid the chaos and confusion that follow time zone changes. Yours truly, DESIGN DIVISION Control Systems Section L. E. DeHeer Senior Consultant 5 PAGESWAPPER - April 1985 - Volume 6 Number 10 Just A Modest VMS Proposal Just A Modest VMS Proposal James Downward KMS Fusion, Inc P.O. Box 1567 Ann Arbor, Mich. 48106 (313)-769-8500 At the Spring DECUS meeting, we are again going to have a session called "Just a Modest VMS Proposal". This letter is a call for VMS users to participate in this session. At the Fall Symposium this session was very popular so additional time is being allocated this time for users to make their "Modest Proposals". The abstract for this session is as follows. Let's face it, at one time or other each of us has thought (privately, to be sure!) that DEC did it all wrong, or really doesn't understand the needs of our particular interest group, or is missing the opportunity for a great product (hardware/software). Well, here is your chance to present to DEC and the VMS community Your Very Own Modest Proposal. Proposals should be limited to about 5 - 10 minutes in length. Viewgraphs, slides, movies or any other presentation aid are encouraged. The entries may be serious, or not so serious. A distinguished panel of DEC Developers, Product managers and the attendees will judge the proposals in three categories; 1)"Noted" ie DEC likes it, 2)"UPG" ie DEC deserves it, 3) "Potential for Cult Following" ie the VMS community likes it. The session is not designed to be a "gong" show, or a forum for beating up on DEC. It is, however, a chance for those of us who must exist in a Love/Hate relationship with VMS, to present those "If only...." ideas, or perhaps some thoughts that gently poke fun DEC (Better yet both!). For those of you who have well thought out SIR's or product requests and would like to make a sales pitch to users and DEC alike, here is your chance! A good idea together with a clear presentation and good graphic aids can make a significant impact on DEC and the SIG. The success or failure of this session, is up you. I have a few ideas (some serious, some funny) but certainly not enough to fill up a session. 6 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) (THE (LINKED LIST)) The Newsletter of the DECUS AI Working Group ...it's the real thing From the Editor Artificial intelligence, the science of making machines mimic intelligent human behavior, has been the subject of dreams, speculation, and prophecy since ancient times. From the talking statues of Greek mythology and the intricate clockwork automata of the 18th century through today's chess-playing programs, expert systems and supercomputers, man has utilized the resources at his disposal in a continuing effort to create machines in his own image. While AI as we know it today is still a youthful science, it has already evolved through a genesis replete with lofty promises, a "dark ages" phase of doubt and disrespect, and a renaissance heralded by by such unlikely journalistic organs as weekly news magazines, business journals, and the mass market press. It almost seems that as it AI has fallen victim to media hype. If you run a frequency count on the buzzwords in software advertising, you'll likely find that AI has replaced "user-friendly" as the Madison Avenue cliche of choice. I am firmly convinced that AI will enjoy a bright future and that it's destined to play a growing role in our lives. But I feel compelled to temper this prediction with reason: artificial intelligence is neither panacea nor cure-all. If you approach the subject objectively and take all the hyperbole with a grain of salt, you'll find AI to be an extremely interesting facet of computer science. On the other hand, if you accept the predictions of self-appointed AI "experts" at face value, it is likely that your opinion of AI will soon become tarnished. My objective in editing (THE (LINKED LIST)) is to provide a forum for those of us interested in AI to exchange useful and credible information for mutual benefit. While I want this newsletter to be characterized by its absence of the hype and off-the-wall predictions of AI charlatans, I feel that it's still possible to produce a publication that's entertaining, informative, and thought-provoking. Future editions of this newsletter will test the validity of my philosophy. I look 7 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) forward to seeing (THE (LINKED LIST)) meet its avowed goals and hope that you will, too. - Terry C. Shannon A Brief History of the Decus AI Working Group The DECUS AI Working Group was conceived by our chairman, David Slater, in response to a growing interest in AI among DECUS members. The working group was created as a result of an informal meeting at the Spring Symposium in Cincinatti last June. At that time we gave some consideration to publishing a newsletter, but decided to bide our time and see if the interest in AI was merely a flight of fancy. (As we all know, ideas spawned with the best of intentions at DECUS symposia are often forgotten once the symposium is over and we return to the real world.) Our activities during the summer and fall were limited to the dissemination of an AIWG questionnaire and a few brief discussions between Dave Slater and myself. However, the AIWG reconvened in Anaheim with an expanded knowledge base: there were significantly more attendees at the Anaheim meeting than at the session in Cincinatti. One of the key decisions that emerged from Anaheim was a resolution to produce this newsletter, so apparently AI is not just a passing fancy among DECUS members. Another decision we had to contend with involved the structure, organization, and scope of our group. Ideally, we would form a SIG, found an independent newsletter, and do our own thing. Despite these admirable goals, logic dictated that we continue to posture ourselves as a working group, and make use of the PAGESWAPPER as a vehicle for our newsletter. Our long-term goals include attaining SIG stature and publishing our own stand-alone newsletter, but we won't even contemplate such expansion until we have an adequate base of involved users. So that's where we've been, where we are, and where we hope to go. Your input and commitment are critical to the success of our group, so if AI is one of your interests, please get involved and help. If you don't know what you can do to help, you can get some good ideas by reading the following article. 8 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) GET INVOLVED IN THE AIWG As newsletter editor, I find this plea for assistance to be both self-serving and necessary. I need your ideas, suggestions, and input (spell that ARTICLES!!!) to edit and produce a useful, informative newsletter you'll look forward to reading every month. If you don't fancy yourself as a writer, make a submission anyhow. Having worked as a writer and editor for some time, I'm convinced that just about any manuscript with intrinsic value can be salvaged. If you are willing to make a submission, I'm willing to live up to my end of the bargain by correcting, editing, and otherwise polishing up your article. The AIWG can use articles on virtually any aspect of AI. Whether you can contribute a book review, AI meeting or convention announcement, hint, trick, program or application, (THE (LINKED LIST)) can use it. If you have authored an article that has already appeared in another publication, don't let this dissuade you from submitting your work to this newsletter. There's a lot to be said for originality, but the primary goal of the newsletter is to disseminate information. If you do submit a published article, please include relevant information so we can give credit where credit is due. If writing definitely is not one of your strong suits, you might want to consider some of the following ideas. NEWSLETTER TITLE Two titles for this newsletter were suggested during the Anaheim symposium, The Inference Engine and (THE (LINKED LIST)). We decided to grace our newsletter masthead with the latter title until someone comes up with a better suggestion. If you have a knack for names and can suggest a more appropriate title, you can enter our "Name The Newsletter" contest. Prizes have yet to be determined, but they will certainly include accolades from the DECUS AIWG. LOGO Not the programming language, but graphics. No self-respecting DECUS group should be without an official logo, and the AIWG is no exception to this rule. Cats, wombats, cavemen, and dragons are already spoken for, but you are limited only by your imagination. The only suggestion to date is a rendition of "The Thinker". Sculptor Auguste Rodin would be delighted, but perhaps you have a better idea. If so, we'd like to hear from you. 9 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) QUOTE OF THE MONTH To amuse and edify our readers, we are instituting a "Quote Of The Month" contest. If you know of an AI-related pearl of wisdom, pithy aphorism, or concise epigram, by all means pass it along. We owe this month's submission, which would give a natural language parser a case of terminal insanity, to Dave Slater. While visiting Ocean City, he noticed the following cautionary message posted on a sign: WARNING SPLINTERS WEAR SHOES Miscellaneous We will consider, and can use help with, anything not mentioned in the foregoing paragraphs. You can send your submissions to me electronically (SHANNON on DCS, or contact me for details on dialing into my PDP-11 or VAX) or through the U.S Postal Service. My business address is: Terry C. Shannon Technical Editor THE DEC* PROFESSIONAL Magazine 921 Bethlehem Pike Springhouse, PA 19477 (215)-542-7008 Book Review Department The following review is quite exhaustive, but my indolent nature precluded me from pruning it down to size. However, I promise to provide less verbose reviews in upcoming issues of (THE (LINKED LIST)). 10 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) MACHINES WHO THINK By Pamela McCorduck W.H. Freeman and Company 660 Market Street San Francisco, CA 94104 375 pages Price $10.95 MACHINES WHO THINK provides a well-written, understandable introduction to the branch of computer science known as artificial intelligence. Though written in 1979, this book provides a timely overview of the historical aspects of AI and people involved with it, as well as some examples of current implementations of the science. The book begins by outlining some early attempts to produce machine intelligence, such as the statues and automata commom in Greek mythology. Later in history, we are introduced to Pope Sylvester II, a medieval pontiff who was alleged to have contrived a statue with a talking head. Still later, in 1580, we learn of Joseph Golem, the creation of one Rabbi Judah ben Loew. Rabbi Loew's artificial man was contrived out of clay dug from a riverbank. Subjected to the appropriate prayers and incantations, the robot assumed life and went about its business of spying on Gentiles and performing custodial duties in the temple. However, problems soon arose - the golem would carry out only those orders given by the Rabbi. If someone else were to tell the golem to do something, the results were unpredictable. Finally, the rambunctious robot attacked its creator, who promptly brought its life to a halt. McCorduck then relates tales of other automata which appeared in the 16th century and beyond. Vaucanson's mechanical duck is discussed, as well as some outright frauds like Von Kempelen's chess-playing Turk, an android costumed in the garb of a turk that sat at a chess table. Beneath the chess table was the mechanism that ran the android. (Not surprisingly, this mechanism turned out to be a human accomplice to the hoax.) The mechanical Turk was celebrated throughout Europe, and was reputed to have bested Napoleon in an 1809 chess match. In 1854, a fire in a Philadelphia hotel abruptly checkmated the Turk. Chapter 2 deals with the philosophical and psychological aspects of AI pertinent to information theory. Crucial to the development of information theory is a good grasp of intelligence - what it is, how to quantify it and what to do with it. Enter Binet and the concept of IQ, and the Gestalt psychologists. By the conclusion of the chapter, you'll have received a broad introduction to information theory and its importance as an underlying concept of AI. Chapter 3, "The Machinery of Wisdom," exposes the reader to more 11 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) contemporary AI figures, including Leonardo Torres y Quevedo, a member of Spain's Royal Academy of Sciences who devoted himself to the construction of automata. Torres postulated an advanced automata with sensory organs and limbs that would be capable of making decisions. However, Torres, like Babbage before him, was unable to manufacture his automata using the engineering principles available in his time. McCorduck next turns to Alan Turing and the Automatic Computing Engine he attempted to develop, as well as his paper, "Intelligent Machinery." John von Neumann's efforts at formalizing intelligent behavior are also analyzed in this chapter. The attention given to these early researchers helps put things into proper perspective, and allows the reader to move easily into the next chapter, "Meat Machines". Therein is a discussion of researchers like Marvin Minsky, Martin McCulloch, Ross Ashby, Frank Rosenblatt and Donald MacKay, all of whom labored to produce machines that could think by imitating the human brain. Chapter 5 recounts the birth (renaissance might be a more appropriate phrase) of AI as we now know it at the Dartmouth Conference. This conference was a Rockefeller Foundation-funded study of artificial intelligence which brought together AI notables including John McCarthy, Marvin Minsky, Nathaniel Rochester and Claude Shannon. The conference, which marked the coining of the term "artificial intelligence" is recalled in detail, as are some of the developments that the project germinated. The next chapter studies the early AI research at the RAND corporation. Two of the leading players in the RAND scheme of things, Allen Newell and Herbert Simon, are introduced and their accomplishments in the field of AI are explored in depth. We next meet J.C. Shaw, a RAND programmer, and are shown the results of collaboration between Shaw and the team of Newell and Simon. These results included the concept of list processing, critical to success of the Logic Theory Machine, the first program to lend credence to AI as a viable science. Chapter 7, "Fun and Games," looks at some of the game playing programs and machines of the late 1950's. Checkers was the first game to be computerized, and the author paints a vivid picture of CPUs rolling off the IBM assembly line, playing ghostly games of checkers with their programmers. IBM soon squelched this gameplaying, lest customers labor under the misapprehension that the big, dumb, fast morons marketed by Big Blue could do anything more than follow rote instructions. Chapter 8, "Us and Them," details the beginnings of resistance and mistrust about AI. It seems that there were far more people who were willing to argue against machine intelligence than there were AI proponents. The chapter sorts these anti-AI arguments into categories of emotion, insuperable differences, 12 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) no existing examples, and ethical considerations. Each argument is elaborated on in detail. Armed with this philosophical background, you are ready to forge into Chapter 9, which features AI as voodoo and its practitioners as charlatans. "L'Affaire Dreyfus" introduces Hubert Dreyfus, one-time AI consultant to the RAND Corporation and author of "Alchemy And Artificial Intelligence" and "What Computers Can't Do; A Critique of Artificial Reason." Dreyfus became firmly convinced that, in the end, AI would never work. Entirely correct in his contentions that the blue-sky predictions about AI made in 1957 would not be realized a decade later, the man appears to truly enjoy subjecting AI to ridicule. If you read the remainder of the book, you'll begin to harbor some doubts about who will laugh last. Chapter 10 explores robotics and general intelligence. The LISP programming language is introduced, as is its author, John McCarthy. The GPS, or General Problem Solver, program dedicated to solve nonspecific problems is discussed. (The GPS is critical to AI because of the importance of problem resolution as a facet of AI programming.) The remainder of the chapter deals with early robotics projects, programs that pass the Turing Test, acquisition of knowledge and sensory data, vision processing and other AI subdisciplines needed to produce a useful robot. Chapter 11, "Language, Scenes, Symbols and Understanding," delves into these aspects of humanity which make us unique, and efforts that have been made to mechanize them. Natural language processing, machine vision, scenes and symbolic knowledge representation are all necessary attributes of an intelligent machine, and McCorduck looks at what has been done in this regard. Chapter 12 addresses applied artificial intelligence - putting AI to work in the real world. Included is a discussion of DENDRAL, an intelligent chemist's assistant which is adept at interpreting data from a mass spectroscope. DENDRAL was one of the first expert system programs, a forerunner of knowledge-based systems like DEC's XCON that are in widespread use today. This takes us to 1979, the year "Machines Who Think" went to press. The remainder of the book deals with the future of AI. While the book is six years out of date, the philosophical implications expressed in the final chapters are still timely today. Chapter 13, "Can a Made-Up Mind Be Moral," asks if we really can create artificial intelligence, and "if we can, should we?" The ethics and moral issues surrounding AI are explored in detail, giving you something to think about long after you have finished the book. The final chapter of the book, "Forging The Gods," examines the scientific claim that is the crux of AI. The contention that AI demonstrates how symbols can be embodied in a physical system, 13 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) thereby serving as a key to the understanding of the mind, is dealt with objectively and in an unprejudiced manner. Finally, the author contrasts AI with art, and proposes that AI is a link between science and art. I'll leave that validity of that proposition up to you. I found "Machines Who Think" to be a well-researched and well-written introduction to AI. If you're new to the field of AI and want an engrossing, digestible introduction to the historical aspects of artificial intelligence and the people who made it possible, "Machines Who Think" belongs on your bookshelf. DEC'S AI TECHNOLOGY CENTER Perched atop a hill just outside of Hudson, Massachusetts is an imposing three-story concrete structure known as the Digital Artificial Intelligence Technology Center. This unique facility is a manifestation of DEC's increasing reliance on AI techniques for the resolution of real-world problems faced both internally and by its customer base. Here's a first-hand look at how a closely-knit group AI researchers and one of their projects reflect the Digital approach to practical artificial intelligence. The AI Technology Center represents a milestone in Digital's internal AI research and development efforts. The building houses well over 100 AI specialists, all of whom are dedicated to developing AI products that can solve problems for end users and DEC alike. In this regard, the center is a one-of-a-kind facility. While the bulk of AI research in academia is devoted to devising esoteric solutions for which no problems exist, the people at the Technology Center are developing creative solutions to real-world problems faced by DEC and its customers each day. BEGINNINGS DEC's commitment to AI began some six years ago when Dennis O'Connor, a DEC group manager, happened to meet Professor John McDermott of Carnegie-Mellon University. O'Connor was looking for a method to increase the speed and accuracy of VAX system configuration. McDermott, author of the LISP-based OPS production system language, was searching for a problem that an expert system written in OPS could solve to prove the viability of commercial expert systems. This chance meeting resulted in a collaborative effort that culminated in the development of R1, an expert system that configured VAX systems from customer orders. R1, later renamed XCON, or eXpert CONfigurer, proved to be so 14 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) cost-effective that DEC decided to become more deeply involved with AI, intending to use AI techniques to resolve other business problems. DEC was eminently qualified to sponsor a large scale internal AI program because it already had the necessary hardware and human resources at its disposal. A wealth of AI expertise was concentrated among a small group of DEC employees, and the firm's DECsystem mainframes and VAX superminicomputers had become the computer systems most frequently used in AI research. GOING PUBLIC The potential of commercial AI was not lost on DEC. Corporate decision makers felt that products that employed AI techniques to solve problems for end users were feasible. More importantly, commercial AI was a logical follow-on to an extensive internal AI program. The lessons learned on internal projects could be applied to products developed for the commercial market, and the sales of such products would help offset the considerable expense of an ongoing in-house AI program. It was obvious that AI applications could be designed and implemented most efficiently if the effort was conducted from a centralized location. Accordingly, the AI Technology Center was conceived, designed, and formally opened in January, 1983. Since that time, the Hudson facility has been the focal point for DEC's AI research, development, and marketing. DEC'S AI TRIAD The DEC AI center is home to three teams of employees, each devoted to a different aspect of artificial intelligence. The AI Marketing Group is responsible for the promotion and distribution of DEC's commercial AI products such as the Common LISP and OPS5 programming languages. By the time this article appears in print, DEC Rainbow users should be able to obtain Golden Common LISP, a subset of Common LISP jointly promoted by Gold Hill Computers of Cambridge, Massachusetts and the AI Marketing Group. Expected in the near future from the Marketing Group are a VAX implementation of PROLOG and OPS5 Plus, a fully supported version of OPS5. The mission of the AI Engineering Group involves the development and implementation of new AI applications both internally and for the commercial market. DEC is understandably evasive about future AI product offerings, but likely candidates are a software tool for building expert systems, an intelligent natural language front-end to the VMS DCL interpreter, and possibly an expert system manager's assistant that utilizes data 15 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) collected by VAX SPM to tune VMS for optimum performance. The Intelligent Systems Technology Group devotes its efforts to manufacturing-oriented issues. Products under its aegis include expert systems like XCON, XSEL, and XSITE. This element of the AI triad is also responsible for expert systems that help manage production and material requirement planning. A CASE IN POINT The AI application most frequently associated with Digital is the XCON expert system mentioned earlier in this article. One outgrowth of XCON is XSEL, an expert sales assistant. Although XSEL is derived from XCON, there is an important difference between these two expert systems. XCON handles the entire job of configuring a VAX from a customer order, but XSEL functions as an assistant or aide to a sales representative. Continual interactive dialogue between the expert system and its user is required to generate an error-free customer order with XSEL. Through this dialogue, a DEC sales representative can help a prospective VAX customer select the CPU, memory, and peripheral options that meet his or her needs in the most cost-efficient manner. When XSEL is invoked, it prompts its human counterpart to input factors including memory requirements, disk storage capacity, the desired number and type of terminals, and any layered software products the customer might desire. Once this information is loaded into XSEL's memory or knowledge base, the program manipulates this data, performs substitutions where appropriate, and generates a suggested system configuration. XSEL represents the codification of the heuristics, or rules of thumb and problem solving techniques, of DEC's most experienced salespeople. As such, it permits a novice sales representative to perform at the level of a veteran who has been writing VAX customer orders for years. In addition to reducing the error rate on VAX orders significantly, the expert system has several ancillary functions. It will generate a suggested floor plan for the new site, taking into consideration the minimum allowable clearance between cabinets, the distance at which each component must be placed from a wall or other obstacle to permit free access by Field Service personnel, and constraints of the "don't put a line printer next to a disk drive" variety. XSEL also knows about the power and heat dissipation requirements for VAX components, so it can provide data useful to engineers responsible for sizing the computer room power supply and air conditioning systems. Finally, while XSEL isn't subject to salary reviews, it does ask its users to evaluate its performance on a scale of one to 10. A score of one or two elicits no response from XSEL, but if you award the program a score of three or better it terminates with a "thank you" 16 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) message. A MATTER OF PHILOSOPHY Initially written in OPS, XSEL now consists of modules coded in seven different programming languages including BASIC, C, FORTRAN, and PASCAL. Each language is chosen for its performance and efficiency, underscoring DEC's approach to AI. AI techniques are used where appropriate to resolve problems considered intractable through the application conventional programming languages and methods, not as window dressing or AI for AI's sake. It is of no consequence to DEC - or an end user - whether an expert system subroutine is written in an AI language or a conventional high-level language. A routine that executes slowly in OPS but rapidly in FORTRAN is implemented in the traditional language. If LISP or OPS provides the most feasible solution to the problem, then DEC's knowledge engineers will deal with the problem from an AI standpoint. THE HUMAN FACTOR DEC has been careful not to overlook the human resources aspect of artificial intelligence. Not a single employee has lost his or her job because of the integration of AI into the workplace. Instead, AI has enhanced the work environment by automating tedious, repetitious tasks, freeing employees to devote themselves to more creative enterprises. The increased emphasis on AI has also resulted in a new career field, knowledge engineering. A company-wide program has been introduced to recruit and train selected Digital employees as knowledge engineers. Each knowledge engineering candidate attends a 14-week course of instruction that concentrates on AI languages and tools, problem solving techniques, program management, and interpersonal communication skills. After completing the rigorous 14-week formal training program, graduates serve as knowledge engineering apprentices within DEC. In this capacity, they work on "live" expert systems under the stewardship of senior knowledge engineers. A few of the most promising students are sent to universities like Carnegie-Mellon and MIT to serve internships under the supervision of faculty members. By the end of the training and apprenticeship program, each candidate is a full-fledged knowledge engineer. He or she knows how to obtain knowledge from human experts and code this information into expert systems that use AI techniques to resolve problems deemed intractable through conventional programming languages and techniques. 17 PAGESWAPPER - April 1985 - Volume 6 Number 10 (THE (LINKED LIST)) A LOOK AHEAD In the synergistic environment of the Technology Center, AI is not a solution looking for a problem. DEC's Hudson employees don't work in the ratified atmosphere of the abstract or theoretical - instead, they combine classical programming with the latest AI techniques to provide practical, viable systems that best meet the needs of DEC and its customers alike. User-oriented expert systems like natural-language command interpreters and intelligent word processors are not yet available, and AI system tuners are still a novelty, but it's certain that these applications will enjoy widespread use within the next several years. By the end of the decade, your DEC computing environment will be substantially enhanced through the collective efforts of DEC's Artificial Intelligence Technology Group. Editor's Note: This article first appeared in the April, 1985 issue of THE DEC* PROFESSIONAL Magazine and is reprinted with the permission of the publisher, Professional Press. That's it for the first issue of (THE (LINKED LIST)). We hope you have enjoyed this newsletter and look forward to receiving your contributions, articles and letters to the editor. Be on the lookout for more news from the DECUS Artificial Intelligence Working Group in upcoming issues of THE PAGESWAPPER. .require 'FICHE' page AUTOCONFIGURE for the MASSBUS Adapter VAX Systems SIG Internals Working Group B.C. Dow-Pleines CALMA/GE 525 Sycamore Drive Milpitas, CA 95035 One of the most interesting features of a VAX system running VMS is the ability to add a disk drive and reboot the system without a major system generation (sysgen). This concept of the five minute sysgen sold me on a VAX. On other computers, to add a drive requires a sysgen be performed which will take hours, days, even weeks before it runs correctly. Many a grey hair has been created, and loads of horror stories on sysgen mistakes exists. So how does VMS do it? 18 PAGESWAPPER - April 1985 - Volume 6 Number 10 AUTOCONFIGURE for the MASSBUS Adapter First, you must understand what a device system generation is. It basically defines for the operating system a set of tables containing information about the devices on the system. For example, on the HP 1000 system, the operating system must be told how to divide the disk up into user areas called cartidges. Fortunately, VMS is not as restrictive. VMS also does not require the user to create a system generation file each time a device is loaded. Instead, if the person is just adding a DEC device, specifically a drive, then only a reboot is required along with a few commands to access the drive. The code that performs the system generation type of activities on VMS is extensive and therefore cannot be covered in just one paper. The area of the sysgen that will be covered in this paper is Autoconfigure. Autoconfigure is the code that is run to locate devices which reside on what are called adapters. There are four Dec supported adapters, they are the Massbus, Unibus, CI, and the DR. For each adapter, there is a separate piece of code to determine what devices are hooked up to it. The data structures are an important part of every piece of VMS code. Often it seems that understanding the data structures means that 90% of the effort of understanding the code has already been expended. Several of the main structures used in autoconfigure are shown below. ACF$AB_ADPTYPE: ---------------------------------------- |ACF$UBA (longwd) | AT$UBA (word) | ---------------------------------------- |AT$MBA (word) | ACF$UBA (longwd) | ---------------------------------------- | ACF$MBA (longword) | ---------------------------------------- |ACF$DR (longwd) | AT$DR (word) | ---------------------------------------- |AT$CI (word) | ACF$DR (longwd) | ---------------------------------------- | ACF$CI (longword) | ---------------------------------------- indicates end of table > | 0 (word) | ---------------------- CONFIGURATION CONTROL BLOCK (ACF) ---------------------------------------------------------------- | ACF$L_ADAPTER | ---------------------------------------------------------------- | ACF$L_CONFIGREG | ---------------------------------------------------------------- | ACF$B_AFLAG |ACF$B_AUNIT | ACF$W_AVECTOR | ---------------------------------------------------------------- | ACF$L_CONTROLREG | ---------------------------------------------------------------- | ACF$W_CUNIT | ACF$W_CVECTOR | 19 PAGESWAPPER - April 1985 - Volume 6 Number 10 AUTOCONFIGURE for the MASSBUS Adapter ---------------------------------------------------------------- | ACF$L_DEVNAME | ---------------------------------------------------------------- | ACF$L_DRVNAME | ---------------------------------------------------------------- | ACF$B_COMBO_VEC|ACF$B_CNUMVEC| ACF$W_MAX_UNITS | ---------------------------------------------------------------- | unused |ACF$B_NUMUNIT |ACF$B_COMBO_CSR | ---------------------------------------------------------------- | ACF$_DLVR_SCRH | ---------------------------------------------------------------- The autoconfigure code is called with the address of the CSR - Control Status Register, ACF - Configuration Control Block, and the ADF - Adapter Control Block for what could be a known adapter. The code checks this adapter against the known adapters. If it is a MBA, UBA, CI, or DR then three fields of the configuration control block are initialized and processing continues, eventually leading to the adapter specific code. The fields of the ACF table that are filled in are shown below. ---------------------------------------------------------------- | ACF$L_ADAPTER | ---------------------------------------------------------------- | ACF$L_CONFIGREG | ---------------------------------------------------------------- | | | ACF$W_AVECTOR | ---------------------------------------------------------------- | | ---------------------------------------------------------------- | | | ---------------------------------------------------------------- | | ---------------------------------------------------------------- | | ---------------------------------------------------------------- | | | | ---------------------------------------------------------------- | unused | | | ---------------------------------------------------------------- | | ---------------------------------------------------------------- So far less than a third of the ACF block has been constructed. More items are entered in the table by the adapter specific code, and the device specific code. To enumerate the details for every adapter would require a book, therefore I am going to only describe the details for the MASSBUS adapter. (Perhaps later I'll do the UNIBUS, if there is a demand for it.) 20 PAGESWAPPER - April 1985 - Volume 6 Number 10 AUTOCONFIGURE for the MASSBUS Adapter Before the MASSBUS code looks for the device type, the number of controller vectors is set to one in the field ACF$W_CNUMVEC. The next step in the code is to obtain the device specific information from the MBA table. The table contains the device descriptor, device driver descriptor, device types, and the pointers to the descriptors for four types of devices, DB (RP0X DISK DRIVES), DR (RM0X DISK DRIVES), MF (TU78 DISK DRIVES, TM78 CONTROLLER), MT (TU77 TAPE DRIVES, TM03 CONTROLLER). The table is searched device definition by device definition to find a match with the current device under consideration. A zero at the end of the table indicates the search is to be ended. One of the curious items about the MBATABLE is the order in which it is arranged. The order of the table is: DB (RP0X) devices first, then DR (RM0X) devices, then MT (TM03 Controller, TU77 tape drive), and finally the MF (TU78 tape drive) devices. Since a sequential search is used, the devices that are most likely to be on the MASSBUS should be placed first in the table, and the least likely devices to be found should be placed last in order to save search time. Because of the order DEC has used, I wonder if there are more RP0X drives out there than there are RM05 and RM03's? Not that the order is really important since the time savings of rearranging the code are probably negligible. A portion of the MBATABLE for the DB devices is shown below. ACF$AB_MBATABLE: (DB device entry only ) ---------------------------------------- ---------|POINTER TO DEVICE NAME DESCRIPTOR | | ---------------------------------------- | |POINTER TO DRIVER NAME DESCRIPTOR |-- | ---------------------------------------- | | | HEX DEVICE CODE | HEX DEVICE CODE | | | ---------------------------------------- | | | 0 | HEX DEVICE CODE | | | ---------------------------------------- | -------> | .ASCIC \DBA\ | | ---------------------------------------- | --->| .ASCIC \DBDRIVER\ | < | ---------------------------------------- ---<| RESET POINTER | ---------------------------------------- The next action to occur is the filling in of more of the ACF fields and the search for devices on the bus. This part of the code is particularly interesting. The ACF fields DEVNAME, AND DRVNAME are filled in with the addresses of the device and driver descriptor of the "current device type" being examined in the MBATABLE. This does not imply that a device of that type 21 PAGESWAPPER - April 1985 - Volume 6 Number 10 AUTOCONFIGURE for the MASSBUS Adapter has been found. Instead, these fields are probably filled in now because it is easier to move the data when it is currently being pointed to rather than going back for it at a later time. For example, if the current location points to the DB device then the addresses of the DB devname, and DB drvname descriptors are loaded into the ACF. ---------------------------------------------------------------- | ACF$L_ADAPTER | ---------------------------------------------------------------- | ACF$L_CONFIGREG | ---------------------------------------------------------------- | | | ACF$W_AVECTOR | ---------------------------------------------------------------- | | ---------------------------------------------------------------- | | | ---------------------------------------------------------------- | Address of .ASCIC \DBA\ descriptor | ---------------------------------------------------------------- | Address of .ASCIC \DBDRIVER\ descriptor | ---------------------------------------------------------------- | | | | ---------------------------------------------------------------- | unused | | | ---------------------------------------------------------------- | | ---------------------------------------------------------------- Next the words that indicate the device types in the MBATABLE are compared with the contents of the drive type register for a match. If there is a match then we have found a device of that type. If there is no match then one of several events could have occurred. First, there could be a non-existent device in which case the code tries to seize the port and read the device type register again to verify the existence or non- existence of a device. In this event, either a device is found, or the code gives up on the current non-existent device and branches back to start looking for another device starting with the beginning of the MBATABLE. The second case is when the current word device type value from the MBATABLE does not match the device type value we are looking for in the device type register. In this instance the code looks at successive device types in the MBATABLE until it either finds a type that matches, or it finds a word with the value of zero. A match means we have found the device type. If it finds a zero, then the search is done and the conclusion is that this device is not the type currently being examined in the MBATABLE. Processing begins again with the next device type entry in the MBATABLE. The third case is when it eventually runs out of 22 PAGESWAPPER - April 1985 - Volume 6 Number 10 AUTOCONFIGURE for the MASSBUS Adapter device types. Here the code just falls through and processing branches back up, almost to the beginning, to look for more units. Once the device type has been identified as either a tape drive or a disk drive, the code branches to a region for that device. For a disk drive, more of the fields of the ACF block are filled in. The ACF$L_CONTROLREG field is filled with address of the CSR - Control Status Register. The ACF$B_AUNIT field is filled in with the adapter unit number, and the ACF$W_CUNIT is filled in with the controller unit number. The rest of the fields are filled in elsewhere in VMS. Below is the ACF block with the entries so far filled in by the code. ---------------------------------------------------------------- | ACF$L_ADAPTER | ---------------------------------------------------------------- | ACF$L_CONFIGREG | ---------------------------------------------------------------- | |ACF$B_AUNIT | ACF$W_AVECTOR | ---------------------------------------------------------------- | ACF$L_CONTROLREG | ---------------------------------------------------------------- | ACF$W_CUNIT | | ---------------------------------------------------------------- | ACF$L_DEVNAME | ---------------------------------------------------------------- | ACF$L_DRVNAME | ---------------------------------------------------------------- | | | | ---------------------------------------------------------------- | unused | | | ---------------------------------------------------------------- | | ---------------------------------------------------------------- The tape drive code is similar to the disk drive code except for two things, the examination for slave tape drives, and the TM78 controller. The TM78 controller appears to be a strange beast. Almost immediately into this portion of the code the registers are tested to determine if the tape drive has a TM78 controller (TU78 tape drive), and if so a branch is taken to handle that controller. For non-TM78 controllers the ACF$B_AUNIT (adapter unit number) field, and the ACF$L_CONTRLREG fields are loaded first. One of the differences between the tape drive code and the disk drive code is the contents of the ACF$L_CONTROLREG field. If the device is a tape drive it contains the address of the device control register, whereas for disk drives it contains the address of the CSR. 23 PAGESWAPPER - April 1985 - Volume 6 Number 10 AUTOCONFIGURE for the MASSBUS Adapter Next, the code looks for slave tape drives. The count of the number of slaves tape drives is contained in the ACF$W_CUNIT field. They are searched for in a loop structure, each time one is found, the ACF$_CUNIT field is loaded with the current value for that drive. So at the end of the looping phase the control unit for the last drive found is stored in that field. The rest of the fields in the ACF block are filled in elsewhere. For the TM78 controller, the flow of code starts out the same. The ACF$B_AUNIT field, (the adapter unit field), and the ACF$L_CONTRLREG fields are also loaded into the ACF block in the beginning stages. The next field to be filled in is the ACF$W_CUNIT field, which also contains a count of the slave tape drives. Finding the slave tape drives for the TM78 controller is interesting. It appears that talking to this device and getting its attention is a time consuming process. The first thing the code does is to reset the controller. To do this, the code enters a loop, waiting 250 times, for the reset operation to start. Once the reset operation starts, the code enters a loop, waiting up to two million times for the operation to complete. Once the device is ready the hunt can begin for slave tape drives. To find a slave tape drive, requires looking for the attention bit to be on after accessing the drive. This involves clearing the attention bit, setting up the device to communicate with the system, and then testing for communication on the massbus and drive registers. If communication is successful then a slave drive is present and the ACF$W_CUNIT field is loaded with the controller unit number for the current slave tape drive. If a device is not found the code will eventually fall through and perform clean up operations. And that is the end for the MASSBUS Autoconfigure code. In summary, VMS finds devices by examining the tables for each device, and the associated data structures for those devices. If the code does not recognize a piece of hardware, or a foreign adapter, it continues on, in some cases it puts out an error message. If the code recognizes the device it fills in the ACF block and starts looking for the next device. All in all it is a nice piece of code, and I'd like to thank the developers for it. I never did like doing sysgens. 24 PAGESWAPPER - April 1985 - Volume 6 Number 10 Bug Fix for SDSU_Ask_List Bug Fix for SDSU_Ask_List C.W.Holeman University Computer Center San Diego State University San Diego, CA 92182 31-Jan-1985 SDSU_AskLib is a newly submited package to the DECUS Library (VAX-106). This is a fix for a bug in the SDSU_Ask_List routine. Near the end of the file ASKLST.FOR comment out the two lines as follows: if (ichar(default_allowed)) then type*, 'Default: ', default_string * else if (temp_str(:len(HELP)) .eq. HELP) then * type*, 'Default: ', default_string end if call sdsu_ask__eofhelp (prompt) end if end do return return_point end 25 PAGESWAPPER - April 1985 - Volume 6 Number 10 Bug Fix for SDSU_Ask_List Abstract for SDSU_AskLib SDSU_AskLib is a collection of VAX-Fortran routines that can be used in interactive programs to prompt a user for input, accept user input, and check the validity of user responses. The routines handle additional details such as converting input, displaying error messages, reprompting and looping, processing nested input files and, if enabled, logging input to a journal file. Exact prompts, criteria for determining the validity of user responses, whether defaults are allowed or input is required from users, whether users can backup to previous questions, and whether the program can be exited early are specified by the programmer through the calling arguments. There is a separate routine for each of the following data types and entry formats: string, real, integer, yes/no, table of reals, file name, list of choices, angle (including longitude/latitude), and phone number. The following is an example program that uses two of the routines: real gpa integer units 10 type*, 'Computes grade points from GPA and units.' 20 call sdsu_ask_real ( . '$Enter GPA: ', !Prompt user with this. . 0.0, !Minimum value user can enter. . 4.0, !Maximum value user can enter. . 'N', !Default not allowed (input required). . gpa, !Variable to receive user's valid input. . *10, !Previous question label. . *999) !End of input label. call sdsu_ask_integer ('$Enter units attempted: ', . 1, . 500, . 'N', units, *20, *999) type*, 'Grade points =', units * gpa 999 end 26 PAGESWAPPER - April 1985 - Volume 6 Number 10 Letters Letters March 31, 1985 Lawrence J. Kilgallen Editor, The Pageswapper Box 81, MIT Station Cambridge, MA 02139-0901 Greetings, This is a dual-purpose letter. First, I want to convey the results of the survey done by the VAX Migration/Host Development working group. Secondly, the working group is providing a list of volunteers who have expressed a willingness to assist others in the migration process. First off, let me discuss the results of the survey. The response was totally underwhelming! Only twenty people cared enough to fill out the Pageswapper form and respond. Another 20 or so at each of the past two DECUS meetings responded, so I have a sample space of around 60 replies over the past nine months. Ugh! From this I can assume a) Almost no one ever migrates from any system to VMS, b) Few sites use VMS to develop software for other systems, or c) The subset of sites getting the PageSwapper don't like filling out and sending in questionnaires. Based on a large number of conversations I have had at past DECUS meetings, I do not believe choices a) or b) to be the case. While the surveys were few in number, the answers were informative and possibly indicative of general trends. The sites responding basically fell into two groups: the migrators, and the host developers. The groups were about equally split. The "migrators" were interested in migration issues covering twelve different processor/operating system combinations, namely; RSX: 16 sites RSTS: 1 site IAS: 3 sites RT11: 3 sites IBM: 3 sites TOPS10/20: 5 sites UNIVAC, TI, SEL, HP, and MS-DOS each 1 site. The primary concerns of these sites were those relating to converting a program running on one system to running on another. Most sites worried about Fortran conversion issues but there was also a fair amount of concern relating to commercial languages such 27 PAGESWAPPER - April 1985 - Volume 6 Number 10 Letters as Cobol. In addition, the inability to migrate many RSX tasks via the AME was raised by a number of sites as a complicating factor in the migration process. The "Host Developers" either were using the AME for developing RSX programs, or were using it for running compatibility-mode microprocessor development tools for non-DEC microprocessors. Their biggest issues seemed to concern the AME and its lack of features (RSX developers). I was surprised at the number of sites using VMS for developing software for non-DEC microprocessors. Although my comments on the VMS V4.0 AME (VAX-11/RSX V1.0) will appear in a future letter, I think it quite likely that "lack of features" in the AME is being replaced with a much hotter issue (performance) even as you read these words. Finally, the users listed at the end of this letter, have agreed to let their names be published as someone to contact (besides me) if a VMS site has a migration related question. However, sites having migration or host development related issues should continue to write them down and send them on to me. Since V4.0 was released, two additional topics are being investigated: a) migration from one version of VMS to another, and b) the V4.0 AME. Sites wishing to comment, make proposals, relay war stories, etc. on these topics are urged to contact me. Sincerely, James Downward KMS Fusion, Inc. P.O. Box 1567 Ann Arbor, Mich. 48106 (313)-769-8500 28 PAGESWAPPER - April 1985 - Volume 6 Number 10 Letters Mr. Rodney Boorse Mr. Alan Bruns Hamilton Test Systems, Inc. Allied Electronics 2301 N. Forbes Blvd. 401 E 8th Tucson, Az. 85745 Ft. Worth, Tx 76102 (602)-792-3260 x277 (817)-336-5401 John Clement Mr. Lee Crawfort Bonner Lab Kentucky Geological Survey Rice University 311 Breckinridge Hall P.O. Box 1892 University of Kentucky Houston, Tx 77251 Lexington, KY 40506-0056 (606)-257-8241 Susan Hassel Margaret Knox Burlington Industries Computation Center P.O. Box 21327 University of Texas Greensboro, NC 27420 Austin, Tx 78712 (919)-454-3161 Victor Lindsey Art McClinton VLSystems, Inc. MITRE 2691 Richter Ave 1820 Dolley Madison Blvd Suite 118 McLean, Va. 22102 Irvine, Ca 92714 (203)-883-6356 (714)-660-8855 Thomas Murphy John. H. Pressman U.S. Air Force Northwestern University MMECF 2129 Sheridan Road Hill AFB, Utah 84056 Evanston, Il. 60025 (801)-777-5109 (312)-492-3681 Allen Rueter Mr. Phil Taylor Washington Univ Amax Inc 510 S. Kingshighway Blvd 1707 Cole Blvd St. Louis, Mo. 63110 Golden, Co. 80401 (314)-362-7133 (303)-231-0317 Chris Wysocki Data Life Associates 500 Bloomfield Ave Veronia, N.J. 07044 (201)-239-7500 29 PAGESWAPPER - April 1985 - Volume 6 Number 10 VAX System SIG Committee List VAX System SIG Committee List As of December 12, 1984 Joe Angelico - Volunteer Coordinator and System Management US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA. 70130 June Baker - Planning Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 C. Doug Brown - Security Sandia Labs P.O. Box 2644 Albuquerque, NM 87185 Jack Cundiff - Assistant Symposium Coordinator Muskigum College New Concord, OH 43762 James R. Cutler - Hardware Software Results Corporation 2887 Silver Drive Columbus, OH 43211 Doug Dickey - Data Management SIG Interface CTEC, Inc. 6862 Elm Street McLean, VA 22101 Jim Downward - Migration and Host Development KMS Fusion Inc. 3621 South State Road, P.O. Box 1567 Ann Arbor MI 48106 Dan Fleury - Education University of Hartford West Hartford, CT 06117 Dennis Frayne - Real Time/Process Control McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals In House Systems 165 William Street 30 PAGESWAPPER - April 1985 - Volume 6 Number 10 VAX System SIG Committee List New York, NY 10038 Bob Boyd - Commercial GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709 Don Golden - Overseas Coordinator / Publications Coordinator c/o Shell Development Company, D-2132 Westhollow Research Center Post Office Box 1380 Houston, TX 77001 Mark Graff - TOPS-VAX M/A-COM Linkabit, Incorporated 3033 Science Park Road San Diego, CA 92121 Gary Grebus - System Improvement Request Battelle Columbis Labs 505 King Avenue Columbus, OH 43201 B. Hancock - Network Sohio Petroleum Company Two Lincoln Center 5420 LBJ Freeway, Suite 900/LB 03 Dallas, TX 75240 R. Haydt - Foreign Devices, Hardware/Software Information Consultants International Incorporated P. O. Box 2014, E. V. STA Ormond Beach, FL 32074 Jeffrey S. Jalbert - Symposium Coordinator Dennison University Granville, OH 43023 Ken Johnson - Handouts 800 N. Lindbergh Monsanto MS V2B St. Louis, MO 63043 Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 31 PAGESWAPPER - April 1985 - Volume 6 Number 10 VAX System SIG Committee List Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Bob Robbins - VAXElan Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA P. Sandwell - Graphics Seismograph Service Corporation P. O. Box 1590 Tulsa, OK 74102 David Schmidt - LUG Coordinator Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201 D. Slater - Artificial Intelligence Mantech International 2320 Mill Road Alexandria, VA 22314 Louise Wholey - Languages and Tools Measurex Corporation One Results Way Cupertino, CA 95014 Douglas J. Wilson - Office Automation MIT Joint Computer Facility Room 5-137, 22 Massachusetts Avenue Cambridge, MA 02139 32 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 389 Caption: Implementation of TEX on the VAX -- Reply to I/O # 314 Message: TEX is currently running on VMS and UNIX. More information can be obtained through: American Mathematical Society Post Office Box 1571, Annex Station Providence, RI 02901-1571 USA The VMS tape is distributed by: Maria Code DP Services 1371 Sydney Drive Sunnyvale, CA 94087 USA Contact: Maria Luisa Luuisetto INFN-CNAF Via Mazzini 2 40138 BOLOGNA ITALY Telephone (051) 498286 Date: December 21, 1984 33 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT INPUT/OUTPUT 390 Caption: Bulletin Board System Message: Does anybody know where I can get a BBS for VAX or RSX-11M? Any leads will be appreciated. Thank you. Contact: Karl J. Strube 1050 Linden Avenue Long Beach, CA 90801 Telephone (213) 491-9030 Date: January 23, 1985 INPUT/OUTPUT 391 Caption: Tape Archive and Retrieval -- Reply to I/O # 363 Message: A DCL archive routine can be based upon a $ SET RETENTION command for the entire disk. A monthly tape run would archive all expired files and build a listing of those files. The Retrieval (or restore) routine accesses the above listing upon user request and makes minor checks as to proper ownership. Contact: Joseph H. Dillon 2101 Coliseum Boulevard, East Indiana-Purdue University Fort Wayne, IN 46805 Telephone (219) 482-5766 Date: January 25, 1985 INPUT/OUTPUT 392 Caption: Sharing TS11 between 2 VAXes -- Reply to I/O # 358 Message: The problem is not with the VAX, but is with the TS11 microprocessor. At our installation we use a T-bar switch that connects the TS11 to one of two TS11 interface cards located on the CPUs' Unibuses. After each repositioning of the switch, we re-initialize the TS11 microprocessor by starting the user "self-confidence" test described in the TS11 user manual. Contact: Stephen F. LaVie Duquesne Light Company Post Office Box 4 Shippingport, PA 15077 34 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT Telephone (412) 393-5724 Date: January 28, 1985 INPUT/OUTPUT 393 Caption: VMS-UNIX Interface Message: We are looking for an interface between VMS and UNIX (Berkely 4.2). Ideally, it would look like DECnet to s VMS user and UUCP to a UNIX user. Priorities are electronic mail and file transfer. Contact: Paul Shapiro Philips Laboratories 345 Scarborough Road Briarcliff Manor, NY 10510 Telephone (914) 945-6125 Date: January 28, 1985 INPUT/OUTPUT 394 Caption: Mini-Exchanges and PCs Message: Has anyone established a printer connected to a mini-exchange (in turn connected to PC's) as a printer or terminal queue which VMS and the PC's could share? I can't find any reference to the mini-exchange in the V4.0 doc set. Contact: Joe Perches Rocky Mountain/Information Services 7900 Sepulveda Boulevard Van Muys, CA 91405 Telephone (818) 786-6002 Date: February 13, 1985 35 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT INPUT/OUTPUT 395 Caption: VAX Pascal Pretty Printer Message: Does anyone have a Pascal pretty printer which will handle all the VAX Pascal extensions? Contact: J. A. Koehler Physics Department University of Sask Saskatoon, Sask, STN-OWO CANADA Telephone (306) 966-6401 Date: February 20, 1985 INPUT/OUTPUT 396 Caption: Privileged and Execute-Only Command Procedures Message: What is the availability of the CERBERUS software described in the January 1985 issue of the PAGESWAPPER? What is the address of the source? Contact: George R. Sepelak Kenemetal, Incorporated Post Office Box 231 Latrobe, PA 15650 Telephone (412) 539-5339 Date: February 25, 1985 Pageswapper Editor's Response Contact the author at the following address: Johan Hamaker Netherlands Foundation for Radio Astronomy Radio Observatory Dwingeloo Netherlands 36 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT INPUT/OUTPUT 397 Caption: VMS <--> UNIX "UUCP" Message: We do not, and do not want to, run UNIX on our 11/780, but we wish to become part of an electronic mail network on UNIX machines. We need some sort of UUCP or equivalent for a price near nil! Contact: Dr. G. H. Cohen NIH Building 2, Room 312 Bethesda, MD 20205 Telephone (301) 496-4295 Date: February 27, 1985 INPUT/OUTPUT 398 Caption: Block Letter Printer Message: We are looking for a program which prints large letters on a printer under VMS. I have seen one which produced Olde English, but it ran under RT-11. Does anyone know of a program in the public domain? As an alternative, has anyone figured out how to access the block letters used by the print symbiont to produce the flag pages? Contact: Carl K. Shafer Continental Grain Company Wayne Feed Division 10 South Riverside Plaza Chicago, IL 60606 Telephone (312) 930-1050 Date: March 1, 1985 INPUT/OUTPUT 399 Caption: IBM Series/1 Diskette Handler Message: We are looking for a program which will read IBM Series/1 diskettes and build a library of programs on a VAX. The diskettes were created using the EDX operating system on the Series/1. What we would like to be able to do is move the text file names as the Series/1 used. this means the program would need to be smart enough to follow the EDX directory structure. We don't necessarily need to be able to write a 37 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT diskette which the Series/1 could read. Has anyone done something like this? Contact: Carl K. Shafer Continental Grain Company Wayne Feed Division 10 South Riverside Plaza Chicago, IL 60606 Telephone (312) 930-1050 Date: March 1, 1985 INPUT/OUTPUT 400 Caption: Foreign Terminals Message: We are using ADDS Viewpoint A2 terminals on our system (Regent 25 comaptible) that we had connected to our previous NCR system. Does anyone have any terminal drivers that support the use of the auxillary port for a serial printer? Contact: Greg Collver Josephine County School District 706 North West A Street Grats Pass, OR 97526 Telephone (503) 476-7721 Date: March 4, 1985 INPUT/OUTPUT 401 Caption: Partial I/O through DZ/DMF ports Message: We have a program to receive binary/ASCII data from one of our devices under development and store it on a disk. The logical records from the device terminate in a . However, the presence of binary data in the record complicates the use of the as a record terminator, and we simply collect blocks of 512 bytes to disk and separate the logical records later. There are other "beginning of logical record" indicators which are used to distinguish between s which are followed by a new record and those which are merely imbedded within a logical record. Unfortunately, the input data does not have any "end of file" coding, and operational requirements prevent us from using timeout to end a data run - the period is too variable. 38 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT At the moment, the end of a run is entered manually by the operators as a CTRL/C, which leads to a CTRL/C AST; this, in turn, ussues a SYS$CANCEL to the outstanding QIOs. I originally assumed/hoped that the resulting IOSB could report either SS$_CANCEL or SS$_ABORT and, in the latter case, give a partial byte count in IOSB(2), so the last block could be filled with, for example, nulls, and written to disk. This does not appear to happen; I am not even really sure that it is SUPPOSED to. IOSB(2) seems always to be zero!. But, it seems to me, that it OUGHT to. Any suggestions? Of course, I could use the as a record terminator, and assemble the logical record later, but this would increase by a factor of perhaps as much as 10 the QIO activity of the program; typical logical records may be some 50-60 bytes. I would like to avoid this overhead. Contact: John L. Prather Technicon 511 Benedict Avenue Tarrytown, NY 10591 Telephone (914) 681-2694 Date: March 7, 1985 INPUT/OUTPUT 402 Caption: DECnet-VAX and Remote Command Terminal Connections Message: How do you relate a specific remote command terminal (RTAx) to a specific DECnet link and therefore to the initiating remote process? Telephone Support says this is not possible. Example: Assume user A on node X issues SET HOST as user B to node Y and is allocated terminal RTA1. SHOW DEVICE RTA1 tells me it is user B and the local process ID. Show process/ID=x tells me the NETxxx devices allocated. NCP SHOW KNOWN LINKS tells me local links, process ID's and corresponding remote links and IDs. The local process ID for the link in question is that of REMACP, not the process which is allocated RTA1. SHOW PROCESS/ID=x of REMACP shows me additional allocated NETxxx devices, which do not correspond to those allocated to user B. How do I get the system to cough up the relationship between RTA1 and the local link? Contact: Charles W. Vertrees CXC Corporation 2852 Alton Avenue 39 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT Irvine, CA 92714 Telephone (714) 660-1801 Date: March 6, 1985 INPUT/OUTPUT 403 Caption: HEXZAP Directions Message: Does anyone have any directions on how to use HEXZAP? If so, could you send them to me? Contact: B. C. Dow-Pleines Calma 525 Sycamore Drive Milpitas, CA 95035 Telephone (408) 970-1500 Date: March 7, 1985 INPUT/OUTPUT 404 Caption: Newlett-Packard 7550A Plotter Queue -- Reply to I/O # 371 Message: We set up a plotter queue on a terminal port with the DCL command INITIALIZE/QUEUE/TERMINAL. We made it a spooled device with the SET DEVICE/SPOOLED command. Anyone can queue a file of HP plotter commands with the PRINT/QUEUE=tta1 command. Set up the plotter handshake mode as XON/XOFF and data flow as REMOTE STANDALONE. We use VAX/VMS V3.7. Contact: Philip Kelley B. F. Goodrich Tech. Center Post Office Box 122 Avon Lake, Ohio 44012 Telephone (216) 933-1691 Date: March 8, 1985 40 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT INPUT/OUTPUT 405 Caption: Development of a Computer-aided Municipal Accounting System Message: The City of Torrance is designing an automated Fund Accounting system with the basic accounting modules properly integrated. Initial development includes modules such as Accounts Payable, Accounts Receivable, General Ledger, Budget, Purchase Order and Inventory Management. Further development will include subsystems such as Payroll, Personnel, Equipment Maintenance/Rental and Fixed Assetts. Our configuration is a VAX 11/780 running VMS. Any suggestions or comments from those operating within a Fund Accounting environment that would contribute to developing a highly effective package are welcomed. Contact: Mr. James A. Werner City of Torrance Information Systems Department 3031 Torrance Boulevard Torrance, CA 90503 Telephone (213) 618-5939 Date: March 8, 1985 INPUT/OUTPUT 406 Caption: FORTRAN Argument List Checker Message: I need a program that will read FORTRAN source an check to see if subroutine argument lists and calls correspond in number and size of arguments. Contact: Peter Gaynor Merit Computer Programming 16 West 16th Street New York, NY 10011 Telephone (212) 243-6413 Date: March 11, 1985 41 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT INPUT/OUTPUT 407 Caption: Archive System for VMS -- Reply to I/O # 363 Message: We are currently developing a user friendly archive system due for general release this summer (1985). Contact: Gareth Griffiths United Information Services Apec House 6A-10 West Street Epsom, Surrey, KT18-7RG UK Telephone (UK) 3727-29655 Date: March 13, 1985 INPUT/OUTPUT 408 Caption: Public Domain COGO Message: Does anyone have information on the availability of a public domain version of COGO? Contact: Steve Arndt City of Gresham 1333 NW Eastman Avenue Gresham, OR 97030 Telephone (503) 661-3000 ext 366 Date: March 14, 1985 42 PAGESWAPPER - April 1985 - Volume 6 Number 10 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, 249 Northboro Road (BPO2), Marlborough, MA 01752, USA 43 PAGESWAPPER - April 1985 - Volume 6 Number 10 INPUT/OUTPUT Submission Form Tear out to submit an I/O item PAGESWAPPER Editor DECUS 249 Northboro Road (BPO2) Marlborough, MA 01752 USA 44 PAGESWAPPER - April 1985 - Volume 6 Number 10 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) 45 PAGESWAPPER - April 1985 - Volume 6 Number 10 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201 USA 46