Index of /pdf/dec/decus/DECUS SIG Newsletters
DECUS U.S. CHAPTER SIGs NEWSLETTERS
GENERAL INTEREST . . . . . . . . . . . . . .. . . ... . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GI DAARC SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · . . . DAR DATATRIEVE/4GL SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · . . . . . . . . . . . . . . . DTR GRAPHICS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GRA IAS SIG ........................................................................................ IAS NETWORKS SIG . . . . . . . . . . . · . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NTW OFFICE AUTOMATION SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA PERSONAL COMPUTER SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PC UNISIG ..............................................................·.......................... UNI VAX SYSTEMS SIG............................................................................ VAX EDUSIG ....................................................................................... EDU RT SIG .......................................................................................... RT ARTIFICIAL IN;fELLIGENCE SIG ................................................................... Al BUSINESS APPLICATIONS SIG ................................................................. BA DATA MANAGEMENT SIG ..................................................................... OMS HARDWARE MICRO SIG ...................................................................... HMS LANGUAGESANDTOOLSSIG ....................................................... : .......... L&T LARGE SYSTEMS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LS MUMPS SIG .......................................................<........................... MMP RSTS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RST RSX SIG ........................................................................................ RSX SITE MANAGEMENT & TRAINING SIG .......................................................... SIT LIBRARY INFORMATION SECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LIB SIG INFORMATION SECTION .......·......................................................... SIC SUBMISSION FORMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SUB QUESTIONNAIRE SECTION . . . . . . . . . . . ·. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QU SUBSCRIPTION & MEMBERSHIP FORMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S&M
I
o June 1988 Volume 3, Number 1
GENERAL TABLE OF CONTENTS
SECTIONS
PAGE NO.
GENERAL INTEREST .Dear SIGs Newsletters Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GI-1
DAARC SIG
.Letter fro the Editor
. . . . . . . . . . . .
.An Application of CIM Using a Personal Computer
.Editors Note . . . . . . . . . . . . . . . . . . . .
DAR-1 DAR-1 DAR-4
DATATRIEVE/4GL SIG .How Not To Define Your Default Dictionary in DCL....DTR-2 .Wombat Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Using DATATRIEVE Record Definitions with the SORT/MERGE Utility .VAX RALLY Application Development Topics. . .Ask the Wombat Wizard . . . . . . . . . . . . . .DATATRIEVE/4GL SIG PIR Submission Form.
DTR-3 DTR-6 DTR-1
QU-1 . QU-3
GRAPHICS SIG .Submissions. . . .From the Editor. .Woods Meeting Minutes
GRA-1 GRA-1 GRA-2
IAS SIG .From the editor's Keyboard. .In This Issue . . . . . . . . .Contribution Guidelines. . . .Ten Years Ago This Month . .IAS Product Panel . . . . . .The Program of the Month Club
. IAS-1 . IAS-1 . IAS-1 . IAS-2 . IAS-2 . IAS-4
NETWORKS SIG .Happy Campers! . . . . . . . . . . . . . . . . . . . .Networks and Communications SIG Wishlist ... . .Terminal Servers on Ethernet Local Area Networks. .Biographies . . . . . . . . . . .DATAGRAM . . . . . . . . . . . . . . . . . . . . .
NTW-1 NTW-1 NTW-1 NTW-11 QU-11
OFFICE AUTOMATION SIG .From the Editor. .Notes on Notes ....... .
OA-1 OA-2
PERSONAL COMPUTER SIG .PRO Section ..... .MACINTOSH Section
PC-1 PC-6
UNISIG .Editor's Corner ........ . .Using Ucbmail . . . . . . . . . .Unix as a Window to the World. .The Way it is . . . . . . . . . .
. UNI-1 . UNI-3 . UNI-7 . UNI-9
i
VAX SYSTEMS SIG .Contributions . . . . . . . . . . .A New Hand at the Tiller . . . . .Spring 1988 SIR Ballot Results .It's On The Tapes . . .VAXNMS Security ...... .
EDUSIG .Fellow Educators . .TESTGEN ...
RT SIG .From the Editor....... . .Introduction to KERMIT/RT . .The FORTRAN Slate .. .RT-11 Wish List Survey . . .
LIBRARY .New Library Programs Available. .Revisions to Library Programs ..
SIG INFORMATION SECTION .Special Interest Committee Lists.
SUBMISSION FORMS .Submitting Articles to Hard News .
QUESTIONNAIRE SECTION .Ask the Wombat Wizard . . . . . . . . . . . . . . . . . . . . . .DATATRIEVE/4GL SIG PIR Submission form . . . . . . . . . .Hardware Submission Form - A SIG Information Interchange .L&T Masters Application .. .L&T Wishlist Questionaire . .DATAGRAM . . . . . . . . .RT-11 Wish List Survey ..
SUBSCRIPTION & MEMBERSHIP FORMS .Subscription Service SIGs Newsletters Order Form . .DECOS U.S. Chapter Application for Membership .
VAX-1 VAX"l VAX-2 . VAX-26 . VAX-27
EDU-1 EDU-2
. RT-1 . RT-2 .RT-13 QU-13
. LIB-1 . LIB-5
. SIC-1
SUB-1
QU-1 QU-3 QU-5 QU-7 QU-9 QU-11 QU-13
S&M-1 S&M-3
ii
Digital Equipment Computer Users Society
DECUS, U. S. Chapter 219 Boston Post Road. (BP02) Marlboro. MA 01752
U. S. Activities (617) 480-8259 or 8802 Finance & Admin. (617) 480-8684 Library (617) 480-8521
Dear SIGs NEWSLETTERS reader:
This month I will continue a long tradition, (started last month,) by reporting on topics of general interest to the readers. This column may not always appear, but it will appear when I find I have problems with this 21-ring circus and feel that the problems directly affect you, the subscriber.
This month, I will be talking about the problems with our subscription services, (or more accurately, with our REsubscr!ption services.) Currently our subscription service leaves much to be desired. Much of the problem revolves around our current subscription software. Eventually we WILL be getting new software, but for now I will be talking about some short-term fixes and workarounds. Anyway, the major problems I see are:
0 It takes a long time to start a subscription.
0 It's not easy to tell when your subscription expires, or when you should re-subscribe, and we don't make it easy enough to re-subscribe.
The simplest thing that is wrong with subscribing is that the subscription form (and DECUS membership form,) are included in the "How To" Submit an Article section. Starting this month, they will have their own section, clearly marked as such on the front cover, so you can FIND THEM.
The simplest thing that is wrong with renewing is that we only send you one renewal form. (Yes, only one form is not enough, most magazines send at least 3 forms.) We're working on that, soon you will be getting multiple forms, so if the US Snail loses one, you still have a chance. Anyway, until we get this working, there are some simple things you can do.
As far as general questions about renewal, here are some typical questions about subscriptions, along with some (hopefully helpful) answers.
Question: Answer:
Question:
I found the form in the newsletter and sent it in. When will I get my first (or renewal) newsletter?
When your form gets to DECUS, it takes a couple of days to process, (maybe a little longer right around Symposium.) Usually about a week elapses from the time you mail your subscription. Let's say the subscription is processed on April 15th. You will eventually know this date because it is printed on your mailing label. (The first 6 digits are your DECUS number, the next 6 are the date in the format yymmdd.)
On about the first of the month, your subscription is counted for the next production run of the newsletter. But since we start working on the JUNE issue on the first of May, you end up getting your first issue with the June issue, a month and a half later. (Not the next issue as it states on the subscription form.)
When should I renew?
GI-1
-2 -
Answer: Question: Answer:
Question: Answer:
Question: Answer:
Question: Answer:
Question: Answer:
Question: Answer: Question: Answer:
You should have received a renewal notice and sent it in by the date one year later than the date on your subscription.
What should I do if don't receive a renewal form?
If necessary, you can tear out the form from the newsletter and send it in, but mark it clearly "RENEWAL". (Yes we don't have separate boxes to check for "NEW" and ·RENEWAL" on the form.)
Can I subscribe or renew by phone?
Yes, if you can pay by MasterCard, VISA, American Express or DinersClub/ Carte Blanche®. Just call (617) 480-3659, and have your membership number ready. (Just to complicate things further, after July 15th, the telephone company is changing the Marlboro area code to 508.)
I renewed my subscription, but the date on my label didn't change, why not?
Our current subscription software can't handle renewals. What happens is that your renewal effectively gets entered as a whole NEW subscription. When your current subscription runs out, your new one starts automatically. You can tell because the date code on your label will change when your new one starts.
I think I renewed twice this year, once by mail and once at the fall symposium. How can I tell?
Like the previous answer, renewals get queued up behind current subscriptions. If you renewed twice, you may have a couple of subscriptions stacked up. ( A few of our subscribers have a couple of years stacked up!) If in doubt, call the office. I want a different address on my newsletter than the one I get regular DECUS mailings sent to. Why can't you do that.
All DECUS mailings are tied into a master address data file, keyed to your DECUS membership number. This address must be the same for Library mailings, DECUSCOPE, Newsletter, etc.
I submitted a change of address using the form on the back cover. How long should that take?
The same as a subscription entry or renewal. About a month and a half.
For any other problems, what should I do?
When in doubt, call. Once again, the magic number is, (617) 480-3659. Remember, after July 15th, the area code changes to 508.
That's all for this month folks, hope this information has been helpful.
Frank "Ringmaster" Borger
GI-2
Letter from the Editor
By: Dale Hutchison Cummins Engine Company 4720 Baker Street Extension Lakewood, New York 14750
Its been a few months since you've heard from me. Glad to see that you are still reading the newsletter. Remember, even you can have your article published in the DAARC SIG section of the newsletter. Forward your article to me at the above address. Be sure to include your name, address and phone number. The phone number is for me, just in case I have a question regarding your article.
In this issue we have another article from Jim Duba. His article is about a project he has worked on, involving the use of a personal computer in a computer integrated manufacturing application.
Note: For those of you that were unable to attend the spring symposia in Cincinnati, you can order a copy of the Proceedings. Contact the DECUS Office
219 Boston Post Road Marlboro, MA 01752-1850
Until next month.
AN APPLICATION OF CIM USING A PERSONAL COMPUTER
By: Jim Duba Cummins Engine Company 4720 Baker Street Ext. Lakewood, New York 14750
1 Purpose The purpose of this project was to measure hole location and diameter in a part with reamed and drilled holes. The results of the measurements are intended to be used in adjusting machine performance on the spot and for evaluating long term performance.
2 How It Works (in general) The part has two holes all the way through. The start of each hole is considered a separate hole. This means that the left hole is numbered hole one on the back of the part and hole four on the front of the part. They are numbered one through four. Hole one is coaxial with hole four and hole two is coaxial with hole three. Holes one, two, and three are the same diameter. Hole four is slightly smaller. We are concerned with measuring the diameter of each hole, the location of each hole in the part, and the distances from the center of holes two and three to the center of hole four.
The part is first placed in a gauging fixture, then probes are inserted through the fixture into the part. The fixture holds the probe securely in place (the shoulder of the probe is held in place by the gauging fixture). Near the end of the probe there is a small, spring-loaded button that presses against the side of the hole in the part. The distance it sticks out is changed into an electrical signal that is sampled and converted into a number in a personal computer. The probe is rotated around the hole by the operator and the signal is sampled every ninety degrees. The numbers obtained from measuring a part this way are compared with the numbers obtained by measuring a master with known dimensions in an identical fashion
DAR-1
3 Electrically - Very Briefly
The button on the probe actuates a transducer. This transducer feeds an amplifier that is connected to an analog to digital conversion board in an AT compatible. The transducer amplifier produces a voltage that is proportional to the distance the button on the probe has moved. This voltage is amplified and then converted into a number between -2047 and +2047 by an analog to digital converter card in the AT compatible. The mechanics and electronics combine to produce numbers that get larger the further the probe is pushed in.
4 Calibration
Calibration is the process of relating the electrical signals to a linear measurement unit such as millimeters. The small button on the probe tip is depressed a known amount, usually with a gauge block. This signal value can then be used in converting the voltage readings into actual measurements.
For example, lets assume we place the probe between two pieces of metal, the button is slightly depressed and produces a reading of 1947 in the personal computer. A one mm gauge block is inserted between the button and its piece of metal which produces a reading of 1352. This means that each unit of measurement from the analog to digital converter is worth .00168mm.
5 Mastering
A part with precisely known dimensions known as the master, is placed in the gauging fixture. The operator goes through the same measuring process described below for a part. The numbers obtained from the probe tips are saved and when a part is measured, the actual values obtained from the part are compared to the numbers obtained from the master. Since the master has known dimensions and the probe has been calibrated, the dimensions of the part can be calculated.
6 Taking a Measurement
This section will only describe the process of taking a single set of measurements for one hole. In actual practice, four such measurement sets are taken, one set through each of the holes in the gauging fixture. This section is intended only to describe the physical process; the computations will be detailed below.
The part is clamped securely into the gauging fixture. Because the hole locations are being compared to the hole locations of the master, it is important that this is done the same way each time. A probe is inserted into the hole with the button down, this is considered zero degrees. The reading from the transducer is recorded and the probe is rotated 90 degrees clockwise, to the ninety degree position. The reading is recorded and the probe is rotated clockwise another 90 degrees to the one hundred eighty degree position. This reading is recorded and the probe is rotated 90 degrees clockwise once more to two hundred seventy degrees and the final reading is recorded. A program running on the personal computer prompts the operator through each step to insure that the probe is in the right place before it's sampled.
7 Calculating the Results
We'll assume that we got the following readings from the process described above. It's not important to know the actual dimensions of the master.
Part
A - 0 degrees - 1397 B - 90 degrees - 1351 C - 180 degrees - 1511 D - 270 degrees - 1394
Master
E - 0 degrees - 1395 F - 90 degrees - 1588 G - 180 degrees - 1394 H - 270 degrees - 1520
Calibration for this probe is .000459 millimeters per division.
DAR-2
7.1 Hole Diameter Zero and one hundred eighty degrees are the vertical diameter. Ninety and two hundred seventy degrees are the horizontal diameter. E is smaller than A so the master is larger than the part:
E ·A= -2
0 is smaller than C:
0. c = -117
This means that the part hole is ·119 times .000459 or .0537 millimeters smaller in diameter than the same hole in the master.
The same calculations for the horizontal diameter:
F · B = 237
H · D = 126
237 + 126 = 363 363 * .00459 = 1.666mm
which means that the part is 1.66mm larger than the master.
7.2 Hole Location (Displacement) Hole location is a little trickier because the signs are not as intuitive. In this case the directions are the same as ordinary Cartesian coordinates. Up (as the part is placed in the fixture) is considered positive Y axis, and right is positive X axis. The direction is from the master to the part. So a positive Y means that the part is above the master, and a positive X means that the part is to the right of the master. Let's work through the computations with the same hole measurements that were used for hole diameter above.
At zero degrees, the part is below the master (negativel:
E - A= -2
and at one hundred eighty degrees, the part is above the master (positive):
C-0=117
Thus the center of the parts hole is:
.000459 * (-2 + 117) I 2 = .0264mm
above the center of where the master was.
Horizontally it works out as follows:
B - F ::::: -237 H - D = 126
.000459 * (-237 + 126) I 2 = -.0255mm
Which means that the center of the hole in the part is .0255mm left of the center of the hole in the master.
7.3 Distance Between Holes It's easy to see how the distances between the holes on the part can be calculated knowing the same dimensions on the master. Assuming that the hole we just calculated values for, is the left hole and the right hole measures -.0132. Then:
140 - .0132 + .0255 = 140.0123
gives the distance between the holes in the part.
DAR-3
8 Wrapping It All Up
This system is implemented on a standard AT compatible with an AID card. We are adding a DEPCA kit to provide communications to our VAX system where our quality database resides. This will provide immediate update of the quality system at the time measurements are made.
Editors Note:
The DEPCA kit referred to is a product of Digital Equipment Corporation, used to integrate personal computers into a local area network.
DAR-4
The Wombat
Ct tt h 4 ~ 14
EXAMINER 1lltnpatr4
"Increases the Circulation of Anyone in America" Volume 9 Number.LO
----------------------.
Contributions
Contributions for the newsletter can be sent to either of the following addresses:
Editor, DATATRIEVE Newsletter c/o DECUS U.S. Chapter Company 219 Boston Post Road, BP02 Marlboro, MA 01752
Joe H. Gallagher, Ph. D. 4GL Solutions 10308 Metcalf, Suite 109 Overland Park, KS 66212
Letters and articles for publication are requested from members of the SIG. They may include helpful hints, inquiries to other users, reports on SIG business, summaries of SPRs submitted to Digital or other information for members of the DATATRIEVE SIG. Machine readable input is highly desirable and machine-to-machine transfer of material is preferred, but most anything legible will be considered. However, this newsletter is not a forum for job and/or head hunting, nor is commercialism appropriate.
Table of Contents
DJilCIJS U. S. Chapter SIGs Revsl.etter, Wollbat Bxaainer,
Vol.uae 3, Rllllber l.O, Vol.uae 9, Rllllber l.O
June l.988
Bow IKJ'.r To Define Your Default Dictionary In DCL .................
2
Wollbat Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Using DATATRIINE Record Definitions with the SORT/llKRGE Util.ity ..
6
VAI RALLY Appl.ication Devel.opment Topics.........................
9
About the authors ···
Bart z. Lederman works in the Advanced Systems Development Group of WU World Communi-
cations in New York City; he holds a Masters of Electrical Engineering in Solid State Electronics and Communications from Rennselaer Polytechnic Institute. Bart is the Library Committee and PDP-11 Working Group representative of the DTR/4GL SIG; a regular speaker at Symposia; the artist for the Wombat Examiner and 4GL Dispatch and special projects coordinator for the SIG; a member of the DTR/4GL Executive Steering Committee; and a 1984 recipient of the DATATRIEVE Greybeards Award.
Anotbony D. Rogers is a principal Software Engineer at Digital Equipment Corporation. He has been the VAX RALLY project leader for two years, and has been working on the RALLY project for four years.
DTR.,..l
How RO'l' To Define Your Default Dictionary In DCL
B. z. Lederman, WU World Communications, New York, NY 10004-2464
I have to work in several different CDD dictionaries during the day, depending upon the job at hand. In order to make this easier, I do two things in my LOGIN.COM file. First I define the logical name CDD$DEFAULT to point to my desired default dictionary: then I define some symbols which make it easier for me to change my default dictionary. The relevant section of my LOGIN.COM file USED to look like this:
$ DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN" $! $ CDDAil :== DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.ALLIN1" $ CDDHDME :== DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN"
This all looks perfectly reasonable and proper, and used to work perfectly well. When I logged in, my default dictionary was CDD$TOP.DTR$USERS.LEDERMAN, and if I typed in CDDAil at the DCL prompt, CDD$DEFAULT was redefined to CDD$TOP.DTR$USERS.ALLIN1, and so on.
Everything worked well until I added some additional dictionaries below my normal dictionary like this:
$ CDDDMF :== DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN.DMF"
$ CDDACC .-- DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN.ACCOUNTING"
Now, if I typed in CDDACC at the DCL prompt I got the error:
%DCL-W-PARMDEL. invalid parameter delimiter - check use of special characters \.ACCOUNTING\
which didn't seem to make much sense. Worse, if I typed in the DEFINE command at DCL level, it worked.
TSC eventually ran this down, and it is documented somewhere in the VMS documentation set that you are not allowed to have special characters in a logical name definition unless they are surrounded by quotes, and a period is a special character. Now, the definition above appears to be surrounded by quotes, but you are also not allowed to have special characters in a symbol definition unless they are surrounded by quotes as well, and the ones above are not. In order to insure that the definitions always work, I have changed my LOGIN.COM file to look like this:
$ DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN" $! $ CDDAil .-- DEFINE "CDD$DEFAULT ""CDD$TOP.DTR$USERS.ALLIN1"" $ CDDHOME .-- DEFINE "CDD$DEFAULT ""CDD$TOP.DTR$USERS.LEDERMAN"" $ CDDDMF ·-- "DEFINE CDD$DEFAULT ""CDD$TOP. DTR$USERS. LEDERMAN. DMF"" $ CDDACC .-- "DEFINE CDD$DEFAULT ""CDD$TDP.DTR$USERS.LEDERMAN.ACCOUNTING""
You may well ask, "If there has to be quotes around special characters, why did the CDDAil and CDDHOME symbols work before the fix?" It appears that there is a hidden
DTR-2
bug in VMS/DCL which allows some invalid definitions to work, and the magic number of special characters appears to be two. With two periods the definitions work, but with three or more they fail. I don't think anyone knows why yet.
Also note that when a definition is enclosed in quotes, that no lower case to upper case translation takes place. In the above examples I don't thin that matters much as I believe COD will itself do the case translation: but in other cases you may have to be careful to enter your definition in upper case if the person/program/utility which uses that definition is going to search in upper case and is case sensitive.
Wombat Wizard
Dear Wombat Wizard:
I have written a large multi-user, menu-driven application in DATATRIEVE (about a dozen domains with about 75 procedures). Within the menu-driven procedures, all domains are readied SHARED except under some special circumstances which don't pertain to my problem. Multiple users can work within the menu-driven system without any file access conflict. My problem occurs when the boss (who knows enough DATATRIEVE to be dangerous and who has privilege to leave the menu-driven application) works in DATATRIEVE interactively. When the boss accesses domains, sometimes my menu-driven procedures fail with
Error using RMS file "FILENAMt.tXI". %RMS-E-FLK. file currently locked by another user
Sometimes the procedure "aborts" and the user is returned to the menu screen (that's the good news); other times the procedure continues processing and writes bad data in other domains (that's the bad news). With much less frequency, we get the message
%RMS-I-FLK. file currently locked by another user Couldn't change access to readied domain.
and the procedure continues processing sometimes corrupting the data.
What can I do to fix this problem? Is there something I can do which will keep the boss' interactive sessions from blowing up concurrent menu-driven sessions? Or are there some coding changes I can make in the procedure to test for and trap the conditions?
Signed,
Confused by simultaneous access
Dear Simultaneously Confused,
As you have surmised, your problem stems from conflicting simultaneous RMS file access. The READY command is where the problem occurs.
Most of the time DATATRIEVE programmers and DATATRIEVE end-users operate in a single user, single process context. In this situation, one only has to worry about what
DTR-3
occurs within that process. In the situation which you have described, multiple users are concurrently accessing many domains. This is a much more complex situation in which most DATATRIEVE programmers, including the Wombat Wizard, have some difficulties.
Before we can proceed to the solution to your problem, we need to review the conditions under which simultaneous access conflicts arise. Recall that you can specify in the READY command the mode of access to the domain with READ, WRITE, MODIFY, or EXTEND and control the access of other users with SHARED, PROTECTED, or EXCLUSIVE. It appears that there are 12 possible combinations of "users access" and "other user control" to consider. However, WRITE, MODIFY, and EXTEND are essentially equivalent (with respect to this analysis); these access modes change (or potentially change) the data. READ mode doesn't. Therefore, there are really only six combinations. Consider the following six by six table showing where conflicts arise. "OK" means no conflict; "X" means conflict and the second READY will fail.
SHARED R WME
PROTECTED R WME
EXCLUSIVE R WME
SHARED
R
WME
OK
OK
OK
OK
OK
x
OK
x
x
x
x
x
PROTECTED
R
WME
OK
OK
x
x
OK
x
x
x
x
x
x
x
EXCLUSIVE
R
WME
x
x
x
x
x
x
x
x
x
x
x
x
Since you state that all your procedures control the access of others by the use of SHARED (you allow all access by others) but the boss causes the problem with interactive access (which by default is PROTECTED), the problem is occurring between PROTECTED READ or WRITE with SHARED READ or WRITE. See the area in the box in the table above.
The default access to domains is PROTECTED; this has been the case since the earliest version of DATATRIEVE. However, since version 4. 0 of VAX DATATRIEVE, it has been possible to specify the default access control. The logical DTR$READY_MODE, if specified, will override the default of PROTECTED. One easy way around your problem is to slip the following line of DCL code into your boss' LOGIN.COM file:
$ASSIGN "SHARED" DTR$READY_MODE
This will work just fine if your boss only knows how to ready domains without specifying any mode control. However, if your boss is like mine, he is compulsive, unpredictable, and slightly crazy, and this change in his defaults ready mode will not completely solve your problem.
A more realistic way to attack your problem is to modify the DATATRIEVE code in your procedures. The apparent unpredictability of your procedures when the file access conflict occurs is due to the state of SET ABORT. If SET ABORT is in effect, DATATRIEVE will abort the remainder of your procedure or command file when
1. an ABORT statement is executed 2. a CTRL/Z is enter at a prompt 3. a logical or syntax error occurs during the execution of a command or statement
(except the DELETE command)
DTR-4
It is the third case which you are experiencing; the "%RMS-E-FLK" error is treated as a logical error and your procedure is aborted if ABORT is set. If ABORT is NOT set, then you get the error message, but the procedure continues to execute.
Thus, if you want to make sure that you don't do any processing if you can not gain access to a domain, then your procedure should contain a SET ABORT before any critical READY. If the READY fails, all the other statements and commands will be ignored.
Now we have taken care of everything except the case when you get the informational message
%RMS-I-FLK, file currently locked by another user Couldn't change access to readied domain.
In this case, the menu-driven process initially had the domain readied SHARED READ. The boss then accessed the domain with a PROTECTED WRITE. Then the menu-driven process tried to change the ready access to SHARED WRITE. This last READY fails with the error message above and the domain is left in SHARED READ access. In this situation, the error is only an INFORMATIONAL error not a FATAL error. So even if ABORT is set, the procedure will not abort!
There are a couple of work-arounds to this. First (and simplest) is to always ready domains in menu-driven application as SHARED WRITE. This will cause the boss' ready to fail rather than the menu-driven application's. The disadvantage to this is that if the menu-driven application has a record selected (even if the record is not going to be changed) there will be a record lock on that record which may block searches by other users. Second is to explicitly re-ready the domain with ABORT set. Consider the following ways to ready a domain SHARED WRITE:
Case 1
Case 2
SET ABORT READY FOO SHARED WRITE
SET ABORT READY FOO SHARED READ FINISH FOO READY FOO SHARED WRITE
In Case 1, if the domain FOO is already readied SHARED READ, and the RE-READY fails with an INFORMATIONAL error message, the procedure is not aborted. In Case 2, the domain is explicitly readied SHARED READ. If someone else has the domain exclusively, this READY will fail and the procedure will abort. If the ready SHARED READ does not fail, then it doesn't matter if the domain was previously ready or not; it is now ready. It can then be ex pl ici tly FINISHed. Then the following READY SHARED WRITE will either succeed or will fail with a FATAL error (rather than an INFORMATIONAL error) and abort!
We have described how to solve your problem; however, the solutions is not very user friendly in that the ABORT occurs (protecting the rest of the data base) but no message is given (nor can one be given) to the user to alert him/her as to what has happened.
A much "cleaner" solution to this problem would be to get the DATATRIEVE developers to add a new function to DATATRIEVE which would report the status of domains. When you type SHOW READY, you get a report of the status of all readied domains. That looks like:
DTR-5
DTR> ready foo DTR> show ready FOO: Domain, RMS indexed, protected read
If we had a function like FN$DOMAIN STATUS(domain_name) which would return the status "Domain, RMS indexed, protected read" or the string "Not ready", then you could use the following type of DATATRIEVE code:
SET NO ABORT READY FOO SHARED WRITE SET ABORT if (fn$domain_status(FOO) not containing "shared write") then begin
print "Domain FOO could not be readied for write access." abort "Aborting procedure." end
I guess someone will have to put in a PIR (product improvement request) for such a function. Hope this solves your problem and your domains can be simultaneously accessed.
Signed,
The Wombat Wizard
Using DATA'l'RIEVE Record Definitions with the SORT/MERGE Utility
Bart z. Lederman, WU World Communications, New York, NY 10004-2464
Most VMS users are (I hope) familiar with the SORT/MERGE utility. Apparently, not so many people are aware that this utility can also change file layouts (delete fields or change the positions of fields in records), eliminate duplicate records, change file organization (sequential to indexed or variable length to fixed length records), and it can often perform these functions faster than DATATRIEVE.
One of reasons SORT/MERGE isn't used as often as it might be is that in order to do such functions as record re-organization, you have to describe where all the fields are in the record. This normally means writing a sort specification file with the fields identified by size and position in the record. Laying out a record and counting bytes to find the locations of all of the fields is tedious and error-prone.
Fortunately, if you have a record definition for your file in the CDD such as a DATATRIEVE record definition, then SORT/MERGE can use the same definition and you don't have to try to figure out where the fields are; you can simply use the same field names you used in DATATRIEVE. This feature is not very well documented in the SORT/MERGE manual, and there are a few oddities to using it. So I will describe what I have learned about it.
Consider the following very simplified DATATRIEVE record definition named ORDER RECORD in CDD node CDD$TOP.SHIPPING
DTR-6
01 ORDER_REC. 10 ORDER NUMBER USAGE INTEGER. 10 SHIP TO. 20 NAME PIC X(lO). 20 ZIP CODE PIC 99999. 10 SOLD TO. 20 NAME PIC X(lO). 20 ZIP CODE PIC 99999.
Suppose I want to sort this file by ORDER_NUMBER. First I must create a sort specification file which tells sort where this record is and what field to use for sorting. I will call this EXAMPLEl.SRT, and it will contain the following:
/CDD_PATH_NAME="CDD$TOP.SHIPPING.ORDER_RECORD" /KEV=(ORDER_NUMBER)
Now all I have to do is tell SORT to use this specification when it sorts my file. For example:
$ SORT/SPEC=EXAMPLEl INPUT.FILE OUTPUT.FILE
where INPUT.FILE and OUTPUT.FILE are of course the names of the files which have my data to sort and the file into which the data will be placed; they can both be the same name. Notice that I didn't have to put any "/KEY=(xxx)" qualifiers on the DCL command line because there is one in the specification file.
Special handling for group fields
In the above example record, there are two ZIP CODE fields. A problem arises in sorting one of these fields, because SORT/MERGE doesn't know quite as much about CDD records as other products (or as much as it should know). You can't just specify a path name such as:
/KEV=(SOLD_TO.ZIP_CODE)
as you would in DATATRIEVE or other languages. Fortunately, there is a work-around suggested by a member of the CDD support group in the Telephone Support Center that appears to function properly (at least the times I've tried it), and that is to pretend to sort on the group header. The sort specification file would become:
/CDO_PATH_NAME="COO$TOP.SHIPPING.OROER_RECORO" /KEV=(SOLD_TO) /KEV=(ZIP_COOE)
Even though SOLD_TO isn't a "real" field, this seems to make SORT/MERGE happy and allows it to find the right ZIP_CODE. I've also sent in an SPR on this, and perhaps some day this may be improved.
Reorganizing files I extracting fields
As an example of how SORT/MERGE can be used to reduce data, I decided to try producing a subset of the system authorization file. 1 This would reduce the size of the
!:_./ A record definition for SYSUAF.DAT is in the DTR/4GL SIG Library collection and
appears in "Accessing SYSUAF.DAT and QUOTA.SYS with VAX DATATRIEVE", by Donald E. Stern, Jr., DECUS U. S. Chapter SIGs Newsletters, Volume 1, Number 2, pp. DTR-12 DTR-14, October 1985; and an Errata in Volume 1, Number 4, pp. DTR-17 - DTR-18, December 1985.
DTR-7
record, eliminate blank spaces and fields I don't need, and in this example allows extraction of only "nonsensitive" data. It also allows me to experiment with the data without accidentally changing or locking the system authorization file. My sort specification file SYSUAF.SRT looks like this:
/CDD_PATH_NAME="CDD$TOP.DTR$USERS.SYSTEM.SYSUAF_RECORD" /KEY= (USERNAME) /DATA=USERNAME /DATA=ACCOUNT /DATA-OWNER /DATA=DIRECTORY /DATA=LOGFAILS /OATA=DATE_LAST_INTERACTIVE_LOGIN
and the DCL command I used with this file was
$ SORT/STAT/SPEC=SYSUAF SYS$SYSTEM:SYSUAF.DAT SYSUAF.SEQ
I received an error message from SORT because the input file is indexed and I had not created a blank indexed file into which SORT could insert the data: so it went ahead and created a sequential file, which happened to be what I wanted anyway. If I had used an additional switch to tell SORT that I wanted a sequential file the error message would not have been produced. Note again that because a CDD record definition is used, all that is necessary to produce a reformatted output record is to name the desired fields in the desired order. Also note that when you are converting from one record layout to another, the one you use in the sort specification file is the INPUT file record layout.
Benefits
There are times when a domain contains a large number of records, and each record contains many fields: yet a report has to be done on only a few fields, or must be done by sorting the data on a field which is not a key, or by sorting in descending order when the key is ascending. In these situations, it may be faster to sort the data into a sequential file with SORT/MERGE, and then report on it without sorting in DATATRIEVE. This is especially true if the /DATA option is used in SORT/MERGE to pull out only the fields which are actually needed, and this can in turn save a significant amount of disk space.
Special note for PDP-11 users
There is a SORT-11 utility available for RSX (and, I think, RSTS) which has most of the functionality of VMS SORT/MERGE, especially SORT-11 Version 3. Unfortunately, it can't read DATATRIEVE dictionaries, so you have to describe the fields individually using the /FIELD command and giving the position and size. However, it is often well worth the effort especially when reporting large domains. DTR-11 often runs out of pool space when doing complicated reports, and especially when sorting large domains. By using SORT-11 first to put only the necessary fields into a sequential file which is already properly sorted, the DATATRIEVE report will take much less time to execute and reports which would have failed for lack of pool space may be obtained.
DTR-8
VAX RALLY Application Development Topics
Anthony D. Rogers
VAX RALLY is a fourth generation application development system from Digital Equipment Corporation. This article is the first in a series that will describe an assortment of special techniques that customers have found useful when developing applications with RALLY. The theme of this article is form/report formatting. The following topics are covered: computed text fields, multiline text fields, floating aggregate fields, and first/middle/last formatting.
Digital Equipment Corporation
110 Spitbrook Road (ZK02-2/K29)
Nashua NH, 03062
Computed Text Fields
One technique for use with VAX RALLY that is useful in many applications is to define a computed field that concatenates data fields and string constants together. Take as an example an employee name that is defined in the database as 3 text fields, FIRST, MIDDLE, and LAST. That's fine for data entry and is especially useful for queries, since it allows people to query on the different fields separately, but on reports, people normally prefer to see names displayed in a more natural way.
The solution to this is very simple. Define a computed field to display the formatted name, and mark the three data fields as non-displayed. The computation is defined using an AOL (Application Development Language) procedure:
fr.formatted name := fr.first I I ' ' I I fr.middle I I '. ' 11 fr.last;
The double bar (" I I") is the AOL concatenation operator.
Andiooy D. Rogers ls a Principal Softw- F.ngfoeer at Digital Equipment Corporation. He h.. been die VAX RAlLY project leader for two yean, and has been working on die RALLY project for four years.
Multi-line Text Fields
There are two ways to handle multi-line text fields in RALLY:
· Using multi-line form/report fields-limit of 512 characters
· Using a callable editor-no limit on size
Both methods are described below.
Using Multi-line Form/Report Fields
The easiest method is to define an Rdb text field that is large enough to hold multiple lines of text. Use any of the normal RALLY procedures for creating a form/report, and then change the vertical size of the field to be more than one line long. This means changing the end line so that it is greater than the start line.
The length of field~ in RALLY is restricted to 512 characters or less, so this method is useful only for small amounts of text.
If the field is to be used for entering or modifying the text, then you must edit the field's input and validation options:
Input options:
· Lines horizontally scroll: clear
· Up, down and newline can exit field: clear
Validation options:
· Newline characters not allowed: clear
Automatic Word Wrapping
RALLY provides a feature for automatic word wrapping. When this feature is enabled, the user can enter multi-line text without pressing RETURN to separate lines. RALLY will automatically insert a carriage return at the nearest word break each time that the text fills up the width of the field.
Rather than turning word wrap on and leaving it on, we advise that you tum word wrapping on each time that you enter a multi-line field and off when you exit the field:
· use 'set word_wrap' when you enter field
· use 'clear word_wrap' when you exit field
DTR-9
Unfortunately these commands cannot be executed directly from any of the fonn/report action sites; they can, however, be executed from within macros and local functions.
To make your application turn word wrap on and off automatically using macros, just define one macro to tum word wrapping on and one to tum it off, and then save them in a special macro file that is always used with the application. You can then invoke the macros from the action sites directly using the CALL_CMD call type.
To use a local function, write an ADL procedure that sets word wrap on or off depending on the state of a global variable. You must use the ADL aliases for the commands with the CALL_CMD function:
IF turn_word_wrap_on THEN
{ Set word_wrap } CALL_CMD(setpwrtype);
ELSE
Clear word wrap } CALL_CMD(clrpwrtype);
Use the Edit a Packet's Local Function Options fonn to make that procedure the local function for the form/report.
Then define two more ADL procedures, one for the before field action and one for the after field action. Make the before action procedure set the global variable to indicate that word wrap should be turned on and then execute the local function:
{ Set state variable turn_word_wrap_on := l;
{ Use local function CALL_CMD(frfunction);
Make the after action procedure set the global variable to indicate that word wrap should be turned off and then execute the local function:
{ Set state variable turn_word_wrap_on := O;
{ Use local function CALL_CMD(frfunction);
With a Callable Editor
If your application requires that pieces of text more than 512 bytes long must be displayed, then you should use a callable text editor to display the text. Write 3GL code (e.g. BASIC, COBOL) that invokes a callable editor (e.g. TPU, EDT). Store file names in the database, instead of the text, and create RALLY external program links to invoke the 3GL code and pass the file name from the database to the program.
One useful technique is to set up your application so that the user views the text by positioning to the record of interest, then using 'use local_function'. For example, you could have a directory style report that listed all of your employees. To see the resume for any employee you would move your cursor to the employee and press GOLD-M. This would invoke the 'use local_function' command, which would invoke the external program link, which would in tum invoke the callable editor. Use the Edit a Packet's Local Function Options form to set the form/report's local function to call the external link.
Floating An Aggregate Field
When you define a fonn/report aggregate in RALLY, you normally put the aggregate field on the output order for the parent group-one group higher than the group over which the aggregation will take place. This means that the aggregate field, and any text that you create for it, will be positioned relative to the parent group, not to the child group. If there will be a varying number of records in the child group, and you would like the aggregate to float up and down on the page, so that it always appears directly below the last child record, then you must use the "relative positioning" form/report feature. For example, say that you wanted to make the following fomt/report:
Sales by Salespeople
Lew Lasher
9-Jan-1988
$ 12.31
Total
$ 12.31
Tony Rogers
3-Jan-1988 12-Jan-1988 23-Jan-1988
Total
$ 47.43 $ 12.23 $ 8.76
$ 68.42
You do this by putting the aggregate (the total) and its text area (for the word "Total" and the line above the total) within a fonnat group, and positioning the format group relative to the end of the child group. You specify this on the Edit a Group's Display Options Relative to a Group form:
Display below group: ORDERS GROUP
You will usually want to mark the format group as not displayed on first and middle pages, so that it only appears once for each parent group, regardless of how many pages the child records for that child take. Make sure that you always leave room for the format group at the bottom of the form/report.
When using relative positioning, be sure to clear the subform attribute when you create your format groups. The subform attribute is set by default when you create a format group, but subforms are used only to create pop-ups.
DTR-10
First/Middle/Last Formatting
First/middle/last formatting is most often used to create header and trailer pages. It also gives you the ability to specify special formatting for the first page of data for a given parent, for middle pages, and for the last page.
First/middle/last fonnatting can be applied to groups, fields and text areas. It is applied most often with fonnat groups.
Output Orders Are Significant
In ordinary situations you need not be concerned about the order of objects on the output order for a group. In such cases you can think of the output order as an ownership list-a list of the objects owned by the group. However, when using advanced formatting features such as first/middle/last formatting, you should make the output orders for all groups reflect the order that the objects will be displayed. For example, objects that will be displayed only on the first page of a report should always be before objects that will appear on middle pages, and objects that will appear only on the last page should always be at the end of their parent's output orders.
Image Editor State
To help you forsee what your fonn/report is going to look like with real data, the Dialog provides you with the ability to tell the form/report image editor to display the form/report as it will look in different situations. For example, to see how the last page of data for a group will be formatted, use the Change a Group's Image Editor State form to select last page formatting for the group in question:
Page location of group: LAST
Leave the group name blank when you want to set the state for the main group.
Similarly, when you set "start new page" for an object, then the logical page numbers for the object, and all of the objects that follow it in the fonn/report, are incremented by one. By default, you will always be shown logical page 1 in the image editor. There is an example of how to view later pages below.
Header and Trailer Pages
H the parent group is the main group, first, middle and last refer to the entire fonn/report-first page means the first page of the fonn/report, last page means the last page, and middle page means all the pages in between.
Header Pages
To create a header page for a fonn/report, create a format group and put it at the beginning of the main group's output order. Clear the format group's subform attribute, then madt the it as not displayed on middle or last pages:
Do not display on First page:
Middle pages: X
Last page: X
Create the text area explicitly, rather than relying on the image editor to create it for you. Put the header page text area and any special header fields into the header format group just created.
Set "start new page on first page" for the title text to be displayed on regular (middle) pages:
Start new page on First page: X Middle pages: Last page: -
Setting the "start new page" attribute for the title text on the data page is like inserting a form feed right in between the the header page and the data pages. The resulting page break makes the first instance of the data page the second page of the report, so to view it after making this change you must use the Change a Group's Image Editor State form to select page 2:
Page number to display: ____2_
Trailer Pages
Create a format group and put it at the end of the main group's output order. Clear the subform attribute for the format group, madt it as not displayed on first or middle pages, and set "start new page on last page":
Do not display on First page: X
Middle pages: X
Last page: -
Start new page on
First page:
Middle pages: -
Last page:
X
Create the text are for the trailer page text explicitly. Put the text, and any special trailer page fields into the trailer page format group. Because two page breaks occur before the trailer page is formatted, the trailer page is on logical page 3, so you must use the Change a Group's Image Editor State form to select page 3 in order to use the image editor to edit the trailer page:
Page number to display: ____3_
The resulting fonn/report structure will be:
Main Group
I
I
+-------------+-------------+
I
I
I
I
I
I
Header
Data
Trailer
Format
Source
Format
Group
Group
Group
DTR-11
Using First/Middle/Last With Data Groups
If an object is within a data group, first, middle, and last refer to the pages spanned by the current record of the parent data group. If an object has its attributes set so that it is not displayed on first and middle pages, and there are several pages worth of child group records for a given parent value, then the child object will not appear on the first page for the parent, or the middle pages, but only on the last page for that parent value.
For example, above it was suggested that when the data for a group with a floating aggregates spans multiple pages, the floating aggregate should only appear on the last page. To implement this, the format group that contains the aggregate and its label should have the following attributes:
Do not display on First page: X
Middle pages: X
Last page: -
Making First Pages Distinctive
It is common for the child records for a given parent record to appear on more than one page. If you have reports where this happens, you may find it useful to use first/middle/last formatting to make it easy to tell the first page from the overflow pages.
For example, you could create a special text area that is only displayed on first pages, and/or have a special text area that just says "Continued", and have that only appear on middle and last pages. H this technique was applied to the form/report shown above, the first page with information about Lew Lasher might look like this:
Page 1
Lew Lasher
23-Jan-1988 24-Jan-1988 25-Jan-1988 26-Jan-1988 27-Jan-1988
$ 47.43 $ 47.43 $ 47.43 $ 47.43 $ 47.43
While the second page might look like this:
Page 2
Lew Lasher [Continued]
28-Jan-1988
$
29-Jan-1988
$
47.43 47.43
================================
Tony Rogers
23-Jan-1988
$ 47.43
26-Jan-1988
$ 47.43
29-Jan-1988
$ 47.43
To do this, explicitly create a text area for the bar and
a text area for the "continued" message. As noted above,
make the parent group's output order reflect the order in which the child objects will be displayed. Put the first page text (the bar) at the beginning of the parent group's
output order, and the middle/last page text ("continued") at
the end of the output order.
Use the Edit a Text Area's Location on Page Options form to made the first text area as not displayed on middle and last pages, and the second text area as not displayed on first pages.
Use the Text Area to Edit form to explitly select the text areas whenever you to edit them. This will keep the image editor from getting these text areas confused with other text areas in the form/report.
DTR-12
Graphics Applications Special Interest Group
Newsletter
Table of contents
Submissions From the editor Woods meeting minutes
.................................................................. GAP-I .................................................................. GAP-I .................................................................. GAP-2
Submissions
Articles, copies of viewgraphs. tips and tricks. and graphics output are all welcome submissions for the Graphics Applications Special Interest Group (GAPSIG) newsletter. There are many ways to make submissions:
1) Send in a tape. Tapes can be 1600 or 6250 BPI density; VMSBACKUP or RSX BRU formats are acceptable. Your editor uses the Mass-11 word processing system from Microsystems Engineering Corporation, so submissions in this format are okay. Otherwise, provide straight ASCII documents. Please place any charts into a ~eparate file. And, please enclose a letter with your address and any notes and description for format that you desire.
2) Send in paper. Hey, your editor can type and chew gum at the same time, so don't be afraid to send in hard-copy. And, if all you have is notes, FINE! Send them in!!! We have many folks who can take the ideas and flesh them out with English language extensions. Questions are desirable, too; DECUS should. in the opinion of your humble editor, be a place to trade information, so questions count for as much as answers here.
3) Mail to HAYS on DCS. If you have a DCS account and the article is all textual, mail it to HAYS on the DCS system.
Your editor's address appears in the From the editor section, so mail yours in today!
From the editor
Bob Hays KMS Fusion, Inc. 3621 South State Rd. Ann Arbor, MI 48106
This is a sparse issue of the newsletter for many reasons; including the upcoming Symposium (the newsletter is prepared two months before the issue date on the cover, so this is being done in April) and new plans growing from the GAPSIG Woods Meeting in March. I personally found the meeting really helpful thanks to many ideas forthcoming from all the attendees. Combined with the newsletter survey, there has been much new thinking in my cubbyhole.
Most obvious is the changeover to two-up format. or landscape mode printing much like other SIG newsletters. While some newsletter survey replys disliked landscape format, more wanted a unified lookand-feel (hope another computer vendor isn't taking a bite out of this issue).
I'd like to try some new things out which were discussed by the SIG steering committee. First. let's try a "Graphic-of-the-Month". For this, submit any single black and white graphic image that conveys a useful idea and was created on a DEC-based system or with the help of a DEC-based product.·
GRA-1
Include a short (100 or less word) description of: how the image was manipulated and generated. what equipment was used, any neat portions of algorithms applied, etc.
Which leads in to another desired end result: I want more graphics in the Graphics Applications SIG newsletter! Please, include final-quality plots, graphs, images, etc. for articles if you have time. I know people are doing really fun and useful things graphical today, so let's see it.
I plan to provide a three-year index every year in a newsletter issue. Which issue is up-in-the-air. since it depends on page counts and other mundane things. However, many members (myself included) have always wanted to find that certain article. The initial index will be by subject and possibly. space permitting, by title.
We want your ideas for a new logo! GAPSIG has lacked a spiffy, modern logo for quite long enough. Submissions for this also should be addressed to me at the above address, and should be in hard-copy form.
I've blow on long enough for this issue. Suffice it to say that there are new plans and additions to your GAPSIG newsletter planned over the next year!
Woods meeting minutes
Mike York
The DECUS GAPSIG Steering Committee woods meeting was held in Phoenix, Arizona, March 26 and 27. Those attending were:
Bob Goldstein Bob Hays Rick Landau Mike McPherson Bijoy Misra Jim Sims Henry Schneiker Paul Waterstraat Mike York
Image processing working Group Coordinator Newsletter Editor Counterpart Library, Vice Chair SIG Chair Engineering Working Group Coordinator Hardcopy Working Group Standards Coordinator Member at Large
The woods meeting began the morning of March 26 with a review of the Anaheim Symposium. Overall. the Steering Committee members had quite favorable reactions to how the GAPSIG performed at Anaheim, but a few problems were brought up: cancelled sessions were more of a problem than usual since some speakers couldn't make the symposium due to budgetary considerations and some sessions were scheduled by someone other than the intended speaker, with the actual speaker being notified too close to the symposium to adequately prepare.
The campground was another concern; security issues and the lack of traffic through the campground were noted. It was suggested that more announcements about the campground be included in symposia sessions at future symposia.
There was also some discussion about session notes. It was pointed out that Digital is submitting much more material for the session notes, but many other speakers are failing to submit material. It was explained that many presenters prepare for sessions in the two weeks before sympo!'ia. long after the deadline for session note submissions. There was some discussion about the GAPSIG publishing its own session notes, but that idea was abandoned when it was revealed that the session notes could not then be pre-sold. It was then suggested that the GAPSIG could publish an addendum to the session notes. to.
GRA-2
include materials submitted after the deadline. It was finally decided to have Steering Committee members and other volunteers gently remind scheduled session speakers of the deadline for session note submittals.
Members of the Steering Committee then gave brief reports on their functional areas. Henry Schneiker, coordinator for the hardcopy working group, reported that he has not yet been able to schedule a meeting with Digital concerning hardcopy futures, but would work on scheduling the meeting within the next few months.
Mike McPherson, Library Coordinator. reported that a Library Committee meeting was recently held in Washington. D.C. Mike reported that the meeting had a good representation of SIGS and was well organized. Discussed at the meeting were catalog restructuring. indexing the catalog. and electronic distribution of library programs.
Bob Hays. Newsletter Editor. was next. Bob reported that a survey of newsletter readers had been conducted. The survey results indicate that readers:
- want more technical articles - want more how to articles - don't like landscape orientation - want common format for newsletters - want an index - want reviews of library programs - want articles rated by expertise - want a list of current versions of products
Bob then went on to briefly discuss other newsletter issues, such as electronic submission of articles. color in the newsletters, and a graphic of the month feature.
There was then some discussion about using the newsletter for publishing symposia information. The general consensus of the Steering Committee was that' the lead time for publishing the newsletters was too long to be useful for symposia information. Some other forms of communication were then briefly discussed, such as bulletin boards & networks, a special GAPSIG publication, and LUG chair mailings.
Paul Waterstraat. the new Standards Coordinator, discussed the turnover from the old standards coordinator, Jim Flatten. Paul reported that there are three ANSI meetings a year, which prompted some discussion about budgeting for attending the meetings. There was then some discussion about the GAPSIG sponsoring a simple "standard" graphics application that could be written using various standards and used as a basis for comparison of standards.
A general discussion about third party involvement in the GAPSIG followed. The SIG has historically had a great deal of third party involvement, because Digital had few serious graphics products until a few years ago. However. with the emergence of workstations and laser printers. Digital is now in the mainstream of graphics products. Should the SIG actively solicit third party involvement? The consensus of the Steering was yes, but commercialism guidelines will have to be adhered to.
A brief discussion about the technical content of symposia sessions followed, with the general opinion of the Steering Committee being that over all. the technical content of symposia sessions has gone down, but the GAPSIG sessions have retained their technical content.
The rest of the day. and one hour the following morning, was spent on each Steering Committee member giving a short presentation on the particular applications they are involved with. While the content of these presentations is too much to publish in these minutes. it was apparent that there is a tremendous amount of experience and expertise on the Steering Committee, and it was very interesting to.
GRA-3
see what the other Steering Committee members are involved in. The presentations were very well received by the Steering Committee.
A good portion of the second day was spent revisiting a problem the SIG has been dealing with for some time: should the SIG expand its scope to include more activities pertaining to workstations. even if some of these activities may not directly relate graphics? This question was brought up after some complaints were received in Nashville about a lack of support for workstations is DECUS. After a great deal of conversation, the Steering Committee reached a consensus that the GAPSIG is supporting workstations within the scope of its charter, and to expand its scope would not be a good idea.
The next item of business was some discussion about a questionaire to be distributed to the GAPSIG membership. It was decided that the questionaire will be one sheet of paper. and will probably be distributed at symposia, published in the newsletter, and a random mailing to GAPSIG members.
The last item of business was assigning tasks for the upcoming symposium. Bob Hays will be the session chair coordinator. Mike McPherson will be the campground coordinator, and Henry Schneiker will be the on-site coordinator.
GRA-4
THE
DEVIAS
LETTER
From the Editor's Keyboard .............................. 1
In this Issue ........................................... 1
Contribution guide l i nes .................................. 1 Ten Years Ago This Month................................ 2
IAS Product Panel ....................................... 2
The Program of the Month Club . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
(::\ (::\ THE DeVIAS Letter All the News That Fits, we print
( l ))
l IAS -1\@/~ U 21-Network- 0 0 0
'iiT ( l ) )
~~) /Mr Spot\
(
)( ( (
Mr Vax VMS
~~) )
FROM THE EDITOR'S KEYBOARD
The following editorial is solely the opinion of the author, and does not represent the views of DECUS or of Digital Equipment Corp. Responses to the Editor's remarks are heartily welcomed.
I don't know what to do, it's almost deadline, and we have no hardware problems to report. (The roof is still leaking, but not over the printer room or my office, it's the conference room this month!)
Just to keep things lively, Milt Campbell has replied to a previous editorial where I stated, "I don't think it would cost the RTll group much to provide a fully commented distribution on a suitable media as an extra cost option." Turns out your editor didn't know beans about the mechanism of RTll distribution. Milt informed me that if you purchase the RTll source license and distribution, you get just that, Fully commented sources. (Just what I asked for.) My apologies to the RTll developers and to Milt.
As you may have noticed, (if you read the front of the May issue,) your editor has agreed to accept an even more involved role with the SIG's Newsletters. Since I stepped into Bill Leroy's shoes at the worst possible time, (I had to wrestle with Budget, work out the bugs on a new set of operating proceedures, and prepare for Spring DECUS) the DeVIAS letter has taken a back seat for a time. Be advised that the Letter is my first love, and it will NOT suffer greatly as a result of
my new responsibilities.
IN THIS ISSUE
Your editor has finally caught up with things, and has included in this issue a talk from the fall Symposium on the IAS product panel by Jack Lockhart of DEC, manager of the mature software products group. If you really want to help Jack direct the efforts of the IAS maintenance crew, any feed-back from readers would be greatly appreciated.
CONTRIBUTION GUIDLINES
Contributions of articles, SPR' s, letters, etc.. will be accepted in any form, (including notes jotted on stained tablecloths.) They will be more happily accepted in the following formats:
Paper submissions will always be accepted. Publishing may be delayed until the editor gets some time at the keyboard to convert them to our current format. We can accept submissions by FAX.
Contributions may be submitted on tape, (800,1600, 3200 or 6250 BPI,) DECtape II, and DecMate or RTll floppies. We're not fussy, we'll even accept paper tape or cards. We can read any IAS/RSX, RTll, VMS format. Any media sent to us will be promptly returned.
We have 2400/1200 baud modems on our !AS system and our VAX, with KERMIT for electronic submission. Give the editor a call @ (312)-791-8075 (preferably later
IAS-1
in the day,) to obtain access info, etc.
If you have a problem you would like to submit to the Devias Demon, send it to the Editor at the following address. Answers to problems from members (or anyone) should also be sent to the Editor.
Frank R. Borger Michael Reese Medical Center Department of Radiation Therapy Lake Shore Drive at 31st St Chicago, IL 60616
TEN YEARS AGO THIS MONTH
A report on the DECUS Spring
Symposium mentioned the DEC announcement
of "TRAX, a totally new operating system
for transaction processing. This system
is similar in function to IBM CISC-type
systems. All screen formatting, error
recovery,
journaling,
transaction
queuing, etc. is handled by TRAX. All
the user has to do is write the
application code in either BASIC PLUS- 2
or COBOL. " (Oh where oh where has my
little Trax gone? ed.)
DEC also anounced the "ONE PRODUCT
STRATEGY" whereby RSX-llD and IAS would be combined into one integrated system. !AS 3.0 is planned for release in late 1978 or early 1979~
The issue also contained an early release of "Files-11 QIO notes" an article by Ralph Stammerjohn (updated by Mike Blake-Knox.) For users who wanted direct QIO access to the Files- 11 disk structure, it was the first light on a
subject never properly documented by DEC.
And finally Glen Everhart announced in a letter the availability of the
latest RSXllM-RSXllD-IAS version of FOCAL!
I !AS PRODUCT PANEL I
Jack Lockhart, Manager Mature Sorftware Products Group
Digital Equipment Corporation
There is an ongoing Digital committment to IAS.
Most of the user community today is in 2 or 3 different sections. There is a strong contingent in the intelligence agency, who typically does not come to DECUS, there is a commercial segment, and a couple of spin-offs in the newspaper field. Over the last couple of years, Digital' s efforts toward !AS have grown, and further growth is expected over the next couple of years.
Ve are also beginning to do a better job of field support for !AS. As the community grows, and most of the growth is in the government area, that increases our ability to provide support for the entire community.
Digital's basic Engineering goals as reguards IAS are as follows:
Increase reliability.
Increase support responsiveness.
We believe we have done a lot to increase the reliability of the product, but we still have a ways to go to improve support. At present we have a backlog of approximately 20 SPR' s. The developers are holding their own, last month the number of resolved SPR's equaled the number of new SPR's. Update D is now in field test, and we are generating internal SPR's and getting problem reports, (QAR's) from the field. Once that these are resolved, we hope to get the backlog of SPRs down.
Telephone support service.
There is telephone support for !AS. That is one area we have target that needs some improvment in the way that we organize that support.
Improved predictability.
It's still not predictable when releases of updates occur. Essentially we have a five man engineering organization that covers a lot besides IAS. IAS is a full blown operating system with a lot of complexity to it. We must not only maintain the operating system, but all the layered products. It takes a lot of work to keep up with it. The end result is that we are not as predictable as we would like. Ve are always looking for information from the
IAS-2
user community to help us prioritize our efforts. Vhat new features should be added, what is valuable to you and what is not valuable to you, what we should not be wasting our time on.
Update D
Update D has been in field test since September. There are a number of problems that have been found with layered products and have been resolved. We have a tentative date of closing field testing in January or February. If we feel we need more testing before we put the product out we may extend field test. (Editor's note, field test was finished in January.)
Some of the functionality that you probably will be interested in in update D include:
o DUMU, which is a multi-user MSCP handler which supports Digital Storage Architecture devices. It will help you with some throughput issues and conserve system resources.
o Crash support has been extended to non-tape devices.
o RMS version 2 is now supported. It provides disk overlay RMS. It does NOT support Supervisor mode libraries, and does not support clustered libraries.
o Sort Version 3.0 is supported.
o There are some improvements to the task builder, mainly dealing with Autoload vector handling.
o Datatrieve 3.0 is supported.
o Fortran 5.0 is supported.
o Macro 5.5 is supported.
o VT3xx terminals are supported.
o A number of bug fixes are done.
Ve also provide a limited amount of strategic consulting to what we consider strategic accounts, which allows access to internal engineering resources. Essentially this has to be pre-arranged, via an agreement between the account and Digital, that they want to take advantage of this kind of service. There
are some times and some commitments that Digital makes, and there is a pre~ arranged escalation criteria and some commitments of what kind of services Digital can provide and what level of services.
Question and Answer
Question: On your DUMU handler. In the past, DEC hasn't supported multi -user disk handlers. Is this going to be a complete support? For example, can you do a sysgen etcetera on disks connected to the second controller?
Answer: I don't know. Give Nancy Fay Autenzio, the product manager for IAS a call, and she can get the specific technical information to you.
Question: Your slide showed support for Fortran version 5.0. I note that on the M and M+ side, version 5.2 is already out in the field. Is support limited to 5.0?
Answer: As far as I know, support is limited to version 5.0.
For the layered products, of ten times there is nothing significantly done to the layered products. After you build the new operating system, you test the layered products underneath it. Just because it works under C may or may not mean that it works under D. Whatever the current version of the layered product is at the time it was tested determines what version of the layered product has been validated, and as far as we know, works correctly. In some cases that means that some work was done, probably to the operating system, to make that happen. In some cases little of anything was done. It is a statement of validation rather than a statement that any changes were made to the operating system.
Question: Does DEC have any intention of supporting C under !AS?
Answer: No.
Question: Does DEC have any intention of supporting Ethernet under !AS, (for example DECNET phase IV?)
Answer: There is no intention of supporting DECNET phase IV under !AS. In fact, as you know there has been considerable concern about DECNET-IAS
IAS-3
al together. It currently only supports Phase III, it really in the SPD only allows you to talk to other IAS systems. VMS is going to be going to phase V, the other PDPll operating systems are or will be going to phase IV, IAS DECNET will probably be facing retirement before too long.
Question: So there is no intention of supporting Ethernet in any fashion?
Answer: There is no intention of supporting it through IAS decnet.
THE PROGRAM OF THE MONTH CLUB
One of the things wrong with hard copy documentation of short BASIC programs, indirect command files, etc is that with no compiler there is no nicely paginated output, no date/time stamp, and no indication of disk and uic.
This program produces a paginated output listing, along with a specification of Date/time disk and UIC.
. title .ident .mcall .mcall .mcall .mcall .mcall .mcall
Note that the header line should be customized with the local organization's name, etc. It is designed for 132character output, but output to 80character devices will still have all the relavent header information .
pag /mrhOOl/
finit$,fsrsz$,qiow$,dir$,call,return open$w,open$,open$r,get$,put$,close$ csi$,csi$1,csi$2,csi$sw,gmcr$,exit$s,gtim$ gcml$,rcml$,gcmlb$,print$,csi$nd fdbdf$,fdat$a,fdrc$a,fdop$a,fdbf$a
fdop$r,nmblk$
pag paginate listing program
provides listings of programs etc on a paginated basis header lines contain device, uic name etc and date time listing a max of 55 lines/page so dont print over fold
;
;calling sequence mcr>pag[elist] dev:[uic]name.type
optional switch "/ta" puts leading tab in for use with lpl so can punch and put in ring binder
mcr>pag[elist] dev:[uic]name.typ=dev:[uic]name.typ
;' if no output file spec is given, the output defaults to: sy:name.lst
;and the file is automatically spooled to lp:
;
; evf's and luns
;
outlun =1 outevf =1
;output file lun ;and evf
tilun =2
;terminal io lun
tievf =2
;and evf
tiflun =3
;terminal "file" lun
tifevf =3
;and evf
influn =4
;the first in-file lun
infevf =4
;and evf
.sbttl main line code
start: finit$
;set up for file io for file i/o
jsr
pc, . rdfui
;get uic i'm running under
IAS-4
5$:
6$:
7$: 22$: 4$: 44$: 441$: 442$: 444$:
222$:
rnov gcrnl$ crnpb bne exit$s tstb bpl dir$ dir$ exit$s rnov
rnov rnov csi$1 csi$2 bitb bne clr csi$2 bitb beq rnov rnov jsr bitb bne dir$ dir$ exit$s fdop$r open$r bee dir$ dir$ exit$s
mov mov mov crnpb beq sob
movb mo vb movb rnov mov mov rnovb sob tst beq csi$2 bitb beq mov mov jsr bitb bne mov
rl,uic
;save the uic (binary)
#gcblk
;get the command line
#ge.eof,gcblk+g.err ;end of file on command input ?
5$
;no
;yes, quit
gcblk+g.err
;any other errors ?
6$
;no
#erpri
;report command line file error
#cmderr
#1,inpflg
;set flag that input file spec seen
;fill in pointers in csi block
gcblk+g.cmld+2,csblk+c.cmld+2
gcblk+g.cmld,csblk+c.cmld
#csblk
;and parse it
#csblk,input,#switch ;try for an input spec
#cs.nmf,c.stat(rO) ;was input spec'd
7$
;br if it was
inpflg
;else clear flag that says it was
#csblk,output ;default to file spec to be spooled
#cs.dif ,c.stat(rO) ;did they spec a uic ?
22$
;no
#csblk+c.dird,r2 ;yes point to descriptor
#uic,r3
;place to store it
pc,.ascpp
;convert string to octal number
#cs.nmf,c.stat(rO) ;is a name given?
4$
;yes
#erpri
#namerr
#infdb,,#csblk+c.dsds ;fill in file name to be listed
#infdb
;and open it
44$
;br if ok
#erpri
;else report problem
#namerr
csblk+c.dsds+lO,rl rl,namlen csblk+c.dsds+12,r2 (r2)+, #'. 442$ rl,441$
#'l,(r2)+ #'s,(r2)+ #'t,(r2)+ namlen,rl csblk+c.dsds+l2,r2 #namsav,r3 (r2)+,(r3)+ rl,444$ inpflg 333$ #csblk,output #cs.dif ,c.stat(rO) 222$ #csblk+c.dird,r2 #uic,r3 pc, .ascpp #cs.nmf,c.stat(rO) 333$ namlen,rl
;change output file type to "1st ;get length of name string ;save length ;and start ;found the "·" in the file name ;yes ;no, get another ;had to have "·" so assume ok ;overwrite "typ" with "1st"
;get length again ;and start ;point to save area ;save name string
;was there an input file spec ;if not, default to name.1st ;get output file name ;did they spec a uic ? ;no ;yes point to descriptor ;place to store it ;convert string to octal number ;is a name given? ;branch if name ok ;get length again
IAS-5
244$: 333$:
2$: rego: 11$:
12$:
in:
333$: 335$: 336$:
mov
mov mo vb sob fdop$r open$w
bee dir$ dir$ jmp
csblk+c.dsds+12,r2
#namsav,r3 (r3)+,(r2)+ rl,244$ #outfdb,,#csblk+c.dsds
#outfdb
2$ #erpri #filerr die
;point to csi block ;point to save area ;restore name string
;fill in filename of output file ;and open it ;br if open went ;tell him file problems
;and close input, then exit
.sbttl transfer to listing file
dir$ mov movb mov mov tst
beq mov mov jsr mov mov jsr sub mov put$ mov mov tst beq mov mov jsr mov mov jsr
mov mov jsr sub clr mov
put$ get$ cmpb beq
tst bpl dir$
dir$ jmp mov add tst beq
put$ br
put$
bee
dir$
#gettim
;get date and time
#1,page
;set page # to 1
infdb+f.fnb+n.unit,devnum ;fill in device unit number in block
#edblk,rO
;set for edmsg
#hdrmeO,rl
;address of input line
tabflg
;want leading tab ?
11$
; br if not
#hdrmea,rl
;else change format
#hdrbf0,r2
;address of buffer
pc,$edmsg
;fill in name
#hdrmel,rl
;address of buffer
#page,r2;address of buffer
pc,$edmsg
;fill in page #
#edblk,rO
;get length of xfer
rO,outfdb+f.nrbd ;tell sys length
#outfdb,#edblk ;put the first header line
#edblk,rO
;address of output buffer
#edmesO,rl
;address of input line
tabflg
;want leading tab ?
12$
;no
#edmesa,rl
;change input line
#edbuf,r2
;address of data buffer
pc,$edmsg
;do device and uic
#edmesl,rl
;point to 2nd decode line
#edbufl,r2
;and 2nd data buffer
pc,$edmsg
;do name.type;version
#edmes2,rl
;point to last decode line
#edbuf2,r2
;and last data buffer
pc,$edmsg
;and do date, time, page #
#edblk,rO
;sub start of resultant header line
r5
;clear lines/page counter
rO,outfdb+f .nrbd ;set length of variable line
#outfdb,#edblk ;put out variable header line
#infdb,#bufl,#132. ;get a record
infdb+f.err,#ie.eof ;end of file
done
;yes
infdb+f .err
;no
333$
;if plus ok
#erpri
#f ilerr
done
;and exit
infdb+f.nrbd,outfdb+f.nrbd ;transfer size of line
tabflg,outfdb+f .nrbd ;adjust for leading tab
tabflg
;is there leading tab
335$
;no
#outfdb,#bufO ;yes
336$
#outfdb,#bufl ;and put the record
334$
; br if ok
#erpri
IAS-6
334$: done: 1$: die:
dir$ #filerr
jmp
done
inc
r5
cmp
r5,#54.
blt
in
clr
r5
inc
page
jmp
rego
tst bne print$ hr
close$ close$ exit$s
inpflg
1$ #outfdb
die
#outfdb #infdb
;and exit ; count a line ;near end of page ? ;no, just do next line ;yes, clear counter ;inc page number for printout ;print header line again ;normal exit ;spool the output ? ;not if two files were specified ;spool the file to lp ;and quit ;close the output file if not spooled ;close input file ;and exit
i' nfdb:
.sbttl .sbttl
fdbdf$ fdat$a fdrc$a fdop$a f dbf$a
fdb's input f db
r.var,fd.cr ,bufl,132. influn infevf
;define fdb block ;file attributes ;record ; file name
;evf
.sbttl
;
outfdb: fdbdf$ fdat$a f drc$a fdop$a
fdbf$a
output fdb
r.var,fd.cr
,bufl,132. outlun
outevf
;define fdb block ;file attributes ;record ;file name
;evf
.sbttl
t' ifdb: fdbdf$
fdat$a
f drc$a
fdop$a
.
fdbf$a
t' idsds: . word
.word
.word
ti:
. asci i
lti=.-ti
.even
terminal fdb
r.var,fd.cr
, bufl ,80.
tiflun, tidsds tifevf
;define fdb block
;files attributes ;record ; file name ; file evf
lti,ti 0,0 0,0 /ti:/
.sbttl
error messages
erpri: qiow$ io.wvb,tilun,tievf,,,,<primes,prilen,44> primes: . asci i /***PAG---/ prilen=.-primes
.even
namerr: qiow$ io.wvb,tilun,tievf,,,,<nammes,namlng,53>
nammes: .ascii /Bad file name***/
namlng=.-nammes .even
filerr: qiow$ io.wvb,tilun,tievf,,,,<filmes,fillen,53> filmes: .ascii /Error on file io***/
fillen=. -filmes .even
IAS-7
cmderr: qiow$ io.wvb,tilun,tievf,,,,<cmdmes,cmdlen,53> cmdmes: . asc ii /Error on indirect command file***/
cmdlen=.-cmdmes .even
.sbttl miscellaneous
.sbttl
csi control block
csi$ csblk: .blkb c.size
.even
.sbttl
gcml control block
;
gclun =tilun
gcblk: gcmlb$ 2,rnp,,gclun
.sbttl
switch table
;
switch: csi$sw ta, 2, tabflg
;specify switch itself
csi$nd
.sbttl
;
tabflg: .word edlen: .word gettim: gtim$ bufO: .byte bufl: .blkw
fsrsz$
0 0
eod, b11uf2
132.
3
other things
;flag to put in leading tab ;length of header line ;get time in 2nd edmsg buffer ;leading tab ;the record buffer ;make room for file storage
.sbttl
edmsg data
;
hdrmeO: . asci i /%F%NMichael Reese Medical Center
I
.asciz /Department of Medical Physics Computer%25S%X/
.even
hdrmea: . ascii /%F%N%8SMichael Reese Medical Center
I
.asciz /Department of Medical Physics Computer%25S%X/
.even
hdrbfO=infdb+f.fnb+n.fnam
hdrmel: .asciz I Page %DI
.even
edmesO: . ascii /%NListing of %2A%M:/ ;device and number
.asciz /[%B,%B]/
;uic
.even
edmesa: . ascii /%N%8SListing of %2A%M:/;device and number
.asciz /[%B,%B]/
;uic
.even
edbuf: .word infdb+f .fnb+n.dvnm ;device string
qevnum: .word 0
;device number
.word guic
;group uic
.word muic
;member uic
;
uic:
;start code stores uic here
muic: .byte 0
;save member uic here
guic: .byte 0
;save group uic
;
;storage for file name for output
inpflg: .word 0
;flag for input file specified
namlen: .word 0
;length of string
namsav: .blkb 40.
;buffer to store string
;
edmesl: .asciz /%X%4S/
;name,type version
IAS-8
.even edbufl=infdb+f .fnb+n.fnam
;
edmes2: .asciz /on %Y at %3Z .even
edbuf2: .blkw 6 page: .blkw 2
;
;now the output buffer
;
edblk: .blkb 150. .end start
;point him to input fdb Page %D%2N/ ;date,time page# ;room for date and time ;do time, then set page i to whatever
;one line of output
Task build command file for the PAGinate program
;
PAGl-FPIMU=PAG
I
TASK= ... PAG ASG=TI:2:3 ACTFIL=3
II
IAS-9
Application Presentation
Session Transport Network Data Link Physical
Happy Campers!
Welcome to Camp DECUS. This issue of NETWORDS contains two noteworthy items:
First, the announcement of Networks and Communications SIG Wishlist. coordinated by L. Stuart Vance. Cincinnati campers might wish to have your ideas for improvements or new product suggestions sent to "the right people"; here's the vehicle.
Second, a very informative article provided by the Digital Technical Journal, on the conception, birth and evolution of the LAT protocol, used in connecting terminals to hosts on an Ethernet. Digital's Terminal Server products (The Ethernet Terminal Server, and DECservers ) use this protocol. The authors are intimately involved in the development of this protocol; their biographies (as of September 1986) follow the article.
The week of DECUS "camp" will go by fast; so don't try and digest everything at once. And don't forget to write home!
Judi Mandi Network SIG Newsletter Editor University of Connecticut Health Center 263 Farmington Ave. Farmington, Connecticut 06032
Networks and Communications SIG Wishlist
Ever thought that LAN Bridge lOO's should be password protected from unauthorized use of RBMS? Or that DEC's router product line should be improved to handle multiple Tl line cards? Or even that DEC should establish a "Network Advisor" expert system accessible by a toll-free number to aid in the diagnosis of network problems? If you have a suggestion for how DEC might improve an existing product, or have an idea for a new product or service that DEC might provide, then be sure to stop by the Networks and Communications SIG suite and fill out a Networking Improvement Request (NIR). After a number of NIR's have been gathered, a summary of the suggestions will be published in a SIGs Newsletter issue, and circulated among LUG's, where DECUS members will be given the opportunity to prioritize the list before presentation to DEC.
If you have a suggestion, from product specific to visionary, please stop by and let us know!
L. STUART VANCE Network SIG Wishlist Coordinator UT System OTS BRC I CMS 1.156A 10100 Burnet Road Austin, Texas 78758-4497 (512) 471-2416
Digital Technical Journal, No. 3 September 1986
(The Networks SIG Newsletter Condensed Version)
TERMINAL SERVERS ON ETHERNET LOCAL AREA NETWORKS
Bruce E. Mann Colin Strutt Mark F. Kempf
Digital's terminal servers provide flexible, cost-effective connections between terminals and host systems in a local area network (LAN). The product developers tried several approaches before developing the Local
NTN-1
Area Transport (LAT) protocol as the basis for all terminal servers. The LAT architecture supports connections to multiple hosts over a high-bandwidth Ethernet LAN. LAT establishes a single virtual circuit between a terminal server and each host, and individual sessions are multiplexed over a virtual circuit. A unique directory service permits terminal servers to be configured automatically, learning about hosts as they become available. The latest implementations support mixed-vendor environments and Digital's major operating systems.
The Original Problem
In 1981, Digital faced the task of designing a method for connecting a few hundred "dumb" terminals and printers to a VAXcluster system. If, as in the past, the terminal were connected to a single computer, then many of the advantages of clustering would be negated. Instead, it was proposed that terminals be connected to a "front-end" terminal server shared by all members of the cluster. This front end would then allow more flexible connections. A user terminal, for example, could connect to any processor in the VAXcluster group, rather than directly connecting to just one. Our goal was to migrate our existing installed terminal base gracefully from single-processor attachments to VAXcluster systems.
The original effort to provide this server was called the CI-Mercury project by our development groups. We aimed to attach this terminal server directly to the high-speed cluster inter-connect, called the CI, so that the server functioned as a switch. However, the cost of this scheme proved to be excessive. (The cost for the interface to the CI itself was about $20,000.) Moreover, a connection to the CI would have resulted in a server that could connect only to nodes in a single cluster.
We also studied other vendors' switch offerings as front-end terminal switches. These products function much as do the data-switch products available today; that is, backplane multiplexers on the CPUs are switched to the terminals. The problems with this approach were excessive cost, the lack of Digital technology in this product area, and poor availability.
Because of these complexity and cost factors, the original CI-Mercury project was replaced with one called Pluto. This product envisioned using an Ethernet as the interconnect, thus lowering the attachment cost dramatically. This server was based on a PDP-11 central processor.and we chose a variant of the RSX-llS operating system for the initial kernel software. The lower-layer communications protocols used between Pluto and the VAXcluster nodes were the DECnet protocols, successfully used in other products.
We believed that Pluto could be cost effective in large installations; however, its initial cost was too high to be competitive in smaller configurations. This cost factor was especially important as Ethernet became an integral part of Digital's strategy. With Ethernet, it became practical and cost effective to distribute small terminal servers throughout an office environment rather than concentrating all terminal interfaces in a large, centrally located server. Therefore, in late 1981, work began on an eight-line terminal server, the primary goals being low cost and high performance. Internally, their project was dubbed Pluto Junior, later called Poseidon.
Late in 1983, significant problems were encountered in the design of the Pluto and Poseidon terminal servers. The CTERM protocol, a new design of a layered DECnet protocol off-loading character-processing _overhead from the host to the terminal server, proved to be more complex than anticipated. Measurements of message-processing overhead and estimates of the overhead in the DECnetNAX software showed that CPU consumption in the host system would be a problem for keystroke editors. Existing studies showed that terminals were used in keystroke modes, rather than command-line modes, more than fifty percent of the time. Moreover, the Pluto server itself was experiencing severe performance problems. For example, CPU saturation occurred when running less than six terminals at 9600 baud, even when their terminal interfaces used direct memory access (OMA).
Finally, a number of issues, not considered during the requirements phase, became more apparent:
· How could a VAXcluster system be viewed as a single system rather than as individually addressable nodes?
· How could the terminal load be balanced across nodes in the VAXcluster system?
· How could the management of the terminal servers be automated?
NTW-2
Thus the use of the CTERM protocol for terminal servers in both Pluto and Poseidon was halted. (In fact, the Pluto project with an RSX kernel was used successfully as the basis for a number of different servers in the Ethernet Communications server, or DECSA, family, including the DECnet Router, DECnet Router/X.25 Gateway, and DECnet/SNA Gateway products. The same hardware base, though with a completely rewritten software kernel, formed the basis for the final Ethernet Terminal Server.)
However, the original task still remained; therefore, an alternative solution was proposed, based upon work done using a new architecture called local area transport (LAT). The LAT solution involved three essential components that were unique to that architecture:
· A new transport and naming architecture to replace the DNA routing, transport, and session layers
· A new operating system for the terminal server
· A new "port" driver for the terminal driver of the VMS operating system.
The Development of LAT
In late 1981, the prototype of the original LAT server was developed on a VT103 terminal server, which contained a small Q-bus backplane with a PDP-11/23 system and an Ethernet controller. {An Ethernet controller made by 3COM Corporation was used since Digital had no Ether-net products available at that time.) This early work involved quantifying the maximum character-echo delay that a person could comfortably tolerate. We learned that an experienced touch typist encounters difficulties when the echo time exceeds 100 milliseconds. By extrapolating from this fact, we deemed that the network and CPU efficiency of the entire LAT subsystem should be dramatically improved. The approach was to "procrastinate" for up to 80 Milliseconds after characters were received from the terminals at each server. This delay had the very desirable effect of reducing the number of messages processed by the Ethernet, the host systems, and the terminal servers. (Eighty milliseconds is implementable as a multiple of either the 60-Hz line-frequency clock common in the United States or the 50-Hz line-frequency clock common in Europe and other countries.)
In early 1982, we created a VMS driver (LTDRIVER) using a dedicated Ethernet controller to support the LAT server prototype. By April 1982, log-in to a VMS system from a server was achieved; about two weeks later, the performance relative to the then current multiplexer, the DZ-11, was measured. The LAT connection was easily able to out-perform the DZ-11 (a programmed-interrupt controller) under a wide variety of loads. Under many loads, the LAT connection was shown to out-perform the DMF-32 (one of a number of DMA controllers).
In early summer 1982, we converted LTDRIVER to the shared Ethernet port driver. This conversion allowed a single Ethernet controller to be used simultaneously for LAT soft-ware, and DECnet and other communications software. Unfortunately, this change yielded a significant performance degradation. At this time, however, the VMS Development Group was designing a lower-level program interface to the Ethernet driver that would allow system-level VMS usage of the Ethernet. Currently, this inter-face is used to implement VAXcluster support via the Ethernet.
By late 1982, we decided to include both LAT and CTERM support in the Pluto terminal server, but only LAT support in Poseidon. In addition, the original code from the prototype VT103 terminal server was migrated to a UNIBUS PDP-11 system; this code was called LAT-11.
By early 1983, a significant number of VMS developers were using the prototype LAT-11 servers. This software was maintained by the LAT developers. It was important that the software worked reliably since the VMS developers were using it in developing the VAXcluster software.
As noted earlier, the original development team for the CTERM terminal server on Pluto experienced a number of problems. Therefore, in early 1984, a new terminal server was implemented on Pluto, based on the LAT-11 code and not on the RSX software. This new server, containing software only from LAT, was referred to internally as Plato.
NTW-3
The prototype LAT-11 code was developed into a product to run on version 3.7 of the VMS system. This product became available in July 1984, somewhat before VMS VAXcluster support appeared in VAX/VMS version 4.0. one month later, the Ethernet Terminal Server, the product name for the Pluto terminal server, became avail-able. The risk of having the VAXcluster offering adversely affected by an unproven terminal server was limited by releasing it with the earlier version of the VMS system. Thus we took advantage of extensive "free" testing from over 1000 internal users.
In March 1985, the DECserver 100, the product name for the Poseidon terminal server, was released. The DECserver 100 implementation was radically different from the other terminal servers.
DECserver 100
Although the Ethernet Terminal Server and LAT-11 products provided the benefits of server-based terminal interconnect, they did not fully implement Digital's terminal server strategy. For server technology to become pervasive, it must compete with other terminal connection methods on the basis of cost alone. In cluster and multi-host systems, servers provide necessary and desirable added functions. Therefore, they should be compared with other connection methods by assigning some value to the additional features and then using cost/performance as the deciding factor. In small single-system environments, the added features of server technology are not necessarily perceived as adding value; then cost becomes the sole factor for comparison. Digital's servers are at a disadvantage in this situation because they offer features that cost more. Digital must pursue a dual path to develop servers for some applications and to maintain and expand backplane terminal interfaces for others.
The first decision we made was an important one: the product would be a local terminal server and nothing more. Telephone data lines usually terminate inside computer rooms. There-fore Pluto, which is suited to computer room configurations, already filled the need for a terminal server with modem control capabilities. Poseidon was specifically designed to be distributed along an Ethernet throughout an office environment, near the attached terminals. Of course, multiple Poseidons could also be used in wiring closets and computer rooms.
We also believed that Pluto already provided a hardware base for other communication server applications; therefore, Poseidon need not support applications other than terminal serving. Although often desirable from the standpoint of the company's total product set, generality is also the archenemy of low cost. Hardware that serves many functions also has capabilities that are unused in some applications. Those unused capabilities represent a cost from which no bene-fit is derived when an isolated application is viewed.
On the other hand, hardware designed for a particular application can optimize cost and performance by eliminating any unnecessary capabilities. The Ethernet Terminal Server and DECserver 100 illustrate both ends of this spectrum. The hardware base for the former functions in a number of general roles related to communications, such as the DECnet Router or DECnet/SNA Gateway products. Consequently, this product has a high entry cost, but a low incremental cost as each terminal is added. The DECserver 100, being a specialized server, has a low entry cost as well as a low incremental cost.
A second equally important decision was made early in the project: the product managers de-fined and then enforced a very aggressive cost goal in terms of dollars per connection. Although some cost reductions seemed quite insignificant and not worth the effort, in the end the old adage of "watch the pennies and the dollars will watch themselves" proved to be true. The insistence on meeting the cost goal also prevented us from adding "bells and whistles" with their associated costs and complexity, to the requirements list as the project progressed.
Work started on the hardware design with a clear cost goal, but with no preconceived requirements for the implementation. It seemed fairly obvious that an eight-line server could be built on a single printed circuit board. Since there is a substantial expense simply in connecting multiple boards, we decided very early that directly incorporating any pieces of existing products was too expensive. The server would be a single board designed from scratch, although we were free to borrow design ideas from other products. We also decided to use only high-volume, and therefore inexpensive, components where possible - a decision driven partially by the desire to shorten the design time.
NTW-4
One of the most important issues was making sure there was enough processing power. Since Poseidon would not be programmed by customers, the extensive PDP-11 and VAX instruction sets were not really needed. We decided finally to use the Motorola 68000 chip, which was the lowest cost, most readily available micro-processor with sufficient power.
As the design progressed, we considered every possible cost reduction option. For example, the dynamic RAMs are refreshed by software since sufficient processing time exists to do that; the cost of refresh hardware could thus be eliminated. Chips were selected to perform multiple functions whenever possible. For example, the terminal interface (UART) chips have integral timers used to control the software refresh, the timer interrupt, and the watch dog timer. Essentially, the interrupt logic uses very little external logic to turn around the interrupt priority level to generate the vector address.
Thus the design resulted in an extremely low-cost, fixed-function terminal server, the DECserver 100, which has proven to be, by far, the most popular member of Digital's terminal server family.
THE LAT ARCHITECTURE The LAT Protocol
One initial goal of the LAT architecture was to connect terminals to host system using the Ethernet as a data link. Even today, LAT is still used primarily for connecting terminals to hosts. However, its application has spread to connecting other asynchronous devices, such as printers or links to hosts other than those directly connected to an Ethernet.
The goals of the LAT protocol are as follows:
· To permit dumb terminals to be connected to multiple hosts
· To be a transparent character transport mechanism (implying that character echo must be performed by the host and not by a server)
· To support a high-bandwidth LAN technology (specifically the Ethernet) · To use a fixed maximum bandwidth that is much less than the total LAN bandwidth, which should be
used in a fair and predictable manner
· To be an efficient data link protocol, relative to the higher-layer DECnet protocols, such as CTERM operating in a LAN environment
· To provide for low CPU loads and memory use on the host system at the expense of higher CPU and memory utilization on the terminal servers
· To allow for simple terminal server implementations, which means low-cost and high-performance hardware implementations
· To permit automatic configuration so that, for example, servers can determine, without manual intervention, the names and addresses of hosts on the Ethernet.
The LAT protocol makes certain simplifying assumptions:
· Communication is local to a single logical Ethernet (possibly connected by repeaters and bridges); thus no routing capability is required
· Communication is inherently asymmetric, which simplifies connection management and permits straightforward host implementation
· The bandwidth of the Ethernet (10 megabits per second) is much greater than the band-width needed for a given terminal (e.g. 9600 bits per second), so that a timer-based protocol is appropriate.
The normal model of dumb terminal usage is one of low-speed data entry, say a few characters per second. and higher-speed display in bursts of several hundred characters at a time, taking several seconds to display. In addition, a user is usually sitting at his terminal while a program operates at the host. LAT takes advantage of this asymmetrical relationship. Also, the terminal connection normally takes place at
NTW-5
the explicit request of the user rather than of the host system. LAT also takes advantage of this asymmetric aspect.
The server does not communicate characters to a host system as they are entered by the user; rather, it collects characters and periodically transmits them to the host. The time interval of this period, the "circuit timer". is quite short -typically 80 milliseconds. With many users connected. a host is interrupted much less often by gathering together all the characters typed by those users and sending them as a single message.
The LAT protocol is divided into two distinct layers, the virtual circuit layer and the slot layer.
VIRTUAL CIRCUIT LAYER
The virtual circuit layer establishes and maintains an error-free communications path (a virtual circuit) between two nodes, typically a terminal server and a host. The connection is initiated by one end of the communications path and operates under the control of the initiator. However, the circuit can be terminated by either end. Typically, the virtual circuit connection is initiated when the first terminal user requests a connection to a host system to which no virtual circuit yet exists. The initiator of the virtual circuit is referred to as the "master node", the other end as the "slave node." Thus the terminal server is normally the master, and the host the slave.
The establishment of a virtual circuit connection requires a single message exchange. Information such .as protocol versions, message sizes, and node names are included in these messages.
Once established, the data exchange occurs as follows:
· Every 80 milliseconds, the master sends to the slave a message containing any data that must be sent.
· On receiving this message, the slave processes any data in that message and sends back a reply containing any data waiting to be sent in that direction.
· On receiving this reply, the master processes any data that was in the message.
· Eighty milliseconds after one message was sent, the next message is sent from the master.
The message round-trip time is typically less than 10 milliseconds. This operation is timer driven on the master, the terminal server, and event driven (by message receiptl on the slave, the host.
The virtual circuit layer provides reliable communication between a pair of nodes. It also provides a datapath that is bidirectional, sequential, timely, and error-free. All users desiring to communicate over that path are multiplexed over the same virtual circuit, consequently lowering the CPU cost per user on the host. This multiplexing function is the responsibility of the slot layer.
THE SLOT LAYER
The slot layer establishes user sessions, transfers data bidirectionally, and multiplexes and demultiplexes sessions over virtual circuits. In this context a session can be envisioned as a connection from one user's terminal to one host system.
A terminal user first identifies the computer system with which he desires to communicate. A virtual circuit is then established - if one does not already exist - from the terminal server to the host system. A session is then established on top of the virtual circuit. The service access point at the host would normally be represented as a virtual terminal port into the host operating system. Thus the user would perceive the virtual terminal as being directly connected to the host system. For example. on the VMS system, the LOGINOUT function can be run to log in and continue with the normal interactive use of the system.
At the slot layer, data is passed to the virtual circuit layer as "slots", which are addressed units of data. A number of different types of slots have been defined. Each session has a unique slot number on the virtual circuit to aid in the multiplexing and demultiplexing of sessions over virtual circuits. Slots are only sent over virtual circuit run messages. Because slots all share the underlying virtual circuit, no explicit error detection and correction need be performed by the slot layer.
NTti-7-6
The establishment of a session is accomplished using one of the assigned slot types called a start slot. First, the master sends a start slot requesting a connection to the slave. If the slave.is able to accept the connection, it replies with a start slot; if not, due perhaps to lack of resources, the slave may reject the connection with a reject slot containing an appropriate reason code.
Owing to the mismatch of speed between terminal and host, some flow-control mechanism is needed to prevent one end from overloading the other. (This mechanism is independent of the flow control required between the terminal server and the terminal itself. That control is normally handled by using the ANSI flow-control characters XON and XOFF.l The LAT protocol defines a credit-based flow-control scheme at the slot layer. In this control scheme, the receiver must give permission to a transmitter to send each data unit, containing one or a collection of bytes. Data may be exchanged in units of up to 255 bytes in a slot type called a data-A slot. The sending of a data-A slot (if it contains any data at all) uses up a single 11 credit 11 · If one end of a session desires to send some data, that end must have a credit outstanding.
The initial credit allocation is passed in a start slot. There are three additional slot types defined for the slot layer. The first, the data-B slot, communicates the following information:
· The physical port characteristics, such as baud rate, character size, and parity
· The session characteristics, such as whether the ANSI flow-control characters (XOFF/XON) should be treated as data or flow-control messages
· The in-band signaling of break conditions or signaling errors (parity or framing errors)
The data-B slot is subject to the same credit mechanism as the data-A slot and indeed shares the same credits.
The next slot type, the attention slot, is not subject to credits and is used for out-of-band signaling. This slot is currently used for an abort-output operation (as in cancel output '0).
A session may be terminated by either end via the final slot type, the stop-slot. Typically, the stop slot is sent by the host system after the user logs out of the system.
DIRECTORY SERVICE
One goal of the LAT protocol is to permit the automatic configuration of the LAN. The important information that needs to be disseminated through-out the LAN is the name of each service that may be used. Rather than requiring that each terminal server possess this information a priori, LAT provides a mechanism that permits each server to "learn" about the configuration.
To accomplish this learning process, and additional message type is used, the "service advertisement". This message is multicast from each slave node to all master nodes and gives the names of all services that the slave node is currently offering. (A multicast message is a single message addressed to and received by multiple nodes.) An advertisement is transmitted periodically, typically every 60 seconds. Thus on start-up, a server can "listen" for service advertisements and build a directory of available services. This directory can be then presented to the user, on demand, enabling him to choose whichever services he wants from those available when a connection to a host system is desired.
There is no restriction that any node may offer just one single service. LAT allows a given node to offer multiple services. One common use for multiple service names is in a VAXcluster environment. When a user requests a connection to the service name representing the cluster, the terminal server can select one of the available nodes. In this case all nodes offering the same service will be presumed to be offering identical capabilities to the user.
To assist the terminal server in choosing a node, the service nodes provide a "rating" associated with eac;h service offered. The rating is a numeric value that represents some measure of the resources avail-able to apply to that service. For example, the current VMS LTDRIVER implementation takes into account the most recent CPU idle time, the CPU type, the amount of memory, and the number of remaining inter-
NTW-7
active job slots. VMS LTDRIVER also allows the system manager to specify a rating. The terminal server can then choose, at any instant, the node that offers a requested service with the highest rating and use that node as the one to which to form the connection. This choice ensures that the load can be shared among the nodes in a VAXcluster system.
By carefully managing the service advertisements, the server makes the service directories reflect the current service list and their associated ratings, If a server fails to hear from a service provided for some period, the server can assume that the service provided has failed, or crashed. The server can then remove the service from its directory of available services.
The LAT "load-balancing" and "fail-over" features are most often associated with VAXcluster systems. However, although they enhance Digital's VAXcluster offering, these LAT features are independent of it.
"Equivalent services" may also be offered by multiple nodes using the directory service. Consider services that are network based, such as Videotex and dial-out modems. With an Ethernet LAN, many independent nodes might offer such services; typically, however, users can access the service only through nodes on which they have accounts. If a user's system is down, he is denied access to the service, even though the service remains available on other nodes. For example, consider a Videotex-based service, such as LIVE WIRE (an in-house electronic bulletin board), that can be offered by many independent LAT host systems. If a LAT user connects to LIVE WIRE, the terminal server software will detect that the service is offered from multiple sources. The software will then make a connection to the source believed to be currently offering the best level of service. If that service should fail (i.e. stops sending Ethernet LAT messages), the terminal server software will automatically reconnect the user to an alternate provided of the same service if one exists; this action is known as fail-over.
Future versions of Digital's LAT products may make more extensive use of the LAT service capability. That would make it possible to install applications that are accessible to the extended LAN but not to the wide area network. A form of nondiscretionary access control is implicit in this design.
PRODUCT IMPLICATIONS OF THE LAT ARCHITECTURE
Although not originally conceived as a distributed terminal switch, an Ethernet can be used effectively in that role if combined with the terminal server products. This fact remains true even when the Ethernet and host system are running other protocols simultaneously, such as DECnet and VAXcluster systems based on Ethernet. Our experience has shown that a single dedicated Ethernet segment, without bridges, can easily support several thousand concurrent users.
Functioning as a distributed terminal switch in the Digital computing environment, LAT offers significant advantages over dataswitches and backplane multiplexers. The most prominent of these advantages is that any terminal server user can connect to any host system. "Blocking" connections to host systems (more accurately called "port contention") is not an issue because host-system ports are logical, not physical. A VAX/VMS system is limited by the LAT architecture to about 6 million simultaneous connections, or 32,000 terminal servers, each with up to 255 sessions. This large number rep-resents a significant cost advantage, especially considering that Ethernet controllers are standard options on many of Digital's processors. In this case the host-processor terminal connection cost then becomes negligible, making backplane-oriented terminal switches much less attractive. This cost advantage improves as the size of the system increases.
Some additional advantages afforded by using LAT are as follows:
· Multi-session capability, not offered by data-switches
· Simplified installation and management (especially where users and computer systems are often added or moved around)
· Higher availability due to the lack of any single point of system failure
· Simplified, incremental expansion and migration capabilities inherent in Digital's extended LAN architecture, utilizing bridges.
NTW-8
THE ORIGINAL IMPLEMENTATION
Digital's original terminal server family had three members: LAT-11, the Ethernet Terminal Server, and the DECserver 100. These LAT products support interactive terminal users. These products use the unique naming capabilities of LAT (service names, load-balancing, fail-over, and auto-configuration) and feature multi-session support and complete application transparency. The servers implement an easy-to-learn user interface that allows users to change parameters, view available services, and connect and disconnect from these services. In addition, the same user interface allows a local manager to control the operation of the server and ports. The DECserver 100 and the Ethernet Terminal Server also implement a remote console feature that allows remote management from the server by using a convenient, centrally located host system.
The LAT-11 product, unlike the other two terminal servers, is a software product. It was originally sold to enable users with PDP-11 systems that were no longer being used for general computing facilities to take advantage of the server technology, but without incurring any initial hardware investment. The software ran on some of the older UNIBUS PDP-11 systems, using 124KB of memory, up to eight DZ-11 multiplexers, and a DEUNA Ethernet controller. The software was loaded either via the Ethernet or from a local disk. LAT-11 offered a user interface and capabilities similar to those on the original version of the Ethernet Terminal Server and could connect up to 64 users to the Ethernet. Being based on PDP-11 technology, servers using LAT-11 would normally be located in computer room environments.
The Ethernet Terminal Server uses the Ether-net Communications Server (DECSA) hardware. This is a special-purpose PDP-11/24 system with 512KB of memory, a DEUNA UNIBUS-to-Ethernet controller, and two protocol assist modules (PAM). PAM's are intelligent microprocessor-controlled interfaces based on the AMD 2901 from Advanced Micro Devices Inc. Each PAM interface connects up to eight line cards, each of which is a dual RS232C interface with full modem-control capability. The server also has a console boot terminator (CBT) module for self-test code, bootstrap code, and remote console support. The Ethernet Terminal Server offers a user interface similar to that on the DECserver 100. Using the LAT protocol, the server can connect up to 32 terminals (either locally or remotely via modems) to the Ethernet. The Ether-net Terminal Server can be located in a computer room environment or a communications closet. The software is always down-line loaded into the unit from a DECnet load host across the Ethernet.
Internally, the DECserver 100 is radically different from the other two members of the terminal server family, yet still retains the same external characteristics. The DECserver 100 is a low-cost terminal server capable of connecting eight asynchronous ASCII terminal to an Ethernet using LAT protocol. This server is a very compact unit and can be located in a computer room, a communications closet, or in an office environment. The server has no modem control. Modem control is implemented using an 8-MHz Motorola 68000 chip, with 128KB of RAM, and 512 bytes of nonvolatile RAM (NVRAM). Like the Ethernet Terminal Server software, the DECserver 100 software is down-line loaded from a DECnet host.
EXTENSIONS TO THE ORIGINAL IMPLEMENTATIONS
The initial implementations of the LAT protocol were on the terminal servers described above and on VAX/VMS systems. The servers implemented only the master end of the LAT protocol, whereas the hosts implemented the slave end. Follow-on implementations have added similar support for additional host systems: MicroVMS, RSX-11M-PLUS, MicroRSX, ULTRIX-32, ULTRIX-32m, TOPS-10, and TOPS-20 systems. Each system implementation offers access to the command interpreter as the service access point.
Version 2.0 of the Ethernet Terminal Server added the reverse-LAT implementation, permitting a server to offer additional services to which terminal users can connect. This implementation permits sessions to be created within the box as well as across the network. thus forming a switch style of operation in a single server. The types of services that may be offered by the terminal server can be grouped into the following three categories.
The first category is connections to non-LAT hosts. In this mode, the server acts as the Ether-net connection for systems (typically not made by Digitall that cannot themselves offer LAT services on the Ethernet. Asynchronous ASCII ports on these systems are connected to a terminal server. Terminal users on the same or different terminal servers can connect to the service offered. They can then communicate with the non-LAT host as though it were connected to the Ethernet.
The second category is service for dial-out modems. Terminal users can connect to a port in a pool of dial-out modems. The users can then use the appropriate ASCII protocol to create a dialed connection and then access the remote system via its own dial-in port.
The third category is service for personal computers (PC). They can be connected to terminal servers and run in either of the terminal emulation modes. Each PC thus acts as though it were a dumb terminal. A PC can also run in file transfer mode when connected to another PC via the same, or another, terminal server.
Subsequent versions of the Ethernet Terminal Server, DECserver 100, and the VMS LTDRIVER soft-ware all permit asynchronous printers to connect to terminal servers. These versions also allow print queues to be directed to the printers from hosts. The LAT protocol has been enhanced so that the connection mechanism remains under the control of the terminal server (for efficiency reasons mentioned previously). That enhancement allows a host to "solicit" a connection from a port on a terminal server. Once the connection has been made, data transfer can occur as in the normal interactive terminal case, except that the printer output is under the direction of a VMS print symbiont. It is possible, with these implementations, to direct the queues from multiple systems to a single printer or bank of printers being offered as a common service. When a connection request is made while the printer is being used by another system, the connection request can be queued. This queuing provides a basic mechanism for sharing printers among multiple systems. Within the LAT environment, the service name offered by a host system does not always have to represent the command interpreter on a given system, though this is by far the most common use today. Instead, a service name could represent an application program, which might be run automatically when a connection request is made. Alternatively, using the solicited-connection mechanism currently employed for printers, application programs could initiate connections to terminals (or other asynchronous devices) located within the LAN.
DECSERVER 200
The DECserver 100 interconnects terminals in an office environment at a very low price. Soon after it was announced, it became clear that modem-controlled lines and connections to non-LAT host systems should also be priced just as low.
Thus the DECserver 200 project was initiated to produce a new server based on the DEC-server 100 design, but with modem control capabilities. Moreover, this product had to meet the original cost goals of the DECserver 100. This project involved a redesign of the printed circuit board, yet retained the same system architecture. A faster version (10 MHz) of the same MC68000 microprocessor was used, and memory was increased from 128KB to 384KB of RAM and from 512 bytes to 2KB of NVRAM. This increase allowed room for the implementation of modem control software and support for non-LAT r.osts (i.e. reverse-LAT capabilities). The increase also allowed a larger service directory database to be stored and an enhanced on-line help capability to be added.
Another feature of the DECserver 200 takes advantage of the DECconnect cabling scheme. allowing connections to be made using DEC423 wiring. This feature allows communications at up to lJ.2 Kbaud over cable that is neither twisted pair nor shielded, for relatively long distances of up to 1000 feet.
SUMMARY
Unlike other existing packet-oriented transport layer architectures. the LAT transport layer implements asymmetric connection management, asymmetric data flows. and timer-based message exchanges.
The most unusual innovation of the LAT architecture is the use of multicasting as a presentation level naming service. On Ethernet, packets are normally addressed to the adapter of a specific system. However. the Ethernet specification de-scribes a form of logical addressing called multicast addressing. In this scheme a packet addressed to a multicast address is received nearly simultaneously by many independent systems. LAT uses these messages to completely configure the topology automatically. This action means that installing a terminal server is as simple as plugging it into the Ethernet and waiting for services to be advertised.
NTW-10
Asymmetric connection management considerably simplifies the complexity of the protocol in which terminal servers initiate connections to host systems. If a host system wants to connect to a terminal server, that connection must be solicited from the terminal server. This protocol solves the problem of having many host systems competing independently for the same resource. The first "solicitation" is serviced by a connection, and subsequent requests are queued on a first-in, first-out basis.
On a particular terminal server, all devices that are logically connected to the same host system share messages both to and from that host. Within each message, each users' data is contained within slots. This multiplexing, in conjunction with the delay timer, reduces further the number of messages exchanged. For example, as more users log in to a host system, the number of messages exchanged remains constant at approximately 12 per second in each direction, even as the lengths of the messages increase.
The DECserver 100 and DECserver 200 are low-cost implementations of the LAT architecture, allowing terminals and other asynchronous devices to be configured in a flexible and cost-effective manner in a LAN.
BIOGRAPHIES
MARK F. KEMPF Mark Kempf is currently involved in planning Digital's next generation of interconnect products. A consulting engineer, he was the project manager for advanced development of the LANBridge 100 and DECserver 100. Coming to Digital in 1979, Mark worked on software for a DECnet front end and one of Digital's first implementations of Ethernet. Earlier, he worked at Standard Oil of Indiana on real-time process control systems. Mark earned a B.S. degree from Northwestern University in 1972. He holds three patents, including one in bridge technology.
BRUCE E. MANN A consulting engineer, Bruce Mann is now studying the application of Digital architectures to commercial on-line transaction processing. He wrote the LAT architecture, creating its first prototypes and products. An early contributor to Ethernet projects, Bruce helped to design the system interfaces. In 1987 he used networking to automate engine tests at the Volkswagon Research Laboratories. Before joining Digital in 1976, he designed medical computer systems at the Harvard Medical School. Bruce earned a B.S.E.E. degree in 1971 from Cornell University and with three other engineers has applied for a patent on the LAT protocol.
COLIN STRUTT Joining Digital in 1980, Colin Strutt was project leader on several communications products, including DECnet-IAS and the Ethernet Terminal Server. He is currently a consulting engineer responsible for product strategy of the terminal server family. Colin is the LAT architect and a member of the DECnet Review Group. Formerly, he worked for British Airways, specializing in network support and operating systems. Colin received his B.A. (Hons) degree in 1972 and his PH.D. degree in 1978, both from Essex University. He is a member of the British Computer Society and the ACM.
Abstracted with permission from Digital Equipment Corporation.
NTW~1.1
r - - - ,·-~- - - ;
! I
,/ '" ,/
'"
I
i
I ,/
'" I
r.,/ AuroMAr10N
I
'I I ·
! I
~ I
! '" I '"
i
J I
,/, /·iI
I '"
,/ I
L': - · . I
-
·
- '~
.J
IN THIS ISSUE...
From The Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .OA-1 · Therese LeBlanc, T.M. LeBlanc & Assoc.
Notes on Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .OA-2 · Mark Hyde & C.J. Trayser
FROM THE EDITOR.~.
We have a short issue this month featuring the return of our Notes column! Many thanks to those of you who took part in the reader survey last fall. The comments and information you provided about the OA section were very helpful to us in structuring the content of future issues. Keep an eye on August and September issues for post-Symposia articles, informationa and the new SIR listing. Regards, Therese LeBlanc OA Newsletter Editor 27 5 London Place Wheeling, IL 60090
OA-1
NOTES ON NOTES
Discussions on VAX Notes Volume 2, Number 1
Mark Hyde and C.J. Trayser, Digital Equipment Corporation
Well, its been a while since we wrote the last article. We have both been quite busy with new jobs (Buck is now an Educational Services Instructor and Mark is busy supporting VMS and DECnet). There are still many things to write about so we will be sending in articles every now and then, but not quite so regular as last year. Volume 2 will consist of more occasional articles written by one or both of us as we encounter interesting topics.
In the past we discussed a lot of user features, but left the system management issues lightly covered. So we will try to cover some of those in this article.
In the pre-sales cycle we are often asked "How much disk space does VAX Notes use?" Well, as you can probably guess, the answer is "It depends." There are three distinct "consumers" in disk space: 1) the installation, 2) the conference creation/growth and 3) users notebooks and storage.
The installation is usually the smallest user of disk space over the long run. The space used depends slightly on the version, but all use less than 3000 blocks. Most of this space is for shareable images and TPU code for the user interface. There are several small files, such as some command files, and a few executables in SYS$SYSTEM and the NOTES$LlBRARY directories. The other file of significant size is the sample conference which is placed in the NOTES$LIBRARY directory.
A major user of disk space (and the hardest to manage) is the individual user. The space is used in three ways: 1) extracting notes to text files, 2) creation of personal conferences and 3) growth of NOTES$NOTEBOOK.NOTE. Although extracting notes and creating conferences are obvious uses of disk space, the (unknown) growth of a notebook can be quite amazing. Because of the way VAX Notes keeps track of which entries are seen and unseen in the notebook, (a topic for another article) it can grow to enormous proportions unless it is managed. Since the notebook file is formatted and organized the same as a conference file, the same routines for compression can be used quite effectively on both conferences and notebooks. Here is an example command procedure that can be used to compress these files.
$1 NOTEFILE CONVERT.COM $1 $! To use this procedure supply the name of the file to compress such
as . ..
$! $! @NOTEFILE_CONVERT.COM SYS$LOGIN:NOTES$NOTEBOOK.NOTE $! $ fdl = f$parse(f$environment("default")+".fdl",pl) $ analyze /rms /fdl 'pl /output='fdl $edit /fdl /analysis='fdl /nointeractive 'fdl /output='fdl $ convert /fdl='fdl 'pl 'pl /statistics
The most obvious consumers of disk space are the conference files. Physically these are indexed-sequential files which are subject to most of the standard "symptoms" of indexed files. Among these problems are growth
OA-2
and fragmentation - both of which can be managed but not necessarily controlled.
These files are the actual repositories of the data (notes, replies, etc.) of a conference. As such, they grow in direct proportion to the amount of data that is placed in the conference. Other than the compression routines, which will only help minimally, deleting information from the conference is the only way to shrink a conference. The problem with this is that a subjective decision must be made as to what information should be deleted. Ve say "subjective" because the use of each conference may differ, therefore deleting notes due to a specific measurement, such as age, may not be reasonable.
As the conference continues to grow its size can become cumbersome. Ve have seen some conferences with over 10,000 entries consuming thousands of disk blocks. Among other things this makes incremental backups take longer because with any change or addition to the file it is marked as modified and a backup routine looking for modified files will encounter a potentially huge conference. To accommodate this we suggest "retiring" conferences periodically. One way to do this would be similar to our hypothetical conference on Trucks:
1. A note should be posted (possibly a reply to topic 1.0) that all new discussions should be started in the next version of the TRUCKS conference called TRUCKS V2. The note should be modified to allow the participants to press the SELECT key to add the conference to their notebook:
Notes> SET NOTE/CONFERENCE=MYNODE::TRUCKS V2
2. Modify the Conference Notice about a week or more ahead of time that the conference will be retired and that they should read note number 1.x for more information.
Notes> SET CONF/NOTICE="Conference being retired. See note 1.4"
3. At the prescribed time the moderator sets the old conference to disable writing (and replying),
Notes> SET CONF/NOVRITE
modifies the NOTICE and posts a follow-up note indicating the conference is closed. This is best done when the moderator knows there is no one accessing the file to avoid any confusion.
4. Generate a full directory listing of the old (retired) conference
Notes> DIRECTORY *·* /OUTPUT=TMP.LIS
and post this as a note in the new conference - preferably as one of the first topics or even as a reply to 1.0.
5. The retired conference file should have the file protection set to (S:RE,O:RE,G:RE,V:RE). This will allow anyone to access the file to read it, but prevent them from writing to it. This is sometimes necessary as any MODERATOR can get past the /NOVRITE
OA-"3
setting, but unless they have exceptional VMS privileges, this prevents accidental writings by the moderators.
After a period of time it may be reasonable for the file to be archived to tape so the moderator can delete the file, saving disk space, This is a judgment call as it depends greatly on the contents of the file.
In addition to disk space, VAX Notes can be a consumer of network resources. Assuming you have VAX Notes running on several nodes in your network and you access conferences on other nodes, this can be a point of concern. If you have the most popular conference in the company on your node, you may find that there are large numbers of network links to the Notes server on your system using up resources that you would rather be using somewhere else. If you have a lot of other network activity, you may even bump into the maximum links limit specified in your DECnet parameters.
The VAX Notes server is multi-threaded, which means that many links at once can be serviced by a single server process. By default the maximum number of links handled by a single server is 16. Vhen the maximum number of links on a server has been reached, Notes will obligingly fire up another se+ver to handle another 16 links. By default there is no maximum number of servers that will be started.
Unless you are used to using NCP to view the total number of links into your system, you may not perceive either of these things happening. Of course, VAX Notes offers a way to control both the number of links per server and the number of servers as well as monitoring them. To see how many VAX Notes server processes are on your system issue a SHOV SYSTEMfNETVORK command at
DCL and looking for the processes that look similar to the following:
VAX/VMS V4.7 on node BATON 6-APR-1988 20:16:02.55 Uptime 12 01:31:37
Pid Process Name State Pri I/O
CPU
Page flts Ph.Hem
20200725 EVL
HIB
6 1109 0 00:00:22.84 47621 51 N
202003B8 NOTES$000E_l* HIB
4 148 0 00:00:03.78
653 45 N
In this case, the VAX Notes server process is the one with the process name of "NOTES$000E l*"· The interesting items are actually part of the process name. The asterisk ("*") indicated that this is the "declared" server, or the one that will accept the next incoming VAX Notes link. The number in
front of the asterisk, in this case the "1", indicated how many links this process is currently serving.
You can modify the default number of servers as well as the default number of
links per server via logicals. As a rule the defaults will be fine except in
the busiest of VAX Notes environments. However, if you feel they need
adjusting, you can adjust the following logicals to either increase or
decrease the defaults.
·
$ DEFINE /SYSTEM /EXEC NOTES$SERVER MAX SERVERS 4 !per system $ DEFINE /SYSTEM /EXEC NOTES$SERVER=MAX=LINKS 16 !per server
Happy Noting :-)
m-4
PERSONAL COMPUT'ER SPECIAL INTEREST GROUP
NEWSLETTER
TABLE OF CONTENTS
PRO Section
PROTO SYSTEMS Memory Upgrade - A Review - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PC-1 By Gary Rice - Need more memory? Try this approach
PROgramming Quickie - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PC-3 By Gary Rice - Create a file EXACTLY where you want it
MACINTOSH Section
Printing Macintosh Output on Your DEC Postscript Printer- - - - - - - - - - - - - - - - - - - - - - - - - - - PC-6 By Mark Sebem - How to tell your MAC a thing or two
PROTO SYSTEMS Memory Upgrade - A Review
By Gary Rice , PC SIG Newsletter Editor
For the last several weeks, I have been using a 1 megabyte PRO 350. Now, for those of you who have a Macintosh or a VAXstation, this may not seem like a "big deal". But for me as a PRO user, it was quite a novel experience. For the first time, I could actually install my Ethernet card. Now what does a memory upgrade have to do with an Ethernet card? Well, the PROTO SYSTEMS memory upgrade consists of either 1or2 small cards (your choice) that attach to the system board directly. When I installed the first card, I was able to remove the memory board that occupied one of the option slots on the CTI Bus. This freed up a slot (that I used for the Ethernet card) and still gave me the same amount of memory that I had before (512K) which is the minimum required for P/OS version 2 or above.
The PROTO SYSTEMS card is an "exact replacement" for the small (3" x 5") daughter memory cards attached to the system board on the PRO 350. However, there is an important difference. The original memory card from DEC has a capacity of 128K bytes while the PROTO SYSTEMS board has a 512K bytes capacity. This is done through PROTO SYSTEMS use of newer technology chips. The PROTO SYSTEMS board also uses fewer components than the DEC board. More on that later.
The shipment from PROTO SYSTEMS arrived containing 2 memory boards and installation/troubleshooting instructions. It was well packed with ''bubble-pack" and anti-static wrappers for the 2 boards.
Installation of the boards was simple. The instructions provided by PROTO SYSTEMS were clear and easy to follow. However, I found 2 things that were 1) annoying; and 2) confusing. The annoying part was the step in the instructions that stated that I needed to detach all of the peripheral connections from the back of the system. You know, the printer, MODEM, TMS, etc. Well, the only one that I ACTUALLY needed to remove was the power cord. The confusing part was the area of the instructions describing the removal of the old memory boards. The instructions were somewhat unclear about this.
However, I succeeded in installing BOTH boards without any real trouble and both came "on-line" without error straight from the box.
To verify that I actually had a 1 megabyte system, I issued a "$ SHOW MEMORY" command from the Toolkit. Here is a pictorial of the resulting display on the next page.
pc.,..1
P/OS V3.l BL26.0
TASK= *IDLE1'<:
FOOL=6016. :6298. :27. 6016. :6298. :27.
<FRO
l 512K UF 000:00:04
23-AFR-88
FREE= 3YO: 14257. D'.:l :Dt10
LBO:l4257. DZ2:DMO
SECPOOL=l54. :290. :53%
154. :290. :53%
IN:
12 45K
OUT:
0
OK
DDT.D F R I T $$TQUT p
ZWT. I 1 f1.N F VDFMMI 0
: : : .. R
Ll
Dl
RM
1 A
c
p
. s s w TFWGHM s
R R 20. LE R
. E E ON. IR E . s M OT. B s
))))=!==>==!=]=)! !+>!>--l
5 c 3 D QF F D s
$ 0 $ $ MR c
GMG M G0 s
c R M R
A G A
T
1
F..., R () I E
c H
L 0
T T
l 1
F RF
M 7 c· ;:)
<- - ) ) +-+- - > ! - ! - ! - ! <- - - ) )
0*******32******64******96*****~128*****160****~192*****224*****
E-P--D-D----- ---------DD-------- - - --- - -·- - --- - - -- - - - - - --- - - ---- - ·-
---------------------------------------------------------------0
256*****288*****320*****352*****384*****416*****448*****480~*~**
( ) ) >= = ! ! !
Y·.XC $ $S
TK$ G AE
: : C I LC
T D P$
E I OF
X S OL
The "512K" on the first line did INDEED indicate that I actually had 1 megabyte, since the text reports the number of 2 byte WORDS available to the system.
Next, I decided to make some comaprisons between the PROTO SYSTEMS board and the DEC equivalent the MSCl 1-B memory board. The DEC board is specifically sold as a PRO 380 option, but it will work in the 350 as well. It is a 512K daughter board similar to the PROTO SYSTEMS board. I happened to have one of the DEC boards so I could make some legitimate comparisons.
Physically, the two boards are the same size. The number of components on each board is different. The DEC board has 61 while the PROTO SYSTEMS board has 37. The memory chips on the DEC board were Japanese. The PROTO SYSTEMS board used Korean chips. Both boards used a double sized foil design, but the foils on the DEC board tended to have narrower control and power foils than the PROTO SYSTEMS board.
To see if there were any differences in performance between the two boards, I set up the following test. First, I wrote a simple memory access program. The listing appears at the end of this article. Then, I ran the program 10 times with the DEC board installed in the PRO 350. Next, I removed the DEC board and substituted the PROTO SYSTEMS board. I ran the program again 10 times. The differences that I found are detailed in the table that follows. The numbers listed in the table are the averaged results for both reading from and writing to a program memory location 1,000,000 times.
To summarize the information that I have previously presented, on the next page is the comparison in table form.
PC-2
DEC
PROTO SYSTEMS
Card Size
3"x5"
3"x5"
Components
61
37
Chip maker
Japanese
Korean
Cost
572
250
Timing results
averaged read
15.870313 sec 15.892188 sec
averaged write
14.092188 sec 14.078125 sec
I will leave it up to you to decide if these numbers are significant.
Just for fun, I ran the same test program on a PRO 380 (using a DEC board) and came up with the following
timings:
read
7.406250 sec
write
7.015625 sec
PROTO SYSTEMS is located at 1238 Josephine Street, Berkley, CA, 94703. Contact Everett Harvey (phone (415)420-9579) for more information.
Timing program
BYTE JUNK(10000)
c
REAL*4 SECNDS, A, B, C
c
A = SECNDS (0.0)
DO 400, K = 1, 1000
DO 200, I= 1, 250
JUNK(I) =I
JUNK(l+7000) =I
200
CONTINUE
DO 300, I= 1, 250
JUNK(I+500) = I
JUNK(l+7500) =I
300
CONTINUE
400 CONTINUE
B = SECNDS(A)
A = SECNDS (0.0)
DO 600, K = 1, 1000
DO 500, I= 1, 500
J = JUNK(I) J = JUNK(I+7000)
500
CONTINUE
600 CONTINUE
C = SECNDS(A)
WRITE (5,10) B
WRITE (5,10) C
10 FORMAT (1X,F10.7)
END
PROgramming Quickie
By Gary Rice, PC SIG Newsletter Editor
This month's "Quickie" consists of a MACRO subroutine (callable from the high level language of your choice) that will create a contiguous file of any size AT A SPECIFIC LOCATION on the disk. You can do the same thing
PC-3
with the PRO/Toolkit program RMSDES.TSK, but this routine let me do it from an application that I wrote. The routine itself is listed first followed by a FORTRAN fragment showing the calling sequence.
CREATE.MAC - This subroutine CREATES a sequential file of a ;specific size at a specific place on the disk.
AUTHOR:
Gary Rice
; CREATED:
January 2, 1988
REVISIONS:
None
INPUTS:
INl - INTEGER*2 Number of characters in device-directory-file name IN2 - CHARACTER*n The device-directory-file name IN3 - INTEGER*4 The block on the disk where the file should start IN4 - INTEGER*4 The size of the file
OUTPUTS:
OUTS - INTEGER*2 RMS Open completion code from STS field OUT6 - INTEGER*2 RMS Open completion code from STV field
NOTES:
This routine uses logical unit #1 to create the file. The LUN must NOT be in use when this routine is called.
The file will ALWAYS be contiguous or no file will be created.
If the requested disk location is in use, RMS will attempt to create the file as close to the specified location as it can.
I
I·**********************************************************
.TITLE .IDENT
CREATE /Vl.O/
; Global definitions
.GLOBL
CREATE
;RMS Macros
.MCALL .MCALL .MCALL
POOL$B,POOL$E FAB$B,FAB$E,XAB$B,XAB$E $CREA TE,$STORE,$CLOSE
; Parameter offsets
IN1=2. IN2=4. IN3=6. IN4=8. OUT5=10. OUT6=12.
; Data section
.PSECT
DATA,RW
PC-4
FABBLK:
.EVEN FAB$B F$BPAO F$DNAO F$DNSO F$FAC F$FNAO F$FNSO F$FOP F$LCH F$MRS F$0RG F$RAT F$RFM F$XAB FAB$E
F$ALQ
10.
FB$WRT
FB$DLK!FB$CTG 1 512. FB$SEQ FB$BLK FB$FIX ALLBLK
; File size - ignored here ; No private buffer ; Default file name ; Length of def file name ; Block WRITEaccess requested
; File name - run time
; File name length - run time ; No lock on abnormal close & Contiguous ; LUN assigned to the file ; Maximum record size (bytes) ; Sequential file
; Carriage control ='NONE"
; Fixed length records ; Use an ALL block for locatability
ALLBLK:
.EVEN XAB$B X$AID X$NXT X$ALN X$AOP X$ALQ X$LOC XAB$E
XB$ALL
0 0
XB$LBN XB$HRD!XB$CTG 0 0
; Set up ALL block
; Use area 0 for this block
; No more XAB blocks follow ; Logical block alignment ; Hard area location & contiguous ; Allocation size (filled in at run time) ; Placement filled in at run time ; That's it for the XAB
.EVEN
POOL$B
P$FAB
1
P$BDB
1
P$BUF
512.
POOL$E
.EVEN
; Pool buffers ; One for the FAB ; and the "Buffer Descriptor Block" ; Buffer size ; That's it for RMS Pools space
I
; Double words are needed for the starting block and file length
I
START:
.WORD
0,0
SIZE:
.WORD
0,0
I
; Executable code
CREATE:
.PSECT .EVEN
CODE,RO
I
; Store file name addr and length in file access block (FAB)
MOV MOV
#FABBLK,Rl @IN1(R5),R2
; Rl =addr of the FAB
; Get count of file name chars
PC-5
$STORE MOV $STORE MOV MOV $STORE MOV $STORE
,
; Try to create the file.
R2,FNS,R1 IN2(R5),R3 R3,FNA,R1 @IN3(R5),START #ALLBLK,Rl START,LOC,Rl @IN4(R5) ,SIZE SIZE,ALQ,Rl
; Store count in FAB ; Get addr of file name ; Store addr of file name in FAB ; Get the starting block number ; Rl = addr of the ALL ; Put the block # in the ALL block ; Get the # of blocks to allocate ; Put the # of blocks in the ALL block
MOV $CREATE MOV MOV $CLOSE RTS .END
#FABBLK,~1
;GetaddrofFAB
Rl
; CREATE it
0$STS(R1),®0UT5(R5)
; Get STS error ststus
0$STV(R1),@0UT6(R5)
; Get STV error value
Rl
;CLOSE th~ file
PC
;&return
A sample call to the "CREATE" routine looks like this:
INTEGER*4 START, SIZE
INTEGER*2 ERROR(2)
c
START=200
SIZE= 100
CALL CREATE (26,'SY:[USERFILES]MYFILE.TMP;l ',START,SIZE,
+
ERROR(1),ERROR(2))
END
This program will create a file starting at disk block 200. It will be 100 contiguous blocks long.
Send me your own PROgramming Quickie and I will publish it here in this on-going column in these Newsletters. (RXSO Please)
. Printing Macintosh Output on Your DEC Postscript Printer
By Mark Sebern, Sebern Engineering Inc., P. 0. Box 268, Cedarburg, WI 53012 414/375-2200 .
Introduction
As even DEC and Apple have belatedly figured out, many DEC users also have a Macintosh. Some such users even have DEC Postscript printers, and would like to use them to print Macintosh output intended for a Laserwriter. If you have a big system with a lot of Mac's, one way is to use commercial products which implement Appletalk on a VAX. For a small user with a single Mac, though, this is not very cost effective. It may be old news, but I did stumble across a cheaper way to get Macintosh laser output on a DEC printer.
The Environment
I am running a Macintosh SE with 20 Mb hard disk, a VAx.station II/GPX, and an LN03R Scriptprinter. The Mac is hooked to the VAx.station via a DHQ11 (TXcn:) port, with Red Ryder on the Mac. The only printer on the Mac itself is an Imagewriter II.
PC-6
Making a Postscript File
The first step is to get the Mac to produce a Postscript file instead of looking for a Laserwriter on Appletalk. To do this, install the Laserwriter driver and use the Chooser to select the Laserwriter. It will want to tum on Appletalk, which is ok, but tum off your Imagewriter first unless you want to see a lot of garbage. The Chooser won't be able to find any Laserwriters, but once you have selected the Laserwriter and enabled Appletalk, just click on the close box to leave the Chooser.
Next, go into your favorite application. I have tested this technique with Microsoft Word, Superpaint, and Hypercard. Select the print function as usual, but when it comes time to OK the actual printing, quickly press and hold the OPTION and F keys immediately after saying OK. If you are successful, you will get a message that says "creating Postscript file" instead of "looking for Laserwriter". If you're too slow, just wait for it to give up, and then try again. With Hypercard, it's a little trickier, since the normal print setup box does not appear, but it still works if you press OPTION-F at the right time.
Now, exit the application and look around for a file with the name "Postscriptn", where "n" is a digit. Normally this file will be in your "root" folder, but it may take a little looking. If you open this file with your favorite word processor, you will see the desired Postscript instructions. Step one is now complete.
Getting the Laser Prep File
Unfortunately, the Postscript file you produced above depends on some Postscript definitions which are stored in the "laser prep" file in the system folder. In older systems, you could use a variant of the OPTION-F trick to get that file, too, but not any more.
The solution here is a piece of shareware called "AddLPrep" which is available on the Compuserve MACPRO Forum as ADDLPREP.SIT, and requires Stufflt for unpacking after downloading. You can get Stufflt from the same forum's data library. Stufflt is also shareware, but carries a fee only if you use it for packing uploads. AddLPrep creates a file which contains both your original Postscript file and the laser prep file. In my experience, you really only need to do this once, since the prep file can be concatenated onto the beginning of any Postscript file later created with OPTION-F. Take a look at it with an editor or word processor and you'll see what I mean.
Getting the File to the Printer
The files I wanted to print were fairly short, so I just used Red Ryder in straight "ASCII send" mode to dump the files up to the VAXstation. Then I printed the files using a Postscript queue on the LN03R. Other file transfer techniques (including a Mac implementation of DECnet) could probably be used. Although I didn't try it, I suspect that you could use a Mac communication program to dump the combined file directly to an LN03R connected to the Mac's communication port.
7While sophisticated techniques may be more flexible, this simple process allows inexpensive Macintosh output on a DEC Postscript printer. H you need a modest amount of high quality output and don't want to buy two laser printers or an expensive network, it may be just the ticket.
PC-7
Editor's Corner
By now everyone should have recovered from the Cincinnati Symposium. I was unable to attend, so my recovery was swift. If you were a speaker whose notes/slides didn't make it into the Unisig Session Notes, please send them to me and I'll publish them here. If you attended a session that you'd like the notes from, and those notes didn't make it into the Session Notes,
let me know and I'll try to get a hold of the speaker and publish the notes.
Turning to this month's newsletter - First, we have Using ucbmail from Steve Gilgut. Steve has included some very handy reference sheets for ucbmail. Great for those of us who learned a couple of functions when we first learned how to use mail, and haven't learned anything new since (at least, in the mail area). Next, our esteemed Unisig Chairperson has contributed Unix as a Window to the World, about usenet and the new UUNET. And last, The Way It Is, pulled from usenet and submitted by
Steve Gilgut. I suppose we could categorize this last article as the Joke of the Month, though it's probably only funny to a certain segment of the computer-literate population. For those who don't see the humor, I'd be
happy to print opposing viewpoints. I am a firm believer in freedom of expression for anyone who sends me something to publish.
As always, your comments, suggestions, articles are encouraged and welcomed. Please send hardcopy to :
Sharon Gates-Fishman NDC Systems
730 E. Cypress Ave. Monrovia CA 91016
or e-mail to:
amdahl !ci t-vax!ndc!sgf
UNI-1
Using ucbmail
First, to elliminate confusion, when I speak of UNIX, I refer to 4.2 Berkeley, or Ultrix. I don't do System V (yet... ). Unix, generally comes with two flavors of mail. /bin/mail. and /usr/ucb/Mail. The first is the original mail utility, that (I believe) came from AT&T. To supplement this, Berkeley put out Mail, sometimes called ucbmaH. Ultrix V2.0 also provides both.
The ucbmail version supports many features; among them, the ability to drop into the editor of your choice, have a local configuration file, which is named .mailrc, and a multitude of others.
Most users have !bin ahead of lusr/ucb in their PATH variable. Typing mail, gets you /bin/mail. Mail is usually linked to /usr/ucb/mail as well, so a simple path change will allow you to use mail instead of /bin/mail.
If you use csh, another way is to define an alias, as in: alias mail Mail
This gets you Berkeley mail by default. An easy way to tell which version you are using is by the prompt you get when you are reading your mail. If it is a ?, you are using /bin/mail. The & denotes /usr/ucb/Mail. For your enjoyment, I have added as a supplement, my Mail Users Quick Reference and Command Summary sheets.
Take a quick look at these before you read on ....
Confused? Good. Lesson 2....
Mail programs in general, are like most Ice Cream. You can't please all the people, all of the time. As a result, there are many public domain mail interfaces. To name a few, uumail, MUSH, Elm, and SMAIL. Some of these resolve internet addresses, do auto-routing, (such as figuring out the path to, say, joe@ucbvax [Hi Joe!]), while others provide curses style user interfaces, and even Sun style icons of rural mailboxes. It really ends up being a case of whatever turns you on.
I also should mention that almost every one of these mailers has a command set that's somewhat unique to it. A lot of the commands are the same, but there seems to be new and different functionality in each. The power in some of these staggers the mind.
Steve Gilgut
Steve Gilgut, Compugraphic Corp. Wilmington, Mass. 01887 (617)658-5600 X5277 UNISIG Suite/Campground Coordinator; DECUS U.S. Chapter "Of all the things I've lost, I miss my mind the most." ... !{decvax,ima,ism780c,ulowell,laidbak.denning.wizvax.cgeuro,cg-f}!cg-atla!gilgut
UNI-3
? ! Print Reply Type alias chdir
cdoe le?te dp edit exit file folders fo fo# fo +file fo% fo& from headers help hold ignore mail mbox next preserve print quit reply respond save set shell size source top type unalias undelete
unset visual write xit z z-
Ucbmail Qwick Reference Sheet
grevious
elp
shell
prints ignored
Reply to originator only
like Print
print, or change arg
cd
save, no delete
delete
delete, print next
text editor
exit, no chage
folder
list folders
current folder name
previous
switch file
switch to system mbox
switch to $HOME/mbox
header contents
list headers
?
save in system mbox
add to ignore list
mail to user
save in $HOME/mbox
hrint next
old
prints
.
quit, save in $HOME/mbox
reply to all
same as reply
append to file
set option
shell
prints size
read commands from file
print top lines
print
reverse alias
marks as NOT deleted
reverse set
editor
save
exit
presents headers + forward
move backward
--icmd
c
--ed
-f -h
---mpq --sr --t
-vw
~md
append ask ask cc autoprint debug dot hold ignore ignoreeof metoo nosave quiet verbose EDITOR SHELL VISUAL crt escape folder record toplines
shell add to CC read dead.letter editor read in msg edit header
same as -f with >
print msg
abort read in file subject add to list editor write msg out pipe for filter precede by -
append to mbox for subject for CC d like dp doesn't work period is terminator save in system mbox break & cntl C off ignore cntl ·D
sender included no dead.letter supress version doesn't work your editor your shell your editor length before "more" escape character path for folder stora~e path to record outgomg #of lines with top
UNI-4
Ucbmail Summary Reference Sheet
commands in mail:
prints previous message
?
prints help
!
executes shell command
Print
Like 'p', but prints ignored lines
Reply
Reply to origmator only
Type
like Print
alias
no arg prints all defined. arg prints arg. args sets or changes arg
alternates
setmail handles this. don't bother with it
chdir
change working directory
copy
same as save, but no delete
delete
marks as deleted
dp
delete, then print next
edit
invoke text editor on msg
exit
exit, no chages to anything
file
same as folder
folders
list names of folders in folder dir
folder
(fo) fo - print current folder
fo # -previous folder .
fo +filename -switch to filename in folder dir
fo % -switch to system mbox
fo & -switch to $HOME/mbox
from
prints contents of headers
headers
prints list of headers ·
help
same as?
hold
save messages in /usr/spool/mail/yourlogin
ignore
add list of header fields to ignore list
mail usemame mail to a user
mbox
default action (save in $HOME/mbox)
next
print next message
preserve
same as hold
print
prints message
quit
quit, saving unresolved in $HOME/mbox
reply
reply to all people in header
respond
same as reply
save file
append to end of file
set
set an option
shell
jump into a shell
size
prints size of message
source
read mail commands from a file
top
print top few lines of message
type
same as print
unalias
reverse of alias (undefines)
undelete
marks a message as NOT deleted
unset
reverse of set command
visual
invokes display editor
write
same as save
xit
same as exit
z
presents msg headers in windofuls.
move forward: z
move backward: z-
UNI-5
-!command -c name ... -d -e -f messages -h -m messages -p -q -r filename -s string -t name
-w tommand --string
Tilde Escapes
execute shell command add names to CC list read in dead. letter invoke text editor read in a message edit the header same as -f, but shift right 1 tab print message as is so far abort this message (like 2 breaks) read in filename makes a subject field add name to recipient list invoke display editor write msg into file pipe through command for filtering insert string preceded by a -
append ask
askcc autoprint debug dot hold ignore ignoreeof metoo nosave quiet verbose
Set Options For .mailrc
append to mbox rather than prepend. is default prompt for a subject prompt for CC list d command behaves like dp doesn't seem to work, should be like verbose a period is the terminator. is default always save messages in /usr/spool/mail (bad idea) break & cntl C ignored ignore cntl D sender included in group alias don't make dead. letter files supress version when mail is invoked doesn't work either. see debug
EDITOR SHELL VISUAL crt
escape folder record toplines
Set Options With A String Value
set to your favorite editor(line or screen) set to your favorite shell set to your favorite editor(screen) msg length before "more" is invoked on it the escape character. default is path/directory for folder storage. like _Mail path/file to record all outgoing mail number of top lines to print with top command
UNI-6
Unix as a Window to the World
Informal Communications Networks
by Kurt L. Reisler
Hadron, Inc 9990 Lee Highway Fairfax, VA 22030
USA !uunet!hadron!klr
Much has been said of the portability of the Unix operating system, and its suitability as a development environment. Articles have appeared in numerous publications discussing the distributed file systems techniques available to unix systems. However, there is another aspect to unix networking that is often overlooked. This is the uucp network or usenet. It is the implementation of the uucp network and its capabilities that make the Unix operating system and the unix community unique. Because of its capabilities, there are more unix users and developers in communication with each other on a world-wide basis than any other operating system community. In a sense, the usenet community is a technical window on the world.
Unix as an operating system is remarkable. It has developed into an operating system that is used on a huge variety of hardware suites, of various manufacture, of dissimilar hardware configurations~ and of a wide range of computing power. Variants of the Unix operating system are found on systems as smal1 as personal computers, and as large as super computers. Yet all of these unix systems have many things in common, including the heart of usenet, the uucp programs.
The uucp programs were originally envisioned as a means of copying files between unix systems. Extensions to the original concept have also provided the ability to execute commands between unix systems. The logical extension of the uucp programs is to use them to move mail messages between systems. After a11, a mail message is nothing more than a file. The final piece that makes unix connectivity on the informal usenet complete is the fact that uucp connections can take place both between directly connected systems, and systems that are only connected through the telephone system. This allows users on one system to communicate with users on another system on a regular basis, regardless of the physical location of the systems. All of these parts combine to form a very large, informal computer network that is composed of heterogeneous hardware configurations, running a variety of variants of the Unix operating system, located in many countries around the world. This international network is known as usenet.
Systems participating in usenet can connect with each other directly, using either a dedicated or a dial-up line, or they can communicate using other systems as relays (or hops). For example, I can send mail directly to a user at decuac by addressing the message to decuac.'user, since my system hadron has a direct uucp link to decuac. If I want to send mail to a user at lzarvard, I would use a more extensive path,
uunet.1lll-winken!uwvax!harvard.1user where the ! character in the address is used to separate the network names of each system, or hop, along the mail path.
UNI-7
One of the obvious problems with this type of network is determining a path to a given system, much less an optimum path. However, as with so many other potential problems in the Unix world, there is a user-developed solution. There is a usenet map distributed on a nearly monthly basis to several systems in the United States, along with the pathalias software to compute optimized mail paths to the systems listed in the maps. The most recently distributed usenet maps include Unix systems located in Austria, Belgium, Denmark, Finland, France, Greece, Iceland, Ireland, Italy, Luxenburg, Portugal, Spain, Sweden, Switzerland, The Netherlands, The United Kingdom, and West Germany as well as numerous sites in Asia and (of course) the United States. Althou~h there is a designated coordinating site for each country, the maps themselves are available from several usenet sites around the US. If you are a part of the uucp network, you can ask your site manager about mapping and path information.
If you are not presently connected to either usenet or the uusp network, you have 2 options, you can attempt to get connected to a system that is local to you, or you can establish an account with UUNET. UUNET is a non-profit communications service that provides access to USENET news, UUCP mail, and many standards (including the Internet RFCs and comp.std.unix archives). UUNET is the newest experimental project of the USENIX Association and has the unprecedented cooperation of DARPA. Without violating DECUS commercialism policies, I can state that the cost of using UUNET to access the Unix community is minimal. For additional information, you should contact
Peter Salus UUNET/USENIX
P.O. Box 2299 Berkeley, CA 94710
415/528-8649 {seismo,uunet,ucbvax,cbosgd,ames,amdahl}!usenix!uunet-request
Although net.news is sometimes referred to as a glorified bulletin board system, it is one of the most popular uses of usenet. It permits an even more rapid exchange of information, because you do not need to know to whom to address your mail. All that is required (other than a connection or feed for the news) is to post a suitable message into the appropriate news group and in a short time the responses will come in, both in the news group and as direct mail. Of course, there will probably be as many different solutions to any given problem as there are people responding, but it is better then attempting to solve a problem in the dark. The news groups circulate messages, sources and some executables (converted to ascii representations using uuencode) in a wide variety of technical and non-technical news groups. In a later column I will provide more information about net.news.
In conclusion, there are many options available for use with a Unix system to provide networking capabilities and the distribution of resources. The inherent capabilities of the Unix uucp programs, and the resources provided by the uucp network provide enables unix systems that are a part of usenet to be connected to a technical window on the world.
UNI-8
The Way It Is
Warner/Davis
Recently someone called me from one of the "Out on the Floor Offices", an ethereal place rumored to exist only in hyperspace, populated by mysterious beings called Users.
She was quite frantic. She was having trouble running a program through the computer, and her message was clear enough, although rather illconceived: "MY FILES ARE FULL!"
I furrowed my brow, lit a smoke, and explained to her, "Really now, Miss Butterman, I don't have time for this." I slowly exhaled the menthol vapors as I stopped her process, crushing any hope she may have had of ever again seeing that document she had spent three hours slaving over.
"I was typing this REALLY important letter, and it HAS to be ready in an hour. .. there's all this stuff on my screen that I didn't type... it says something about an error, should I read it to you?"
"No point. Just press return."
"Oh my, it wants my username. Can I restart that where I left off?"
"Not a chance." I drew another puff and tossed the phone aside. It occurred to me that if I had to hear one more of those whining complaint sessions, heads were gonna roll. Where do you people GET this stuff? I'm going to tell you what's really going on here. Now LISTEN UP. I'm not going over this a second time:
Computer The black box that does your work for you. That's all you need to know.
Response Time Usually measured in nanoseconds; sometimes measured in calendar months. The general rule is: Shut up your complaining about response time.
Hardware See "Computer." Again, not your concern.
Software If we want you to know, we'll tell you about it, otherwise, leave us alone.
UNI-9
Network Don't worry about it, we'll take care of it. Use it to send mail among your half-wit selves, and don't think we won't read it all. What do you think we do all day? By the way, Butterman... shame about your mother's pancreas.
Data The general rule is: Don't use any data files and if you find any, delete them before I find out about them. In fact, just stay off the computer. (See "Response Time")
System Crash Don't ever call the system manager to tell him you think the computer is down. Don't call him to ask him when it will be up again. The more you bother him, the longer it takes.
Downtime Like I said, don't ask.
Uptime Be thankful for it, use it wisely, and get out of my face.
Overtime Don't be ridiculous.
Vacation A time during which I don't have to put up with your sniveling. Don't try calling. There's no point.
Computer Room Keep out, you're not invited. Don't knock on the door - don't even think about it. I broke the phone last time one of you jerks called me, and I'm not about to replace it. And keep your greasy fingers off the windows.
My Office The name says it all. .. it's mine; stay out.
Your Problems Not my concern.
Deadlines The general rule is: Deadlines are not acknowledged by me; they're not my responsibility. Go tell somebody who cares.
UNI-10
Maintenance
a) A Valid reason for shutting down the system at any time b) Much more important than anything any of you bozos do. c) Anything I choose to call maintenance.
Software Upgrades
Far too complex for you to comprehend. If I tell you I'm upgrading
the system, just be quietly thankful. It's for your own good, even if it
does mean extensive downtime during peak hours.
·
Electronic Mai.I I delete it before reading it, so don't bother sending any to me.
Defaults We like them just like they are; we chose them for a reason. Don't mess with them; consider them mandatory.
Error Messages
I'm not interested. I'm going to kill your process anyway, so keep them to yourself.
Killin~ your Process a Don't ever ask why
b Beyond your control c) No warnings given d) The highlight of my day e) If you call, it's going to happen. No exceptions.
Passwords
I reserve the right to change them without notice at any time. I choose them, and the more you bother me, the more degrading yours will be. (Example: BUTTERMAN: SNOTFACE)
Users
a) They slow down the computer b) They waste my time c) A general nuisance d) Worse than that, actually
Software Modifications You don't know what you want - we'll tell you what you want. It stays like it is. Period.
Privileges I've got them, you don't need them. Enough said.
UNI-11
Priority Mine is higher than yours, accept it. That's the reason my games run faster than your lousy accounting package. (See "Response Time")
Terminals Before calling me with a terminal problem, consider this: a) Are you prepared to do without one for weeks? b) Do you REALLY want your process killed? c) Did you just trip over the cord again? d) Of course you did
Disk Space I set the quotas, you live with them. If you need more space, check "Data Files".
Operator I hired him and I trained him. He does what I tell him to. Usually armed; always dangerous.
BackaufsA good idea b If I gave a sh*t c) Which of course I don't
Lunch The only time that calling my office won't result in the killing of your process.
Data Security That's your problem. I'm certainly not going to lose any sleep over it. My files are locked up tight. I feel secure.
Jiffy Length of time it takes me to resolve your problem by killing your process.
Eternity Length of time it takes me to give a sh*t about any problem that can't be resolved by killing your process.
Impossible a) It can't be done (as far as you know) b) I can't be bothered c) You're starting to annoy me
UNI-12
Inevitable a) Couldn't have been avoided b) Not my fault (as far as you know) c) The result of annoying me
Menus If it's not on the menu, don't ask for it. It's not available. If it is on the menu, it's probably of no use or it doesn't work. We're working on it (See "Eternity").
Utilities I find them quite useful, you'll find them quite inaccessible. Besides, they're not on your menu, are they. What did I tell you about that?
Nuisance You.
Of course, I reserve the right to add, change, or remove anything from the above list. I'm not asking you to accept these matters without question, I'm telling you. Now that we all know where we stand, I'm sure there'll be no future problems. If you have any questions or comments please feel free to keep them to yourself. If you feel the need for more information, I highly recommend that you ask someone else.
System Manager P.S. The new disk quota of 30 blocks per user became effective yesterday.
Anyone caught exceeding the quota will lose their accounts (this means you, Butterman!)
UNI-13
NEWSLETTER OF THE VAX SYSTEMS SIG
Table of Contents
Contributions ...................................................................................... VAX-1 A New Hand at the Tiller ........................................................................ VAX-1 Spring 1988 SIR Ballot Results .................................................................. VAX-2 It's On The Tapes ................................................................................ VAX-26 VAX/VMS Security .............................................................................. VAX-27
Contributions
Contributions and suggestions for this newsletter are constantly needed. Articles, letters, technical tips, or anything of interest to our SIG are greatly appreciated. The editor prefers submissions be made electronically. Magnetic tape and hard copy will be accepted, but may delay publication.
Please do not submit program source. It is difficult to typeset and is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations or other meetings. They are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides.
Send your contributions to: ARPAnet/ CSnet/NSFnet: ctp@cs.utexas.edu
UUCP: ctp@ut-sally.uucp ({harvard,ihnp4,uunet}!ut-sally!ctp) BITNET: CTP@UTADNX CompuServe: 75226,3135 DCS: POOLE
or if you must, use the U. S. Mails: Clyde T. Poole
The University of Texas at Austin Department of Computer Sciences
Taylor Hall 2.124 Austin, Texas 78712-1188
A New Hand at the Tiller
David L. Wyse, VAX Systems SIG, Communications Committee Representative
On behalf of the Executive Committee of the VAX Systems SIG, I would like to welcome the new editor of the Pageswapper, Clyde T. Poole.
Clyde has had considerable experience with DECUS and has been the editor of At Large, the Large Systems SIG newsletter. Clyde is very active in the Communications Committee and we look forward to some stimulating issues of the Pageswapper.
It will now be easier to submit to the Pageswapper. If you will take a look at the new "Contributions" article (above), you'll see that Clyde has access to a host of networks and DCS. This should facilitate your contributions to your favorite newsletter.
You should also have noticed one other change in the Pageswapper. Clyde will be typesetting the information sent to him so we should no longer have to turn the page around to read your favorite article.
Lastly, this note would not be complete without our sincere thanks to Larry Kilgallen for the countless hours spent in editing the Pageswapper, including shepherding our publication through the genesis and evolution of "The Big One". Thanks Larry, from all of us.
Spring 1988 SIR Ballot Results
Mark Oakley, SIR Coordinator
A total of 315 ballots were counted in the latest SIR ballot, a slight decline over the past two ballots. The number of ballots cast electronically on the Pageswapper VAX continues to increase. I want to thank Larry Kilgallen again for the use of this machine.
There was a tie in the voting for tenth place between SIR S88-28 (improve VMS DEFINE utility) and SIR S88-11 (no CR/FL for DCL WRITE command). I have asked Digital to respond to both SIR's.
I am hopeful that participation will continue to build, and will look for ways to encourage you to vote.
The SIR ballot is the only on-going program by which the SIG provides input to Digital. Top 10 (and other) SIR's continue to be incorporated into VMS. Digital has repeatedly encouraged the use of this channel of communication.
The summary of this voting appears below. Digital's response to the top 11 requests overall will be presented at the Spring 1988 DECUS Symposium in Cincinnati.
Interpreting the SIR Ballot Results
The results of the System Improvement Request ballot are shown on the following pages. All of the reports have the same one page format. Following the report title is the number of ballots counted for that report. The number shown on the "All Users" report is the total number of ballots which were returned. The ballots on the "11/780 Users" report is the number of ballots which checked the "11/780" blank on the ballot questionnaire, and so on.
The SIR's are listed on the page in order of points received, from highest to lowest. The entry for each SIR be~ins with the SIR number (from the ballot), a brief description, and the total number of votes (positive and negative) received by that SIR.
The data is summarized in two different ways. First, there are a series of reports broken down by user category. The user categories are defined by the questionnaire portion of the SIR ballot. A ballot was counted in each user category which was checked off, for example "11/780 user". Finally, there are a series of reports ranking the SIR's within SIR category. The SIR categories are those shown on the ballot, for example "DCL and Utilities" and "Commercial". The reports by SIR category use the data from all ballots received.
VAX-2
Spring 1988 Ballot The Top 35 SIR's as Ranked by All Users
Total ballots in this category: 315
SIR
SIR
Nr.
Description
7 LAT sessions identity information 19 "Control Print Screen" capability
37 Corrrect READALL behavior 10 Various BACKUP enhancements 23 Enhance SHOW PROCESS command 3 Provide deallocation capability 61 Enhance print form modules 62 Provide BACKUP dismount/deallocate 8 Provide queued ALLOCATE requests 28 Improving VMS define utility 11 No CR/LF for DCL WRITE command 64 Provide limits on simultaneous logins
14 Extend DCL TABLES 42 Provide installed memory-resident code 29 Provide $GETDVI "wild card" capability
9
Provide project accounting
20 Enhance sysgen parameter readability
48 Prevent password reuse by users
21 Provide Mail enhancements
15 DCL status return enhancements
68 Support multiple version products
52 Security alarm messages to a file
63 Support bell character in BACKUP
6 Provide a "virtual disk" capability
66 WSQUOTA/WSEXTENT for INSTALL
49 Suppress certain login failures
58 Provide RIGHTSLIST lexical function
22 SET HOST/DTE for more modems
54 Provide DECnet end-to-end encryption
57 Enhance COPY to copy ACL's
2 Enhance batch load balancing
30 Enhance $GETUAI and $SETUAI
13 Enhanced command RECALL capabilities
24 MOUNT/FOREIGN and uninitialized tapes
1 Provide SCS communication services
Total Votes
120
117
115 111 102
97 94
94
91 80 80
78 76
75
74
72
72
69
67 67 64
60
58 54 53
52 52 48 47 47 47
44
44
44 43
VAX-3
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 8700/8800
Total ballots in this category: 65
SIR
SIR
Nr.
Description
7 LAT sessions identity information
37 Corrrect READALL behavior
29 Provide $GETDVI "wild card" capability
9 Provide project accounting
48 Prevent password reuse by users
52 Security alarm messages to a file
23 Enhance SHOW PROCESS command
8 Provide queued ALLOCATE requests
19 "Control Print Screen" capability
3
Provide deallocation capability
20 Enhance sysgen parameter readability
36 Provide descriptive text for files
6 Provide a "virtual disk" capability
61 Enhance print form modules
54 Provide DECnet end~to-end encryption
11 No CR/LF for DCL WRITE command
62 Provide BACKUP dismount/deallocate
51 Control file access via an image
58 Provide RIGHTSLIST lexical function
55 Support SET HOST proxy access
64 Provide limits on simultaneous logins
68 Support multiple version products
15 DCL status return enhancements
42 Provide installed memory-resident code
30 Enhance $GETUAI and $SETUAI
10 Various BACKUP enhancements
1 Provide SCS communication services
47 Eliminate unsolicited file creation ACE
14 Extend DCL TABLES
31 Improve terminal comm data display
2
Enhance batch load balancing
28 Improving VMS define utility
57 Enhance COPY to copy ACL's
4
Improve tape label recognition
49 Suppress certain login failures
Total Votes
32 28 25
24
24
23 22 21 19
19
18
17 16
16 15 15 15 14
14 13 13 13 12 12 12 12 11
11
11
11
11
11
10
10
10
VAX-4
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 86nn
Total ballots in this category: 111
SIR
SIR
Nr.
Description
8 Provide queued ALLOCATE requests 37 Corrrect READALL behavior 7 LAT sessions identity information 29 Provide $GETDVI "wild card" capability 52 Security alarm messages to a file 19 "Control Print Screen" capability 48 Prevent password reuse by users· 10 Various BACKUP enhancements 23 Enhance SHOW PROCESS command 14 Extend DCL TABLES 42 Provide installed memory-resident code 3 Provide deallocation capability 68 Support multiple version products 58 Provide RIGHTSLIST lexical function 9 Provide project accounting 61 Enhance print form modules 15 DCL status return enhancements 62 Provide BACKUP dismount/deallocate 64 Provide limits on simultaneous logins 11 No CR/LF for DCL WRITE command 1 Provide SCS communication services 57 Enhance COPY to copy ACL's 66 WSQUOTA/WSEXTENT for INSTALL 20 Enhance sysgen parameter readability 51 Control file access via an image 2 Enhance batch load balancing 28 Improving VMS define utility 6 Provide a "virtual disk" capability 13 Enhanced command RECALL capabilities 31 Improve terminal comm data display 54 Provide DECnet end-to-end encryption 55 Support SET HOST proxy access 21 Provide Mail enhancements 60 Support ACE security alarm ACE bypass 36 Provide descriptive text for files
Total Votes
45 43
40 39
37 36 36 36
35
34
34 33 31 28 28 26 25 24 24 24 23 22 22 22 21
20 18 18 17 17 16 16 16 15 15
VAX-5
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 85nn
Total ballots in this category: 53
SIR
SIR
Nr.
Description
19 "Control Print Screen" capability
7 LAT sessions identity information
10 Various BACKUP enhancements
8
Provide queued ALLOCATE requests
23 Enhance SHOW PROCESS command
11 No CR/LF for DCL WRITE command
21 Provide Mail enhancements
42 Provide installed memory-resident code
9
Provide project accounting
61 Enhance print form modules
28 Improving VMS define utility
15 DCL status return enhancements
1
Provide SCS communication services
62 Provide BACKUP dismount/deallocate
37 Corrrect READALL behavior
13 Enhanced command RECALL capabilities
49 Suppress certain login failures
54 Provide DECnet end-to-end encryption
3
Provide deallocation capability
2
Enhance batch load balancing
47 Eliminate unsolicited file creation ACE
48 Prevent password reuse by users
36 Provide descriptive text for files
68 Support multiple version products
29 Provide $GETDVI "wild card" capability
52 Security alarm messages to a file
64 Provide limits on simultaneous logins
14 Extend DCL TABLES
6 Provide a "virtual disk" capability
53 Provide ACL class names management
31 Improve terminal comm data display 66 WSQUOTA/WSEXTENT for INSTALL 56 Improve DECnet file access control 26 Support DCL command /BELL qualifier 25 Enhanced DEFINE/KEY capabilities
Total
Votes
24 23 20 20
19
18 15 15 14 13 12 12 12 12 11
11
11
11
11 11
10 10 10 10 9
9 9 9 8 8 8 8 8 7 7
VAX-6
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 83nn/82nn
Total ballots in this category: 87
SIR
SIR
Nr.
Description
7 LAT sessions identity information 10 Various BACKUP enhancements 37 Corrrect READALL behavior 19 "Control Print Screen" capability 9 Provide project accounting 23 Enhance SHOW PROCESS command 11 No CR/LF for DCL WRITE command 3 Provide deallocation capability 61 Enhance print form modules 62 Provide BACKUP dismount/deallocate 8 Provide queued ALLOCATE requests 48 Prevent password reuse by users 64 Provide limits on simultaneous logins 36 Provide descriptive text for files 21 Provide Mail enhancements 15 DCL status return enhancements 2 Enhance batch load balancing 20 Enhance sysgen parameter readability 63 Support bell character in BACKUP 29 Provide $GETDVI "wild card" capability 42 Provide installed memory-resident code 49 Suppress certain login failures 1 Provide SCS communication services 47 Eliminate unsolicited file creation ACE
22 SET HOST/DTE for more modems
54 Provide DECnet end-to-end encryption 55 Support SET HOST proxy access 6 Provide a "virtual disk" capability 28 Improving VMS define utility 13 Enhanced command RECALL capabilities 30 Enhance $GETUAI and $SETUAI
66 WSQUOTA/WSEXTENT for INSTALL 52 Security alarm messages to a file 58 Provide RIGHTSLIST lexical function 14 Extend DCL TABLES
Total Votes
45 32
32 31 29 28 26 26 26 25 21 21 20 19 19 19 18 18 18 18
17 17
16 16 15 15 15 15 15 15 15 15 13 12 12
VAX-7
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 11/780, 11/782, 11/785
Total ballots in this category: 196
SIR
SIR
Nr.
Description
37 Corrrect READALL behavior
10 Various BACKUP enhancements
7
LAT sessions identity information
19 "Control Print Screen" capability
8
Provide queued ALLOCATE requests
3
Provide deallocation capability
23 Enhance SHOW PROCESS command
62 Provide BACKUP dismount/deallocate
29 Provide $GETDVI "wild card" capability
61 Enhance print form modules
14 Extend DCL TABLES
48 Prevent password reuse by users 52 Security alarm messages to a file
9
Provide project accounting
42 Provide installed memory-resident code
11 No CR/LF for DCL WRITE command
68 Support multiple version products 64 Provide limits on simultaneous logins 28 Improving VMS define utility 20 Enhance sysgen parameter readability
58 Provide RIGHTSLIST lexical function
15 DCL status return enhancements
54 Provide DECnet end-to-end encryption
21 Provide Mail enhancements
13 Enhanced command RECALL capabilities
6
Provide a "virtual disk" capability
66 WSQUOTA/WSEXTENT for INSTALL
63 Support bell character in BACKUP
30 Enhance $GETUAI and $SETUAI
49 Suppress certain login failures
57 Enhance COPY to copy ACL's
2
Enhance batch load balancing
1
Provide SCS communication services
51 Control file access via an image
25 Enhanced DEFINE/KEY capabilities
Total
Votes
77
72
72 71
68
66 61 57 55
54
53
53
51
48
48
48
47 46 46
40
40
38
36 36
34
33
32 32 31 30 30 30 29 29 28
vAx..:.s
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 11/750
Total ballots in this category: 137
Sill
Sill
Nr.
Description
7 LAT sessions identity information 19 "Control Print Screen" capability
37 Corrrect READALL behavior
10 Various BACKUP enhancements
61 Enhance print form modules
23 Enhance SHOW PROCESS command
8 Provide queued ALLOCATE requests 3 Provide deallocation capability 11 No CR/LF for DCL WRITE command 62 Provide BACKUP dismount/deallocate 28 Improving VMS define utility 15 DCL status return enhancements 42 Provide installed memory-resident code 9 Provide project accounting 20 Enhance sysgen parameter readability 64 Provide limits on simultaneous logins 29 Provide $GETDVI "wild card" capability 63 Support bell character in BACKUP 1 Provide SCS communication services 48 Prevent password reuse by users 21 Provide Mail enhancements 55 Support SET HOST proxy access 68 Support multiple version products
66 WSQUOTA/WSEXTENT for INSTALL 6 Provide a "virtual disk" capability
18 Make DCL /LOG qualifier consistent
14 Extend DCL TABLES
58 Provide RIGHTSLIST lexical function
24 MOUNT/FOREIGN and uninitialized tapes 67 Priority for INSTALL 31 Improve terminal comm data display 50 No file update when protections change
47 Eliminate unsolicited file creation ACE
36 Provide descriptive text for files 46 Provide line-number support in TPU
Total Votes
51 50 46
43
43
42
40
39 39
37 36 36
34
33 31 31 29 27 26 26 26 24 24 23 23 21 20 20 20 20 20 19 19 18
18
VAX-9
Spring 1988 Ballot The Top 35 SIR's as Ranked by VAX 11/730, 11/725
Total ballots in this category: 57
SIR
SIR
Nr.
Description
7
LAT sessions identity information
37 Corrrect READALL behavior
19 "Control Print Screen" capability
8
Provide queued ALLOCATE requests
61 Enhance print form modules
28 Improving VMS define utility
15 DCL status return enhancements
3
Provide deallocation capability
10 Various BACKUP enhancements
62 Provide BACKUP dismount/deallocate
66 WSQUOTA/WSEXTENT for INSTALL
68 Support multiple version products
1 Provide SCS communication services
23 Enhance SHOW PROCESS command
42 Provide installed memory-resident code
11 No CR/LF for DCL WRITE command
29 Provide $GETDVI "wild card" capability
67 Priority for INSTALL
36 Provide descriptive text for files
31 Improve terminal comm data display
9
Provide project accounting
64 Provide limits on simultaneous logins
13 Enhanced command RECALL capabilities
52 Security alarm messages to a file
56 Improve DECnet file access control
58 Provide RIGHTSLIST lexical function
14 Extend DCL TABLES
49 Suppress certain login failures
21 Provide Mail enhancements
54 Provide DECnet end-to-end encryption
55 Support SET HOST proxy access
2
Enhance batch load balancing
25 Enhanced DEFINE/KEY capabilities
24 MOUNT/FOREIGN and uninitialized tapes
20 Enhance sysgen parameter readability
Total
Votes
24
22
21 20
19 15
15 15 14 14 14 14
13 12 12 12
11
11
11 10
10
10 9 9 9
9 9
8
8 8 8 8 8
7 7
VAX-10
Spring 1988 Ballot The Top 35 SIR's as Ranked by MicroVAX I, II
Total ballots in this category: 218
SIR
SIR
Nr.
Description
7 LAT sessions identity information 19 "Control Print Screen" capability 8 Provide queued ALLOCATE requests 10 Various BACKUP enhancements 3 Provide deallocation capability 23 Enhance SHOW PROCESS command 37 Corrrect READALL behavior 61 Enhance print form modules 29 Provide $GETDVI "wild card" capability
48 Prevent password reuse by users
42 Provide installed memory-resident code
11 No CR/LF for DCL WRITE command
62 Provide BACKUP dismount/deallocate
14 Extend DCL TABLES
9
Provide project accounting
28 Improving VMS define utility
20 Enhance sysgen parameter readability
64 Provide limits on simultaneous logins
52 Security alarm messages to a file
15 DCL status return enhancements
68 Support multiple version products
58 Provide RIGHTSLIST lexical function
6
Provide a "virtual disk" capability
21 Provide Mail enhancements
2
Enhance batch load balancing
57 Enhance COPY to copy ACL's
1
Provide SCS communication services
55 Support SET HOST proxy access
13 Enhanced command RECALL capabilities
63 Support bell character in BACKUP
54 Provide DECnet end-to-end encryption
66 WSQUOTA/WSEXTENT for INSTALL
49 Suppress certain login failures
36 Provide descriptive text for files
24 MOUNT/FOREIGN and uninitialized tapes
Total Votes
83 75 74 73 73 72 72
68 62
56 54 53 53 51 50 50 46 45 44 44 43 41 40 39 38 37 35 34
32 32 32 32 32 31
30
VAX-11
Spring 1988 Ballot The Top 35 SIR's as Ranked by MicroVAX 2000
Total ballots in this category: 64
SIB
SIB
Nr.
Description
7 LAT sessions identity information
8
Provide queued ALLOCATE requests
23 Enhance SHOW PROCESS command 37 Corrrect READALL behavior 19 "Control Print Screen" capability 28 Improving VMS define utility 10 Various BACKUP enhancements
3 Provide deallocation capability 11 No CR/LF for DCL WRITE command
9
Provide project accounting
48 Prevent password reuse by users
15 DCL status return enhancements 29 Provide $GETDVI "wild card" capability
36 Provide descriptive text for files 6 Provide a "virtual disk" capability
20 Enhance sysgen parameter readability
52 Security alarm messages to a file 55 Support SET HOST proxy access 61 Enhance print form modules 62 Provide BACKUP dismount/deallocate 1 Provide SCS communication services 21 Provide Mail enhancements 14 Extend DCL TABLES 42 Provide installed memory-resident code 58 Provide RIGHTSLIST lexical function 68 Support multiple version products 54 Provide DECnet end-to-end encryption 31 Improve terminal comm data display
51 Control file access via an image
66 WSQUOTA/WSEXTENT for INSTALL 2 Enhance batch load balancing
22 SET HOST/DTE for more modems
13 Enhanced command RECALL capabilities
64 Provide limits on simultaneous logins
49 Suppress certain login failures
Total Votes
30
25 24 23 22 21 19 18 18 18 18 16 14 14 14 14 14 14 14 14 13 13 13 12 12 12 11 11 10 10 10 9 9 9 9
VAX-12
Spring 1988 Ballot The Top 35 SIR's as Ranked by MicroVAX 3n00
Total ballots in this category: 17
SIR
SIR
Total
Nr.
Description
Votes
7
LAT sessions identity information
9
37 Corrrect READALL behavior
8
3
Provide deallocation capability
7
19 "Control Print Screen" capability
7
6
Provide a "virtual disk" capability
7
48 Prevent password reuse by users
6
52 Security alarm messages to a file
6
61 Enhance print form modules
6
64 Provide limits on simultaneous logins
6
8
Provide queued ALLOCATE requests
5
9
Provide project accounting
5
2
Enhance batch load balancing
5
21 Provide Mail enhancements
5
22 SET HOST/DTE for more modems
5
47 Eliminate unsolicited file creation ACE
4
11 No CR/LF for DCL WRITE command
4
10 Various BACKUP enhancements
4
54 Provide DECnet end-to-end encryption
4
58 Provide RIGHTSLIST lexical function
4
28 Improving VMS define utility
4
62 Provide BACKUP dismount/deallocate
4
20 Enhance sysgen parameter readability
4
49 Suppress certain login failures
3
13 Enhanced command RECALL capabilities
3
29 Provide $GETDVI "wild card" capability
3
15 DCL status return enhancements
3
45 VAX ADA needs complete VMS RTL package 3
1 Provide SCS communication services
3
63 Support bell character in BACKUP
3
23 Enhance SHOW PROCESS command
3
68 Support multiple version products
3
43 Provide /NOWAIT switch for TPU
2
57 Enhance COPY to copy ACL's
2
26 Support DCL command /BELL qualifier
2
31 Improve terminal comm data display
2
VAX-13
Spring 1988 Ballot The Top 35 SIR's as Ranked by Business EDP
Total ballots in this category: 116
filR
sm
Nr.
Description
7 LAT sessions identity information 10 Various BACKUP enhancements 61 Enhance print form modules 37 Corrrect READALL behavior 23 Enhance SHOW PROCESS command 29 Provide $GETDVI "wild card" capability 48 Prevent password reuse by users 19 "Control Print Screen" capability 3 Provide deallocation capability 68 Support multiple version products 14 Extend DCL TABLES 62 Provide BACKUP dismount/deallocate 42 Provide installed memory-resident code 58 Provide RIGHTSLIST lexical function 8 Provide queued ALLOCATE requests 9 Provide project accounting 63 Support bell character in BACKUP
64 Provide limits on simultaneous logins 52 Security alarm messages to a file 11 No CR/LF for DCL WRITE command 22 SET HOST/DTE for more modems 28 Improving VMS define utility
57 Enhance COPY to copy ACL's 55 Support SET HOST proxy access 6 Provide a "virtual disk" capability 49 Suppress certain login failures 20 Enhance sysgen parameter readability 21 Provide Mail enhancements
66 WSQUOTA/WSEXTENT for INSTALL 15 DCL status return enhancements 54 Provide DECnet end-to-end encryption 36 Provide descriptive text for files
2 Enhance batch load balancing
51 Control file access via an image 31 Improve terminal comm data display
Total
Votes
53 50
43
42 40
40 39 37 35 33 32 31
31
30
29 26 26 26 26 25
25 24
24 22 22 22 22 21 20 20
19
18
17
16 16
VAX-14
Spring 1988 Ballot The Top 35 SIR's as Ranked by Education
Total ballots in this category: 53
SIR
SIR
Nr.
Description
37 Corrrect READALL behavior 19 "Control Print Screen" capability 10 Various BACKUP enhancements 7 LAT sessions identity information 62 Provide BACKUP dismount/deallocate
64 Provide limits on simultaneous logins
30 Enhance $GETUAI and $SETUAI 28 Improving VMS define utility 23 Enhance SHOW PROCESS command
11 No CR/LF for DCL WRITE command 21 Provide Mail enhancements
66 WSQUOTA/WSEXTENT for INSTALL
14 Extend DCL TABLES 20 Enhance sysgen parameter readability 61 Enhance print form modules 52 Security alarm messages to a file
54 Provide DECnet end-to-end encryption
51 Control file access via an image 15 DCL status return enhancements
22 SET HOST/DTE for more modems 49 Suppress certain login failures
9 Provide project accounting
8 Provide queued ALLOCATE requests
67 Priority for INSTALL 68 Support multiple version products
57 Enhance COPY to copy ACL's 42 Provide installed memory-resident code 65 Provide UAF distributed management 63 Support bell character in BACKUP 31 Improve terminal comm data display 3 Provide deallocation capability
55 Support SET HOST proxy access
18 Make DCL /LOG qualifier consistent 32 Provide directory file enhancements 29 Provide $GETDVI "wild card" capability
Total
Votes
27 26 24 20 20 20 18
17
16 16 16 16
15 15
14 13 13 12 11
11 11
11
11 11 11
10 10
10 9 9 9 8 8 8 8
VA~.,..15
Spring 1988 Ballot The Top 35 SIR's as Ranked by Data Acquisition/Control
Total ballots in this category: 65
SIR
SIR
Nr.
Description
7 LAT sessions identity information
37 Corrrect READALL behavior
23 Enhance SHOW PROCESS command
11 No CR/LF for DCL WRITE command
19 "Control Print Screen" capability
28 Improving VMS define utility 8 Provide queued ALLOCATE requests
20 Enhance sysgen parameter readability
3 Provide deallocation capability
42 Provide installed memory-resident code
62 Provide BACKUP dismount/deallocate
61 Enhance print form modules
31 Improve terminal comm data display
10 Various BACKUP enhancements 15 DCL status return enhancements 14 Extend DCL TABLES
64 Provide limits on simultaneous logins
48 Prevent password reuse by users
55 Support SET HOST proxy access 29 Provide $GETDVI "wild card" capability
6
Provide a "virtual disk" capability
36 Provide descriptive text for files
9 Provide project accounting 68 Support multiple version products 66 WSQUOTA/WSEXTENT for INSTALL
18 Make DCL /LOG qualifier consistent 21 Provide Mail enhancements
57 Enhance COPY to copy ACL's
58 Provide RIGHTSLIST lexical function 2 Enhance batch load balancing 51 Control file access via an image
53 Provide ACL class names management
54 Provide DECnet end-to-end encryption
47 Eliminate unsolicited file creation ACE
13 Enhanced command RECALL capabilities
Total Votes
29 29 24
23 23
20 20
19 19 19
19 18 18
17
15 15 15 14 13 13 13 13 12 12 11 11 10 9 9 9 9 9 9
9 8
VAX-16
Spring 1988 Ballot The Top 35 SIR's as Ranked by Service Bureau
Total ballots in this category: 23
SIR
SIR
Nr.
Description
8
Provide queued ALLOCATE requests
10 Various BACKUP enhancements
14 Extend DCL TABLES
37 Corrrect READALL behavior
23 Enhance SHOW PROCESS command
31 Improve terminal comm data display
36 Provide descriptive text for files
7 LAT sessions identity information
68 Support multiple version products
21 Provide Mail enhancements
13 Enhanced command RECALL capabilities
52 Security alarm messages to a file
55 Support SET HOST proxy access
11 No CR/LF for DCL WRITE command
38 Support image backward compatibility
39 Enhance DYNSWITCH software
47 Eliminate unsolicited file creation ACE
6 Provide a "virtual disk" capability
19 "Control Print Screen" capability
58 Provide RIGHTSLIST lexical function
61 Enhance print form modules
62 Provide BACKUP dismount/deallocate
65 Provide UAF distributed management
29 Provide $GETDVI "wild card" capability
28 Improving VMS define utility
42 Provide installed memory-resident code
15 DCL status return enhancements
48 Prevent password reuse by users
64 Provide limits on simultaneous logins
9 Provide project accounting
54 Provide DECnet end-to-end encryption
44 Multiple ".END" statements in Macro
2 Enhance batch load balancing
3
Provide deallocation capability
51 Control file access via an image
Total Votes
11 10 8 8 7 7 7 7 7 6
6 6
6 6
5 5
5
5 5
5
5 5
5
5 4 4 4
4 4 4 4 3 3 3 3
VAX-17
Spring 1988 Ballot The Top 35 SIR's as Ranked by Scientific/Engineering
Total ballots in this category: 194
SIR
SIR
Nr.
Description
37 Corrrect READALL behavior
8
Provide queued ALLOCATE requests
3
Provide deallocation capability
19 "Control Print Screen" capability
7 LAT sessions identity information
10 Various BACKUP enhancements
23 Enhance SHOW PROCESS command
61 Enhance print form modules
62 Provide BACKUP dismount/deallocate
29 Provide $GETDVI "wild card" capability
9 Provide project accounting
14 Extend DCL TABLES
11 No CR/LF for DCL WRITE command
28 Improving VMS define utility
42 Provide installed memory-resident code
52 Security alarm messages to a file
20 Enhance sysgen parameter readability
68 Support multiple version products
48 Prevent password reuse by users
64 Provide limits on simultaneous logins
15 DCL status return enhancements
57 Enhance COPY to copy ACL's
58 Provide RIGHTSLIST lexical function
21 Provide Mail enhancements
63 Support bell character in BACKUP
2
Enhance batch load balancing
49 Suppress certain login failures
66 WSQUOTA/WSEXTENT for INSTALL
47 Eliminate unsolicited file creation ACE
13 Enhanced command RECALL capabilities
24 MOUNT/FOREIGN and uninitialized tapes
6
Provide a "virtual disk" capability
1 Provide SCS communication services 36 Provide descriptive text for files
55 Support SET HOST proxy access
Total
Votes
76 71
71
69 62 62 59 59
57 49
48 47 46 46 44 44
43
43
42
38 38 36 35
34
33 29 29
28
27 27 27 25 25
24 24
VAX-18
Spring 1988 Ballot The Top 35 SIR's as Ranked by Telecommunications
Total ballots in this category: 93
SIR
SIR
Nr.
Description
8
Provide queued ALLOCATE requests
10 Various BACKUP enhancements
3
Provide deallocation capability
7
LAT sessions identity information
42 Provide installed memory-resident code
52 Security alarm messages to a file
37 Corrrect READALL behavior
19 "Control Print Screen" capability
61 Enhance print form modules
48 Prevent password reuse by users
58 Provide RIGHTSLIST lexical function
29 Provide $GETDVI "wild card" capability
14 Extend DCL TABLES
9
Provide project accounting
68 Support multiple version products
11 No CR/LF for DCL WRITE command
28 Improving VMS define utility
23 Enhance SHOW PROCESS command
62 Provide BACKUP dismount/deallocate
15 DCL status return enhancements
57 Enhance COPY to copy ACL's
60 Support ACE security alarm ACE bypass
6
Provide a "virtual disk" capability
13 Enhanced command RECALL capabilities
20 Enhance sysgen parameter readability
2
Enhance batch load balancing
54 Provide DECnet end-to-end encryption
55 Support SET HOST proxy access
64 Provide limits on simultaneous logins
1
Provide SCS communication services
70 Enhance BACKUP file attribute
21 Provide Mail enhancements
36 Provide descriptive text for files
31 Improve terminal comm data display
66 WSQUOTA/WSEXTENT for INSTALL
Total Votes
40 36 35 33 33 31
30 29 28 27 26 26 25 23 23 22 22 21
19
18 18
17 17
16 15 15 15 15 15 15 15 13 13 12 12
VAX-19
Spring 1988 Ballot The Top 35 SIR's as Ranked by Software Development
Total ballots in this category: 238
SIB
SIB
Nr.
Description
37 Corrrect READALL behavior
7 LAT sessions identity information
23 Enhance SHOW PROCESS command
10 Various BACKUP enhancements
19 "Control Print Screen" capability
3 Provide deallocation capability
61 Enhance print form modules
8 Provide queued ALLOCATE requests
11 No CR/LF for DCL WRITE command
29 Provide $GETDVI "wild card" capability
9 Provide project accounting
14 Extend DCL TABLES
62 Provide BACKUP dismount/deallocate
42 Provide installed memory-resident code
15 DCL status return enhancements
48 Prevent password reuse by users
64 Provide limits on simultaneous logins
28 Improving VMS define utility
20 Enhance sysgen parameter readability
52 Security alarm messages to a file
21 Provide Mail enhancements
68 Support multiple version products
58 Provide RIGHTSLIST lexical function
57 Enhance COPY to copy ACL's
6
Provide a "virtual disk" capability
63 Support bell character in BACKUP
54 Provide DECnet end-to-end encryption
66 WSQUOTA/WSEXTENT for INSTALL
2
Enhance batch load balancing
13 Enhanced command RECALL capabilities
1
Provide SCS communication services
31 Improve terminal comm data display
30 Enhance $GETUAI and $SETUAI
55 Support SET HOST proxy access
22 SET HOST/DTE for more modems
Total
Votes
90 86 79 79
78 77
77
75 63 63 60 59 59 58 54
53
52 51 50 47
47
47
42 41 39 39 38
38 38 36 36 34 33 33 32
VAX-20
Spring 1988 Ballot The Top 35 SIR's as Ranked by Computer Science Research
Total ballots in this category: 31
SIR
SIR
Nr.
Description
37 Corrrect READALL behavior
9
Provide project accounting
48 Prevent password reuse by users
7
LAT sessions identity information
19 "Control Print Screen" capability
28 Improving VMS define utility
3
Provide deallocation capability
23 Enhance SHOW PROCESS command
62 Provide BACKUP dismount/deallocate
8
Provide queued ALLOCATE requests
6
Provide a "virtual disk" capability
10 Various BACKUP enhancements
68 Support multiple version products
14 Extend DCL TABLES
54 Provide DECnet end-to-end encryption
52 Security alarm messages to a file
11 No CR/LF for DCL WRITE command
55 Support SET HOST proxy access
31 Improve terminal comm data display
49 Suppress certain login failures
24 MOUNT/FOREIGN and uninitialized tapes
27 Restore CONTROL_U behavior
1
Provide SCS communication services
20 Enhance sysgen parameter readability
2
Enhance batch load balancing
56 Improve DECnet file access control
58 Provide RIGHTSLIST lexical function
61 Enhance print form modules
42 Provide installed memory-resident code
47 Eliminate unsolicited file creation ACE
15 DCL status return enhancements
21 Provide Mail enhancements
18 Make DCL /LOG qualifier consistent
35 Priority control of DECnet processes
36 Provide descriptive text for files
Total Votes
14 13
12
11 11 9
9
9 9 8 8 8 8 7 7
6 6
6 6 6 5 5
5 5 5 5 5 5 5 5
4 4 4
4 4
VAX-21
Spring 1988 Ballot The Top 35 SIR's as Ranked by CAD/CAM
Total ballots in this category: 87
SIR
SIR
Nr.
Description
3 Provide deallocation capability 8 Provide queued ALLOCATE requests 10 Various BACKUP enhancements 19 "Control Print Screen" capability 61 Enhance print form modules 48 Prevent password reuse by users 37 Corrrect READALL behavior 29 Provide $GETDVI "wild card" capability 7 LAT sessions identity information 68 Support multiple version products 62 Provide BACKUP dismount/deallocate 42 Provide installed memory-resident code 23 Enhance SHOW PROCESS command 11 No CR/LF for DCL WRITE command 9 Provide project accounting 14 Extend DCL TABLES 52 Security alarm messages to a file 58 Provide RIGHTSLIST lexical function 28 Improving VMS define utility 15 DCL status return enhancements 57 Enhance COPY to copy ACL's 49 Suppress certain login failures 70 Enhance BACKUP file attribute 54 Provide DECnet end-to-end encryption 63 Support bell character in BACKUP 47 Eliminate unsolicited file creation ACE 6 Provide a "virtual disk" capability 60 Support ACE security alarm ACE bypass 46 Provide line-number support in TPU 1 Provide SCS communication services 64 Provide limits on simultaneous logins 31 Improve terminal comm data display 20 Enhance sysgen parameter readability 2 Enhance batch load balancing 18 Make DCL /LOG qualifier consistent
Total Votes
38 36 36 33 32 31
30 29 29 28 26 26 24 24 23 23 23 22 19 19 16 15 15 13 13 12 12 11 11 10 10 10 10
9 9
VAX-22
Spring 1988 Ballot
The Top 35 SIR's as Ranked by Hardware Development Total ballots in this category: 33
SIR
SIR
Nr.
Description
3 Provide deallocation capability 8 Provide queued ALLOCATE requests 19 "Control Print Screen" capability 37 Corrrect READALL behavior 7 LAT sessions identity information 10 Various BACKUP enhancements 61 Enhance print form modules 9 Provide project accounting 62 Provide BACKUP dismount/deallocate 42 Provide installed memory-resident code 1 Provide SCS communication services 15 DCL status return enhancements 11 No CR/LF for DCL WRITE command 23 Enhance SHOW PROCESS command 2 Enhance batch load balancing 66 WSQUOTA/WSEXTENT for INSTALL 68 Support multiple version products 21 Provide Mail enhancements 29 Provide $GETDVI "wild card" capability 47 Eliminate unsolicited file creation ACE 49 Suppress certain login failures 5 Providing batch job "filtering" 20 Enhance sysgen parameter readability 14 Extend DCL TABLES 6 Provide a "virtual disk" capability 54 Provide DECnet end-to-end encryption 28 Improving VMS define utility 18 Make DCL /LOG qualifier consistent 64 Provide limits on simultaneous logins 33 Provide a real-time debugger 36 Provide descriptive text for files 58 Provide RIGHTSLIST lexical function 46 Provide line-number support in TPU 31 Improve terminal comm data display 63 Support bell character in BACKUP
Total Votes
12 12 12 12 11 11 11 9 9 8 8 8 7 7 7 7 7
6 6 6
6 5 5 5 5 5 5 5 5 5 5 4 4 4 4
VAX-23
Spring 1988 Ballot The Top 35 SIR's as Ranked by Office Automation
Total ballots in this category: 145
SIR
SIR
Nr.
Description
7 LAT sessions identity information
10 Various BACKUP enhancements
37 Corrrect READALL behavior
61 Enhance print form modules
3
Provide deallocation capability
48 Prevent password reuse by users
42 Provide installed memory-resident code
19 "Control Print Screen" capability
23 Enhance SHOW PROCESS command
8
Provide queued ALLOCATE requests
29 Provide $GETDVI "wild card" capability
11 No CR/LF for DCL WRITE command
62 Provide BACKUP dismount/deallocate
14 Extend DCL TABLES
68 Support multiple version products
58 Provide RIGHTSLIST lexical function
52 Security alarm messages to a file
9
Provide project accounting
20 Enhance sysgen parameter readability
64 Provide limits on simultaneous logins
15 DCL status return enhancements
54 Provide DECnet end-to-end encryption
28 Improving VMS define utility
55 Support SET HOST proxy access
22 SET HOST/DTE for more modems
36 Provide descriptive text for files
66 WSQUOTA/WSEXTENT for INSTALL
57 Enhance COPY to copy ACL's
49 Suppress certain login failures
6
Provide a "virtual disk" capability
63 Support bell character in BACKUP
21 Provide Mail enhancements
51 Control file access via an image
31 Improve terminal comm data display
25 Enhanced DEFINE/KEY capabilities
Total Votes
64
60 55 55 49 48
47
45 45 44 42 38 38 37 35
34
34
31 31 30 30 29 29 27 27 26 25 25 24 23 22 22 21 21 21
VAX-24
Spring 1988 Ballot The Top 35 SIR's as Ranked by Other
Total ballots in this category: 21
SIR
SIR
Nr.
Description
7
LAT sessions identity information
20 Enhance sysgen parameter readability
23 Enhance SHOW PROCESS command
28 Improving VMS define utility
37 Corrrect READALL behavior
21 Provide Mail enhancements
15 DCL status return enhancements
19 "Control Print Screen" capability
6
Provide a "virtual disk" capability
62 Provide BACKUP dismount/deallocate
64 Provide limits on simultaneous logins
67 Priority for INSTALL
10 Various BACKUP enhancements
1
Provide SCS communication services
42 Provide installed memory-resident code
68 Support multiple version products
48 Prevent password reuse by users
61 Enhance print form modules
3
Provide deallocation capability
63 Support bell character in BACKUP
29 Provide $GETDVI "wild card" capability
8
Provide queued ALLOCATE requests
24 MOUNT/FOREIGN and uninitialized tapes
11 No CR/LF for DCL WRITE command
18 Make DCL /LOG qualifier consistent
54 Provide DECnet end-to-end encryption
26 Support DCL command /BELL qualifier
2
Enhance batch load balancing
56 Improve DECnet file access control
22 SET HOST/DTE for more modems
36 Provide descriptive text for files
14 Extend DCL TABLES
5
Providing batch job "filtering"
43 Provide /NOWAIT switch for TPU
46 Provide line-number support in TPU
Total Votes
11 9 9 9 9 7 7 7 7 7 7 7 6 6 6
6 5 5 5
5 5 5 5
4 4 4 3
3 3 3 3 3 3 3 3
VAX-25
It's On The Tapes
Glenn Everhart
Did you ever wish you had a VAXstation on your desk instead of a VTlOO or VT200? Ever feel that you could be more productive with lots of windows and processes so you could avoid waiting for the VAX to get finished with something?
Well, you can (almost).
A VT terminal usually has too few characters to be usefully split up, and applications that run multiple processes through windows on a VT (using SMG$ or the like) are CPU hogs. However, software that can let you use the whole VT screen as a window exists. It's called BOSS and a version can be found in the [vax87d. rcaf87. netnew] directory. This is a program written by Charles Karney and released via the ARPAnet. It uses the pseudo terminal driver submitted to the tapes by Kevin Carosso and allows you to manage up to 8 subprocesses at a time, switching dynamically between them via a "hotkey". Its system overhead is negligible and it can swap out of a process at any time. Because it uses the PY/TP driver combination, the applications are running at real terminal devices, so they all act normally. Also, one can spawn a new process (if one hasn't used all available) at any time without disturbing the context.
Full screen applications are generally able to repaint the screen, so BOSS does nothing to keep track of what's on any screen. You do lose the contents of a screen in non-full screen applications, as they scroll off screen, but this generally presents few problems.
A new version, which should be on the Spring '88 tape, has been released which buffers output from the hidden processes and displays it when you bring up their windows. This is very handy for many applications.
The F87 version of BOSS introduced the ability of one process to send controlling input to another too. With a little work, this can be used to create a hypertext system, with the restriction that only one "box" can be displayed at a time. The random connections between "boxes" (where a box is implemented as one of the subprocesses, and another "master" subprocess has the program that fires up the commands to move from one subprocess to another) can be implemented using fairly crude techniques. It takes only the will to build it and a use for it.
To use such a system, you'd get into a "master" process to bring up the "window" of what to link to. The master process would allow selection of one of several possible commands to be sent to a "slave" process (e.g. to edit text or pictures) by accessing some data base or data file based on the "current" (or last) subordinate command selected. One possible command might result in editing the list of commands at any point in the database, allowing links between subordinate commands to be modified. The master process could then, via the good offices of BOSS, send the command to another BOSS subprocess and thus run any desired command. Full screen applications would present no problems this way, as they might where mailboxes were used. Also, more elaborate implementations that permitted several open applications could be devised.
BOSS is an enabling technology for terminal users which has abilities that should not be overlooked. I recommend that if you use a VT terminal, you look it over.
/
VAX-26
VAX/VMS Security
One in a Series
Ray Kaplan, PIVOTAL, Inc., Tucson, AZ
On Hackers
The usage of the term "hacker" has changed over the last few years. Of late, the term "hacker" has come to mean what I consider to be a "computer criminal" in its current common use by the lay public and press. Even the current trade press abuses the term.
By some definitions, a hacker is the ultimate expert programmer of days of old when memory, disk and CPU cycles were very scarce. A hacker could produce a most beautiful and elegant solution to a problem in a very few lines of code. By some definitions, a hacker is a consummate programmer that can completely exploit their machine resources so well that they end up with absolutely no extraneous code and a problem solution that is perfectly tight and elegant. And, by some definitions, a hacker is anyone that "plays" at anything that they do. You know, folks that hack at golf, tennis, flying or whatever their interests are! All I know is that I must be a hacker. After all, my friends all say that I hack code and my significant other says that I hack at our relationship!
While I (and many other "old timers" in this game) strenuously resist the change that is taking place in the common usage of the term "hacker", I also feel that it may be a bit of a lost cause to resist the change. This feeling is based on my observation that the media (like the trade press) has more power over the "common law" definitions in the language than we do (as the technicians that control our technical language.)
Thanks, Criminals
I will attempt to set the record straight in some future writings on the hacker matter, but for now I want to say a big "thanks" to to the computer criminals that have caused the recent stirs in the world's data processing community with their break-ins from overseas. Yes, that is correct. As a practicing computer security consultant, I want to say thanks to the computer criminals! Fact is, I think that you ought to join me in thanking them. If you have not recovered from the shock of reading that last statements, please read on.
Ater statements like that, I figure that you either believe that I have a legitimate point to make or believe that I am ready to give up my VAX/VMS and DECnet-VAX related computer security consulting practice! I assure you that I am not ready to give up my consulting practice, so let's get started figuring out why we should thank computer criminals.
Have you heard Retired Admiral Grace Hopper speak on the "state of the world of information processing?" If not, you are in for a shocker of a technical entertainment experience. Your DECUS Local User Group (LUG) can get a video tape of her address to the 25th anniversary celebration at the DECUS U.S. National Symposium in Dallas from the DECUS National LUG Organization video tape library. If your LUG has not seen the tape, have your LUG chairperson get a copy of it for the next LUG meeting. If you don't know where your LUG is, find it by writing the national DECUS office at the address contained elsewhere in this newsletter. If you don't have a LUG in your area, go start one! (I'll even help you do it.)
VAX-27
In her talk, Admiral Hopper proposes that we (as the data processing industry) are woefully unaware of how important the data that we process is and show an amazing lack of interest in its well being and correctness as a result. She presents quite an articulate argument that we had better get ourselves oriented to not only the value and importance of the data that our machines process, but oriented to the potential for a first order societal disaster that could be induced by errors that are introduced into the data by our improper custodianship and/or processing as well. In addition she asserts that as a society, we only change as a result of large and self induced crises that do significant damage to us all.
Given the nature of the data that our systems hold and process, you can probably accurately detail any sort of disaster that you can imagine. Failure to launch, an incorrect medical operation being performed, a sizable business bankruptcy and the ruin of someone's credit life are but a few of the scenarios that you could come up with that could result from lax custodianship of data or out and out negligence. Simple examples of her theme can easily be found in the contemporary examples of commercial computer crimes that are well documented these days. Stories about dishonest and inept employees top the list. Remember the Equity Funding Scandal where the management of an insurance company inflated their stock's value with scads of computer generated fraudulent insurance policies? Then there is the not-so-well documented case of the insurance executive that was retired with a gold watch after it was discovered that he had successfully embezzled $28 million from his employeer (you see, they didn't prosecute since they didn't want the bad PR!).
With all of this as background, you'd think that the right thing do do with a computer criminal would be to shoot them on sight! After all, they are a menace to society and they have collectively cost everyone a lot of trouble. System down time, lost productivity, data corruption, monetary losses - and - lots of lost sleep and ulcers for us system and security managers! Why the nasty computer criminal creeps! After a system that I am responsible for has been attacked, I angrily shout "Hang the bastards!"
Wait a moment. Is this a multiple personality here? I say that we ought to thank computer criminals and then I call them creepy bastards? What gives?
As a final piece to the puzzle, you need to understand my argument is my experience as a technical trainer and a VAX/VMS consultant. By far the biggest problem that we find in the DEC based DP shops that we see and hear about is a severe lack of system and network management resources. Out of the things that we generally find missing, the most common is very simple lack of time for the system and network managers to do their jobs. Of course, the jobs of system and network management includes system and network security management. Stated plainly, most system and network managers do not seem to have the time to do the security management portion of their jobs! Further, we typically find that the problem is really a manager that has not budgeted any time or resources for the system and network security job. Most system and network managers that we meet are sufficiently interested in this important aspect of their job to be doing the best that they can with it by begging, borrowing and stealing resources from other tasks that are "officially funded" to insure that their systems and networks are secure. The refrain "I'll be a little late tonight, honey" wears thin after a time.
There is one more piece to consider before you can see my justification in thanking the computer criminals. Currently, when a security related problem is discovered with either the operating system, the network, or layered applications software - it is not discussed in any way that system and network managers can expediently find out about them. Using the two security problems that have recently been fixed by DEC as examples, it is plain to see that both DEC and DECUS have been unable to come up with a way to discuss these sorts of problems in the sort of an open forum that would allow many of our systems from being compromised. While DEC built and shipped fixes to the problems as quickly as they could, all of our systems were wide open to attack during the time that it took them to do this. Worse, no one would talk about the problems so that we could at least monitor our systems more closely. The reasoning behind this behavior
VAX-28
that is being given is that if the problems are discussed openly, systems will be subjected to unnecessary exposure to "bad guys" that know about the problem. They say that there are many. systems out there that are not even being protected at a minimal level and that to distribute information about the problem is needlessly arming criminals to do those systems harm. Just for the record, I say that these arguments are as flawed as those that the fundamentalist religious people use against sex education in grammer school. A typical fundamentalist argument against it is that sex education at a young age will "corrupt the morality" of our young people by inducing them to experiment with sex. I say that sex education is one of the only ways that we will ever put a cap on the AIDS epidemic!
Now that you've read all of this, try the following on for size.
Given: · That the safety and integrity of the data on our systems is at the very core of our infras-
tructure,
· The fact that we (as system and network security managers) generally have a hard time gathering the resources that we need to do the security part of our system and network management jobs
· The fact that often security patches and information about security problems arrive to late to do us any good
maybe it is appropriate for some force, "external" to our infrastructure, to "shake us up with a bit of reality therapy." Come on now, when you last asked your manager for additional resources to do a better job of system or network management, what did they say? I'll bet they sent you away feeling that it was your fault that system and network management even needs to be done (let alone not giving you the resources that you need to do the job!)
Maybe we ought to thank computer criminals for reminding the custodians of the societies data that its safety and integrity are very important. Maybe we ought to thank the computer criminals for getting themselves on the front pages of newspapers across the country where managers and controllers of organizational resources can be told publically that they have problems that are not being properly addressed. Maybe we ought to thank computer criminals for reminding managers that our technology is not only fragile, but that it needs to be carefully managed as well. Maybe we ought to thank computer criminals for reminding DEC and DECUS that hiding from problems and management by ignorance is not appropriate - especially when our hardware, software and practices are so widely known and understood.
Maybe we ought to thank computer criminals. What do you think?
Let me hear from you on this!
Until we meet again - Happy VAXing!
Ray Kaplan, PIVOTAL, Inc., P.O. Box 32647, Tucson, Arizona 86751
VAX-29
F~l:ow educat~rs:
ThE: dust should ha·,,,.c settle or.. t:-:.o;; sp!:":_:l;: VE:::s
Cincinnati.
hope t:ha~ you O"C.nd ~.. a.J.'.1 us-;:::f u.
to·.:.:i.s c1:-i~
thought provoki~g i~~as. I;: s -:.ir.c ~v i:;: :L :-'J.
c:.Dvut -chc
Woods ~eeting it~ Ju~~ a~d the !all DECUS.
The~c i s nev~:r-
any rest fo~ th~ ones ~ho are wil:ing.
: f you are net fa~~:iar ~it~ a Woods t1~Eting l6t ~12
enlighten you.
T~e Woods ~;eeting is 2 ti~~ ~or t~E
cffice~s of the Sig , in this case ED~SIG, to gst togather
and pla~ out st=ategies fer the up co~ing yea~.
Ha~y old
questions wil: crop up as well as new on2s.
Costs,
quality, presenters, new DEC prod~=~s {beth ha=dware and
software) anci the cou~tship with our counter parts in DEC
re among the ~a~y thi~gs discussed at these ~eetings.
I~ow
s the time to add your thoughts to the list. We need
nput.
F.G.B. Taft College Taft, CA 93268
The TESTGEN article discribes a software product that can be obtained from the Clearinghouse at Iowa State University.
EDU-1
TEST GEN
TESTGEN, in one form or another, has a long history. Those of us at Taft College are grateful for the use of a prototype provided by Bakersfield College in 1981. This version of TESTGEN ~as produced by Fred Bell of Taft College and Dan Esbensen, president of Touch Technologies, San Diego. TESTGEN is written using "Intouch", a next generation language developed by Touch Technologies. Inc. A free run version of Intouch <TMl is included, courtesy of Touch Technologies.
TESTGEN is a unique, easy to use, test generating program. It uses the "KISS" principle to make it superior to other generating packages. TESTGEN can handle multiple-choice, true-false and matching type questions. It is completely menu driven with on-line help for each menu. The main menu gives the user following choices:
ADO Add New Questions CHA Change an Existing Question DEL Delete an Existing Question LIS List Existing Questions GEN Generate a Test
Entering questions or correct existing ones:
The main menu will prompt the user for the type of task to perform, "ADD" for adding new question either to an existing chapter or a new one. If the user types "new" the menu prompts the user for the name of the chapter (max of 8 characters), with the usual rules for VMS file names.
One of the unique features of TESTGEN is that it uses EDT as the editor for correcting or modifying test questions. Users do not have to learn to use another editor. When typing the question TESTGEN uses prompts for the type of question (multiple-choice, true-flase or matching>. Each question is terminated by a blank return. Backing up is another helpful feature. If an error was made in the previous responses for correction. Control-Z or "EXIT" will take the user from a sub·menu to the main menu or exit the program altogether.
Generating a test or getting a list of questions:
The user is prompted for the test title, instructor's name, class type, letter or number choices, comput,er-selected or user-selected question in each test generating operation. The user hcts the folowing printing options:
SCR - Print to Screen PRI - Print to Printer Port SYS Print to System Printer
The option of printing from the printer port saves time and equipment.
EDU-2
Instructional strategies: The ease of use of TESTGEN makes it especially valuable for the comonly accepted practice of pretesting. It is not difficult to prepare two versions of an exam and allow students to practice the pretest from a terminal at their time and convenience. Such practice is consistent with the view that testing should measure learning and yet not become "game playing" barriers to student success. If used with a pa~kage such as Digital's Courseware Authoring System CCAS), then computer managed learning CCMLl components come into play, allowing instructors to measure the time and effort that students are putting forth.
EDU-3
I I THE " la'1" ke·· DECUS
11111111111111111111111111111111111 RT-11 SIG NEWSLETTER IIIII II II IIi 1111111111111111111111
~
DDEQJS USa-TER
RT-11 MINITASKER June, 1988
<C©Imft<e:mft~
From the Editor . . . . . . . . . . . . . . Introduction to KERMIT/RT The FORTRAN Slate . . . . . . . . . . . . . . . .
RT-1 RT-2 RT-13
*********************************************************************************
From the Editor:
Hey folks! The Minitasker Folder is empty. There were only two articles for This newsletter is your medium for exchanging ideas, so send me some. Are there any of you out there who (like I) used Version 1 of RT-11? (Of course it wasn't called Version 1 at the time.) For our 15th anniversary, I'd like to collect your recollections of RT-11 over the years. Send your war stories, bugs, fixes, questions, comments, or ramblings to:
John M. Crowell RT-11 Newsletter Editor Multiware, Inc. 2121-B Second St. Suite 107 Davis, CA 95616
Gary Sallee's Introduction to KERMIT/RT is long enough that I'm splitting it between this month's and next month's issues. (Mostly so I know I'll have
something to publish next month.) I found this article particularly useful. I think you will too. Bob Walravenn's FORTRAN SLATE addresses the problem of Virtual Arrays that get mapped into oblivion. It's all done with smoke and mirrors!
Kermit/RT/TSX Introduction Gary F. Sallee
From Brian Nelson's KllART.DOC, K11F85.DOC, and KllINS.DOC Presented at the Regular ~CURT LUG Meeting Southern California Users Of RT-11 Pasadena, California
ABSTRACT
This is an introduction to Brian Nelson's KERMIT from the University of Toledo as it may be used in an RT-11 or TSX-plus computer system. Topics covered will be what Kermit does, how I use Kermit, what SYSGEN options are needed, how to set up the needed hardware, how to install Kermit, how Kermit talks to other Kermits, how to use KERMIT.IN!, how to set up a dialing list, and anticipated futures by Toledo and by SCURT.
USES
Kermit is used to support file transfers to and from superminis such as the VAX and PDP-11 and remote personal computers, such as the PC, the Rainbow, and the Macintosh. Kermit is used as a basic terminal emulator. Kermit has a log file capability that can record data and/or commands from the terminal or the communication link. It is possible to control several RT-11 systems from one "master" RT-11 multi-terminal system by wiring the "master" DL ports to the the "slave" console lines. Because there is an existing Kermit for almost any DEC configuration, then Kermit can be used as a poor man's Decnet.
BOW I USE KERMIT
I routinely use Kermit for transferring files between a TSX-plus system, RT-11 systems, RSTS/E systems, and VMS systems. I also use Kermit to control "slave" systems from a "master" TSX-plus system over DL serial lines. This provides a "super set host". I use Kermit's log file to record anomalies like crashes and ODT interactions on the "slave" systems. I use the Kermit log file to record data from a connected system or from dial up services such as DECUSERV and DECdirect: (800) 258-1710 (1200/2400 baud).
I have obtained the Toledo Kermit by dialing into the VAX 11/785 at the University of Toledo: (419) 537-4411 (1200 baud, Service ~lass: VX785A, Account: KERMIT, Password: KERMIT).
CONCLUSIONS
Kermit-11 is useful, easy to run, and easy to install.
RT-1
RT-2
TERMINAL EMULATOR
Terminal emulation can be done several ways: A Kermit program can provide a simple "glass tty" mode. A Kermi~ might provide an intelligent terminal emulation. In the case of a PC the emulation is likely to be of a VTlOO series terminal. MacKermit provides this. Some mode of terminal emulation is generally required since the file transfer operation of Kermit requires that two Kerrnits to be running; one on the LOCAL system and one on the REMOTE system. The simplest method of running two Kerrnits at once is to use terminal emulator mode (CONNECT) on the local system as a terminal to log into the remote system. Then invoke the host's Kermit program.
While logged onto the Host with the terminal emulator it is possible to use any of the host's services and programs. You are not limited to "RUN KERMIT", as far as the host allows you privileges.
MY HARDWARE
I have a DLVll-E modern port with the programmable baud rate enabled. The DLVll-E for a modern port is well supported in RT-11. I am using a DITTO 2400XL, a Hayes compatible modem which is made by Rockwell, Newport Beach (TR24-D310). I also have a SmarTEAM 103/212A Hayes compatible modem that I have used on the DLVll-E.
I put my modem on CSR 176530 and Vector 330. This allows my first DLVll-J to have the console port and my second DLVll-J to start at an even CSR 176540 and vector 340. Be sure to set the jumpers for the desired CSR and vector on the serial card.
OTHER HARDWARE
The DZ/DZVll ports which support modem control can also be used. The DH/DHVll port may be used but Kermit does not support the SET SPEED command yet. A plain vanilla DL port can be used to dial out if you do not want to change the transmission speed from the operating system. The SET SPEED command is not supported for RT-11; it is supported for TSX-plus. So for a dial out line with RT-11 Kermit-11 V3.56, there is no disadvantage to using a vanilla DL line.
HOW I SET UP MY Hl\YES COMPATIBLE MODEM
DTR forced on (Not good for RSTS/E or RSX, but ok for RT-11) Hayes word result codes Send Hayes result codes No echo in command mode (Important with TSX+. RT-11 echo is ok.) Auto answer enabled ( Probably no reason for this for RT-11) Set CCITT V.22 bisync mode ( This is for 2400 baud) Set default speed 2400 baud
Hayes commands are enabled. RTS is disconnected RLSD/CD to DSR loop is off Asynchronous line communication mode Internal Sync Clock
The Cable from the DLVll-E to the Modem RS232-C includes null
modem
RS232-C DB25
DLVll-E 50-PIN BURG
EIA PIN NAME
NAME
PIN NAME
AA 1- P-GND -- *protective ground A protective ground
AA 1- P-GND -- *protective ground vv protective ground
BA 2- TD <-- *transmit data
F transmit data
BB 3- RD
-->*receive data
J receive data
CB 5- CTS -->*clear to send
T clear to send
AB 7- S-GND -- ·signal ground
B signal ground
AB 7- S-GND -- *signal ground
uu signal ground
CF 8- RLSD -->*carrier detect (CD) BB rev. line signal
detect
CD 20- DTR <-- *data terminal ready DD data t~rrninal ready
CE 22- RI
-->*ring detect
X ring indicator
* CA 4- RTS <-- * request to send cc 6- DSR --> data set ready
M EIA interlock E EIA interlock none (V)
none
SBA 14- STD <-- 2nd transmit data none (FF)
SBB 16- RD
--> 2nd receive data
none (JJ)
17- RxCLK --> receiver clock
none
23- SPDS <-- speed select
none
24- TxCLK<-- transmitter clock none
25- FB <-- force busy
none (C)
Note: * is a real wire. Signal ground is connected to protective ground. 6-DSR from modem is not connected. 4-RTS to modem is not connected.
FORCING DTR
Forcing the assertion the DTR signal to the modem is normally not recommended if full function auto answer from the operating system is desired. But DTR control and auto answer are normally not used with RT-11; and TSX-plus does not treat the DTR signal in a manner compatible with non-DEC modems. So forcing DTR hecomes a necessity in most RT-11 or TSX-plus environments. The C'tJSt of fc,rci11g DTR is in t<:ducPd 11ti1.it.y: the HANGUP and the BYE commands will not hang up the remote line.
Some people will go to great lengths to make their TSX-plus system work without forcing DTR. Greg Adams has a "fix-it" program that wakes up every minute. It resets DTR, then sets DTR, for any inactive modem dial in line. This program for the DTR compatibility problem will allow the BYE command to work as
RT-3
RT-4
a log off and hang up operation. Greg claims that this is what VMS does with it's modem lines.
RT-11 OPERATING SYSTEM SET UP
RT-11 Sysgen options must include 1) timer support and 2) multi-terminal support or the XL handler (XC for pro). Do not use multi-terminal support faster than 1200 baud. Multi-Terminal support is not required if the XL handler is used. FB or XM is desired because timer support is in the distributed systems, but SJ with sysgened timer support is ok.
Kermit-11 supports the XL and XC handlers, supports the multiple terminal service, and supports the use of the console line for connecting to the RT-11 system.
The best modem handler for RT-11 is the XL driver (XC on pro), available on RT-11 version 5.1 and later. This driver makes very efficient use of a DLll or DLVll interface. It's the same handler that is used by VTCOM. To use XL, you must have an extra DLll/DLVll interface port in addition to the console interface.
The XL handler supports two DCL commands:
SET XL CSR=n,VECTOR=m
Where: "n" is the control status register address and "m" is the interrupt vector address.
The first default sysgen DL address is 176500 for the CSR, and 300 for the interrupt vector. Be sure to set the handler's CSR and the vector according to your hardware straps on the serial module.
The XC handler, used ONLY on the PR0/300 series, has it's CSR and vector fixed at 173300 and 210 respectively. Kermit-11, upon finding itself running on a PR0/3xx under RT-11, does an implicit SET LINE XC. The DCL command SET XC SPEED=N must be used outside of Kermit to change the XC line speed from the default of 1200 baud.
The Multiple Terminal (MT) support requires a SYSGEN. Serial lines in the MT case are designated by numbers; the console is always line zero. The next line, say a DLVllE, is line one. These line numbers are assigned during SYSGEN based upon the order of entry during SYSGEN (under RT VS.2, the questions start with question number 180). You can also use a DZll or DZVll. The actual assignments may be viewed on a running system with the DCL command SHOW TERMINAL (SHO TER).
If there is no way to get an additional interface into your system (perhaps you have a four slot QBUS back plane), then you
can force Kermit to use the console. This implies, of course, that it will not be possible to dial out from the RT-11 system; the system could be used only for a remote Kermit to connect to it via the console port. If Kermit finds that the XL handler is
not present, and that multiple terminal service is absent, it will force the use of the console.
To force the console to be used, command:
Kermit-ll>SET LINE TT:
In summary, the following commands specify serial lines for RT-11:
Kermit-ll>SET LINE l Kermit-ll>SET LINE XL
Kermit-ll>SET LINE TT:
use terminal line one use the XL handler force use of the console line
Kermit-11 also requires the presence of timer support in the
executive. This is required to support the .TWAIT directive; FB and XM systems always have support for this; SJ systems by default do not. If Kermit decides that it does not have a clock, which it would think if .TWAIT support is missing, it will try to fake .TWAIT's with cpu bound loops. The best thing is to insure that you have a FB or XM monitor available for use with Kermit.
KERMIT.IN! FOR RT-11
The file KERMIT.IN! must be on SY:
!*TITLE* - KERMIT.IN! - Customize Kermit for RT-11 SET MODEM HAYES SET CONSOLE 8 SET PROMPT K-11 LOW BALL> SET LOGFILE KllLOG.TXT SET PHONE TONE SET PHONE NUMBER DECDEMO 1,800,3323366 SET PHONE NUMBER DCS 1,800,2477003 SET PHONE NUMBER DECUSE 1,617,485,2574 SET PHONE NUMBER WORK 5551212 SET LINE XL
DIAL WORK CONNECT
TSX-PLUS OPERATING SYSTEM SET UP
The TSX-plus SYSGEN options that must be included are 1) 100. blocks of PLAS swap file (SEGBLK) and 2) one spare CL unit or the XL driver. The CL may be dedicated (for dial out only), or
may be spare (the time share line can be used for dial in, too). The PLAS swap file is not needed if the K11RT4.SAV image is used for KERMIT.SAV.
RT-5
RT-6
Kermit-11 can be used on TSX-plus (a product of S&H Computing) as either a LOCAL and a REMOTE. A LOCAL Kermit (you connect out to another system using the CL handler) is similar to Kermit use on RT-11 with the XL/XC handler. A REMOTE TSX-plus Kermit (you log into a TSX-plus system and run Kermit-11 on the REMOTE) is identical to Kermit use on most multiuser systems (for example, TOPS-20 and RSTS/E).
In order to CONNECT out from TSX Kermit to another system, you need to associate the appropriate DL line with a CL or an XL. This association can be at SYSGEN time or with an ASSIGN. See the examples below:
Kermit-ll>SET LINE CL2 or:
.SET CL2 LINE=4,NOLFOUT .ASS CL2 XL .KERMIT Kermit-ll>SET LINE XL .
The image KllXM.SAV will use approximately 100 blocks of PLAS swap file space. If Kermit fails to load, then the TSGEN.MAC parameter SEGBLK may be too small to contain KllXM's virtual overlay; the TSX-plus system manager will need to increase SEGBLK and reboot TSX-plus. If adding 100 PLAS blocks is excessive, then the disk overlayed image KllRT4.SAV may be used for KERMIT.SAV.
In TSX-plus, I find no degradation in using KllRT4.SAV. The generalized data cache is probably of assistance on a busy system.
Note that if you have 256 Kbytes or less of memory on your TSX-plus system, then Kermit can be a system hog. If you have 256 Kbytes or less, please don't do anything else while Kermit is running (i.e. B to print screen or Wn to window). If you do, then the system will probably slow to a snail under tortoise pace.
Without the added concurrent task on a 256 Kbyte system, Kermit is good and fast. But with the low cost of memory now, please put in another 256 Kbytes or more. You will like it.
KERMIT.IN! FOR TSX-PLUS
The file KERMIT.IN! must be on SY:
!*TITLE* - KERMIT.IN! - Customize Kermit for TSX+ SET MODEM HAYES SET CONSOLE 8 SET PROMPT K-11 HIJACK> SET LOGFILE KllLOG.TXT SET PHONE TONE
Kermit will fetch the handler if it is not resident.
CONNECTING THE SYSTEMS
The first thing to do, before starting Kermit, is to get the modem turned on and set up. I have a separate power switch on my modem. The modem is only on when I anticipate a need. I
modify some of the modem's set up parameters. This modification is not necessary and for initial check of a set up nor for many
applications.
The command files that I use for the modem set up are below:
!*TITLE* - LOADMM.COM - Load Modem parameters SET CL2 LINE=3,SPEED=l200,NOLFOUT,DTR COPY SY:LOADMM.000 CL2: COPY SY:LOADMM.010 CL2: i 5 SET CL2 LINE=O
The LOADMM.000 file is Hayes attention:
AT
The file LOADMM.010 sets some Hayes modem parameters:
AT T S0=2 S6=4 S7=95 Sl0=13 Sll=l00 Xl
Hayes parameters explained:
T
! TONE DIAL:
DEFAULT IS PULSE DIAL
S0=2
! 2 RINGS BEFORE ANSWER: DEFAULT IS ANSWER FIRST
RING
S6=4
! WAIT FOR DIAL TONE 4 SECONDS: DEFAULT IS 2 SECONDS
S7=95 ! WAIT FOR REMOTE CARRIER 95 SECONDS: DEFAULT IS 30
SEC.
510=13
CARRIER LOSS TIME 1300 MS.: DEFAULT IS 700 MS.
511=100 TONE DIAL SPEED 100 MS: DEFAULT IS 70 MS.
Xl
EXTENDED RESPONSE SET: DEFAULT IS XO: BASIC SET
If we wish to dial out, then the DIAL command is issued. The "number" for the DIAL can be a predefined symbol from the SET PHONE NUMBER command, or can be an input number typed in.
When the two modems agree on a speed and protocol, then Kermit will issue the message:
Connection made, type CONNECT to access remote
The normal next thing to do is to type CONNECT<RETURN> to start
the remote system logon operation. But now is the time to enter
any other command that needs to be issued, like SET SPEED 300,
before the CONNECT. Also, if the remote system is a PC or an RT-11 with the console as the communication port, then the remote will already be running Kermit, so the CONNECT is
RT-7
RT-8
inappropriate.
When we are connecting two physically close systems without a modem, we would simply connect DL ports together with a NULL modem cable and then invoke Kermit on each system.
If the REMOTE is a single user system (i.e. RT-11 or a PC), then the single user system would most often be set up as a Kermit "server". This allow~ the LOCAL system to control the server and to initiate file transfer requests without the need
for the operator to move between the two machines.
STARTING KERMIT
Once the physical link has been made, we would log into the remote system, then invoke Kermit on that system and run it as a server. This is done by typing SERVER on the remote Kermit.
Then escape back to the LOCAL Kermit with the <CTRL>C.
RUDIMENTARY KERMIT COMMANDS
Now that we have established the physical link, how do we get files transferred? Quite simple. First we give the remote Kermit the SERVER command, then we continue as below:
REMOTE Kermit-ll>SERVER
<CTRL>C LOCAL Kermit-ll>GET [file.type)
LOCAL Kermit-ll>SEND [file.type]
LOCAL Kermit-ll>FINISH
LOCAL Kermit~ll>CONNECT
. LOGOFF <CTRL>C LOCAL Kermit-ll>EXIT
Request the remote Kermit to SERVE
Request a file from the remote system Send a file to the remote system Request the remote exit Kermit Connect to the remote system .
Exit kermit
The BYE command does not work for REMOTE TSX-plus or for REMOTE RT-11.
These are the commands we need when talking to a Kermit server. There are, of course, many other commands which support file manipulation on the host, as well as obtaining REMOTE HELP. These commands are normally thought of as REMOTE commands. Indeed, they are prefixed by the REMOTE keyword, as in:
Kermit-ll>REMOTE HELP Kermit-ll>REMOTE COPY FILEl.TYP FILE2.TYP Kermit-ll>REMOTE CWD [USERFILES]
SET PHONE NUMBER DECDEMO 1,800,3323366 SET PHONE NUMBER DCS 1,800,2477003 SET PHONE NUMBER DECUSE 1,617,485,2574 !SET LINE CL2
Note that the SET LINE CL2 command is commented out with the "!". This is only because Kermit is sometimes used for dial in. If the SET LINE CL2 is attempted from a dial in line, then there will be an assignment conflict. I leave the comment line in the KERMIT.IN! file to remind me which line I am supposed to set when I am dialing out. If kermit is. only used for dialing out, then it is ok to activate the SET LINE CL2 command in the KERMIT.IN! file.
INSTALLING KERMIT ON RT-11 AND TSX-PLUS
KERMIT.SAV is required, all other files are optional.
The RX02 floppies distributed at the SCURT meeting contain the files:
KllXM. SAV
KllRT4.SAV
KllHLP.HLP
KllUSR.DOC KERMIT. INI
Copy to SY:KERMIT.SAV for RT-11 XM, PRO/RT-11 and TSX-plus
Copy to SY:KERMIT.SAV for RT-11 SJ and FB, usable on TSX-plus
Copy to SY: or DK: for online help file. This is optional.
Print file of the Kermit-11 user's guide is created on SY:. This is optional.
Note that on the PR0/350 RT-11 you may have to UNLOAD XC before Kermit-11 can be started via a .FRUN command. Additionally,
when running in the foreground, you will likely want to give the command:
.FRUN KllXM.SAV
AF Kermit-ll>SET QUIET
In the event that you are using RT-11 with multiple terminal
support, you could use a command of the form:
.SHO TER
Unit Owner
Type Width Tab CRLF FORM SCOPE SPEED
0
s-console
DL 132
No Yes
No
No
N/A
1
Remote
DL
80
Yes Yes
No
No
N/A
.KERMIT Kermit-11 T3.44 Last Edit: 04-Feb-86 Kermit-ll>SET LINE 1
If you are you are using the XL handler (XC for the PRO), then the XL handler must be installed; it does not have to be loaded.
RT-9
RT-10
Kermit-11 has the following commands available:
@
BYE CONNECT COPY CWD DELETE DIAL DIRECT DISCONNECT DISPLAY ERASE EXIT FINISH GET HANGUP HOST
LOCAL
LOG FILE QUIT PRINT RECEIVE REDIAL
REMOTE
RENAME SEND SERVER SET SHOW TAKE TRANSFER TYPE WHO
Synonym for TAKE Log out a remote server Connect to a remote system Local copy of a file(s) Set new working directory Local delete of a file(s) Have a connected modem dial a number Local directory display Hang up a remote line Internal debugging Local delete of a file(s) Exit to system Stop a remote server without logging out Get a file(s) from a remote server Hang up a remote line Execute system command locally (where applicable) Force interpretation of command to the local
system Create a log file Same as EXIT Print a file locally (where applicable) Receive a file(s) from a remote kermit Have a connected modem redial a number several times Prefix for file management commands to a server Local rename of filename(s) Send a file(s) to a remote Kermit start a Kermit server Change Kermit parameters Display Kermit parameters Execute indirect command file Send an ASCII file without Kermit protocol Local display of file on terminal Local display of logged in users (RSTS/E
only)
Commands for File Transfer SEND, TRANSFER, Abort control characters
RECEIVE, GET
Server operation SERVER, BYE, FINISH
REtlOTE REMOTE COPY, REMOTE CWD, REMOTE DELETE REMOTE DIRECTORY, REMOTE HELP, REMOTE HOST REMOTE LOGIN, REMOTE RENAME, REMOTE SPACE
REMOTE TYPE, REMOTE WHO
Commands for Local File Management
The Connect Command CONNECT
The Set Command SET ATTRIBUTES, SET BAUD, SET BINARY-TYPE, SET BLOCK-CHECK, SET CONSOLE, SET DEBUG SET DELAY, SET DEFAULT SET DIAL, SET MODEM USERDEFINED SET DTR, SET DUPLEX SET END-OF-LINE, SET ESCAPE, SET FILE SET HOME, SET IBM-MODE, SET LINE SET LOGFILE, SET MODEM, SET PACKET-LENGTH SET PARITY, SET PAUSE, SET PHONE, SET POS SET PROMPT, SET RECEIVE SET RECORD-FORMAT, SET RETRY SET RSX, SET RT-11 SET SEND, SET SPEED SET TIMEOUT, SET TERMINAL, SET UPDATE
The Dial Command DIAL REDIAL
Before continuing, please note that Kermit programs do not necessarily implement the same level of support. In general, the large system Kermits, such as Kermit-32 (VMS), Kermit-20 (Tops-20) and Kermit-11 (PDP-11 and PRO) support a large command set. No single command is really required by Kermit; the protocol specifies the transportation of files, not the command interface. At a minimum, however, a Kermit program requires the SEND and RECEIVE commands to effect file transfer. SERVER support is optional. If we don't have server support available then we must use the SEND and RECEIVE commands and tell each Kermit such for every time we want to move a file.
*******************************************************************
Editor's note: Part 2 of this article will appear next month. It will include descriptions of the KERMIT Protocol and how KERMIT transfers files.
RT-11
RT-12
The FORTRAN Slate
Bob llalraven Multiware, Inc.
Last time I said I would say more about running FORTRAN-77 programs as RT-11 system jobs, but an interesting F77 SPR came in that I wanted to tell you about, so we'll continue the discussion about system jobs next time.
The SPR reported a problem accessing virtual arrays both from a program's mainline code and from a completion routine: after the completion routine is called and control is returned to the mainline code, the pointers to the virtual arrays may be incorrect. The FORTRAN-77 documentation doesn't explicitly say you can't access virtual arrays from both the mainline and a completion routine, but a little thought will tell you that it can lead to problems.
The FORTRAN-77 (and FORTRAN-IV) virtual array support is based on the assumption that a single thread of code will be accessing the extended memory area where the virtual arrays are stored. For example, you would not expect virtual array support to work correctly if both a f-0reground and a background program were independently reading the same area of extended memory because each program would change the the mapping into the extended memory without informing the other program.
Although RT-11 completion routines are built into a program so that they can pass data back and forth with the mainline code, they are run almost as if they were an independent program. That is, when RT-11 decides to run a completion routine, it interrupts the mainline code at wherever it happens to be and saves the register context before calling the completion routine. On return from the completion routine, the register context for the mainline code is restored and the mainline is started up where it left off.
I was talking to one of the RT-11 engineers recently and mentioned this SPR. He said that they had talked about the possibility a while back of changing RT-11 so that when a completion routine is run the mapping register contents are also saved, but they have not made that change so far. The important point is that RT-11 DOES NOT SAVE THE MAPPING REGISTER CONTEXT llHEN A COMPLETION ROUTINE IS CALI.ED. The implication of this is
that unless the user explicitly saves and restores the mapping register context on completion routine entry and exit, virtual ·array mapping may_ be corrupted on return to the mainline code. The mainline code can also change the mapping the completion routine thought was in effect, so on the second call to the completion routine its virtual array mapping may also be corrupted.
The bad news is that you can't blithly reference virtual arrays in the mainline code and a completion routine, but the good news is that there is very little you have to add to the completion routine to make it work. The following MACRO module describes how to modify your completion routine and supplies two FORTRAN-callable routines you need to use. The MACRO module is followed by a sample FORTRAN-77 program to demonstrate the use of virtual arrays in the mainline and a completion routine.
.title VIRMAP
;-----------------------------------------------------------------------This module contains two FORTRAN-77-callable subroutines that make it possible to reference a virtual array element in an RT-11 c~mpletion routine.
DISCUSSION:
For a FORTRAN-77 program that has virtual arrays, PAR7 is used as a window into the extended memory address space where the virtual arrays reside. llhenever a FORTRAN-77 virtual array element is referenced in a program, the F770TS virtual array support routines check to see if the element is in the window that is currently mapped into PAR7. If it is not in the window, PAR7 is remapped to a window that contains the element.
RT-11 FORTRAN completion routines can be scheduled from several SYSLIB programmed requests. Completion routines can interrupt the mainline code at any point. RT-11 calls FORTRAN completion routines as co-routines so that all registers can be saved before the completion routine is called and the registers automatically restored when the completion routine returns. This is done to preserve the register context of the mainline code and to allow any FORTRAN subroutine to be used as a completion routine.
If a FORTRAN-77 virtual array element is referenced in an RT-11 completion routine and remapping is performed, then the mapping that was in effect when the completion routine was entered is no longer valid. If the original mapping is not restored when the completion
RT-13
RT-14
routine finishes, then subsequent virtual array references in the
mainline code may corrupt data in the virtual array that the completion routine last referenced. This problem can be corrected by saving the FORTRAN virtual array mapping context at the start of the completion routine and restoring it when the completion routine is d.one. The two FORTRAN'- 77-callable subr:ou tines GETMAP and PUTMAP in this module provide this capability.
Likewise, if the virtual array mapping is changed in the mainline code between calls to the completion routine, the completion routine doesn't know this has occured, so it may corrupt whatever virtual array data the mainline was accessing at the time the completion routine was run. This problem can be corrected by forcing the completion routine to ALVAYS remap on entry.
Note that these problems are not caused by a bug in FORTRAN-77, but result because of the way an RT-11 completion routine can asynchronously interrupt the mainline code. FORTRAN-77 has no way of knowing that a particular subroutine is going to be used as a completion routine, so it can't take any corrective action.
The virtual array mapping data consists of a 7-word Vindow Definition Block (VDB) plus the current low and high window addresses. This data is contained in the OTS impure area. The routine GETMAP saves the mapping data in a user-supplied array, and the routine PUTMAP restores the mapping data and remaps PAR7 to the original window as indicated by the VDB.
USAGE:
The following FORTRAN-77 completion routine demonstrates how GETMAP and PUTMAP are to be used:
subroutine INIT ( VARRAY )
C----C-----
C----C-----
C-----
This subroutine must be called once in the mainline code so that virtual array address information for VARRAY can be picked up for the completion routine entry point COMPLT. The mainline code must declare VARRAY to be a virtual
array.
virtual VARRAY(O:lOO)
virtual IDUMMY(l) integer*2 mapdat(9) return
A virtual array defined in the mainline code that is to be referenced by completion routine A dummy virtual array to force correct completion routine mapping Mainline mapping data stored here
C----- This entry point is the actual completion routine:
. ; entry COMPLT(id)
C----- Save the mainline virtual array mapping infotmation
call GET MAP ( mapdat )
C----C----C----C----C-----
Reference the dummy virtual array to force the code below to remap on the first reference to the virtual array VARRAY. This must be done because this routine does not know that the mainline code may change virtual array mapping between calls to this routine.
i = !DUMMY (1 )
(Reference the virtual array VARRAY here as needed)
C----- Restore the mainline virtual array mapping information
call PUT MAP ( mapdat )
end
;-----------------------------------------------------------------------
.mcall .VDBDF .MAP .VDBDF
· PRINT . EXIT
Offsets to OTS impure area current low and high window addresses
w.wnlo 260 w.wnhi 262
Error Message
.psect MAP$D,d
MSG:
.asciz /?PUTMAP-F-window mapping error/
.even
RT-15
RT-16
The FORTRAN-77-callable routines:
.psect HAP$I,i
GETHAP:: mov mov mov
10$:
sob
2(r5),r2
llwndow$,rl
ll7,r0
mov
(rl)+,(r2)+
r0,10$
r2 -> mapdat rl -> OTS impure area VDB
rO = length of a VDB
; Hove VDB to mapdat
20$:
mov mov
mov
ll$0TSVA,r3
w.wnlo(r3),(r2)+
w.wnhi(r3),(r2}+
; r3 -> start of OTS impure area
Save low window address in mapdat Save high window address in mapdat
return
PUTHAP:: mov mov
mov 20$:
sob
2(r5),r2
llwndow$,rl
ll7,r0
mov
(r2)+,(rl)+
r0,20$
r2 -> mapdat rl -> OTS impure area VDB
rO = length of a VDB
; Hove mapdat to VDB
.HAP j!YNHAP$,l!YNDOV$
bee
30$
.PRINT llHSG
return
Remap to the original window Branch if no error
Otherwise throw up on user's console
30$:
mov
ll$0TSVA,r3
mov
(r2)+,w.wnlo(r3)
mov
(r2)+,w.wnhi(r3)
return
; r3 -> start of OTS impure area
Restore low window address
Restore high window address
.end
***************************************************************************
program SPROBl
! ..........................................................................·. This program demonstrates by example how to access virtual arrays from a completion routine. It uses the FORTRAN-77-callable MACRO routines GETHAP and PUTHAP in the module VIRMAP.HAC to save and restore the mainline code
mapping.
Build the program as follows:
.fortran sprOBl .macro virmap .link sprOBl,virmap,sy:virtxm/xm ! .........................................................................··.
virtual fill(30000) virtual iget(0:4095)
! array continuously filled in mainline I array sampled by completion routine
type*· 'SPROBl demonstration:'
type *· ' ' type *· 'This program uses the RT-11 request ITIHER to schedule a' type *· 'completion routine that types out the first 20 elements' type *· 'of a virtual array. The completion reschedules itself' type*· 'to run at one second intervals. The data displayed by' type*· 'the completion routine should be the numbers 0 through 19,' type*· 'consecutive. If any other data is printed, the virtual' type *· 'array referenced by the completion routine was corrupted' type *· 'by the mainline program. llhen the completion routine is' type *· 'not running, the mainline fills a different virtual array' type *· 'and verifies it has not been corrupted by the completion' type*· 'routine. If it has, the program will stop with error.' type *· I I
type *· 'If this program is running correctly, it will run' type*· 'continuously until you type a double ctrl-C.'
type *· ' ' type*· 'Press RETURN to start demonstration:' accept '(Al)' , i
ITIHER requires one extra queue element
i = IQSET (1)
RT-17
RT-18
Initialize the array to be sampled by completion rn11tine
do 10 i=0,4095 iget {i) = i
10 continue
Pass virtual array address information to the completion routine
call INIT (iget)
Start the timer
call TIMERl
Loop here filling and verifying the local virtual array forever
20 continue
do 30 i=l,10000 fill(i) = i
30 continue
do 40 i=l, 10000 if ( fill(i) .ne. float(i) ) then type*· '?SPRXXX-F-fill error at i = ',i stop 'Use of virtual arrays in completion routine incorrect' end if
40 continue
go to 20
end
!------------------------------------------------------------------------
subroutine TIMERl
TIMER! schedules completion routine PLAYBK to be run after 1 second.
integer*2 area(4) external PLAYBK call !TIMER ( 0 , 0 , 1 , 0 , area , 1 , PLAYBK ) end
!-------------------------------------------------------------------------
subroutine !NIT ( !GET )
INIT must be called once in the mainline code so that virtual array address information for IGET can be picked up for the completion
routine entry point PLAYBK. The mainline code must declare IGET to be a virtual array
virtual IGET(0:4095) virtual IDUMMY(l)
integer*2 mapdat(9) return
Array to be sampled by completion routine A dummy virtual array used to force the completion routine to map correctly Mainline mapping data stored here
I ......................................................................... . This is the entry point for the timer completion request:
entry PLAYBK(id)
Schedule another timeout interval
call TIMER!
Save the mainline virtual array mapping information
call GET MAP ( mapdat )
Reference the dummy virtual array to force the code below to remap on
the first reference to the virtual array IGET. This must be done because this routine does not know that the mainline maps away the virtual array IGET between calls.
i = IDUMMY(l)
Print the first 20 elements of the virtual array IGET to verify that they are correct.
write (5,'(lx,10!7/lx,1017/)') (IGET(j),j=0,19)
Restore the mainline virtual array mapping information
call PUT MAP ( mapdat )
end
***************************************************************************"
RT-19
RT-20
RT-11 DUCM/DYC GRAFll DEL DIR PLOT-10 IMAGE LIBED FSTATS MS/DOS TIC-TAC-TOE QIX VAX-LIB-
DATMANNAX EDTPlus SPICE2 TREEDUPL LI~e TYPE PLUS MINC DISK USE FRAG EDTEX
PORT LOCATOR TECO CHPLOT NANNY DIRll-
DOG INACTIVE ACCOUNTS IMGSPL ICE TEX
EDlTOR VAX-LIB-4 GRAPHIC UTILITIES SETA ARC., ATPK FIGure KERMIT Distribution TENBACKU
JUICER VTEDIT 2022 VAX-LIB-3 VISTA EDITO
E RSTSOPEN DRAWTREE WATCHDOG PRM-1
SI\IARTMAILER TEN SPELL DECPoint of Sal
PARALLEL Library V2 RTMULTI and Addo
SMARTMAILER for RSTS/E CU FILTRA Spring 86 RT-11 SIG CP/M KERMIT S Invasion for PRO Bonner La
SPLICE RUNOFF VAX-LIB-3 VAX-LIB-2 IMAGE SPELL TURBOCOM FNDFIL PC-8088 Collection #10 VT20
TOOLKIT PLATOOLS SMARTMAILER DEPROC LaTex KERMIT-11 FANCY FONTS XMIT CU ReGis to HPG
CED International RUNITOFF JP5-JP6 FODT PASCAL-OS/8 ANISMT WPSIM PARALLEL LIBRARY
DECSYSTEM-20 SIG Spring 85 CAMERA DELPHIN HACK BIBENTRY APFELN DIGITIZING Acid Docume
Generator VAX-LIB-2 AMAR-10 AMAR-20 DATMABNA~AXEt¥~-1 DUCM/DYC GRAFll DEL DIR PLOT-1
IMAGE LIBED FSTATS MS/DOS TIC-TA~. I A I B-.
MANNAX EDTPlus SPICE2 TREEDUP
LISPEX MCLS TYPE PLUS AMAR-20 DI~
r
T
ORT LOCATOR TECO CHPLOT NANN
DIRll-W WATCHDOG- INACTIVE ACCOUNTS IMGSPL ICE TEXT EDITOR VAX-LIB-4 GRAPHIC UTILITIE
SETAUX.ARC STATPK FIGure KERMIT Distribution TENBACKUP JUICER VTEDIT 2022 VAX-LIB-3 VIST
EDITOR MTU TDE RSTSOPEN DRAWTREE WATCHDOG PRM-11 SMARTMAILER TEN SPELL DECPoint of Sa
.JUICER PARALLEL Library V2 RTMULTI and Addons SMARTMAILER for RSTSIE CU FILTRA Spring 86 RT-1
SIG CP/M KERMIT S Invasion for PRO Bonner Labs APFELN RUNOFF VAX-LIB-3 VAX-LIB-2 IMAGE SPEL
TURBOCOM FNDFIL PC-8088 Collection #10 VT200 TOOLmT PLATOOLS SMARTMAILER DEPROC LaTe
EERMIT-11 FANCY FONTS XMIT CU ReGis to HPGL CED International RUNITOFF JP5-JP6 FODT PASCAL-OS/
A S
NISMT TECO DIGITIZING
AWciPdSIDMocDEuCmSeYnSTfEtM!-l20fSiI'G1SXprEin1gN85~RCA-M1Y:Afl\~iiHI~ N H~ ACKX BlBENIMTRAYG.EA.VPFTE20L0NTKOEORLMKII
C'OMPRO EVENTS PC8088 C_l!()ct·nU , iIJ.l1:1!f.lJ.ee · . a JlcQ·
stem EXPORT Data Inputt
Generator CMSBROWSE PERSONNEL ENTORY MS/DOS COMMS Selectio Electronic Grade Book CPI
I\.ERMIT LaTex JUICER SPELL PORTACALC DPRINT DUNGEON MINC BUDGET BUG CALC C Langua
System DPROC "DEP" DECENC DECmate II OS/278 DIAL DTC GAMMA-11 GDADL LISP for RSX-11 MEM
I\.ERMIT S VAX-LIB-G SPICE 3A6 VT200 TOOLKIT RUNNOFF SPLICE SPY:RSX TCOPY SPELL VT-200 COMPR
EVENTS CMSBROWSE UNDELETE DIAL BLOCKER SCAN CODER BITMAP DTC/PC ADDRESS BOO
i:Alcts· LaserWriter PORTACALC SPICE 3A6 PRO/Smart Mailer CBASIC2 Accts JP5-JP6 Payable/Receivable McGraw-Hi
Payroll SEDT: EDT/WPS Screen CLNDRS:A Calendar Program INDEX AKCOUNT CORPHONE E-Systems Grab Ba
RDBGMTS/RSDpG!~P(L~ TXStM'BtlICfO1N'YD1Ec.V~ICJSRD -AAA
T& -2
.
IR/
M
p
~ ) CoS0E 1 EXp~rI fiE ~·. OIMR.ATGE
RT-11 DU '
C · IDI · E'fff'1/RJ:i!fKr
I ·
-
· ·
X-LIB
DAT1\1AN1 X E TPlus SPICE2 TREEDUPL LISPEX MCLS TYPE PLUS EXPORT DISK USE FRAG EDTEX
PORT LOCATOR TECO CHPLOT NANNY DIRll-W WATCHDOG INACTIVE ACCOUNTS IMGSPL ICE TEX
EDITOR VAX-LIB-4 GRAPHIC UTILITIES BETAUX.ARC STATPK FIGure KERMIT Distribution TENBACKU
JUICER VTEDIT 2022 VAX-LIB-3 VISTA EDITOR MTU TDE RSTSOPEN DRAWTREE WATCHDOG PRM-1
S:\>lARTl\'lAILER TEN SPELL DECPoint of Sale JUICER PARALLEL Library V2 RTMULTI and Addo
SMARTMAILER for RSTS/E CU GRAPHKIT FILTRA Spring 86 RT-11 SIG CP/M KERMIT S invasion for PR
Bonner Labs RUNOFF VAX-LIB-3 VAX-LIB-2 IMAGE SPELL TURBOCOM FNDFIL PC-8088 Collection #10 VT2
TOOLKIT PLATOOLS SMARTMAILER DEPROC LaTex KERMIT-11 FANCY FONTS XMIT MEMO ReGis to HPG
CED International RUNITOFF ,JP5-JPG FODT PASCAL-OS/8 ANISMT CODER WPSIM DECSYSTEM-20 SIG Sprin
S5 CAMERA DELPHIN HACK BIBENTRY APFELN REPORTER DIGITIZING Acid Document Generator VAX-LIB-
AMAR-10 AMAR-20 DATMANfVAX IMAGE VT200 TOOLKIT COMPRO EVENTS PC8088 Collection #9 TECO Cher
Tree Workstation Bookings System EXPORT Data Inputter Generator CMSBROWSE PERSONNEL INVENTOR
!\IS/DOS COMMS Selection Electronic Grade Book CPIM KERMIT LaTex JUICER SPELL PORTACALC DPRIN
DUNGEON MINC BUDGET BUG CALC C Language System DPROC "DEP" DECENC DECmate II OS/278 DIA
DTC GAMMA-11 GDADL LISP for RSX-11 MEMO PORTACALC VAX-LIB-G SPICE 3AG VT200 TOOLKI
RlJNNOFF SPLlCE SPY:RSX TCOPY SPELL VT-200 COMPRO EVENTS CMSBROWSE UNDELETE DIA
lB\lLaOileCrI<CEBRASSfI-A~N
IJC}O:.tDs E,.iY~EITptMJIA.hiT
C~ /Pi
ilD .1
D.eR~El.eSS~·Br·.o'qn1¥<t}·ILierWa.ryita.ejr
Pi' SI.
J:··C.lALfCWS~PI~C·E.~A3·
~RO/Sma
(:,LNDRS:
C'alcndar Progran~E0~ ·.QIJ · I'jl~E-9Vcfh1i.t I; B:@RO llJJJJU..ilJ.tr«.B · ~ON DEVIC
DATATRIEVE Library Collection CMSBROWSE EXPERT FPaint IMAGE DBMS/Spreadsheet for MS/DOS AMAR-I
A;"viAR-20 RDIRJSQMAP PC-8088 Collection #11 UP TIME REPORTER RT-11 DUCM/DYC GRAFll DEL DIR PLO
10 IMAGE LIBED FSTATS MS/DOS TIC-TAC-TOE QIX VAX-LIB-5 DATMANNAX SPICE2 RT-11 DUCM/DYC G
DECUS PROGRAM LIBRARY
Corrections to programs that have been announced through this report.
DECUS No. VAX-288. Title: REPORT WRITER add '"Submit. ted by: W29-50, Los Angeles .CA'".
NEW'LIBRARY PROGRAMS AVAILABLE FOR THE
VAX/VMS FAMILY OF COMPUTERS
DECUS No: V-SP-74 Title: Symposium Collection from the OA SIG. Fall I987.Anaheim Version: Mareh I988
Author: Various
Operating System: VAX/\'llS Source Language: ALL-IN -I Keywords: ALL-IN-I. Symposia Tapes - VMS
Abstract: This submission contains the programs submitted to theOASIG attheFall I98i.DECUS US.Symposium in Anaheim. California. It incJudes the following subdirectories and topics located in directory (.OAS&\]. (For more specific and detailed information, please refer to the AAAREADME TXT in each directory/subdirectory). The follo";ng is a briefsummaryofthe contents of the office automation colJection .
I. (.BRUNER] (.ANSWERJILE_) OR._DELETE] (.A._ONE_HELPS]
(.INTERFACE]
(.MULTIPLE-ATTACH]
(.NEXT _ORJRE\o10US] (.QUEUE_MANAGEMENT]
[.SYSJ>ICT] (.SY8-UDP]
An ALL-IN-I script to enable the user to dispose of the originalmail message as partoftheAnswerpro cedure. Contains articles "3 HELPS" and ''YOURS.AIINE. & OURS ''and related forms, scripts, and command procedures. An ALL ~N -I application for controlling access to ALL-IN -!functions, DCL commands, and external applications. An ALL-IN-I function to allow the contents of a selection list to be attached automatically to the current mail message teplaces previous MAIL FOLDER function). Two ALL lN-I functions for locating the next or the previous docu~ ment in numeric sequence from the current document. Four ALL-IN-I functions which allow the users to specify a. form name for printing, reset the queue. show queue ,and delete a job from the queue. An ALL-IN-I facility for creating and using site-specific System Die tion-aries. An ALL-IN -1 facility for accessing t:ser or System UDP's.
II. (.COY] [COLORS] (.DM$SD]
(.MAKE_TLB] (.ll!CL] (SHOWME] (.VAXNOTES] (WPE]
[WPELSE] Ill (.GILBERT] (.EMP]
(.LN03]
(.SWP] IV(.IOELE] (.AICALCHK)
v.
(.LEDERMAN( (.ACCOUNTING]
(.ALL-IN-I]
A package for managing and setting 'llefault" colors for VT 241and VT'd40 terminals. An extensive revision ofthe Hayre/ Gregory Directory Management package. A revision of Alan L. Zirkles SET DEFAULT program. ProceduresformakingaDXCCompressed TextLibraryfromall"text" files in a directory. Two programs for producing multicolumn listings. Program which provides users with node. terminal. and process information. Some useful things for systems running VAXNOTES. A "complete" and extended impie.. mentation of WPS-PLUS for editing ASCII files. including some language sensitive features for .COM files. An implementation of WPS-PLUS for LSE.
A hierachical EmployeeData phone directory and database, which replaces "ALL" and 'COR" phone directories under ALL-IN-I. A modification to the LN03. PRA file which enables printing66 lines per inch in portraitorientation. fixes total line count error when using eight lines per inch, and will count lines correctly when using "GOLD PAGE" (if down-line load fonts are available). A Shared Word Processing System under ALL-IN-I.
An ALL-IN-I function to allow a user to determine for a given day when one or more users have activities on their own calendars.
Programs to convert System Accounting and PSI Accounting data to a normalized form readable by DATATRIEVE and other languages with record definitions. Contains DTR definitions to work ALL-IN-I logging and data files: document database also works with WPS.PLUS/VMS.
(.CORPHONE] (.FUNCTIONS]
(.NEWSLETTERS]. (.PLOTS] (.RECALL]
(.RSJLACCOUN TING] (.SESSIONS] f.SIXEL] (.SYSMGRJ
DTR replacement for ALL-IN-I corporate phone directory. User defined functions: DTR procedures for cataloging. defining. and generating functions. Past issues of the "Wombat Examiner'" ne\vsletter. Additional PLOTS and articles on adding your own plots. Uses SMG to provide command line recall in DTR: plus DAB definitions in "C". MACR0-32. Process RSX-llM-PLUSsystem accounting and RSX console logs with DTR. Transcriptions of some Symposia sessions. A program .to convert ReGIS to SIXEL. DTR definitions for Disk Quotas.
SYSUAF, etc.: procedures to record
user login history and terminal/line usage.
VI. (.ROTH] (.LG02] (.PENDING] (.RMN(
(. TMPRINT]
(.TODO]
AJlows use of available fonts resident in LG02 line printer with ALLIN-I. Shows ALL-IN-I PENDING file by user~specified number of pending messages. An ALL-IN-I Multiple Read for maiJ which allows users to read new mail sequentially and answer, print. or delete it as they read. Allows ALL-IN-I user to specify a window of time (rather than the 24 hour default window) for printing week's schedule and calendars. Sorts "to do" list in ALL-IN-I by priority and number: results may be displayed or printed.
Media (Service Charge Code): 2400' Magnetic Tape CPS) Format: VMS/BACKUP. TK50 TapeCartridge(TC) Format VMS/ BACKUP
DECUS No: VAX-323 Title: Systems Services Version: Mareh I988
Submitted b)' David N. Mitchell. Information Systems& Net. works. Inc., Durham. NC
Operating System: VAX/VMS V4.5 Source Language: C. VAX FORTRAN Keywords: System Management- VMS. UtilitiesVMS
Abstract This package contains the following programs:
CRELNM.C
The program utilizes system services to create a logical name and place it in one of the processes logical name tables. The program should be passed the name of the logical name table where the logicalwill be placed, the logical
SNDJBCW.C and GETSJC DEF.FOR
TRNLNM.C
name to be set and the equivalenc,.. which the logical will be equated. T' which are included in the progrnrr t"essary:
·"descrip.h" which holds the stn,. the necessary descriptors.
· "lnmdef.h" which holds definitio' logical name flags.
· ··psldef.h'" which contains the ac(·· definition to be used.
The descriptors for the logical narn<' · the logical name are set up alonr: single item list i~ which to return th, lence string. A final zeroed out item up and then the system service to trH' logical is called followed by an error · to be printed if the call should fail . The pr~grarn utilizes system servie· mit command procedures to batrr The program has four parameter into it:
· The name of the procedure to be !":l r ·The name of the queue to which ;
submitted ·A string containing up to eight ar;·
to be passed to the submitted pr· These eight parameters must be ~, by commas and the string mu!":~ minated with a comma All strinS!'. to this routine must be null termir use with C fllnctions. This pro~r written to be called by PL/I and but should work with most any Ian" long as the aforementioned requ: · are .followed. This program call· TRAN routine which includes then· definitions for the send to job ,.,. system service and the translat, name system service. The reasr,-necessary is because this definitv not available in theC language. Tho. sets up the necessary item list !":t ·· and enters the proper informatir. includes:
· The queue name logical. ·The procedure-file specification Jo;..
DCL procedure to be submitted!. ·The log file specification. ·No log delete to prevent the loy
being erased. ·No log spool to prevent the lol!'
being printed. ·Job name to set the process mur
submitted job. ·Eight parameters.
These routines· can easily be modir elude or exclude qualifiers required tieular application. The program utilizes system servi{'f' slate logical names. The program
LIB-1
LIB-2
the address of the character array containing the logical name to be translated.This array must be declared in the calling program to be 256characters. This is the maximum possible length of an equi\'alence string. If the array is smaller. there is a possibility of over-writing other variables in memory. Two inelude files are necessary :
·"descrip.h" which holds the structures of the necessary descriptors.
· "lnmdef.h" ·Which holds definitions for the logical name flags.
The descriptors for the logical name table and the logical name are set up along with the single item list in which to return the equivalence string .A final zeroed out item list is set up andthenthe system service to translate the logical is called followed by an error message to be printed if the call should fail.
Notes: A FORTRAN routine had to be called in order to get the
"Send To Job Controller" MACRO difinitions. Digital Equip ment Corporation has not converted these definition files to the C Language.
Documentation not available.
Media (Service Charge Code): 600' Magnetic Tape (MA) Format VMS/BACKUP
DECUS No: VAX-324 Title: TPU Hebrew Functionality Version: 1. January 1988
Submitted by: Digital Equipment Corporation
Operating System: MicroVMS V4.6, VAX/VMS V4.6 Software Required: TPU English versionHardware Required: Printer and terminals to support Hebrew option. Keywords: Editors
Abstract: VAX users who find themselves with a need to be able to easily create/edit text files in Hebrew yet do not require sophisticated word processing capabilities will find H_EDIT a reliable solution.
lL_EDIT is a TPU based editor which enables the user to create/edit Hebrew text files. It allows for the typing of text from either righLto_left or left_to_right. Direction switching is accomplished by simple keystrokes.
ILEDIT utilizes the EDT style Keypad Emulator and functionality.
Notes: Terminals must contain Hebrew firmware for this prcr gram to perform properly.
Media (Service Charge Code): 600' Magnetic Tape (MA) Format VMS/BACKUP
DECUS No: VAX-325 Title: RDB Report Writer Version: 1, March 1988
Submitted by: David Cohen, Security Pacific Automation Co. W29-50, Los Angeles, CA
Operating System: VAX/VMS V4.5 Source Language: DCL. VAX COBOL Software Required: COBOL Keywords: Tools -
Applications Development Abstract: This package can generate a COBOL subprogram (with a linkage section Iwhich can be called from an RCO program. The subprogram will handle all the report logic. including control breaks. totals. formatting, and creating the actual print file. Accepts as input fourusersupplied files which define the report and the data file record. Validates input files. Handles up to eight levels of control breaks. with totals available for each level. Options include: · At Top of Control Group. ·At Bottom of Control Group. ·At Top of Page. ·At Bottom of Report. ·New Page.
These terms have the same meaning as in DATATRIE\"E. Grand totals are available. Grand totals and "At Bottom of Report" are in addition to the eight allowable control breaks. Report column positions are computed automatically, from Layout Chart created by the user, in any editor. Output program can be edited and modified, if desired.
The generated subprogram is designed to be called from an RCO program, once for every database record in the stream
Notes: Operating system VMS 4.0 and later is required. File.. names are greater than nine letters.
Media (Service Charge Code): User's Manual(EA). 600' Magnetic Tape (MA) Format: VMS/BACKUP
DECUS No: VAX-326 Title: Protect Version: 1.00, February 1988
Submitted b)' Andre Baskin, SYSCON Corp, Williamsburg, VA
Operating System: VAX/VMS V4.5 Source Language: C. MACR0-32 Keywords: Security
Abstract Protect is a system to protect VMS executables from attack by computerviruses by detecting any tampering with the executable done by the virus. A virus is a program which has the ability to infect other programs by inserting a new section of code into another program. 'This new code will cause some harm to the system (ie.. corrupt data, delete files, etc.). In addition, the code inserted by the virus will infect other programs, thus spreading itself throughout the system Protect is able to provide protection from computer viruses by signaling when the executable code of a program has been tampered with in any way. This is done by using the Protect program to place a stamp on the executable. This stamp will be used to check for any changes to the file and will in no way affect the program at run time. Once the program has been stamped by Protect. there are two ways in which tampering can be detected. The first method is to include a call to the function check_program either in the initialization function used by LIB$INITIALIZE or in the first line of executable code. This function will return either "1" which means the program has not been tampered with, or "O" which means the program has been tampered with. In the case ofa program for which the source code is unavailable, once it has been stamped by Protect.. the program Check can be run and will set the symbol $STATUS to either"l" if the executable has not been tampered with. or to "O" if the executable has been tam· pered with.
Documentation may or may not be on magnetic media. Sources not included
Media (Service Charge Code): 600' Magnetic Tape(MA) Format VMS/BACKUP
DECUS No: VAX-32i Title: \'CU VAX/VMS Calendar Utility Version: 3.i. March 1988
Submitted by: Michael C. Johnson. Spuds Software. Brookline. MA
Operating System: MicroVMS V4.5, VAX/VMS V4.6 Source Language: VAX BASIC Memori· Required: 350K Hardware Required: VTJOO. VT220 Terminals Keywords: Calendars
Abs.tract: VCU is an interactive perpetual calendar for the VAX/VMS operating system. It provides you with a simple way to store and retrieve messages for any day.
Features include:
·A complete pull-down menu system with command keys. ·A display consisting of the time, date, previous month. current ·month, next month, day of the year, days left in the year,
yearly messages, weekly message, and daily messages. · A search function. ·Output capability. ·On screen· message editing. ·Qualifiers and parameters to provide complete access from
lDCL. ·Toggling -Of the yearly. weekly. and daily message displays. ·A full year display. · on.line help.
Notes: Operating system VMS V4.0 or later is required. because the program utilizes system routines. screen management routines, and utility routines.
Sources not included
Media (Service Charge Code): User's Manual (EA). 600' Magnetic Tape (MA) Format VMS/BACKUP
DECUS No: VAX-328 Title: SCOPY Version: 1.0, March 1988
Submitted by: John T. Carroll III, Columbus, IN
Operating System: MicroVMS V4.6 Source Language: VAX FORTRAN Hardware Required: VT200 or VT300 Terminal Keywords: FORTRAN. Graphics, ReGIS
Abstract SCOPY is a FORTRAN subroutine that transfers images displayed on Digital Equipment Corporation's VT200 and VT300 series graphics terminals to a plot file. The transfer is accomplished by initiating a remote screen copy and redirecting the screen image from the printer port to the host. The resulting plot file can be printed on any one of Digital Equip-ment Corporation's graphics printers or rapidly redisplayed at the terminal
Media (Service Charge Code): One RX50 Diskette (JA) Format VAX/ANSI, 600' Magnetic Tape (MA) Format VAX/ ANSI
NEW LIBRARY PROGRAMS AVAILABLE FOR THE
PROFESSIONAL-300 SERIES OF COMPUTERS
DECUS No: PR0-178 Title: SIXELPRINT Version: 2.22, July 1987
Submitted by: Digital Equipment Corporation
Operating System: P/OS \'3.J Source Language: PASCAL Memory Required: 512KB Hardware Required: LASO. LA75, LAJOO. LA210 OR Ll'\03 printer Keywords: Graphics. Text Formatting
Abstract SIXELPRll'\T and FONTEDIT are two applications which make up a publishing package for flyers. slides. front pages or even small documentations.
SIXELPRINT formats text for output to any printer capable of handling sixel data. The input text is supplied by a file which you may create using your favorite editor. SIXELPRINT uses font.s supplied with the application or generated by FONTEDIT. and creates a sixel file (SPRINT.SIX) containing the sequences which draw those characters on the printer. SIX· ELPRINT also knows how to do text justification, center, indent. underline and other document formatting operations.
FONTEDIT is a special-purpose editor, used to create and edit font files which will be used by SIXELPRINT .It allows the user to work with the way characters look and takes care of the encoding of the font in the language that printers understand, transparently to the user.
The package includes se\·enteen ASCII fonts, three multinational fonts. two numeric only fonts, two fancy fonts. a Digi· tal Equipment Corporation Logo font and a chess font. The fonts come in sizes of 12. 18. and 24 points (72 points = 1 inch).
Notes: Operating system P/OS VS.O or later is required.
Media (Service Charge Code): User's Manual(EA), TwoRX50 Diskettes (JB) Format FILES-11
NEW LIBRARY PROGRAMS AVAILABLE FOR THE
PDP-II COMPUTER FAMILY
DECUS NO! 11-902Title: Routine Backup FacilitatorVersion: 1.0, March 1988
Submitted by: Richard Desper, Army Materials Technology Lab.. Watertown, MA
Operating System: RT-11 V5.0 Source Language: !:ND Memory Required: 56K Software Required: IND.SAV Keywords: Utilities -Disk - RT-11
Abstract This pair of Il'\D files, FULLBAKCOM and PARBAKCOM, smoothly leads you through RT-11 to perform disk backups. The two files perform the following tasks:
FULLBAK.COM PARBAKCOM
Writes full backups from a large disk (default: DLO) to a magnetic tape unit (default: ~11'0). supporting possible mu1tiVolume outpul Writes partial backups of the same large disk to a smaller removeable media disk (default: DYO).consisting of all files since the date of the last full backup.
LIB-3
LIB-4
Directory listings and dates of the most recent full and partial backups are maintained on DYOalongwith the most recent partial backup. Devices definitions may be changed readily by editingthe.COM files. More extensive comments are aYailable in the file COMENT.LST.
A separate removeable output disk (e.g., DYO) should be supported for each device(e.g., DLO) to be backed up to receive data specific to that device. FULLBAKCOM AND PARBAKCOM may optionally reside on this disk as well.
The partial backup will fail when the size of the partial backup exceeds a limit (about 900 blocks for DYOJ on partial output device.The partial backup will not copy undated files. nor will it copy recent files within a logical disk file on DLO where the logical disk file itself bears an earlier date. Also. the partial backup procedure temporarily defines logical disk LD3. causing potential conflict with user definition of LD3. COMENT.LST offers remedies for all of these restrictions.
Notes: Operating system RT-11 V5.0 or higher is required. Defines, uses logical disk LD3.
Restrictions: Partial backups limited to size of partial backup volume. Undated files not copied in partial backup.
Media (Service Charge Code): One RXO! Diskette (KA) For· mat RT-U. 600' Magnetic Tape (MA) Format RT-U
NEW ULTRIX PROGRAMS
DECUS No: UX-!U Title: PLAtools Version: November 1987
Submitted by: University of California at Berkeley, through Digital Equipment Corporation
Operating System: ULTRIX/UNIX Source Language: C. RAT· FOR Memory Required: 1.5MB Software Required: VAX C Compiler, RATFOR Compiler Keywords: Utilities. ULTRIX
Abstract: The Berkeley PLA Tools are a setof tools designed for perlorming logical and topological optimization as well as test pattern generation of programmable logic arrays (PLAs). The tools form a system encompassing the design of PLAs from the specification of algebraic equations, through logic: minimization and folding. to final physical layout and test pattern generation. These tools also support the optimization offinite-state machines (FSMs) when the machine is implemented as a programmable logic array.
Notes: Operating system UNIX V4.1, V4.2, or V4.3BSD is required. This program was developed by the Computer-Aided Design Group, Department of Electrical Engineering and Computer Sciences. University of California-Berkeley.
Restrictions: US. Government export regulations prohibit the distribution of this program outside the United States without the appropriate export licenses.
Media (Service Charge Code): User·s Manual (EE). 600' Magnetic Tape (MA) Format TAR
DECUS No: CX-112 Title: SPLICE3 Version: 3.0. ~larch 1988
Submitted by: University of California at Berkeley. through Digital Equipment Corp.
Operating System: CLTRIX/U!\IX Source Language: C Memory Required: !.5MB Software Required: \'AX C Compiler Keywords: Circuit Simulation
Abstract: SPLICE3 is a circuit simulation program for largescale integrated circuits. It performs electrical simulation using event-driven selec~ive-trace techniques. This analysis is done using the Iterated Timing Analysis (ITA) algorithm which performs an accurate electrical waveform analysis up to fifty times faster than SPICE2.
Release notes are distributed with each order.
Notes: Operating system UNIX V4.2 or V4.3BSD is required. This program was developed by the Computer-Aided Design Group. Department of Electrical Engineering and Computer Sciences, University of California-Berkeley.
Restrictions: U.S. Government export regulations prohibit the distribution of this program outside the United States without the appropriate export licenses.
Media (Service Charge Code): User's Manual IEEJ. 600" Magnetic Tape (MA) Format: TAR
REVISIONS TO LIBRARY PROGRAMS
DECUS No: U-SP-47 Title: AnalytiCalc IPortaCaic): A 3D Spreadsheet/Database System Version: V22.3B. March 1988
Author. Glenn C. Everhart. Ph.D.
Operating System: AMIGA DOS. !AS, MS/DOS. MicroVMS. RSX-UM. RSX-UM-PLUS. VAX/VMS Source Language: FORTRAN 77. MACRO,U, MACR0-32 Keywords: Business Applications. Data Base Management. Mathematical PortaCalc, Spreadsheet
Abstract: AnalytiCalc is a powerful three dimensional spreadsheet/database and analysis system with easy user extensibility designed to outperform most any commercial package available, running on PDP~ll systems able to support the F4P compiler, or VAX systems, needing the VAX FORTRAN compiler to compile. Several terminals are supported. including the VTIOO series, VT52, Datamedia Colorscan 10 and Elite 1500, Televideo 925, and ANSI color tenninals. A full DTR-32 inter· face is supported on VAX and a command mode structure similar to Visicalc or other micro spreadsheets is available as an option. Address range maxima are 32.000 rows and 32.000 columns on VAX.10.000by10.000 on PDP-U (using software\;rtual memory on PDP-11). A mode for "connecting" arbitrary VAX applications to AnalytiCalc is with simple syntax and numerous supporting new string functions.
The program is designed for power, and to be easily portable to other systems supporting FORTRAN, with peculiarities used documented. and its manual is designed to be turned into a system HELP file so that it can be read online. Tutorials are SUJr plied as well.
A data management system interface is built in. permitting spreadsheets to access a potentially unlimited number of files
and records or parts of records in those files for·user defined functions. numbers, formulas. text. or whatnot In fact. it has many of the attributes of a language. Every cell may contain far more complex formulas than most commercia1ly sold programs. and indeed may be a complete program with the ability to execute most command-level spreadsheet commands. though with minor restrictions.
Merging of multiple sheets. matrix algebra general function solving (a la TK!SOLVER. though with a less polished user interface), and easy document load/unload make this spreadsheet very significantly more powerful than all but the most elaborate mainframe packages, and infinitely easier to customize. User commands may be entered via keyword or function key and are provided with a comprehensive HELP system permitting users to individually tailor commands to their needs.
A powerful text integration function permits integration of word processing files with reports, permitting use of AnalytiCalc (PortaCalc) to integrate sections of reports which are edited with any editor. It also simplifies inserting text from external files flexibly over null cells of the spreadsheet
This package runs on PDP-11. or on VAX in NATIVE MODE. Versions have been built for RSX-UM, RSX-llM-PLUS, VMS, and RSTS. though supplied build files are for the RSX and VMS versions only. Speed of the VAX versions is higher than many of the expensive commercial VAX versions. An AMIGA and a MS/ DOS version of AnalytiCalc are presented here also.
Several new trig functions and some bulletproofing corrections have been added to this version, plus some new code speedups.
The ability to call UNMODIFIED FORTRAN callable subroutines (plus a few hundred example routines) has been added, and performance for really huge VAX sheets has been improved via better hashing methods. It is now trivial to add almost any desired functionality to AnalytiCalc.
SPECIAL HARDWARE: On VAX. screen-independent cursor routines are used for screen addressing normally. On PDP11, the software must be built for the appropriate terminal. Versions of the UVTIOO subroutine for VTlOO. VT52. Datamedia Elite. and several other types of terminals inc:luding VTIOO with Advanced Video and Colorscan 10 are supplied;'With command files for most combinations. The VT52 versions will show what the minimum requirements are for control. Most any terminal can be easily interfaced to the package by editing-one of the UVTlOO routines to correspond to the terminal's control sequences, provided direct cursor addressing is supported.
Release Notes are distributed with each order.
Notes: VAX/VMS users see DECUS No. V-SP-24.
Changes and Improvements: Faster VAX. Amiga versions. VAX version can now call any unmodified FORTRAN callable subroutines.
Media (Service Charge Code): 2400' Magnetic Tape(PC) Format RMSBCK TK50 Tape Cartridge (TC) Format RMSBCK
DECUS No: V-SP-24 Title: AnalytiCaic (PortaCalc): A 3D Spreadsheet/Database System in VMS/BACKUP Version: V22.3B. March 1988
Author. Glenn C. Everhart. Ph.D.
Operating System: AMIGA DOS. !AS, MS/DOS. RSX-UM. RSX-llM-PLUS. VAX/VMS Source Language: FORTRAN77. MACRO-!!. MACR0-32 Keywords: Business Applications. Data Base Management. Mathematical. PortaCalc. Spreadsheet
Abstract: AnalytiCalc is a powerful three dimensional spreadsheet/database and analysis system with easy user extensibility designed to outperform most any -commercial package available. running on PDP-11 systems able to support the F4P compiler. or VAX systems. needing the VAX FORTRAN compiler to compile. Several terminals are supported, including the VTIOO series. VT52, Datamedia Colorscan 10, and Elite 1500, Televideo 925. and ANSI color terminals. A full DTR-32 interface is supported-on VAX and a command mode structure similar to-Visicalc or other micro spreadsheets is available as an option. Address range maxima are 32.000 rows and 32,000 columns on VAX, 10,000 by 10.000 on PDP-11 (using software virtual memory on PDP-11). A mode for"connecting" arbitrary VAX applications to AnalytiCalc is now available also w-ith simple syntax and numerous supporting new string functions.
The program is designed for power and to be easily portable to other systems supporting FORTRAN, with peculiarities used documen~ed, an.d its manual is designed to be turned into a system HELP file so that it can be read online. Tutorials are supplied as well.
A data management system interface is built in, permitting spreadsheets to access a potentially unlimited number of files and recordsor parts of records in those files for user defined functions, numbers. formulas, text or whatnot. In fact. it has many of the attributes of a language. Every cell may contain far more complex formulas than most commercially sold programs, and indeed may be a complete program with the ability to execute most command-level spreadsheet commands, though with minor restrictions.
Merging of multiple sheets, matrix algebra, general function solving (a la TK!SOLVER. though with a less polished user interface), and easy document load/unload make this spreadsheet very significantly more powerful than all but the most elaborate mainframe packages, and infinitely easier to customize. User commands may be entered via keyword or function key and are provided with a comprehensive HELP system per~ mitting users to individually tailor commands to their needs.
A powerlul text integration function permits integration of word processing files with reports, permitting use of AnalytiCalc (PortaCalc) to integrate sections of reports which are edited with any editor. It also simplifies inserting text from external files flexibly over null cells of the spreadsheet
This package runs on PDP-11, or on VAX in NATIVE MODE. Versions have been built for RSX-UM. RSX-UM-PLUS. Vl\IS and RSTS, though supplied build files are for the RSX and VMS versions only. Speed of the VAX versfons is higher than many of the expensive commercial VAX versions. An AMIGA and a MS/ DOS version of AnalytiCalc are presented here also.
Several new trig functions and some bulletproofing corrections have been added to this version, plus some new code speedups.
The ability to call UNMODIFIED FORTRAN callable subroutines(plus a few hundred example routines) has been added. and perlonnance for really huge VAX sheets has been improved via better hashing methods. It is now trivial to add almost any desired functionality to AnalytiCalc.
LIB-5
LIB-6
SPECIAL HARDWARE: On VAX. screen-independent cursor routines are used for screen addressing normally. On PDP11. the software must be built for the appropriate terminal.
Versions of the L"\'1100 subroutine for v;:noo. VT52. Datamedia
Elite. and several other types of terminals including VTlOO with Advanced Video and Colorscan 10 are supplied. with command files for most combinations. The VT52 versions will show what the minimum requirements are for control. Most any terminal can be easily interfaced to the package by editing one of the U\"TlOO routines to correspond to the terminal's control sequences, provided direct cursor addressing is supported.
Release Notes are distributed with each order.
Notes: PDP-11 users see DECUS No. ll-SP-47.
Changes and Improvements: Faster VAX, AMIGA versions. VAX version can now call any unmodified FORTRAN callable subroutines.
Media (Service Charge Code): 2400' Magnetic Tape (PC) Format VMS/BACKUP, TK50 TapeCartridge(TC) Format VMS/ BACKUP
DECUS No: VAX-183 Title: JUICER Version: March 1988
Submittc!d by: Michael N. LeVine, Naval Weapons Center, China Lake. CA
Operating System: VAX/VMS V4.X Source Language: MACRO. 32 Software Required: RUNOFF Keywords: Utilities - Disk. VMS
Abstract TheJUICER package of programs and command files is provided to the system manager to allow him to monitor VAX/ VMS ODS-2 disks for disk and file fragmentation, disk usage and to do such compression as might be needed. The package is made up of eight parts:
· JUICER__l to do stand alone disk compression. · JVICER__2 to do online disk and file defragmentation while
disk is in use by other users. · FRAG to monitor disk fragmentation. · FILE to monitor and optionally compress fragmented files. ·DIR to make a map of disk directory structure and its file/
block usage. ·DISK to show by user and account the number of disk blocks
in use, authorized and overdraft. · DISKMON to run as a detached prQcess to provide a constant
monitor of all disk(s) free space. · BAD to scan a selected disk for bad blocks and on user
authorization. try to repair them.
JUICER.__! is an inplacedisk compression utility for VAX/VMS ODS.2 disks suffering from excessive fragmentation. This program.. within limitations, attempts to move portions of files from the high end of the disk to any Unused areas (fragments) at the low end, freeing up larger contiguous free areas at the high end.
JUICER..._2 is an on-line in-place disk and file compression utility for VAX/VMS ODS-2 disks suffering from excessive fragmentation. This program runs on-line while other users are also using the disk. It defragments the most defragmented files it can find that will fit in the largest contiguous free areas on disk. and moves other files as far down toward the low end of the disk as it can. filling up free fragments at the low end and freeing up more space at the high end.
FRAG is run on a disk to see how badI;; the target disk free space is fragmented. giving a histogram of fragmented areas by size, a calculated measure of the disk free space fragmentation and. if wanted. a map of free fragments by starting LBN vs size.
FILE scans all the file headers on the target disk and outputs two list files. one containing a list of the 100 files having the most retrieval pointers in use. and the second being a matrix of file size versus number of pointersin use. The command file CONTIG is used which reads one of the list files produced by FILE and running interactively with the user, converts the listed files from fragmented to contiguous.
DIR scans a target disk and creates an output file DIRECTORY.MAP containing a graphical output showing the on disk directory structure. with a notation for each directory showing the number of files and blocks contained therein.
DISK COM sets up data for the program DISK.EXE which produces a list by user and account (for each disk specified) of disk blocks in use, authorized and permitted overdrafts.
DISKMON is a program that! found on a VAXS!Gtapesubmitted by Eric Richards of Gould Ocean Systems, 18901 Euclid Ave. Cleveland, Ohio 44117. It is a detached process which constantly monitors all disks on the system and warns when free space falls below preset values.
BAD scans a selected disk for bad blocks. When a bad block is found, the user is asked if BAD should attempt to rewritethe block, assuming a soft error. If the rewrite is selected, the user can select to edit the contents of the bad block before the rewrite is attempted.
Notes: JUICER_! is Vl.13 and JUICER_2 is V2.17.
Changes and Improvements: Bug fix to JUICER-2.
Restrictions: Does not do volume setting.
Media (Service Charge Code): 600' Magnetic Tape (MA) Format VMS/BACKUP
DECUS No: VAX-193 Title: \'TEDIT: Keypad Text Editor and Corrector for VAXTPU Version: 4.5, January 1988
Submitted by: Dr. Gerhard Weck. InfodasGmbH. D-5000 Koeln 71, West Germany
Operating System: MicroV~!S V4.5. V4.6, VAX/VMS V4.6 Source Language: VAX FORTRAN. VAXTPU Memory Required: Virtual Hardware Required: Digital Equipment Corporation ANSI Terminal (\'TlOO. VT200. VT300 compatible) Keywords: Editors
Abstract: The Video Terminal Editor VTEDIT is an editing interface for the VAX Text Processing Utility VAXTPU, and optionally for VAX LSE. The VTEDIT interface is an efficient, keypad driven editor allowing multi-window editing and providing semi-automatic, context dependent text formatting. VTEDIT implements, among others, the following features:
·Multi-file and multi-buffer editing. ·Split screen editing. ·Insert and overstrike editing. ·Free and bound cursor moYement. ·Recognition of all TECO matc:h control constructs and access
to VAXTPU pattern building constructs. ·Journaling the editing session.
·Access to the VMS operating system via DCL. SPA \VN and Attach commands.
·Access to VAXTPU.
Many additional editor functions like:
· Search and replace. · Rectangular cul paste. and delete. ·Remember and retrieve buffer positions. ·Insertion of date. time. file and buffer names. ·Case and position control for searches. · Case conversion and capitalization of words. · Center line and fill paragraph. · Control of tabulator setting. ·Replace Tabs with spaces. · Deletion of trailing blanks. · Sorting of buffers and ranges. · Wildcard filename search and selection. · Selection of user and system buffers from a list.
Optional semi-automatic, context dependent text formatting providing the following functions:
·Case conversion/automatic case control ·Automatic indentation. · Manual correction of indentation. · Automatic word wrap · Automatic line justification. · Optional automatic insertion of closing parentheses and str-
ing delimiters. ·Optional highlighting of the matching opening parenthesis
and string delimiter. ·Extensive online help.
Optional access to the Language-Sensitive Editor VAX LSE, providing operations to:
· Fill and align program comments. · Specify a directory search list. · Retrieve sources from a CMS library. ·Protect buffers against modification. ·Move to and/or delete placeholders. · Expand tokens. routines, placeholders, and aliases. ·Define aliases for use in later expansions. ·Compile sources and review errors. · Locate errors and retrieve the corresponding source text. ·Load language definitions and environments at run time. ·Access the LSE command interpreter directly.
Optional access to the Source Code Analyzer VAX SCA, providing operations to:
·Find declarations of symbols. ·List positions of variable declarations and/or references. · Retrieve corresponding sources. ·Access the SCA command interpreter directly.
Notes: Operating system VMS V4.4 or later is required. Installation via VMSINSTAL: needs at least 1600 blocks; may interface to VAX LSE {this requires additional 800 blocks).
Changes and Improvements: Additional interfaces to VAX LSE and SCA.
Media (Service Charge Code): User's Manual (EC). 600' Magnetic Tape (MAI Format VMS/BACKUP
DEC US No: VAX-214 Title: NEWS Version: 5.1, March 1988
Submitted by: Geoff Huston. Australian National University, Canberra City. A.C.T. Australia 2601
Operating System: MicroVMS V4.6. VAX/VMS V4.6 Source Language: C Keywords: Bulletin Board
Abstract NEWS is a software product which manages user. system and network news items. The news items areasetoftext files which have been posted on the system for general public view.
NEWS complies with the USENET Standard for Interchange of Messages, Request For Comment (RFC) 1036. The program includes network management{for inclusion of a VAX node into the USENET NEWS network). local news data management and screen-based user presentation modules. The release also includes a DECNET implementation of the Network News Transfer Protocol (NNTP). as defined in RFC 977, allowing server/client configurations of NEWS.
The program supports similar functionality to that of the rnews (b2.11) and related USENET news readers as well as Digital Equipment Corporation's VAXNOTES.
Changes and Improvements: Compiles with Usenet RFC 1036.
Media (Service Charge Code): 600' Magnetic Tape (MA) Format VMS/BACKUP. or order VAX-LIB-6
DECUS No: VAX-297 Title: ReGISto HPGL Conversion Program Version: 2.K, February 1988
Submitted by: Dr. N.S. Hoult. Racal Research Ltd., Reading, Berkshire. EnglandRG2 OSB
Operating System: VAX/VMS V4.5, V4.6 Source Language: DCL. VAX FORTRAN Memory Required: 36KB Software Required: FORTRAN run-time system Keywords: Graphics, Hewlett Packard ReGIS
Abstract This program converts a file of ReGIS graphics commands, as used by the '\11125 and VT'240 terminals, into HewlettPackard Graphics Language (HP-GL), as used on the 7580B plotter. It sends them to a file or directly to the plotter, which may be connected "in-line" with the terminal. Other plotters which accept HP-GL may be accommodated by slight changes to the initialization sequences. All ReGIScommands are parsed, but only a subset(sufficient for line graphs with labelling, and including macrographs) is sent to the plotter. The resulting graphs may be scaled to fit the paper, or specified explicitly as Al. A2, etc.. or in mm. The program is designed to facilitate the addition of extra ReGIS commands.
Changes and Improvements: Mixed absolute and relative coordinates are allowed.
Restrictions: Not all ReGIS commands are interpreted although all are accepted.
Documentation may or may not be on magnetic media
Media (Service Charge Code):600' Magnetic Tape (MA) Format VMS/BACKUP
LIB-7
LIB-8
DECUS No: VAX-314 Title: VAX Capacity Management Tool Version: 3.1, April 1988
Submitted by: Digital Equipment Corporation
Operating System: VAX/VMS V4.3 - V4.6 Source Language: MACR0-32, VAX BASIC Memory Required: 102KB Software Required: VAX RETOS if hardcopy graphs tel spooled sixel printers is required. Hardware Required: VT240 Terminal, VT330 Terminal or VT340 Terminal Keywords: System Management - VMS
Abstract This system is designed as a tool for use by those people responsible for capacity management of a VAX or VAXcluster. It is not necessary to have VMS internal knowledge or system management knowledge to make use of this package. It is mainly designed for medium or large scale VAX installations.
This package collects statistics on the utilization of CPU. memory and disk devices on the monitored VAX or VAXcluster. It also collects information on the CPU response of the machine and the number of processes executing. In addition to the VAX wide and VAXcluster wide information collected. this package also collects information for each UIC group. If your VAX system is arranged with each application in a separate UIC group then this allows the total system utilization to be broken down by application.
The information collected can be displayed in a graphic form on VT240, VT330 or VT340 terminals. The capacity manager uses an interactive display program that has a DCL-like command syntax. The user can display histograms orfrequencydiagrams with hourly, daily or monthly information. The UIC group statistics can be added or subtracted from system wide statistics so graphic answers to questions like, "What wiJI happen to the system ifl take that application off?", can be seen
Hardcopy output to printers that handle ReGIS is possible. If the Digital Equipment Corporation product RETOS is available, output to printers like the LAIOO that support sixel graphics can be performed.
A machine uptime subsystem is included which records VAX uptime accurate to five minutes. These statistics can be reported between date ranges, hour ranges and weekends can be either included or excluded from the calculation
Complete user documentation, help text and installation documentation is included on the media
Changes and Improvements: Correction to MASSBUS disk statistic collection.
Media (Service Charge Code): 600' Magnetic Tape(MA) Format VMS/BACKUP
DECUS No: 11-462 Title: TERM.FOR Version: 5.0. March 1988
Submitted by: Richard Desper. Army Materials Technology Lab.. Watertown. MA
Operating System: RT-11 V5.0 Source Language: FORTRAN IV Memory Required: 56KB Hardware Required: LSI-II with DLV-llJ (Standard ~UNC Hardware) Keywords: Data Communications. Emulators
Abstract TERM is a program written in FORTRAN to convert a PDP-11/23 with a DLV-llJ Quad Serial Interface into a smart terminal. The program allo\>.,·s the PDP-11/23 console terminal to converse with a remote computer. Disk files on the PDP-11/23 may be accessed as either sources or sinks for ASCII data files. File transfer is limited to ASCII files and is not automatically checked for errors. but is quite reliable at speeds up to 2400 baud. IA second speed limitation is that the remote computer baud rate must be slower than the PDP-11/23 console terminal rate. 9600 baud at this installation.)TERJ\I is sufficiently transparent to the user to allow editing operations on the remote computer. e.g. VAX/VMS EDT using VT!OO or VT200 terminal support. For possible use with a remote VAX, a VMS file TER)l.COM is also provided to facilitate file transfer. Further details are in the file TERM.DOC and as comments in TERM.FOR
Notes: Operating system RT-11 V5.0 or higher is required. Multi-terminal support is required. Bold and reverse video controls of VTIOO or VT200 terminals are used. VTIOO or VT200 support is not essential. High speed ring buffer support in RT11 is highly recommended.
Changes and Improvements: Run-time control of file transfer Echo. automatic control-Z termination of transmit files, added VMS TERM.COM file for easy conversation with VAX, transparency to EDT Editor controls.
Restrictions: Record length 132 characters; ASCII Files only.
Media (Service Charge Code): One RXOJ Diskette (KA) For· mat RT-11, 600' Magnetic Tape (MA) Format RT-11
LIB-9
STEERING COMMITTEE LISTS
ARTIFICIAL INTELLIGENCE SIG
CHAIR Cheryl Jalbert JCC 128 West Broadway Granville, OH 43023 (614) 587-0157
VICE-CHAIR OPSS WORKING GROUP CHAIR
Don Rosenthal Space Telescope Science Inst. Homewood Campus Baltimore, MD 21218 (801) 338-4844
NEWSLETTER TASK FORCE CHAIR ADMINISTRATIVE ASSISTANCE
Becky Wise AmdalhCSD 2200 North Greenville Ave. Richardson, TX 75081 (214) 699-9500 x 272
NEWSLETTER EDITOR Terry Shannon Computer Info. Sys., Inc. Technical Consultant 165 Bay State Drive Braintree, MA 02184 (617) 848-7515
SYMPOSIA COORDINATOR Pam Vavra Hughes Aircraft EDSG P.O. Box 902 E52/D220 El Segundo, CA 90241>-0902 (213) 616-7071
MEMBERSHIP COORDINATOR SUITE COORDINATOR
Chris Goddard Simpaet Associates 9210 Skypark Court San Diego, CA 92123 (619) 56&-1865
SESSION NOTE EDITOR George Humfeld Naval Sea Systems Command PMS 350 ED Dept of the Navy Washington, DC 20362-5101 (202) 692-0137
ASS'T SESSION NOTES EDITOR David Frydenlund
STORE REPRESENTATIVE Sally Townsend Inst. Defense Analysis 1801 N. Beauregard St Alexandria, VA 22311 (103) 845-2122
PUBLIC DOMAIN SOFTWARE TF CHAIR LIBRARY REPRESENTATIVE
Jim Sims
Space Telescope Science Ins. 3700 San Martin Drive Baltimore, MD 21218 (301) 338-4949
Al LUG COORDINATOR ASSISTANT STORE REP.
Dennis Clark
RT2Box264 Kingston, TN 37768 (615) 576-7384
REPORTER TO THE UPDATE.DAILY Bill Lennon
SEMINAR UNIT REP. CAMPGROUND COORDINATOR
Leona Fluck Educational Testing Service Rosedale Road Princeton. NJ 08540 (609) 734-1243 DEC COUNTERPART Art Beane Hudson. MA MEMBERS-AT-LARGE David Slater George Winkler Jeff Fox John Williamson Wayne Graves Matt Mathews Dave Campbell Shirley Bockstahler-Brandt Barry Breen Tom Viana
BUSINESS APPLICATIONS SIG
CHAIRMAN George Dyer Gallaudet University 800 Florida Ave, NE-EMG Bldg Washington, DC 20002 (202) 651-5800
COMMUNICATIONS COORDINATOR Steve Lacativa Price Waterhouse 153 East 53rd Street New York, NY 10022 (212) 371-2000 x 3107
SYMPOSIA COORDINATOR Mark Hults USSA Administrative Systems USSA Bldg. BOIE San Antonio, TX 78288 (512) 498-8725
LUG COORDINATOR Patrick LeSesne U.S. Coast Guard Room 1416E 2100 2nd St SW Washington, DC 20593 (202) 267-0354
MARKETING COORDINATOR Tom Byrne I. Karp& Sons 1301 Estes Elk Grove Village, IL 60007 (312) 598-5706
PROGRAM PLANNING COORDINATOR Stuart Lewis Douglas Furniture Corp. P.O. Box97 Bedford Park, IL 60499 (312) 458-1505
SEMINARS COORDINATOR Daniel Esbensen Touch Technologies, Inc. 9990 Mesa Rm, Rd. #220 San Diego, CA 92121 (619) 455-7404
LRP COORDINATOR Arnold I. Epstein D-M Computer Consultants Rolling Meadows, IL 60008 (312) 394-8889
NEWSLETTER EDITOR Dave Levenberg Credit Suisse Dept OAl 15th floor 100 Wall Street New York, NY 10005 (212) 612-8372
SESSION NOTE EDITOR Marty Schmitt Harris Publishing 8 Barker Avenue White Plains, NY 10601 (914) 946-7500 x 287
LIBRARY REPRESENTATIVE David Hittner Projects Unlimited 3680 Wyse Road Dayton, OH 45414 (513) 890-1800
CL SIG LIAISON Becky Burkes-Ham
OMS SIG LIAISON Joe Sciuto MEMBERS-AT-LARGE Robert D. Lazenby Dixie Beer Dist., Inc. Louisville, KY Robert Kayne Gallaudet College Washington, DC Ray Evanson Paragon Data Systems Winona, MN
DEC COUNTERPARTS Sue Yarger Digital Equipment Corporation Merrimack, NH 03054-0430 Paula Daley Digital Equipment Corporation Merrimack, NH 03054-0430 Pam Kukla Digital Equipment Corporation Maynard. MA 01754
DATATRIEVE/4GL SIG
CHAIRMAN Donald E. Stern Jr. Warner Lambert Company 10 Webster Road Milford. CT 06460 (203) 783-0238
SYMPOSIA COORDINATOR LisaM. Pratt Vitro Corporation Nuwes Code 3144 Keyport WA 98345 (206) 396-2501
ASS'T SYMPOSIA REPRESENTATIVES T.C. Wool E.I. duPont DeNemours & Co. Engineering Dept P .0. BOX 6090. Newark, DE 19714-6090 (302) 366-4610 Janet G. Banks Weyerhaeuser Info. Sys. Mail Stop CCB-2E Tacoma, WA 98477 (206) 924-4082
SIC-1
COMMUNICATIONS REPRESENTATIVE NEWSLETTER EDITOR
Joe H. Gallagher Research Medical Center 2316 East Meyer Blvd. Kansas City, MO 64182 (816) 276-4235
COMMUNICATION REPRESENTATIVE PRODUCTION EDITOR
Steve Cordiviola Kentucky Geological Survey 311 Breckinridge Hall Lexington ,KY 40506 (606) 257-5863
ASSOCIATE NEWSLETTER EDITOR Pasquale (Pat) F. Scopelliti Corning Glass Works Mail Stop MP-R0-01-1 Corning, NeW York 14831 (607) 974-4496
Lorey B. Kimmel Digital Equipment Corp. 6707 Whitestone Road Baltimore, MD 21207 (301) 298-1500
Herbert G. Reines Reznick Feddder & Silverman 4520 East West Highway Suite 300 Bethesda, MD 20814 (301) 652-9100
Alan Winston Stanford Synchrotron Radiation Lab. SLAL BIN69 PO .Box 4349 Stanford, CA 94305 (415) 854-3300 x2874
VOLUNTEER COORDINATOR Susan Krentz NKF Engineering 12200 Sunrise Valey Dr. Reston. VA 22091 (703) 620-0900
ASSISTANT VOLUNTEER COORD. Harry Miller City of Ontario Police 200 N. Cherry Avenue Ontario, CA 91764 (714) 988-6481
SEMINARS COMMITTEE REP. Dana Schwartz 15719Millbrook Lane Laurel, MD 20707 (301) 859-6277
SESSION NOTES EDITOR Bernadette Reynolds City of Ontario Police 200 N. Cherry Avenue Ontario, CA 91764 (714) 988-6481
SUITE COORDINATOR Bert Roseberry Commandant (G-APA-1) 2100 2nd Street, S.W. Washington, DC 20593-0001 (202) 267-2629
FEATURE EDITOR Philip A. Naecker Consulting Engineer 3011 N. Mount Curve Ave. Altadena, CA 91001 (818) 791-0945
DEC COUNTERPARTS Mary Ann Fitzhugh 110 Spit Brook Road ZK2-2/M28 Nashua, NH 03060 (603) 881-2329
ARTIST & LIBRARY REP. Bart Z. Lederman WU World Communications 67 Broad Street (28th Floor) New York, NY 10004 (212) 607-2657
RALLY WORKING GROUP CHAIR Steven G. Fredrickson Fredrickson Consulting Service 107 1st Avenue N. Seattle. WA 98109 (206)283-0273
POWERHOUSE W/G CHAIR David N agurney TSO Financial Corp. Five TSO Financial Center Three Hundred Welsh Road Horsham.PA 19044-2009 (215) 657-4000
DMS SIG LIAISON William Tabor W.I. Tabor, Inc. 12018 Royal Palm Blvd Coral Springs, FL 33065 (305) 755-7895
SMARTSTAR WORKING GROUP CHAIR Thomas Colati Time Enterprises 301 North Harrison Suite 101 Princeton. NJ 08540 (800) 548-6865
ACCENT-R USER GROUP LIAISON Winston Tellis Fairfield University North Benson Road Fairfield, CT 06430 (203) 255-5411
FOCUS WORKING GROUP CHAIR Les Hulse The Gillette Company Prudential Tower Bldg. Boston, MA 02199 (6171 421-7910
_/
DAARCSIG
CHAIRMAN James Deck Inland Steel Research Lab. 3001 East Columbus Drive East Chicago, IL 46312 (219) 392-5613
SYMPOSIA COORDINATOR Mack Overton
FDA
Chicago, IL
COMMUNICATIONS REPRESENTATIVE NEWSLETTER EDITOR
Da1e Hut.chison Cummins Engine Co. 4720 Baker Sl, Exl Lakewood, NY 14750 (716) 456-2191 DEC COUNTERPART Bill Forbes Marlboro, MA
SIC-2
HARDWARE & INTERFACING Peter Clout Los Alamos National Lab Los Alamos, NM
MATH STATISTICS & ANALYSIS Herbert J. Gould C.C.F.A. Univ. of III. Medical Ctr. Chicago, IL
PROCESS CONTROL-INDUSTRIAL AUTOMATION Bill Tippie Kinetic Systems Corp. Lockport, IL
RS-1
George Winkler CPC International Argo, IL
DATA MANAGEMENT SYSTEMS SIG
CHAIRMAN Doug Dickey GTE Government Systems 1700 Research Blvd Rockville, MD 20850 (301) 294-8462
MEMBER AT LARGE Alan Schultz Southwestern Bell Yellow Pages 12800 Publication Dr., Suite 108 Sl Louis, MO 63131 (314) 957-2029
SYMPOSIA COORDINATOR SQL Standards Rep.
Keith Hare JCC P.O. Box 463 Granville, OH 43023 (614) 587-0157
COMMUNICATIONS REP. Debbie Kennedy Coleman Shane Co. 2 W Washington St., Suite 600 Indianapolis, IN 46204 (317) 635-9100
NEWSLETTER EDITOR William Packard Mass Mutual Life Ins. 1296 State Street B-391 Springfield, MA )1111 (413) 788-8411
SESSION NOTE EDITOR Mark Morgan Farm Credit Banks P.O. Box 141 Springfield, MA 01102 (413) 786-7600
MEMBERSHIP COORDINATOR MEMBER AT LARGE
Rocky Hayden Userware International 2235 Meyer Avenue Escondido, CA (619) 745-6006
MEMBER AT LARGE PAST SIG CHAIRMAN
Steve Pacheco Ship Analytics North Stonington, CT 06359 (203) 535-3092
PAST SIG CHAIR MEMBER AT LARGE
Joe Sciuto U.S. Army 5910 Westchester Street Alexandria, VA 22310 (202) 692-6903
SEMINAR REP. Stephen Gomez Signal Technology 1700 Montgomery St. San Francisco, CA 94111 (415) 954-8532
WORKING GROUP COORDINATOR/ Jim Perkins PSC, Inc 20 Kimball Ave., Suite 305 Shelburne, VT 05401 (802) 863-8825
CAMPGROUND COORDINATOR Rosemary O'Mahony Arthur Anderson & co. 33 West Monroe Street Chicago, IL 60603 (312) 507-6510
SESSION CHAIR COORDINATOR Andy Menezes AD&E 29-B Montvale Avenue Woburn, MA 01801 (617) 938-1979
Rdb WORKING GROUP Coordinator Howard Cheng Bechtel Western Power Corp. 12440 East Imperial Highway Norwalk, CA 90650 (213) 807·4077
ROADMAP COORDINATOR Elizabeth Irving
Dupont
P.O. Box 1089 Orange, Texas 77630-1089 (409) 886-9427 DBMS COORDINATORS Bryan Holland 1006 Pleasant St, #20 Weymouth, MA 02189 (617) 335-7573 Paul E. Reese Aetna, Systems Dept Financial Division City Place Hartford, Connecticut 06156 (203) 275-2012 MEMBERAT LARGE Jim Redfield BDM 9020 N. Cap. of Texas Highway Austin, TX 78759 (512) 346-6760 STORE REPRESENTATIVE FIMS STANDARDS REP. Paul W. Plum, Jr Lukens Steel Company Coatesville, PA 19320 (215) 383-2024 RMS WORKING GROUP COORDINATOR Allen Jay Bennett Logisticon, Inc. 5035 Whitneyville Road Ada. MI 49301 (616) 452-1823 DEC COUNTERPART Wendy Herman John Wood Nashua, NH
EDUSIG
CHAIRMAN Robert A.Shive, Jr. Millsaps College Jackson, MS 39210 (601) 354-5201
SYMPOSIA COORDINATOR Mary Jae Reed Off Comp Based Instruction University of Delaware 305 Willard Hall Newark, DE 19716 (302) 451-8161
COMMUNICATIONS REPRESENTATIVE Robert W. McCarley Millsaps College Jackson, MS 39210 (601) 354-5201
NEWSLETTER EDITOR Fred Bell Taft College 29 Emmons Park Drive P.O. Box 1437 Tai~ CA 93267 (805) 763-4282
PSS COORDINATOR VAX SYSTEMS SIG LIAISON
Donald C. Fuhr Tuskegee Institute Tuskegee Institute, AL 36088 (205) 727-8242
ADMINSTRATIVE APPLICATIONS COORD. Dave Cothrun Taft College 29 Emmons Pk Drive P.O. Box 1437 Tai~ CA 93268 (805) 763-4282
SESSION NOTE EDITOR Paula Barnes Guilford College 5800 West Friendly Avenue Greensboro, NC 17410 (919) 292-5511
DEC COUNTERPART Gary Finerty Marlboro, MA
[Q] Graphcs Appications
OECUS ~
GRAPHICS APPLICATIONS SIG
CHAIRMAN Bijoy Misra Smithsonian Institution 60 Gordon St, MS39 Cambridge, MA 02138 (617) 495-7392
SESSION NOTE EDITOR Carol Schwob Florida Atlantic Univ. Bldg. 22, Room 106 Boca Raton, FL 33431 (305) 393-2640
NEWSLETTER EDITOR (acting) OPEN
ASSOCIATE NEWSLEITER EDITOR Charles D. Carter Huntington Alloys, Inc. Technology Dept. P. 0. Box 1958 Huntington. WV 25720 (304) 526-5721
WORKSTATION WORKING GROUP COORD. Bob McCormick Video Communications, Inc. 1325_ Springfield Street Feeding Hills. MA 01030 (413) 786-7955
ENGINEERING GRAPHICS WORKING GROUP COORD. Eric Rehm Gonzaga University SPOCAD E 502 Boone Spokane, WA 99258 (509) 484-6814
COMMUNICATIONS REP NEWSLETTER EDITOR
Robert Hays KMS Fusion 3621 So. State Road Box 1567 Ann Arbor, MI 48106
LIBRARY COORDINATOR Mike McPherson Michigan University 269 Engineering Bldg. East Lansing, MI 48824 (517) 353-9769
STANDARDS COORDINATOR OPEN
VOLUNTEER COORDINATOR Dick Mccurdy University of Florida Room 216, Larsen Hall Gainsville, FL 32611 (904) 392-4915
LIBRARY COMMITTEE James M. Turner Saber Technology San Jose, CA
DEC COUNTERPART Jim Flatten Spit Brook, NH
Rick Landau Marlboro, MA
INFORMATION OFFICER Mike York Boeing Computer Services P. 0. Box 24346 M/S 03-73 Seattle, WA 98124 (206) 342-1442
SYMPOSIUM COORDINATOR Dottie Elliott Northrop Services Inc. P.O. Box 12313 Research Triangle PK, NC 27709 (919) 541-1300
DATA DISPLAY WORKING GROUP COORD. Joy Williams Eaton Corp. P.O. Box 766 Southfield, MI 48037
HAllJ) NE1'1S
HARDWARE MICRO SIG
CHAIRMAN Willian K. Walker Monsanto Research Corp. Miamisburg, OH
PRODUCT PLANNING COORDINATOR George Hamma Synergistic Technology Cupertino, CA
PRE-SYMPOSIUM SEMINAR COORDINATOR James R. Lindesmith Monsanto Research Corp. Miamisburg, OH
COMMUNICATIONS COORDINATOR John G. Hayes Information Systems South Central Bell Birmingham, AL
NEWSLETTER EDITOR Carmen D. Wiseman Digital Review Boston, MA
SESSION NOTE EDITOR DAARC SIG LIAISON
Bill Tippie Kinetic Systems Corp. Lockport, IL
SIC-3
STANDARDS COORDINATOR CAMAC WORKING GROUP COORDINATOR
Peter Clout Los Alamos National Lab los Alamos, NM
LUG COORDINATOR Gregg Giesler Los Alamos Science Lab Los Alamos, NM
TOEM (CHIPS & BOARDS) Jack J. Peterson Horizon Data Systems Richmond, VA
HHK (HARDWARE HINTS & KINKS) Wayne Kesling Monsanto Research Cor. Miamisburg. OH
UNIBUS HARDWARE Ron Bogue LIV Aerospace & Defense Co. Dallas, TX
PERFORMANCE MEASUREMENT COORD. William Wallace 600 W. Washington Street Peoria, IL
CSS COORDINATOR Pratap Gobel E.L duPont Ingleside, TX
NETWORKS SIG LIAISON Sandra Traylor Target Systems Yorba Linda, CA
VAX SIG LIAISON Dave Schmidt 5100 Centre Avenue Pittsburgh, PA
UNISIG LIAISON Jim Livingston 1 Results Way Cupertino, CA
SITE SIG LIAISON Emily Kitchen A.H. Robins Co. Richmond, VA
RT-II SIG LIAISON Gary Sallee Sallee Software Consulting yorba Linda, CA
RSX SIG LIAISON Hans Jung Associated Press New York, NY
MEMBERS-AT· LARGE MikeRembis American Dade Costa Mesa. CA
Hans Dahlke Richland, WA
Jim Cutler EDS Tower 16533 Evergreen Southfield, MI
DEC COUNTERPARTS TERMINALS Nina Abramson Maynard, MA
TOEM (Chips & Boards) Art Bigler Marlboro, MA
DIAGNOSTIC George D. Cooke Maynard, MA
STORAGE Marilyn Fedele Maynard, MA
MSD (Micro Systems Develp.) Roy Rodgers Maynard, MA
PRINTER PRODUCTS Frank Orlando Maynard, MA
DECUS EUROPE LIAISON Hans Zoller
IAS SIG
CHAIRMAN Alan Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065 (213) 256-2575
NEWSLETTER EDITOR Frank R. Borger Radiation Therapy Michael Reese Medical Center Lake Shore Drive@ 31st St Chicago, IL 60616 (312) 791-2515
WHIMS COORDINATOR Kathleen Anderson Eaton Information Management System Division Hampton, VA (804) 326-1941
RSX LIAISON Ray French Boeing Computer Services Seattle, WA (206) 655-6228
MEMBER-AT-LARGE Doug Reno Abbot Laboratories North Chicago, IL (312) 937-7504
PAST CHAIRMAN Mike Robitaille Grumman w CTEC, Inc. 6862 Elm Street McLean VA 22101 (703) 556-7400 x431
CHAIRMAN EMERITUS Bob Curley Division of Medical Physics University of Pennsylvania Philadelphia, PA (215) 662-3083
SYMPOSIA COORDINATOR Lynda L Roenicke Special Systems Branch Naval Ocean Systems Center 271 Cataline Blvd Code 742 San Diego, CA (619) 225-7569
LIBRARY COORDINATOR Ted Smith The University of PA Philadelphia, PA 19101 (215) 662-3500
MEMBER-AT-LARGE Kerry Wyckoff Salt Lake City, UT
DEC COUNTERPART Nancyfaye Autenzio Stow, MA (617) 496-9606
SIC-4
LANGUAGES AND TOOLS SIG
CHAIRMAN Sam Whidden American Mathematical Society 201 Charles St P.O. Box 6248 Providence, RI 02940 (401) 272-9500
VICE CHAIR SYMPOSIA COORDINATOR
Earl Cory Eaton Corporation 31717 La Tienda Dr. Westlake Village, CA 91359 (818) 706-5385
STORE REPRESENTATIVE Chair, TECH. PROD OF DOC. WIG
Howard Holcombe RCA Front & Cooper Sts. Camden, NJ 08055 (609) 338-4946
NEWSLETTER EDITOR ALT. CommComm REP.
Al Folsom, Jr. Fischer & Porter Co. E. County Line Rd. Warminster, PA 18974 (215) 674-7154
SESSION NOTES EDITOR Mark Katz GTE Government Systems 100 First Avenue Waltham, MA 02154 (617) 466-3437
AUSTRALIAN L&T INTERFACE Gordon Brimble Bldg. 180 Labs Area Defence Research Centre Box2151 GPO Adelaide, S.A. Australia 5001 (61)(8)259-6119
INTERSIG COORDINATOR Dorothy Geiger Wollongong Logistics Group 49 Showers Drive # 451 Mountain View, CA 94040 (415) 948-1003 (415) 962-7160
EUROPEAN METHODS L&TINTERFACE
Bernd Gliss
Max-Planck~Institute
Heisenbergstra Be 1 7000 Stuttgart 80, W. Germany (711) 686-0251
PAST CHAIR PRODUCTIVITY TOOLS COORDINATOR
Kathy Hornbach Digital Equipment Corporation 110 Spit Brook Rd., ZK03-3IY25 Nashua, NH 03062 (603) 881-2505
CHAIR TECO WORKING GROUP MarkJ. Hyde Advanced Computing Services 209 Ardsley Drive DeWit~ NY 13214 (315) 446-7223
MEMBER, ANSI BASIC X3J2 STDS, COMM. STANDARDS COORD. PDP-II REP. CHAIR, PDP-II LAYERED PRODUCT WIG
Stephen C. Jackson SCJ Consulting, Inc. 7260 University Avenue N.E. Suite 105 Minneapolis, MN 55432 (612) 571-8430
CHAIR, CONFIG. MGMT. WORKING GROUP Mark Alan Kidwell Texas Instruments Inc. P. 0. Box 869305 Ml S 8435 Plano, TX 75086 (214) 575-3547
DEVEL. COUNTERPART, PDP-I I SOFTWARE Joe Mulvey Digital Equipment Corp. ,ZKOl-3/JlO 110 Spit Brook Road Nashua, NH 03062-2642 (603) 881-1218
LISP/Al COORDINATOR Don Rosenthal Space Telescope Science Institute Homewood Campus Baltimore, MD 21218 (301) 338-4844
LIBRARY REPRESENTATIVE SIG TAPE LIBRARIAN CHAIR, PUBLIC DOMAIN SOFTWARE WIG
Tony Scandora Argonne National Laboratory CMT205 Argonne, IL 60439 (312) 972-7541
CHAIR, C WORKING GROUP James Maves Eaton Corp, IMSD 31717 La Tienda Drive Box 5009 Westlake Village, CA 91359 (818) 706-5395
COMMCOMM REP. Jay Wiley Bechtel Power Corp 12400 East Imperial Highway Norwalk, CA 90650 (213) 807-4016
SESSION CHAIRS COORDINATOR BOF CHAIRS COORDINATOR SESSIONS QUALITY COORD. ALT. SYMPOSIUM COORD.
Gary C. Lelvis IMSL 2500 Park West Tower One 2500 City West Blvd. Houston, TX 77042-3020 (713) 782-6060
CHAIR, FORTRAN WORKING GROUP Scott Krusemark 8473 Daisywood Ave N.W. North Canton, OH 44720 (216) 499-6251
CHAIR, LOW LEVEL LANGUAGES W/G Gerald Lester Computerized Processes Unlim. 2901 Houma Blvd. Suite 5 Metairie, LA 70006 (504) 889-2784
DEVEL. COUNTERPART, COMM. LANG. Jim Tatton Digital Equipment Corp. ZK02-3/K06 110 Spit Brook Road Nashua. NH 03062
ALT. ANSI X3J9 PASCAL STDS. COMM. Phil Wirth E-Systems, Garland Division Box 660023, MS 53730 Dallas, TX 75266-0023 (214) 272-0515 x4319
ALT. ANSI X3J4 COBOL STDS. COMM. Dale Marriott El Paso County Office Bldg. 27 E. Vermijo Street Colorado Springs, CO 80903 (303) 520-6435
CHAIR, DIBOL WORKING GROUP ASSOC, WIG COORD. UNSCHEDULED TOPICS ACTING CHAIR, COBOL WORKING GROUP
Bruce Mebust Burlington Northern Railroad 176 East Fifth Street P.O. Box 64962 St Paul. MN 55164 (612) 298-2382
CHAIR, SECURITY WORKING GROUP Rich Harris General Research Corp. 5383 Hollister Avenue P. 0. Box 6770 Santa Barbara. CA 93160~6770 (805) 964-7724
ASSISTANT CAMPGROUND COORD. Tom J. Jeffrey Rockwell International Corp. 1225 N. Alma Road Richardson, Texas 75081 (214) 996-7818
CHAIR, ADA WORKING GROUP Lisa Kerby· Rodgers GTE Government Systems 100 Ferguson Drive P. 0. Box 7188 Mountain View, CA 94039 (415) 966-2720
CHAIR, PROJECT MANAGEMENT W/G Lynn C. Lewis Lawrence Livermore National Lab. University of California P.O. Box 808 Livermore, CA 94550 (415) 422-8949
TEMP. CHAIR, OBJ. ORIENTED DES. W/G Frank B. Modruson Arthur Andersen & Co. 33 West Monroe Street Chicago, IL 60603 (312) 580-0033
CHAIR, TeX/LaTEX WEB WIG John Osudar Argonne National Lab. 9700 South Cass Avenue Argonne. IL 60439 (312) 972-7505
CHAIR, VAXset W/G David J. Powell The Upjohn Company 7263-267-712 301 Henrietta St. Kalamazoo, MI 49007 (616) 344-3341
MEM., ANSI DIBOLX3Jl2 Stds. Comm. Kenneth Schilling 2314 Mira Vista Avenue Montrose, CA 91020 (818) 249-0795
SUITE & RECEPTION COO RD. Matt Variot Eaton Corporation Box 5009 31717 La Tienda Drive Westlake Village, CA 91359 (818) 706-5388
CHAIR, TPUIEVEILSE W/G John Wilson Aetna Life & Casualty City Place YFB3 Hartford, CT 06103 (203) 275-2064
VICE CHAIR SYMPOSIUM LOGISTICS COORD.
Terry Medlin Survey Sampling, Inc. 1 Post Road Fairfield CT 06432 (203) 255-4200
MASTERS COORDINATOR Dena Shelton Cullinet Software Inc. 2860 Zanker Rd, Suite 206 San Jose, CA 95134 (408) 434-6636
ACTING CHAIR, APL WORKING GROUP CHAIR, BASIC WIG WISHLIST COORDINATOR
Bob Van Keuren UserWare International, Inc. 2235 Meyers Ave. Escondido, CA 92025 (619) 745-6006
SIC-5
WORKING GROUPS COORD. CAMPGROUND COORDINATOR
Joseph Pollizzi, III Space Telescope Science Institute 3700 San Martin Drive Homewood Campus Baltimore, MD 21218 (301) 338-4901
CHAIR, SCAN WORKING GROUP CHAIR, PL/I WORKING GROUP VOLUNTEERS COORD.
David Ream Lexi·Comp 26173 Tallwood Drive N. Olmsted, OH 44070 (216) 777-0095 (216) 468-0744
CHAIR, PASCAL WORKING GROUP MEMBER, ANSI PASCAL X3J9 STDS. COMM. CHAIR, MODULA-2 W/G
E. Wayne Sewell E-Systems, Garland Div. Box 660023, MS 53700 Dallas, TX 75266-0023 (214) 272-0515 x3553
CHAIR, SOFTWARE METRICS W/G Michael S. Terrazas LOS Church 50 E. North Temple. 27th Floor Salt Lake City, UT 84150 (801) 531-3246
MEMBER, ANSI COBOL X3J4, STDS, COMM. Bruce Gaarder Donahue Enterprises, Inc. 2441 26th Ave., S. Minneapolis, MN 55406 (612) 721-2418
ALT. SEMINAR COMM REP. Janet E. Bressan Boeing Aerospace Co. P. 0. Box 3999, MS3C-24 Seattle. WA 98124 (206) 773-9404
CHAIR, RPG WORKING GROUP Charles Williamson Hargray Telephone Co. P.O. Box 5519 Hilton Head I&. SC 29938 (803) 686-1204
SEMINAR COMMITTEE REP. Barry C. Breen Sundstrand Data ControL Inc. 15001 N.E. 36th Street P.O. Box 97001 Redmond, WA 98073-9701 (206) 885-8436
ASSIST. MASTERS COORD. CLINIC DIRECTOR CHAIR, CASE & TOOLS INTEGRATION WIG
George Scott Computer Sciences Corp. 304 West Route #38, P.O. Box N Moorestown. NJ 08057 (609) 234-1100
ASSISTANT CAMPGROUND COORD. Keith Batzel Crowe, Chizek & Co. 330 E. Jefferson Box 7 South Bend, IN 46624 (219) 232-3992
DEVEL. COUNTERPART TECH. LANG. Leslie J. Klein Digital Equipment Corp. ZK02-3IN30 110 Spit Brook Road Nashua, NH 03062
DIGITAL COUNTERPART Celeste La Rock Digital Equipment Corp. ZK02-3IQ08 110 Spit Brook Road Nashua, NH 03062
LARGE SYSTEMS
CHAIR
E.F. Berkley Shands
Washington University
Department of Computer Science
P.O. Box 1045
.
Sc Louis, MO 63136
(814) 889-6636
UUCP:BERKLEY@WUCS.UUCP
BITNET: Berkley@Uunet
COMMUNICATIONS RE PRESENTATIVE NEWSLETTER EDITOR
Clyde T. Poole The University of Texas at Austin Department of Computer Sciences Taylor Hall 2.124 Austin, TX 78712-1188 (512) 471-9551 ARPANET/CSNET:ctp@sally.utexax.edu
36 BIT SYSTEMS Clive Dawson Microelectronics & Computer Technology Corp. 9480 Research Blvd Echelon Bldg. # 1, Suite 200 Austin, TX 78759 (512) 343-0860 ARPANET/CSNET:CLIVE @ MCC. COM
SYMPOSIUM REPRESENTATIVE Vacant
DISTRIBUTED SYSTEMS Don Kassebaum Computation Center University of Texas at Austin Austin, TX 78712 (512) 471-3241 ARPANET:CC.KASSEBAUM@A20.CC. UTEXAS.EDU
SEMINARS REPRESENTATIVE Robert C. McQueen (201) 428-4242 ARPANET:SIT.MCQUEEN@cu20B.COLUMBIA.EDU
SUPERCOMPUTING Vacant
SIG VICE-CHAIRMAN Ralph M. Bradshaw Johnson & Johnson Research &Scientific Services Management Information Center Rarilsn, NJ 08869-1489 (201) 685-3434
LIBRARY REPRESENTATIVE SIR/MENU BALLOT
Jack Stevens The Gillette Company Technical Services, 4U-3 1 Gillette Park Boston, MA 02106-2131 (617) 463-2089
SIG MARKETING Steve Attaya Weiner Enterprises P.O. Box 23607 Harahan, LA 70183 (504) 733-7055 ARPANET:G.ATTAYA@R20.UTEXAS.EDU
CORPORATE ISSUES Ralph Bradshaw Johnson & Johnson Research and Scientific Services Management Information Center Rarilsn, NJ 08869-1489 (201) 685-3484
DEC COUNTERPARTS Dave Braithwaite Digital Equipment Corporation Marlboro, MA
Rich Whitman Digital Equipment Corporation Marlboro, MA
Reed Powell Digital Equipment Corporation Marlboro, MA
·--·--
MUMPS SIG
CHAIRMAN Chris Richardson Richardson Computer Research P.O. Box 8744 La Jolla, CA 92038 (619) 488-6193
NEWSLETTER EDITOR VICE-CHAIR COMMCOMM REP.
MarkJ. Hyde Advanced Computing Services 209 Ardsley Drive DeWit~ NY 13214 BITNET: MJHYDE@SUNRISE INTERNET: MJHYDE@SUNRISE.ACS.SYR.EDU (315) 446-7223 SYMPOSIUM SCHEDULER Brad Hanson Group Health, Inc. 2829 University Ave., S.E. Minneapolis. MN 55414 (612) 623-8427
LIBRARY REPRESENTATIVE PDP-I I WORKING GROUP REP.
Michael Mcintyre PRx, Inc. 43 Bradford Street Concord, MA 01742 (617) 369-3566 SEMINARS REPRESENTATIVE Edward Woodward Science Applications Intl Corp. 10260 Campus Point Drive MS42 San Diego, CA 92121 (619) 535-7210
CAMPGROUND COORDINATOR ASSIST. SYMPOSIUM SCHEDULER
Jerry Hsu Rubicon Corp. 1200 E. Campbell Richardson, TX 75088 (214) 231-6591 SESSION NOTES EDITOR Bob Van Keuren 4087 Chamoune Avenue San Diego, CA 92105 (619) 283-5285 PAST CHAIR MUMPS DEV. COMMITTEE REP. Mark Berryman Digital Equipment Corp. 3 Results Way (MR03-2/H7) Marlborough, MA 01752 (617) 467-4875 BITNET: BERRYMAN@DSM.DEC.COM DEC COUNTERPART Dave Smith Digital Equipment Corp. 2 Iron Way (MR03-2/H7) Marlborough, MA 01752 (617) 467-2397 ALTERNATE DEC COUNTERPART Denise Simon Digital Equipment Corp. 129 Parker Street (PK02-l/M28) Maynard MA 01754 (617) 493-9077
S'!C-6
NETWORKS SIG
CHAIRMAN Stuart Lewis Douglas Furn. Corp. (812) 458-1505
COMMUNICATIONS COMMITTEE REP. Bob Gustafson Northeast Utilities (203) 665-5082
NEWSLETTER EDITOR JudiMandl UCONN Health Center 268 Farmington Ave. Bldg. 19 Farmington, CT 06032
SEMINAR UNIT REP & VICE (BACKUP) SIG CHAIR
Sandy Traylor Target Systems, Inc. (714) 921-0112
SYMPOSIA COORDINATOR Bill Hancock (817) 261-2283
STANDARDS COORDINATOR Jim Ebright Software Results Corp. (614) 267-2203
ASSISTANT NEWSLETTER EDITOR JudiMandl UConn Health Center (203) 674-3912
SESSION NOTES EDITOR Mary Marvel-Nelaon General Motors Research Lab. (818) 986-1382
DEC COUNTERPART Monica Bradlee (617) 486-7341
~~~~~~.
0
-
.,,··
.
~"'4i>E"~
OFFICE AUTOMATION SIG
CHAIR Katherine"Kit" Trimm Pivotal, Inc Tucson, AZ (602) 886-5563
VICE CHAIRMAN Ralph Bradshaw Johnson and Johnson Raritan, NJ (201) 685-3434
COMMUNICATIONS REPRESENTATIVE Mary Jane Bolling Foreign Mission Board 3806 Monument Avenue Richmond, VA 23230 (804) 353-0151
SYMPOSIA COORDINATOR Mitch Brown GenRad Ind. Waltham, MA (617) 369-4400 x3052
NEW MEMBER COORDINATOR Tricia Cross American Mathematical Society P.O. Box 6248 Providence, RI 02940 (401) 272-9500
BOF COORDINATOR Ray Kaplan PIVOTAL, Inc. Tucson, AZ (602) 886-5563
NEWSLETTER EDITOR Therese LeBlanc T.M. LeBlanc & Assoc. Wheeling, IL (312) 469-1784
LIBRARY Bob Hassinger Liberty Mutual Research Center Hopkington, MA (617) 435-9061
OA TAPE COORDINATOR Mary Jane Boiling Foreign Mission Board 3806 Monument Avenue Richmond, VA 23280 (804) 353-0151
SYMPOSIA ASSISTANT Sal Gianni Northeast Utilities Hartford, CT (203) 666-.5652
STORE COORDINATOR Mike Jackson Air Force Operational Test and Evaluation Center Kirtland AFB, NM (506) 846-6641
PERSONAL COMPUTER SIG LIAISON Cheryl Johnson Grinnell College Grinnel~ IA (516) 236-2670
OA LUG COORDINATOR Tom Orlowski American Council on Education 1 DuPont Circle (Suite 110) Washington, DC (202)939-9371
OA SIG COORDINATOR Joe Whatley Neilson Media Research 876 Patricia Avenue Dunedin, FL 33528 (813)734-5473
SESSION NOTE EDITOR George Bone 194 Nalisty Drive Vallejo, CA 94690 (707) 646-2531
PERSONAL COMPUTER SIG
CHAIR Lynn Jarrett San Diego Union-Tribune Pub. Co. 860 Camino de la Reina San Diego, CA 92108 (619) 293-1180
WORKSTATIONS/MACS/PRO WORKING GROUP CHAIRMAN
Thomas R. Hintz Univ. of Florida IFAS Computer Network, Bldg, 120 Gainesville, FL 32611 (904) 392-5180 VICE, CHAIR RAINBOW W/G CHAIRMAN Lynn Jarrett Union Tribune Publishing Co. P.O. Box 191 San Diego. CA 92108 (619) 299-3131 x1130
VAXMATE WORKING GROUP CHAIRMAN Frederick G. Howard Eastman Kodak Company 901 Elmgrove Road, 0346-LP Rochester, NY 14650 (716) 253-2363
VOLUNTEER COORDINATOR Pierre M. Hahn SUNY HSC-Tl0-028-8101 Stony Brook, NY 11794
LIBRARIAN Rep. Ron S. Hafner Hafner and Associates P.O. Box 2924 2499 Wellingham Dr. Livermore, CA 94550 (415) 422-2149
COMMUNICATIONS REPRESENTATIVE Kenneth LeFebvre Sytek, Inc. 19 Church St P.O. Box 128 Berea, OH 44017 (216) 243-1613
NEWSLETTER EDITOR Gary Rice McDonnell Douglas 6555 Garden Grove Blvd. MS: K200 77/200 Westminster, CA 92683 (714) 952-6582
RAINBOW/DECmate W.G. CHAIR Vince Perriello Crosfield Composition Systems One Crosfield Ave. West Nyack, NY 10994 (914) 353-4000
SYMPOSIA COORDINATOR Jimbo Wilson Natl Tech. Inst for Deaf Rochester Inst of Tech. P. 0. Box 9887 Rochester, NY 14623 (716) 475-6241
SESSION NOTES EDITOR Dr. Tom Warren Oklahoma State Univ. Dept of English Dir. Tech. Writing Program Stillwater, OK 74078 (405) 624-6138
PCSA WORKING GROUP CHAIRMAN To be announced
MEMBERS-AT-LARGE Michael Bowers Univ. of California Animal Science Department Davis, CA 95616 (916) 752-6136
Theodore Needleman Odea Teeh. 67 W. Burda Pl. Spring Valley, NY 10977 (914) 250-100
DEC COUNTERPARTS PERSONAL COMPUTING SYSTEMS GROUP
Anita Uhler Digital Equipment Corporation LJ02/13 30 Porter Road Littleton, MA 01460 (617) 486-2397
PRO Jeff Slayback Digital Equipment Corp. ML021-2/U12 146 Main Street Maynard, MA 01754 (617) 493-9340
BUTTON COORDINATOR Ken Stricker Martin Marietta Aerospace P.O. Box 5837 MP 320 Orlando, FL 32856 (305) 356-6589
SIC-7
CAMPGROUND COORDINATOR Jim Hobbs Adolf Coors Co. Golden, CO 80401-1296 (303) 277-2855
SEMINARS COORDINATOR Tim Bundrick 3480 TCHTW/TTVC Goodfellow AFB, TX 76908-5000 (915) 657-5424
RSTS SIG
CHAIRMAN Charles Mustain Stark County School system Data Services Division 7800 Columbus Rd. N.E. Louisville, OH 44641 (216) 875-1431
COMMUNICATIONS REPRESENTATIVE STORE REPRESENTATIVE
Ed Beadel Instructional Computer Center S. U.N.Y. College at Oswego Oswego, N.Y. 13126 (315) 341-3055 SYMPOSIA COORDINATOR Glenn Dollar Digital Computer Consultants Inc. 21363 Lassen St, Suite 205 Chatsworth, CA 91311 (818) 341-9171 ASS'T SYMPOSIA COORDINATOR Dan Stoller Natural Country Farms P.O. Box758 58 West Road Rockville, CT 06066 (203) 872-8346 NEWSLETTER EDITOR Terence M. Kennedy St Peter's College Department of Computer Science 2641 Kennedy Blvd. Jersey City, NJ 07306 (201) 435-1890 LIBRARY REPRESENTATIVE R.R. Patel (PAT) Krupp/TaylorUSA 12800 Culver Blvd Los Angeles, CA 90066 (213) 306-3646 PRE-SYMPOSIA SEMINAR COORDINATOR Scott Castleberry 1750 North Collins Suite 108 Richardson, TX 76080 (214) 437-3477 VICE CHAIRMAN WISH LISTS COORDINATOR Lynnell Koehler Campus America POISE Prod. Ctr. 201 North Nevada Avenue Roswell, NM 88201 (505)625-5500 EDUSIG LIAISON George Wyneott Purdue University Computer Center W. Lsfayette, IN
RSTS PRODUCT PLANNING COORDINATOR Errol E. Ethier Information Design and Management, Inc. 23 Hunting Avenue (617) 842-4220 Shrewsbury, MA 01545
DEC COUNTERPART Kathy Waldron Digital Equipment Corporation Continental Blvd. Merrimack, NH 03054
MEMBERS-AT-LARGE Edward F. BeadeL Jr. Manager Instructional Computing Center S. U.N.Y. College at Oswego Oswego, NY 13126 (315) 341-3055 Mark Hartman Jadtec Computer Group 546 W. Katella Avenue Orange, CA 92667 (714) 997-8928 Jeff J. Killeen Information Design & Management, Inc. 31 Hopedale Street Hopedale, MA 01747
RSX SIG
CHAIRMAN Dan Eisner Perkin-Elmer Corp. Garden Grove, CA
SYMPOSIA COORDINATOR Rick Sharpe Toledo Edison Toledo, OH
PRE-SYMPOSIUM SEMINAR COORDINATOR Hans Jung Associated Press New York, NY
COMMUNICATIONS REPRESENTATIVE Jay Allen Bennett Logisticon, Inc. 5035 Whitneyville Road Ada, MI 49301 (616) 452-1823
NEWSLETTER EDITOR MULTI-PROCESSORS WORKING GROUP COORDINATOR
Bruce Mitchell Machine Intelligence & Industry Magin Byron, MIN STORE COORDINATOR Jim Hopp Carlton Financial Computation South Bend, IN SESSION NOTE EDITOR Burt Janz BHJ Associates Nashua, NH LIBRARIAN Glenn Everhart Mt Holly, NJ CAMPGROUND COORDINATOR Jerry Ethington Prolifix Inc. Frankfort, KY DEC COUNTERPARTS Lin Olsen Nashua, NH Dick Day Nashua, NH WORKING GROUP COORDINATOR Sharon Johnson Epidemiology Minneapolis, MN
WORKING GROUP CHAIR Evan Kudlajev Philadelphia Electric Co. Philadelphia, PA
RSX GROUP CHAIR SOFTWARE CLINIC COORD. RoyS. Maull U.S. Air Force Offutt AFB, NE
SOFTWARE CLINIC COORDINATOR Bruce Zielinski RCS Moorestown, NJ
VOLUNTEER COORDINATOR Gary Maxwell U.S. Geological Survey Menlo Park. CA
SRD WORKING GROUP COORDINATOR Bob Turkelson Goddard Space Flight Center Greenbelt, MD
ACCOUNTING & PERFORMANCE WORKING GROUP COORD. Denny Walthers American McGaw Irvine, CA
MENU COORDINATOR Ed Cetron Center for Biomedical Design Salt Lake City, UT
MEMBERS-AT-LARGE Jim McGlinchey Warrenton, PA Jim Neeland Hughes Research Labs. Malibu, CA Anthony E. Scandora, Jr. Argonne National Laboratory Argonne, IL
Ralph Stamerjohn Creve Coeur, MO
RT-11 SIG
CHAIRMAN John T. Rasted JTR Associates 58 Rasted Lane Meriden, CT 06450 (203) 634-1632
COM. COM VOTING REP. COBOL CONTACT
Bill Leroy The Software House, Inc. P, 0. Box 52661 Atlanta, GA 30355-0661 (404) 231-1484 STANDARDS COORDINATOR Robert Roddy Naval Ship Research Ctr. Bethesda, MD 20084 (301) 227-1724 MACRO CONTACT Nick Bourgeois NAB Software Services Inc. P. 0. Box 20009 Albuquerque, NM 87154 (505) 298-2346 NEWSLETTER EDITOR TECO CONTACT PRODUCT PLANNING CONTACT John M. Crowell Multiware, lnc. 2121-B Second St Suite 107 Davis, CA 95616 (916) 756-3291
NETWORKING CONTACT Jim Crapuchettes Omnex Corp. 2483 Old Middlefield Way Mountain View, CA 94043 (415) 966-8400
WISH LIST CONTACT UNIX/ULTRIX CONTACT
Bradford Lubell LA. Heart Lab, UCLA 10833 Le Conte Avenue Los Angeles, CA 90024-1760 (213) 206-6119
TSX & C CONTACT Jack Peterson Horizon Data Systems P.O. Box 29028 Richmond, VA 23229 (804) 740-9244
RUNOFF CONTACT John Davis Naval Ship Research Center Code2950 Bethesda, MD 20084 (301) 227-1592
LUG CONTACT Ned Rhodes Software Systems Group 2001 North Kenilworth St. Arlington, VA 22205 (703) 534-2297
PERSONAL COMPUTERS Dennis V. Jensen AMES Labs. ISU/USDOE 310 Metallurgy Ames, Iowa 50011 (515) 294-4823
SYMPOSIA COORDINATOR Milton Campbell
Talisman Systems Drawer CP-255 Manhattan Beach, CA 90266 (213) 318-2206
TAPE COPY GENERATION TAPE COPY DISTRIBUTION RT DECUS LIBRARY CONTACT
Tom Shinal Syntropic Technology P.O. Box 198 Waterford, VA 22190 (703) 882-3000
PRE-SYMPOSIUM SEMINAR RT-I 1 SUITE MANAGER
Bruce Sidlinger Sidlinger Computer Corp. 4335 N. W. Loop 410, #209 San Antonio, TX 78229 (512) DIG-ITAL
BASIC CONTACT Ralston Barnard Div 7523 Sandia· Labs Alburquerque, NM 87185 (505) 844-5115
PRO RT-I I & HARDWARE Bill Walker Monsanto Research Corp. P.O. Box 32, A-152 Miamisburg, OH 45342 (513) 865-3557
FORTRAN CONTACT Robert Walraven Multiware, Inc. 2121-B 2nd St Suite 107 Davis, CA 95616 (916) 756-3291
OTHER LANGUAGES Gary Sallee 19912 Fernglen Drive Yorba Linda, CA 92686 (714) 970-2864
SIC-8
SITE SIG
CHAIRMAN Timothy Fraser Specialized Bicycle Components 15130 Concord Circle #77 Morgan Hill, CA 95037 (408) 779-6229
SYMPOSIA COORDINATOR Sue Abercrombie 48 Malilly Rd. Portland, ME 04103 (207) 772-2837
SESSION NOTE EDITOR LARGE SYSTEMS SIG LIAISON
Gary Bremer Emerson Eleetric Co. 8100 W. Florisant St Louis, MO. 63136 (314) 553-4448
NEWSLETTER EDITOR NETWORKS SIG LIAISON OA SIG LIAISON
Gregory N. Brooks Washington University Behavior Research Labs 1420 Grattan St. St Loui~ MO. 63104 (314) 241-7600 ext 257
HARDWARE COORDINATOR HMS SIG Liason Emily Kitchen A.H. Robins Co. 1211 Sherwood Ave. RT-2 Richmond, VA. 23220 (804) 257-2925
COMMUNICATIONS COMMITTEE REPRESENTATIVE AI SIG Liason
Terry C. Shannon Digital Review 160 State St 6th Floor Boston, MA. 02109 (617) 367-7190
PRE-SYMPOSIA SEMINAR COORDINATOR Phillip Ventura
STAFF MANAGEMENT Adam Zavitski Simmonds Precision ICD 3100 Highland Blvd. Raleigh, NC. 27625 (919) 872-9500
MEMBERS-AT-LARGE Ann Goergen Texas Instruments 13510 N. Central M/S437 Dallas, TX. 75266 (214) 995-4629
HMS SIG Liason RT SIG Liason
David Hunt Lawrence Livermore National Lab MS L-230 P.O. Box 808 Livermore CA. 94550 (802) 656-3190
Gary Siftar Digital Equipment Corporation Tulsa, OK.
DEC COUNTERPARTS Joe Allen Stow MA.
Lil Holloway Bedford MA.
Susan Porada Marlboro, MA
UNISIG
CHAIRMAN Kurt L. Reisler Hadron Incorporated 9990 Lee Highway Fairfax, VA 22030 (703) 359-6100 decvax !seismo! hadron !klr
SYMPOSIA COORDINATOR Stephen M. Lazarus Ford Aerospace & Communications 3939 Fabian Way. MS X-20 Palo Alto, CA 94303 (415) 852-4203 ihnp41fortune!wdll!sml
SESSION NOTES EDITOR William Cheswick New Jersey Institute of Tech. Computing Services 323 Martin Luther King Blvd. Newark, NJ 07102 (201) 596-2900 bellcore! njitcccc !be
NEWSLETTER EDITOR Sharon Gates-Fishman NDC Corporation 730 E Cypress Avenue Monrovia, CA 91016 (818) 358-1871 !amdahl! cit-vax! ndc! sgf
COMMCOMM REPRESENTATIVE James W. Livingston, Jr. Measurex Automation Systems 10411 Bubb Rd Cupertino. CA 95014-4150 (408) 973-1800 x 766 ihnp4!masl!jwl
ADMINISTRATIVE DAEMON Dorothy A. Geiger The Wollongong Group 49 Showers Drive, # 451 Mountain View, CA 94040 (415) 948-1003 ihnp4!<lecwrl ~dgeiger
TAPE LIBRARIAN Carl Lowenstein Marine Physical Laboratory Scripps Institute of Oc'graphy, P-004 LaJolla. CA 92093 (619) 294-3678 [ihnp4,decvax.akgua,dcdwest,ucbvax) !sdcsvax !mp Ivax~ cdl
USENET LIAISON STANDARDS COORDINATOR
Ed Gould Mt.Xinu 2910 7th St. Suite 120 Berkley, CA 94710 (415) 644-0146 ucbvax!mtxinu!ed
MINISTER WITHOUT PORTFOLIO Norman Wilson Bell Laboratories, 2C-529 600 Mountain Avenue Murray Hill, NJ 07974 (201) 582-2842 Idecvax,ihnp4I !research! norman
SEMINARS COORDINATOR Steven Stepanek Computer Science Dept. School of Eng. & Computer Science 18111 Nordhoff St. Northridge, CA 91330 (818) 885-2799 or 3898 ihnp4!csun !sgs
SIC-9
DEC COUNTERPART Gary Oden Digital Equipment Corporation Continental Blvd, MK02 Merrimack. NH 03054 (603) 884-5111 decvax! oden
VAX SYSTEMS SIG
SYMPOSIUM COORD., ASSISTANT David Cossey Computer Center Union College Schenectady, NY 12308
SESSION NOTES EDITOR Ken Johnson Meridien Technology Corp. P. 0. Box 2006 St. Louis, MO 63011
NEWSLETTER EDITOR Clyde Poole Univ. Texas/Austin Dept. of Computer Science Taylor Hall 2,124 Austin, TX 78712-1188 (512) 471-9551
LIBRARY WORKING GROUP Glen Everhart 25 Sleigh Ride Road Glen Mills. PA 19342
VAXcluster WORKING GROUP Thomas Linscomb Computation Center University of Texas Austin, TX 78712
NETWORK WORKING GROUP Bill Hancock Dimension Data Systems, Inc. P.O. Box 13557 Arlington, TX 76094-0557
MicroVAX WORKING GROUP Ray Kaplan Pivotal, Inc. 6892 East Dorado Court Tucson, AZ 85715-3264 (602) 886-5563
SYSTEM IMPROVEMENT REQUEST (CORE) Mark D. Oakley Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2669
MULTIPROCESSOR WORKING GROUP Eugene Pal U.S. Army CAORA (ATORCATC) Fort Leavenworth, KA
PRE· SYMPOSIUM SEMINAR COORD. HISTORIAN Jeff Jalbert JCC P.O. Box 381 Granville, OH 43023
PRE-SYMPOSIUM SEMINAR COORD. (ACTING) June Baker Computer Sciences Corp. 6565 Arlington Blvd. Falls Church, VA 22046
FIELD SERVICE WORKING GROUP Dave Slater Computer Sciences Corp. 6565 Arlington Blvd Falls Church. VA 22046
LARGE SYSTEMS INTEGRATION WORKING GP Leslie Maltz Stevens Institute of Tech. Computer Center Hoboken, NJ 07030
VOLUNTEER COORDINATOR Elizabeth Bailey 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35661
COMMERCIAL WORKING GROUP Bob Boyd GE Microelectronics Center P.O. Box 13409, MS7T3-01 Research Triangle Park, NC 27709-3049
SECURITY C. Douglas Brown Sandia National Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185-5800
MIGRATION AND HOST DEVELOPMENT VAXintosh WORKING GROUP
Jim Downward KMS Fusion Incorporated P.O. Box 156D Ann Ari ·or. Ml 48106
REAL TIME/PROCESS CONTROL Dennis Frayne McDonnell Douglas 5Wl BolsaAvenue Huntington Beach, CA 92646
Larry Robertson Bear Computer Systems 56512 Case Avenue North Hollywood, CA
INTERNALS WORKING GROUP Carl E. Friedberg Seaport Systems. Inc. 165 William Street, 9th Floor New York, NY 10038-2605
COMMUNICATIONS ASSISTANT David L. Wyse Professional Business Software 3680 Wyse Road Dayton, OH 45414-2539
CAMPGROUND COORDINATOR Kirk Kendrick Shell Oil Co. 333 Highway G, MS D-2146 Houston. TX 77082-8892
PAST CHAIR Marge Knox Computation Center University of Texas Austin, TX 78712
SYSTEM MANAGEMENT Steve Tihor 251 Mercer Street New York, NY 10012
ADVISORS Joseph Angelico U.S. Coast Guard Detachment National Data Buoy Center NSTL Station, MS 39529-6000
Art McClinton Mitre 1820 Dolley Madison Blvd. McLean, VA 22102
Al Siegel Battelle Memorial Institute 505 King Avenue Columbus. OH 48201-2693
CHAIR (CORE) Susan T. Rehse Lockheed Missiles & Space Co. 0/19-50, B/101, P.O. Box 3504 Sunnyvale, CA 94088-3504
VICE-CHAIR (CORE) WORKING GROUP COORD.
Ross Miller Online Data Processing Inc. N 6:W Hamiiton Spokane, WA 99202
SYMPOSIA COORD. (CORE) Jack Cundiff Horry-Georgetown Tech. College P.O. Box 1966 Conway, SC 29526
COMMUNICATION COORD. (CORE) David Wyse Professional Business Software 3680 Wyse Road Dayton, OH 45414 (513) 890-1800 x223
LIBRARIAN Joseph L. Bingham Mantech International 2320 Mill Road Alexandria, VA 22314
LUG COORDINATOR (CORE) Dave Schmidt Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232
STORE REPRESENTATIVE G. Beau Williamson Rockwell International 1200 N. Alma Road MIS 406-280 Richardson, TX 75081 (214) 996-5547
SIC-10
SUBMITTING ARTICLES TO HARD NEWS
The purpose of HARD NEWS, the HMS SIG newsletter, is to serve as a forum to share information related to DEC hardware with the members of the SIG. As such, the existence of the newsletter is entirely dependent on your contributions. If you have an HHK item, a better or safer way to do something, product news, a tutorial article of general interest, etc., we would like to publish it in the newsletter. We hope that HARD NEWS will be published at
least six times a year.
You can submit material to the editor, Carmen Wiseman, or to the HMS SIG chair, Bill walker. We can accept submissions in a wide variety of formats:
o Items can be sent to the editor on VMS-format RX50s, TK50 cartridges, or IBM PC format 5 1/4" floppies. The SIG chair prefers RT-11 floppies but can handle any reasonable media.
0 Hard copy, like cash, is always
acceptable.
Camera-ready copy will save us a lot of typing, but we
don't insist on it. You can also use the Hardware
Submission Form in the "Questionnaires" section of the
combined SIGs Newsletters.
o Those of you with access to DCS can send things to WALKER or WISEMAN. DCS is usually checked on a daily basis.
o You can reach the SIG chair on CompuServe as "Bill Walker 71066,24" or via EasyLink mailbox 62752448 or MCI Mail account 333-1675. You can reach the editor via EasyLink mailbox 62960090 (be sure to say ATTN: or TO: Carmen Wiseman somewhere in the body of the
message).
If you have anything to submit, send it! If it is a mess, EUt we can read it, we wilr-get it into the newsletter somehow. Finally, if you have any questions about submitting material, call one of us. The telephone numbers are listed below.
Contributions can be sent to:
William K. Walker
Monsanto Research Corp.
OR
P.O. Box 32 A-152
==
Miamisburg, OH 45342
(513) 865-3557
(work)
(513) 426-7094/0344 (home)
Carmen D. Wiseman Digital Review Prudential Tower, Suite 1390
800 Boylston Street Boston, MA 02199 (617) 375-4361 (work)
$UB-1
Ask the WOMBAT WIZARD Submission Form.
To submit a problem to the WIZARD, please fill out the form below and send it to:
WW Editor, Philip A. Naecker Consulting Software Engineer 3011 North Mount Curve Avenue Altadena, CA 91001 USA
OECUS Membership No.
Please following the following guidelines when submitting support material:
1. If you are trying to demonstrate a method or a concept, please simplify the procedures, records, and other informatipn to the shortest form possible. 2. Annotate your attachments. Simple comments or hand-written notes ("Everything worked until I added this statement.") go a long way toward identifying the problem. 3. Keep an exact copy of what you send. And number the pages on both copies. But send everything that is related to your question, even remotely. 4. If you would like a direct response or would like your materials returned, please don't forget to include a stamped, self-addressed envelope large enough to hold the materials you send.
ou-1
DATATRIEVE/4GL SIG Product Improvement Request Submission Form
Submit tor: Address:
PECUS Membership Number: Firm:
Phone:
Product or Products:
How to write a PIR
' II
A PIR should be directed at a specific product or group of
products. Be sure to give the full name of the product(s) and
version numbers if applicable.
Describe the functionality you
would like to see in as complete terms as possible. Don't assume
that the PIR editors or software developers know how it is done
in some other software product - state specifically how you want
the software to function. Provide justification of your request
and give an example of its use. If you can, suggest a possible
implementation of your request.
Abstract: (Please limit to one or two short sentences.)
Description and Examples: (Use additional pages as necessary.)
[Put my name and address on reverse side, thus:]
FIR Editor, Philip A. Naecker Consulting Software Engineer 3011 North Mount Curve Avenue Altadena, CA 91001 USA
OU-3
*H M S S I G* HARDWARE SUBMISSION FORM -- A SIG INFORMATION INTERCHANGE Message
Contact Name
Address
Telephone Type of equipment
SUBMIT ANY TYPE OF HARDWARE PROBLEMS AND/OR FIXES.
SEND TO:
William K. Walker
Carmen D. Wiseman
Monsanto Research Corp. OR Digital Review
P.O. Box 32 A-152
Prudential Tower, Suite 1390
Miamisburg, OH 45342
800 Boylston Street
Boston, MA 02199
ou-5
Languages & Tools SIG - Masters Directory
16
MASTERS APPLICATION
:N'anie: - - - - - - - - - - - - - - - - - - - - Title - - - - - - - - - - - - - - - - - - - Co!llpany: -----------------------------------------~
Address: -------------------------------------------
>~~~~~~~~~~~~~~~
:N'etwork Address: -----------------Date: - - - - - - - - - - - - - - - - -
The Languages & Tools SIG has established the designation "LANGUAGES AND TOOLS MASTER", to be applied to selected, qualified people willing to share their expertise in various subjects with others. Masters are people who are knowledgeable enough in one or more languages or tools to be comfortable answering questions about them. The qualifications of an L&T Master are: expertise in a specific area, a willingness to have his/her name published as a Master,
and a willingness to volunteer services in different ways. Each product may have several Masters, and there is an overall Masters Coordinator who is a member of the L&T Steering Committee.
Masters are asked to serve other users (and, under some circumstances, DEC), as a resource on products within their competence. In addition to being listed in the L&T Masters Directory (published in the newsletter) as available for
occasional telephone consultation, Masters may act as 'Doctors' at Symposium Clinics, present Symposium sessions on the products of interest to them, field test products, interact with DEC product managers when appropriate, or act as a
reference for a product for Digital salespeople. Especially on mature products, the SIG is anxious for knowledgeable users to offer product tutorial sessions at Symposia, and Masters can be of great help here. At Symposia, Masters will wear an
identifying button bearing the legend "Ask Me About....." and the name of the language or tool in which he/she specializes.
If you'd like to serve as an L&T Master, please mark the products on which you are willing to answer questions with
an "M" (for Master). Please mark any other products running at your site with an "A" (for "also running") to provide
users with a broader picture of your facilities. (Although not an L&T product, Mumps is included here at the request of the Mumps SIG as a service to Mumps users). You may request removal of your name from the Masters Directory at any
time, although you may continue to be listed for a month or two, because of publication lead times.
H I am qualified to act as an L&T Master for the following products:
DPaosbcual'
Bliss Basic
CMS MMS
TPU EVE
c
Ada1
Test Manager Runoff & DSR
D Mumps
[j Fortran Document
Cobol Dibol
LSE SCA
EDT TECO
APL RPG
1F.;X & :U.TEX
Cobol Generator
VAX Notes
Emacs
PCA
PL/I
Scan
Software Project Mgr
Briefly describe your experience with those you checked. - - - - - - - - - - - - - - - - - - - - - - - -
How long have you held your present p o s i t i o n ? - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Are you able to attend at least one symposium each year? - - - - - - - - - - - - - - - - - - - - - - - Users are encouraged to seek assistance with products by calling appropriate Masters listed in the Directory. As a Master, your name and telephone number will be published in the Masters Directory, and users will call on you for limited help from time to time. Please check, below, any additional activities you might do:
D Field-test new versions of your product at your work site. D Provide feedback on the product when needed by its DEC product manager.
D Act as a reference for the product at the request of Digital Sales or Marketing people.
Mail to: Dena Shelton, L&T SIG Masters Coordinator, Cullinet Software, Inc., 2860 Zanker Road, Suite 206, San Jose, CA 95134.
1 Ada is a trademark of the DoD
OU-7
Languages & Tools SIG
WISHLIST QUESTIONNAIRE
:Nanie: ___________________ Title------------------Conipany: --------------------------------------Address=----------------------------------------
)-~~-~-~~~~~~~~-
:Network Address: ----------------Date: ----------------
The Languages & Tools SIG is principally concerned with the DEC and public domain software products listed below. H your request directly involves one of these products, please check which one (if you have more than one request, please use a separate form for each):
Debug Pascal Fortran Document VAX Notes
Bliss Basic Cobol Dibol Emacs
CMS MMS LSE SCA PCA
TPU EVE EDT TECO PL/I
c
Ada1 APL RPG Scan
Test Manager Runoff & DSR
TEX & JI.TEX
Cobol Generator
Software Project Mgr
H your request or suggestion doesn't relate to one of the products listed above, check which one of the following
Language & Tools SIG topics it concerns:
~ I\'ewsletter Masters Program Information Folder
§Symposium Sessions Working Group Activities SIG Tape
§Pre-Symposi.um Seminars Session Notes DECl}S Store Item
Other L&T SIG topic:
i :
Wish List Request-brief description: - - - - - - - - - - - - - - - - + - - - - - - - - - - - - -
Complete description-please explain your request thoroughly; don't assume we know details of other products or services; give e x a m p l e s . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mail to: Shava :Nerad, LkT Wishlist Coordinator, MIT, 7'1 Mass Ave. W91-219A, Cambridge, MA 02139; (617)25S-74S8
1 Ada ia a trademark of the DoD
OU-9
DRTRGRRffi
DAT AGRAMs ere short messages, comments, requests, or ens we rs thet ere published in NETwords. Please fill in the sections below end send the DAT AGRAM to:
JUDI MANDL UCONN HEALTH CENTER 263 FARMINGTON AVENUE, BLDG. #19 FARMINGTON, CT 06032
Your NBme:
Address:
Telephone:
If this 1s o reply to a previous DATAGRAM .. whot ' ? _
i
i
nu-11
Place
Stamp, I
Here '
JUDI MANDL UCONN HEALTH CENTER 263 FARMINGTON AVENUE, BLDG. #19 FARMINGTON, CT 06032
Fold Here
()U-12
i I
· I
Name (optional)
. I
Address (optional)
RT-11 WISH LIST SURVEY
DECUS Number (optional) ---------------------------------------
1.1 1.2 1.3 1.4 1.5 1. 6 1. 7a 1. 7b 1.8 1. 9a 1. 9b 1. 9c 1. 9d 1.10 1.11 1.12 1.13 1.14 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24
3.1 3.2a 3.2b 3.2c 3 .2d 3.2e 3.3a 3.3b 3.3c 3.3d 3.4a 3.4b 3.4c 3.5a 3.5b 3.6a 3.6b 3.6c 3.6d 3.6e 3.6f 3.6g 3.7a 3. 7b 3. 7c 3. 7d 3.7e 3. 7f 3. 7g 3. 7h 3.7i 3.7j 3.7k 3.71 3. 7m 3.7n 3. 7o 3.7p 3. 7q 3. 7r 3.7s 3.7t
3.7u 3. 7v 3. 7w 3. 7x 3. 7y 3.7z 3.7aa 3.7bb 3. 7cc 3. 7dd 3.7ee 3.8a 3.8b 3.8c 3.9a 3.9b 3.9c 3.9d 3.9e 3.9f 3.9g 3.9h 3.9i 3.9j 3.9k 3.lOa 3.lOb 3.lOc 3.lOd 3.lOe 3.lOf 3.lOg 3.lOh 3.lOi 3.lOj 3.lOk 3.101 3.lOm 3.lOn 3.lla 3.llb 3.12
3.13a 3.13b 3.13c 3.13d 3.14 3.15 3.16 3.17a 3.17b 3.17c 3.17d 3.17e 3.17f 3.18 3.19a 3 .19b 3.19c 4.1 4.2a 4.2b 4.3 4.4a 4.4b 4.5a 4.5b 4.6 4.7a 4.7b 4. 7c 4.7d 4.7e 4.7f 4.7g 4.7h 4.7i 4.7j 4.7k 4.71 4. 7m 4.7n 4.70 5.la
5.lb 5.2a 5.2b 6.1 6.2a 6.2b 6.2c 6.2d 6.3 6.4a 6.4b 6.4c 6. 4d 6.5 6.6a 6.6b 6.6c 6.6d 6.7 6.8a 6.8b 6.8c 6.8d 6.8e 7 . 8. 9.1 9.2a 9.2b 9.3a 9.3b 10.1 10.2 10.3
Send Responses to: RT-11 Wish List Survey Multiware, Inc. 2121-B Second St. Suite 107 Davis, CA 95616
nu-13
I I I
c
DECUS
DECUS U.S. CHAPTER SUBSCRIPTION SERVICE SIGS NEWSLETTERS ORDER FORM
(U.S. Members Only)
As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS monthly publication, SIGs Newsletters. You also have the opportunity to subscribe to the Symposia Proceedings which are a compilation of the reports from various speakers at the U.S. National DECUS Symposia.
· No Purchase Orders will be accepted. ·The order form below must be used as an
invoice. , ·All checks must be made payable to DECUS.
·All orders MUST be paid in full. , ·Minimum of $25.00 for orders placed via a
credit card.
·No refunds will be made. ·The address provided below will be used for all DEC US
mailings; i.e. Membership, Subscription Service and Symposia. ·SI Gs Newsletters Price is for a one-year subscription beginning
the month following receipt of payment.
Name_ 1 Company __ _
Address __ __
DEC US Member# __
I City --------------' Telephone# ( ____ )_ __ _ __
State
Zip _
Subscription Service Offering
! SIGs Newsletters Spring '87 Proceedings (SP7)
: Fall '87 Proceedings (FA7) Spring '88 Proceedings (SP8) Fall '88 Proceedings (FAS)
Unit Price
$35.00 15.00 15.00 15.00 15.00
Quantity
Total
Total Amount
$ -
0 0 0 0 MASTERCARD
VISA
DINERS CLUB/CARTE BLANCHE"'
AMERICAN EXPRESS
Credit Card# _ _ _ _
_ _ _ _ Expiration Date
I understand that there will be no refunds even if I decide to cancel my subscription.
Signature _
Badge# ________ _ Cost Center Mgr. Name ___
FOR DIGITAL EMPLOYEES ONLY
Cost Center _ Cost Center Mgr. Signature _
MAIL TO: Subscription Service, DEC US ( BP02), 219 Boston Post Road, Marlboro, MA 01752·1850, (508) 480·3659. As of July 1, 1988 the phone number will be (?08) 480·3659
Check Number Amount$ __
FOR DECUS OFFICE ONLY
Bank Number
S&M-1
[Q] DECUS U.S. CHAPTER APPLICATION FOR MEMBERSHIP
DECUS
D New Membership D Update to current membership profile
Current DECUS Member.# _ _ _ _ _ _ -~-
Please provide a complete mailing address, include zip code in accordance with postal regulations for your locality.
Are you an employee of Digital Equipment Corporation? D YES D NO
NOTE: Please print clearly or type!
(First)
(Middle lnitia~
(Last/Family Name)
City/Town/State/Zip: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Telephone: Home (
Work(
How Did You Learn About DECUS? Please Check Applicable Item.
10 ANOTHER DECUS MEMBER 20 SYMPOSIA 80 DECUS CHAPTER OFFICE 100 DIGITAL STORE
:
40 DIGITAL SALES 50 HARDWARE PACKAGE 60 SOFTWARE PACKAGE 12 0 ADVERTISING
130 LOCAL USERS GROUP 140 SPECIAL INTEREST GROUP
70 SOFTWARE DISPATCH !Digital Newsiette~
Do you wish to be included in mailings conducted by Digital (for marketing purposes etc.?) DPermission DRefusal
Type Of Digital Hardware Used: Please Check Those Applicable To You.
200 DECMATE
520 LSl-11
21 0 PROFESSIONAL
50 WP&8
820 DECSYSTEM-10
30 PDP.8 FAMILY
220 RAINBOW
51 0 WP&11
830 DECSYSTEM-20
· I
500 PDP.11 FAMILY
540 VAX FAMILY
:= Major Operating Systems? Languages Used: Please Check Those Applicable To You.
10 ADA 20 ALGOL 50 APL
260 CORAL-66
280 cos
340 DATATRIEVE
470 FOCAL 480 FORTRAN 51 0 GAMMA
670 OS/8 680 PASCAL 720 PL-11
1090 RT-11 970 TECO 700 TOP&10
70 BASIC
17 0 BLISS
190 c
350 DBMS 380 DECNET 430 DIBOL
1100 IAS 530 IQL 580 MACRO
920 RPG 81 0 RSTS/E 830 RSX
71 0 TOPS-20 111 0 ULTRIX/UNIX 1040 VMS
220 COBOL
450 D0&11
650 MUMPS
91 0 RMS
1070 WP&8
S&M-3
Type Of Business(Environment)/Computer Applications Please Check That Which Best Describes Your Businesw Application.
210 ACCOUNTANCY
10 EDUCATION/PRIMARY
230 NUMERICAL CONTROL
70 BANK
20 EDUCATION/SECONDARY 680 OEM-COMMERCIAL
640 BUSINESS/COMMERCIAL
61 0 EDUCATION-TECHNOLOGY 780 OEM-TECHNICAL
740 BUSINESS/INFORMATION SYSTEMS
30 EDUCATION/UNIVERSITY 560 PHYSICAL SCIENCES
570 CHEMISTRY
670 ENGINEERING
200 RESEARCH/DEVELOPMENT
540 CLINICAL LABORATORY
650 FINANCE/ ACCOUNTING
100 RETAIL
630 COMPUTATION
770 GOVERNMENT
730 SOFTWARE DEVELOPMENT
11 0 CONSUMER ELECTRONICS
750 GRAPHICS
530 TELECOMMUNICATIONS
180 CONSULTANT
40 HOSPITAL
190 TELEPHONE/UTILITIES
720 DATA ACQUISITION
620 INDUSTRIAL
510 TIMESHARING
520 DATA COMMUNICATIONS
550 LABORATORY/SCIENTIFIC 800 TRAINING/INSTRUCTION
130 DATA PROCESSING SERVICES
i 71 0 DATA REDUCTION
r·D· 170 DIGITAL EMPLOYEE-ENGINEERING DIGITAL EMPLOYEE-MARKETING 160 DIGITAL EMPLOYEE-SERVICE GROUP
140 LIBRARY 580 LIFE SCIENCES 700 MANUFACTURING 790 MARKETING 590 MEDICAL RESEARCH
660 TYPESETTING/ PUBLICATION
600 EDUCATIONAL ADMINISTRATION
60 MILITARY INSTALLATION
I·· Special Interest Groups ( SIGs) Enrollment I Wish To Participate In The Following DECUS U. S. Chapter Special Interest Groups.
· 30 ARTIFICIAL INTELLIGENCE
70 BUSINESS APPLICATIONS
I 20 COMMERCIAL LANGUAGES
··· 60 DATA MGMT. SYSTEMS
11 0 HARDWARE AND MICRO 350 IAS 270 LARGE SYSTEMS 160 L& T
360 PERSONAL COMPUTER 180 RSTS/E 170 RSX 190 RT-11
·= 31 0 DAARC (LABS)
··= 50 DATATRIEVE/4GL ! 80 EDUSIG
140 MUMPS 150 NETWORKS 340 OFFICE AUTOMATION
320 SITE MGMT. & TRNG 210 UNISIG 260 VAX
100 GRAPHICS APPLICATIONS
Job Title/Position - Please Check:
10 CORPORATE STAFF 20 DIVISION OR DEPARTMENT STAFF 30 SYSTEMS ANALYSIS 40 APPLICATIONS PROGRAMMING
i· 50 SYSTEMS ANALYSIS/PROGRAMMING
···· 60 OPERATING SYSTEM PROGRAMMING
c·· 70 DATABASE ADMINISTRATION
:· 80 DATA COMMUNICATIONS/TELECOMMUNICATIONS
90 COMPUTER OPERATIONS 100 PRODUCTION CONTROL
101 0 CORPORATE DIRECTOR OF DP/MIS 1020 ADMINISTRATIVE ASSISTANT 1030 TECHNICAL ASSISTANT 1040 SERVICES COORDINATOR 1050 MANAGER 1060 ANALYST 1070 PROGRAMMER 1080 DATABASE MANAGER 1090 DATABASE ADMINISTRATOR 1100 MANAGER OF DP OPERATIONS
Citizen of The United States of America? 0 YES 0 NO Country:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
Signature:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Date:_ _ _ _ _ __
Forward To:
DECUS U. S. Chapter Digital Equipment Computer Users Society Membership Processing Group 219 Boston Post Road, BP02 Marlboro, MA 01752-1850 Phone: (617)480-3418 DTN: 8-296-3418
S&M-4
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
NOTES
Printed in the U.S.A.
"The Following are Trademarks of Digital Equipment Corporation"
CI DATATRIEVE DEC DECmate DECnet DECserver FOCAL IAS (et.al) LAN Bridge LN03 Micro/RSX
Micro VMS PDP-11 PDP-11/24 (et. al) P/OS RALLY RSX RSX-llS RSX-llM-PLUS RSTS/E RT-11 TOPS-10
TOPS-20 ULTRIX-32 UNIBUS VAX VAXcluster VAXstation VAXNMS VMS VT VT50 (et.al)
CopyrightlDDECUS and Digital Equipment Corporation 1988 All Rights Reserved
The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation or DECUS. Digital Equipment Corporation and DECUS assume no responsibility for any errors that may appear in this document.
It is assumed that all articles submitted to the editor of this newsletter are with the authors' permission to publish in any DECUS publication. The articles are the responsibility of the authors and, therefore, DECUS Digital Equipment Corporation, and the editor assume no responsibility of liability for articles or information appearing in the document. The views herein expressed are those of the authors and do not necessarily express the views of DECUS or Digital Equipment Corporation.
AT&T is a trademark of American Telephone & Telegraph Company; IBM is a registered trademark of International Business Machines Corporation; RMS is a trademark of American Management Systems, Inc.; TSX-PLUS is a trademark of S&H computer Systems, Inc.; UNIX is a registered trademark of American Telephone & Telegraph Company.
Production Staff: Beverly Welborne: Communications Committee Chair R.E. Center Frank Borger: SIG Publications Chair Michael Reese Hospital Judy Mulvey: Publications Manager DECUS Judy Tessier: Phototypographer/Graphics Designer DECUS
Circulation: 6135
________________________ ,
..-......o....·..·..
nZo·8··_·'.Q....C,._.....S....:..:..
................. .-..... rZsH·C-,-4.:. "'"*"">a""a' ·
'"O:Sf'IC:S
·
,..,er·~· ~,...
z;"s'0·.0
..... .3,1..:., I%'ll
... ..···.p..
n
0
"'
··0.....
14
0
Z'
STATUS CHANGE
Please notify us immediately to guarantee continuing receipt of DECUS literature. Allow up to six weeks for change to take effect.
) Change of Address ) Please Delete My Membership Record
(I Do Not Wish To Remain A Membel'.) DECUS Membership No: _______
Name:~-----------~ CompanY.------~------
1 Address: _ _ _ __
State/Country. ____________ Zip/Postal Code:
Mall to: OECUS - Attn: Subscription Service
219 Boston Post Road, BP02
Marlboro, MaSsa.chusetts 01752-1850
111n:s111·:r>
0 01110.~ ..·~:!;
"2 . 330.-·CD><
(\I iD iii" ;:,ol::Q::::3
-- c:--·:C:Dr1"-1Il1l1=
I I
USA.
ci 2.
iii:ia:_i-o~-c~r:c;o·
I
<U<\Ili-~ii-n:c:1· :-:1
-· 0
-
m
"- ·.O<?am. 00:::91.0~"
I I
I
L-----------------------~
s:~o~
l>coG>o
~:::0OClJ) >-Iccn
-o0:::oco-Z-ntoc·mccc:cnno
s: s: "'O "'O 0
)> 0 :::0
ocn
....... -I
mz
-:o::!
"~" ~::0 o-Iz0
~oOcn
roex>- ~ m
·0O1 -o-oc<:::o 10\-lm-1O- :::om
(/)
0 0
m ~
~[O]
"~ll ~0
c Ill
!:nc
g =3i:~"ll.,~,"ll:~:0
0.Z
O
:-:0f
O
-G>I>>m-f
0o)>-_ m
.~---
--~·
---
Acrobat 11.0.23 Paper Capture Plug-in