~~;~;: DECUS U.S. CHAPTER SI Gs NEWSLETTERS

180
1961-1986 DECUS U.S. CHAPTER B Foture SI Gs NEWSLETTERS APL SIG ........................................................................................ APL ARTIFICIAL INTELLIGENCE SIC .................................................................. Al BUSI NESS APPLl.CATIONS SIC .................................................................. BA COMMERCIAL LANGUAGES SIG ................................................................ CL DAARC SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAR DATA MANAGEMENT SIG ..................................................................... OMS DATATRIEVE SIG............................................................................... DTR EDUSIG ....................................................................................... EDU GRAPHICS SIG ................................................................................ GRA . HARDWARE MICRO SIG ...................................................................... HMS IAS SIG ......................................................................................... IAS LANGUAGES AND TOOLS SIG.................................................................. L& T LARGE SYSTEMS SIG............................................................................ LS MUMPS SIG .................................................................................. MMP NETWORKS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NTW OFFICE AUTOMATION SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA PERSONAL COMPUTER SIG · .................................................................... PC RSTS SIG....................................................................................... RST RSX SIG ........................................................................................ RSX RT SIG ........................................................................................... RT SITE MANAGEMENT & TRAINING SIG .......................................................... SIT UNISIG ......................................................................................... UNI VAX SYSTEMS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX LIBRARY INFORMATION SECTION ............................................................. LIB "HOW TO" SUBMIT AN ARTICLE ... GROUP FORMS .......................................... HOW QUESTIONNAIRE SECTION ..................................................................... OU APRIL 1986 Volume I, Numbers

Transcript of ~~;~;: DECUS U.S. CHAPTER SI Gs NEWSLETTERS

1961-1986

~~;~;: DECUS U.S. CHAPTER B Foture SI Gs NEWSLETTERS APL SIG ........................................................................................ APL

ARTIFICIAL INTELLIGENCE SIC .................................................................. Al

BUSI NESS APPLl.CATIONS SIC.................................................................. BA

COMMERCIAL LANGUAGES SIG ................................................................ CL

DAARC SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAR

DATA MANAGEMENT SIG ..................................................................... OMS

DATATRIEVE SIG............................................................................... DTR

EDUSIG ....................................................................................... EDU

GRAPHICS SIG ................................................................................ GRA . HARDWARE MICRO SIG ...................................................................... HMS

IAS SIG ......................................................................................... IAS

LANGUAGES AND TOOLS SIG.................................................................. L& T

LARGE SYSTEMS SIG............................................................................ LS

MUMPS SIG .................................................................................. MMP

NETWORKS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NTW

OFFICE AUTOMATION SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA

PERSONAL COMPUTER SIG ·.................................................................... PC

RSTS SIG....................................................................................... RST

RSX SIG ........................................................................................ RSX

RT SIG ........................................................................................... RT

SITE MANAGEMENT & TRAINING SIG .......................................................... SIT

UNISIG ......................................................................................... UNI

VAX SYSTEMS SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX

LIBRARY INFORMATION SECTION ............................................................. LIB

"HOW TO" SUBMIT AN ARTICLE ... GROUP FORMS .......................................... HOW

QUESTIONNAIRE SECTION ..................................................................... OU

APRIL 1986 Volume I, Numbers

GENERAL TABLE OF CONTENTS

SECTIONS PAGE NO.

APL SIG . Steering Committee Listing APL-i

ARTIFICIAL INTELLIGENCE SIG . Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Al-i . SIGnificant Meeting ............................................................................. Al-1

BUSINESS APPLICATIONS SIC Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BA-i

. Editorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BA-1

. Business Applications Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BA-3

COMMERCIAL LANGUAGES SIG . Steering Committee Listing ...................................................................... CL-i . BASIC Magic .................................................................................... CL-1

DATA ACQUISITION ANALYSIS, RESEARCH AND CONTROL SIG . Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAR-i

DATA MANAGEMENT SIG . Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DMS-i . Calling All Hands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DMS-1

DATATRIEVE/4GL SIG Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTR-i Chairman's Corner............................................................................... DTR-2 From the Editor's Pen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTR-2 DTR/4GL Sessions at Spring 1986 Symposia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTR-3 VAX-DATATRIEVE Internals ...................................................................... DTR-5 DATATRIEVE-11 to VAX-DATATRIEVE Conversion ................................................ DTR-12 Wombat Magic, Fall 1985, Part 111 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTR-20

EDUSIG . Steering Committee Listing EDU-i

GRAPHICS APPLICATIONS SIG Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GRA-i Report on the GAPSIG GKS Working Group ...................................................... GRA-1 Pre-Symposium Seminars on Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GRA-2 Report on the 21st Meeting of X3 H3.............................................................. GRA-3 Graphics Application SIG Activity in Dallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GRA-9

HARDWARE MICRO SIG . Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HMS-i

IASSIG Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAS-i Curley's Corner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAS-1 Letter from the Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAS-4 IAS Users in Silicon Valley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAS-5 Thank you, Ken Guralnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAS-6 Meet Your Steering Committee................................................................... IAS-7 Getting Started with Macro-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAS-9

LANGUAGES AND TOOLS SIG . Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L& T-i

LARGE SYSTEMS SIG Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LS-i Chairperson's Article............................................................................. LS-1 One User Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LS-2 Doctor Tops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LS-4

MUMPS SIG . Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMP-i

NETWORKS SIG Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NTW-3

. DATAGRAM ..................................................................................... QU-9

OFFICE AUTOMATION SIG Steering Committee Listing ...................................................................... OA-i From the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA-1 OA SIG Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA-2 First Time Attendee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA-2 Symposium Session Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA-3 Call for Tape Submissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA-4 OA SIG SIR Submission Form .................................................................... QU-7

PERSONAL COMPUTER SIG . Steering Committee Listing

RSTS SIG

PC-i

. Steering Committee Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RST-i

RSX SIG Steering Committee Listing ..................................................................... . From the Editor ................................................................................. . The RSX System Manager ...................................................................... . Modifying PRl's Print Buffer .................................................................... . Correction to FORTRAN-77 OTS for l/D Tasks Using Virtual Arrays ............................... . User Written Drivers and RMS Block Locking .................................................... . SEE Utility ...................................................................................... . How to Use the RSX Full-Duplex Terminal Driver with Terminals .................................. .

RTSIG Steering Committee Listing ..................................................................... . SECN OS Subroutine by John Crowell ........................................................... . Announcing BASIC-PLUS/RT-11 ................................................................ . DISCRETE for the DEC US Library ............................................................... . Auto Sysgen on a Floppy ........................................................................ . DECUS U.K. Reponse to VAX/RT Position Paper ................................................. .

SITE MANAGEMENT AND TRAINING SIG . Steering Committee Listing ..................................................................... .

UNISIG

RSX-i RSX-1 RSX-3 RSX-7 RSX-8 RSX-11 RSX-12 RSX-14

RT-i RT-1 RT-4 RT-5 RT-11 RT-14

SIT-i

. Steering Committee Listing ...................................................................... UNl-i

VAX SYSTEMS SIG Security Hole in VMS 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX-3 Editor's Workfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX-4 A Concern about Security and DZ Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX-5 A User's Concern about Security and DZ Ports.................................................... VAX-8 European DECUS Question and Answer Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX-13 VAX System SIG Committee List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX-61 IN PUT/OUTPUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAX-64 INPUT/OUTPUT Submission Form ............................................................... QU-1 System Improvement Request Submission Form.................................................. QU-3 VAX Systems SIG Spring 1986 SIR Ballot. ........................................................ QU-5

LIBRARY . New Library Programs Available LIB-1

HOW TO SUBMIT AN ARTICLE .. ORDER FORMS SECTION How to Submit An Article......................................................................... HOW-i

. Article Submission for HMS ...................................................................... HOW-1

. Subscription Service Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HOW-3

. Membership Application Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HOW-5

QUESTIONNAIRE SECTION lnpuVOutput Submission Form................................................................... QU-1 System Improvement Request Submission Form.................................................. QU-3 VAX System SIG Spring 1986 SIR Ballot .......................................................... QU-5 OA SIG SIR Submission Form .................................................................... QU-7 DATAGRAM ..................................................................................... QU-9

,- , , t-, / () f._3 4-)()) b) ( ;_ ; X ! \-a.._ n l E _Vt>\ a '0 I T<H 7 fr "'.j. u WC> tc f-t--+.>_ -OAE<C[•ErGH I J K LMMOf""llF:S TUVW::·r"Z{-i}$,..Ao9 ! flllll.,:s: A .o,Al!-Cr~c;;f\'-tl!,JI( !::~tfOf:<;.ll'>~ T~yw:_: 1

J••~••aHR•oDl•J.i;;-)<!=>]vA#+.+,/0123456789([;x:\-a ... nle_V6\u'01Te•?fr"'.i.uw~tLf-t- ... !-OAE<CDEFGHIJKLMMOra~STUVW::YZ{-i}t ...... e:f~\~noAB~DE[GH) L~UQEgB§!YY~~r;a•~n••eBll•oDm • .;i.i;;-)<!=>]vA~+,+,/0123456789([;x:\-u ... nLE_VA\•'DITB•7rr"'.i.uwe>tcf-t--+!-OAE<CDEFGHIJKLMl<OPOR5TUVWKY~{ ~} ....... 9; -:rft&le!~£~gEQt!!"1~!::~UQEQ!'::~ !':!:,.1w:n;c:it•C11P•eBll•oDm • .;i.i;; - ) < -~ "-) ] v A~.;.,+. 101. 23456 7139 ( [ ; x : \-a .L n LE -.. '17A I u • DI TIH 7 r r .... uw l tc f-t--H -OAE<CDEF· Ml ior nr.'

XYZ{-i}$ ...... S:r~~:EA&l!~£~g[Qtl!~~!::~HOrgB~!YY~Ll!;c:i••CJ~•ee11•0Dm • .;i.~-)<i=>]vA-~,+./01234567139([;x:\-a ... nle_'176\•'0IT0•7fr"'.i.uw~t OAE<CDrr• IJKLMHOPORSTUVWHYZ{-i}$1"•e:r~i.,:s;ft&l!~£~~~~UI~~!::~UQEQB§!Y~~Ll!;a••C1~•eee•oDmT~~~)<i=>JvA-~,+./0123456789([;x:\-a ... nLE_V6\u 7 rr"'••··-c~~ ... !-OAE<CDEFGHIJKLMMOPORSTUVWKYZ{-i}$ ...... B!f~i.,IA&1a,cQ~E§t!!~~!::~UQEgB§!Y~~Ll!;c:i••n$•aDR•oDm.J.~-,<!=>]vA-+,+,/0123456789([ Lill • .,,. '01TID*?fr•tuw::.tcf-t-~!-OAE<CD~~~UT.JKLMMOPORSTUVWKYZ{-i}$1"•8!fl!l~%AQ8~£~~E~t!!~!!::~UQEQB§!YY~UX~U••n••eE1e•oOm.:21.-)<i=>]vAI+• 3~5678~ ; x: \ -u ... n LE - '96 I 0 I a I Te•?f r "'"' ... H-~!-OAE<CDEFGHI JllLMMOr·of.:STUVWH't"Z{-i}$1"•a: flili.,:s; A'1ie!~£~§;f.:§t!!J~!::~UQE!;rn21.:l.IV!!!U!;;atl-Ctl>•BElllVoOm ~. ) l ""~' +. /0123456789 ( [; x: \-a ... II LE - Ill a I Te• ?fr "'tUw::> tc f-t-~ !-OAE•C[•EF'"GHI JKL_MMOF"llf':STUVW:n·z{-i}$1"•9: rl!l~:r:A&ie~£~~[Qt!!~!l,,,fo1110F':gB§IY~~u !l;•eneopc• t9;i.i;;-)<!=>]vA_+,+,/0123456 ;x:\-a ... nle_'Q()\a'DITB•?rr•tuw::>tc•~~l-OAE<CDErGHI.JKLMMOPORSTUVWHYZ{~}$1"•9!rlll~:r:ft&le~£~~(Gli~~~b~~QEgE~!~_ :·::r;;a••o••eee••Dll•:2~ - ) ( i=)] Cl) +. /0123456 789 ( [; x: \-a .l. II l. E _ 'Q() I a • a I TIH? fr N.j. UW'.'.> t<= f-t-~ !-OAE<CDEF'"Gtil .JK LMl·IOF"OF:STUVW:·:"fZ{~}· ... -~l :fl!!'-t % ~A~l<C ~·c;r I~!b~LJQ(g8§!YY~H!;;c:l,.0.eBE l•J.i;-)<i=>]vAl+,+,/0123456789([;x:\-a.._nlE_'96\ 0 '0IT0*?fr•tuwe>tc~~ ... !-OAE<CDEF'"GHIJKLMMOPllf'~Tuvw .. t,{-i}$~ 'r•i..xftQ8!£~~E~~!~!b~LJQEQB§ • :!~a·•~tl>•BDS•oDll•:2~-,<!=>JvA_+,+,/0123456789([;x:\-a ... nLE_'96\a'OITO*?fr•,a.uwe>tc•~~!-OAE<CDEFGHI.JKLMl/Or'. UVW)O"Z{~}f1"•e: ,.. .. ~:s:ft&l8!£~~E ~ .!::~LJQEQ!:;?.H!~"!:~::G!;D••D••eDB••Dm.J.i;; - ) < J=)] vA-+, +. 10123456 789 ( [; x : \-a .J.. II l. E - Vil I a I a I Tlil*?f r •tu w.:i tc f-1-·+ t - OAE<r~ FGHI.JKLMHOPORSTUVWH'r"Z{~}fw Ill •i.,:cft&lf'.!~£~§;[Q!..l!JH·MllCll':;l:_!B§!YY~~!;;gt•CJIPH10fl••Dll•;.ii;-) < .i=> ]vA-+ ,+, /0123456789( [; X !\-U.J..lll E '961 ° '0 I Tflt7r r ~: w::.tc ~~~!-OA8Cl•EFGtiI .JKLMNOF· 1vw:o·Z{-i}f 1"•S ! r•i.,:1: ft &if'.!~£~!;;[91 I ~~~bMUQEQE§!Y~~t;!;;D••D••eBEl••Dll•J.i.. - ) < !::: > ] vA;il!""'' +, 10123456~9 ( [; X ! \-II.&. fl l ~~ 6 I 0 I a I TCD*'!'f r •tuw::.tc~~ ... .!.-OA ... "GHI.JKLMl·IOF"OF:STUVWH"fZ{~}$1"•EI: "~~'.I'. 11ie.A.~1~c.~g!:§t!!~!!::MLJQEgB§!YY~U:r;at•Ct1>•AIHl••Dm.;i.i;; •) < .i=) ]vA;>'+. +. 101234'.Jt! 9 ( [; x: \-a .J.. n LE - '96 I a I a I To•'!', "' •=>tc ~~ ... !-OABCDEFGHI .JK LMl·IOF"ORSTUVWH"t"Z{ ~}$.,•El: rlll~ I A~e!~£P.gEQt1! ~!!::~LJQEgB'.H!JY!!!lJ:r:~c:i•.t.l'l'll•ee··· ~.•oDlh;i ~ - ) ( !. - ) ~E -+.+,/01234S6789([;x:\-a.J..n ~ ,\a'OITO•?rr•tuw::.tc:•~ ... 1-0AE<CDEFGHI.JKLMMOPORSTUVWK1Z{~}$1"•El:r~~:rA&le!~£~g[Qtl!~!b~UQEQEbllJV~~!;at•l'lt1>•A[ll ·•Dll•;i.i; •) ( !=) ]vA-+, + ./0123 ~ :9 ( [ 'x: \-a .l.0 LE - Vt> I 0 I a I TO* ?r r "'tUwe>tc: ~~ .... !.-OAE<Cl•EFGHI .JKLMllOPORSTUVWH"t"Z{-i}$1"•9: rlll~:s:ft&le!~£~~EQ!:H,JI( l. Mo 'fll". "·.·­

U~WHI~a·•~··•BB••Dl•~i;;-) < 1 ~ -+.+,/01234S6789([;x:\-a ... nle_V6\a'OITO*Tfr•tuw~tc:f-t-~.!.-OAE<CDEFGHIJKLMHOPORSTUVWHTZ{-i}S~•El!lllli.,rAAA~d F§t:!l~~b~LJQEg!:;§!Y~!!!l:!!;;D••CJ• .,,. ••DIT;.ii;; •) < i= > ] vA-+ r +, /0123456 789 ( [; X ! \-<I .J.. n l E _Vt> I a '0 I TO*? fr "'t UWCJ tc: ~t- ... 1-0AE<CDEF'"GH I .JK LMNOF·ar.:STIJVW:: ,- ;: C-! •4Ell~•i..:s:ftAAl£~~EQ~!~!b~tlQE ~ l~!!!H:r;;a••CIP•HBH•oCl•J.i;:-)<J=>JvA/+,+,/0123456789([;x:\-a ... nLE-'96\•'01T0*7fr-tuw~tc•t--+.!.-OAE<CDEFGHt.JKL~ RSTUVWHYZ{~}f,..•S l f~i.,'.I: A Aim£ c l!~!!::~LJQEQB§ !YY!!!lJ"(::at•l'lt1>•BBEl•oDll•;ii;; •) < !"" > ] vA-+' +, /0123456 789 ( [; X: \ -u .J.. 11 l. E _ '96 I 0 '0 I TO*? fr "'ob UWe> {'< +- 1--t > -ol CDEFGHIJKLMNOPORSTUVWXYZ{~ llf~i.,:rft&le!~£Q~EQt:!!~!!::~UQEQEST4~~~:r;c:it•Ot1>•eDll•oDl•J.i;;-)<!=>]vA;ii!+,+,/01234S6789([;x:\-u.J..nLE_V6\•'01TO•i •+uw::.tc ~~~!-OAE<CDEFGHI.JKLM ::c :STUVWH"t"Z{-i}$1"•9 l r•i.,:1:A&lf:!~f~gEQt!!~~'='1'!0F':l:.!B§!YY!!!l:!!;;';Dt•CJcpeeBS!l'oDll•;;i~ - ) < != > ]vA-+' + • /0123456 789 ( [; X ! \-a ... E _ '96 \a' 0 I TIU ?fr •tuw:>tc~~~.!. II' DEFGHI.JKLMl·IOF·ORSTUVWH't"Z{~}$wAS l f~ll.,:s:n&IA!'!£Q~f.g1!J; .J~b~LJQEQ!:i§!!JY~l:!!;;a••CJ••eOll•oDm.~i;:-) < != > ]vA/-· • + • /01 '.:':C 6789([;x:\-a ... nle_'Qo\a'DIT0 ~ .•uw~tcf-t-4!-0AE<CDEFGHI.JKLMNOPORSTUVWKYZ{~}f ...... e:r~~'.l:ft&IAP~Q~EQt!!~!!::~UQEQB§!YY!!!Ll!;;at•Otl>•enH~~DllT~~-,,~, ]vAl+,+./0123456789([~x:\- _Q()\a'DITO•?rr•tuw~tc~t--+.!.-OAE<C[IEFGHI.JKLMMOPORSTUVWHTZ{~}$ ...... El:r~\:s:ft&l8~£~~EQ!::l!~!'=~UQEg!:;§!Y~!!!U!;at•n -DB••DITJ.!;-) < i=)] vA-+, +. 10 .... 6 789 ( [; x: \-a .J.. fl l. E - 'Q() I a I a I To*? fr .... UW'.'.> tc: 4-t-~ .!.-OAE<CDEFGH I JKLMNOF"Of':STUVW)("t"Z{ ~}$w•EI: f~i..,% ft&le!~£QgE§t! ! ~~ !::~ll R~!!JY~KY~a••O••eDll••D•·~~- ]vA_+,+,/0123456789([px:\-a ... nLE-'96\a'DITO•Trr•tuw~tc•t-~.!.-OAE<CDEFGHI.JKLMHOPORSTUVWHYZ{~}$1"•a:r~~rA~ C!;!~E§!::l!~~b~l:!Qf:crn~IYY!!!~!!l;D' c EEl•oDll•=ti;-) ( i"') ]vA-+, +. /0123456 789 ( [; x: \-a .l.fl LE_ '96 I 0 I a I TO• ?r r .... uw:otc~t-~!-OAE<CDEFGIU JKLMllOF"ORSTUVW:n! ..... El: ,,.i.,'.I'. A&l8!'!£~gEQ•:!.b!I< l~~UQ - !J~~u:r;a, •C11P•eBE1•0Dll•.;i.i.;. •• ) ( i=)] vA#+' +. 10123456 789 ( [; x : \ - '" -· 'Q() I 0 • 0 I T0 ~?fr N.j. uwc> tc f-t-~ 1-0AE<C[•EFGl-tl ,J K4 Df"OF:S Tuvw::'t"Z{ ~)$,....,S ! f~i.,:r ft A 11' ":§ti!J~!::~UQE!:.'E § !Y~~i.:l!;at•Cltl>•BE[l~oom•.;i.i;; - ) < ~::•: > ] vA;il!+ r +, /01 \,J 789 ( [ ; X ! \-a.!. 11 l E _ '96 I a '0 I T0 *?fr "'t uw:.> fc +-1--llj OAE<CDEFGHIJKLMNOPOf':STUvW:-n· ~ ...... a: r~'-t:i:AA~~c;;QgEQt:!!~~!::~UQE!:.'E~!YY~u!;';c:l'f'•l'.1$•HBEl•oDll•;ii;;-) ;;::; vA;il!+, +. /0123456789( [; x: ,-a ... 11L e _Vt:.\ a. D 1..-j Tf r •tuw=> tc f-~~.!.-OAE<Cl•EFGH I J Ill •F·tlf':STUVWH"fZ{-i}$,..•EI ! flll\:1: n&lf'.!~£!H~EQ!::l!~!!::~LJQ[gf:;§!YY!!!!.n:;;;at• \I~ 111'7oDll•J.~ •) < j:: >] vA;il!+, +, /0123456 789 ( [; X ! '' inle_'Q(l\o'DITS•?rr•tuw=>tc~ AE<CDEFGHIJKLMHOPORSTUVWHYZ{-i}$1"•9!r~~'.l:ft&l8!£~~EQ~!~!!::t::!U !YY~u1;c:it•C1t1>•ee11•0Dm•J.~-)<.i=>]vA~~.+./ 3456789 ( [; x: \ -0.l.ll LE_ 'Q() I a I 0 A. fr ..... UW:J tc ~r~l-OAE<C[•EF'"GHI.JKLMllOf'•ar.:STUVW)O"Z{-i}$ ...... 9: rl!l~:r.ft ..J g[Q!:.i!"1~b~UQE:gE§!!JY~1:l:!:;a,.c •• aee ... am • .;i.~ i=)] vA#+, +. /0123456 789 ( [; x ... II LE - 'Q() I .. I 0 I T0 jt? fr ·•uw:> tc f-1- + 1. -OAF.•C[•EFGH I JK LMllOf' ar::s Tuvw:: I'\ $1"•EI: f~i..,:r A&le!!l!f~gE§!:J!~!bt::!UQEgE§!!JYll!Ll!:;a 0$•B011'70Dll•;,ti;;-) ( !=) ] vA;lf!+, + "' 3456 789 ( [; x: \·-a .l. n LE - 96 I 0 ID I., m jt 7 r r .... uw It< f-1-~ .t-vAE•Cl"•EFGI I ...... llOF nr.·s TIJVW::·.-z{-i}f ... •EI: "~~% A&l8~£P.P'.9.t!;l ,.J! DE!;!8§!YY~1:$!;at•OIP•eBB••Dll• i-) ] vA~ '-' +. 101:?3456789 ( [; x : \ -() J fl l E - QA\ u • []I., <H -~fr .... uw ) t <( -OAI"•C[•EF"GHI JK LMllOF·ar:·s Tuvw::' Z{ -1}$1"•EI: rill 6f'.!~£~g[Q!::!!~l!.!::~!JQEQE§!!J~~!i! Ill t1>•B8Elll'oDmTJ.I. .. ) < 5 >]vi\/,' , +, /01234'.J6789 ( [; X: \-II Lfl l E _ '1761C1· • ~ n '""'tuw J t<- 1-t- .... ! -OAE<CDEFGHI ,Jl<LMllOF ar, STU _ {~}$w4E1: r~i..:s:n&l!~£~g;[Q!::!!."1~!:: E~!!JY~)_!!_<:D••C1t1>•eeeivoo11 • .;i.i;; - ) < -~ .. ) ] vi\/ - • +. /01:'3451.,789 ( [ - 'Q() I ... a I Te* ?fr-· uw J tc: ... ~ ... !-OAE•Cl•Er-f·ll ~ LMllOF·ar.:STUVWH"r"Z{-i}$ ...... EI: fllli.., ::c £ ~~[!?t1!. J!~ ~LIQ[ CJ!:'."2 !"~Y~U!.;at•l'.l<l>•aDEl•ofJftl•J. ~ - ) ( ( - ) ] v Al - • 789 ( [; x: \ -(1.J.. fl L f. ··- '96 I 0 • DI TIH 7 fr-· u WC> t<; ... !-OAE<Cr<EFGI I I J K LMttor·ar:. STUV -i}$ ...... a: f lq""I fl oBf!f. PECQI..!! ~~!::~t.!!?E.CJE:2 !!:.!'!'.~:_:_.;;at .t.Cl$•F.JllE11VoOm Al-, i • /0123456 789 ( [; x: \ -,IJ fl LE - '171'> I 0 ·! T~'" r •hw>h+ Hl-•••"""" ... "''"' "'" '"""' 0{"}$·••' ,.,,, •• "°"'<•• ""' """"' OE>1"Y"'·'' ~ •• a • .,.-)' l•' ,,., •• +. /01?3456780 ( [•I \ a .l. fl LE - '17(; I 0 • DI Tr:>. 7 fr .... u WC> t<- H- ... 1-0AE•C[IE':rGHI JI( LMllOf" 111' ~>ruvw::' Z{-i}$ ... •EI: f Ill~ T n<Cif'..'lf•f. [•[ cr-1_11,~ !!.l:::~~IQ[~1B2!YY~l..U:;at ... CllP•BEIEl•oDm • .;i.i;; •• ) < .5 - ) ] v A/'-· i· 0123456 789 ( [; X : \-a .L n l E ·- Q6 I 0 '0 I T0 Vi' fr "'.j. u w, t<- •t- -t J_ -OAE•croE:F-GH LI K LMllOF ar: <; ruvw::' :" { ·i} $..,..,9: f lll\:1· 11 <Ci~f!£Q~f~Qtl!J!!.!::~UQE.!;!!'::? !!J~~<:;!_;;;Dt•CJt1>•eDEJ•oDftl c-) < i-) ] v "#~.·I .10123456 789 ( [ ; x : \-a Jn L E - V6 I 0 • DI T0. 7 fr-· u W-> tc. 4· 1-· • l. ·-OAF.•CI:•ErGI I I ,J ICLMllOF m:·r, 1 uvw::·1·:--c -1}$ ... •EI: f~~:r. ll &lf'.!~£~g;EQ!::!!,.J!b~Ul?.E:QF. s :r y~~L Dt•C1t1>•e81J••Dm • .;i.1. •• ) < !-=)] vA~·'-' +, /() l 23456789 ( [ ; x : \ - II .l. n L f. -· '176 I 0 • []I TB*? fr-· u w ) t<- .. t-··• l-·OAl.<CN;:rGH LJK l MllOF"Of::STUvw:: f::{-i}$ ... •9: r~\:r. ftQS~·!'.:!=!~P':Qt!_ 1-!::!UQ!: Q!::: '.?!!,JY!!!Ll .!. ;at •CJll>•BllEI• 0 Dll•J. ~ - ) ( .i""-) ] v"'/.-- I • I 012 3 4 :'"16 7B9 ( [ ; x : \ -- a J "L E -- 'Q () I •• D I r<H 7 fr N .j. u w ::> t ( .. t- .... ?. -OA[IC [•EF'"GH I J t< l_MllOf"'llf-:5 TUvw:: I ;: {-i) $ ...... 9: ·-:rft&1e!!;'£!;!~[Q!::l.!"1!!!::~UQEQ!':.2!!.!Y~Ll!. ;;;at•r.J<P•SEIEl'7o0 T;l i;; - ) < J - ) ] v Al~,+./() 1234!16 789 ( [; x : \ "'n Lil L f. - QA I u • []I., <H ~·fr "'tuw.:> t<: f-t--+ 1. - OAE•C[•EFGIU JI< LMllDF" ar::. ::·i::{-i}$¥•EI! flllll.,:s:llA~~£~t=t:~tJ!~!!!::t::!t.!QLQE~!!JY!!!t:I c:it•CJIP•BBEl•->Dl•.;i.i;-) < -~ '·) ]vAI- .... /01234~"i6789 ( [; x: ,-(J Lill E __ '96 I a. a I -rO•?rr ... tuw :itc~t-~ >_--OAI•cr•E '

Chairman (RSTS) Larry LeBlanc Teletype Corp. Elk Grove, IL 60007

Library Coordinator Susan Abercrombie Ventrex Laboratories Portland, ME 041 03

Newsletter Editor (RT, TSX) Douglas Bohrer Bohrer and Company Wilmette, IL 60091

Symposia Coordinator (RSX) Bob Awde Jr. General Mills Inc. Minneapolis, MN 55427

APL SIG

APL-i

Symposia Assistant Bob Van Keuren UserWare International, Inc. Escondido, CA 92025

Standards Representative Dan Esbensen Touch Technologies Escondido, CA 92025

VAX APL (Contact:) OPEN

European Contact (TOPS) Jean-Pierre Barasz BARTS 75008 Paris, France

Digital Counterpart Dave Quigley Digital Equipment Corporation Nashua, NH 03062

I

I I I I

I I ARTIFICIAL I I I I INTELLIGENCE I I I I I I I I I I I I I I I I I I I I [Ql I I _ _J L_ DEC US

- - - -

ARTIFICIAL INTELLIGENCE SIC

Chairperson Cheryl Jalbert JGC Granville, OH

Ass't Chairman Don Rosenthal Space Telescope Science Inst. Baltimore, MD

Symposium Coordinator David Slater Institute for Defense Analysis Alexandria, VA

Ass't Symposium Coordinator Session Note Editor

Greg Parkinson Cognitive Systems Inc. New Haven, CT

Newsletter Editor Terry Shannon Digital Review Boston, MA 02109

Newsletter Publisher Bob Zeek Pfizer Inc. Groton, CT

Membership Coordinator Pamela Vavra KMS Fusion Inc. Ann Arbor, MI

Al-i

PSS Scheduling Tom Viana

Store & Buttons Sally Townsend Inst. Defense Analysis Alexandria, VA

Quality Control Chair Dick Ciero Harris Corp. Palm Bay, FL

Quality Control Carol Guyermelli

Site Coordinator, Anaheim Chris Goodard

Volunteer Coordinator, Anaheim Peter MacDonough Tractor Inc. California, MD

Members-at-Large George Humfeld

Matt Matthews IV

Evaluation Research Corp. King George, VA

DEC Counterpart Art Beane Digital Equipment Corporation Hudson, MA

(THE (LINKED LIST))

THE NEWSLETTER OF THE DECUS ARTIFICIAL INTELLIGENCE SPECIAL INTEREST GROUP

Vol. 2 No. 3 April 1986

SIGnificant Meeting

Saturday, April 26, 1986, at 3 PM in the suite

The AI SIG will hold an important organizational meeting prior to the Dallas symposium at 3 PM in the AI/L&T/UNISIG suite. We will be discussing SIGnificant issues at this meeting and may be voting. This is an OPEN meeting. You are welcome. If you would like to offer input, but will not be able to be in Dallas on Saturday, please contact Terry Shannon (newsletter editor), Chris Goddard (membership coordinator), or Cheryl Jalbert (chair).

Thank you for your input. I'll look forward to seeing you in Dallas.

Cheryl Jalbert AISIG Chair

AI-1

[Q] DEC US

BUSINESS

APPLICATIONS

BUSINESS APPLICATIONS SIC STEERING COMMITTEE

Chairman Stuart Lewis Douglas Furniture Bedford Park, IL

Symposium Coordinator Steve Simek I RT Corporation San Diego, CA

Asst Symposium Coordinator Bobbie Wiley CEI Perry Nuclear Power Plant Euclid, OH

LRP and Marketing Coordinator Arnold I. Epstein D-M Computer Consultants Rolling Meadows, IL

Marketing Asst George Dyer Gallaudet College Washington, DC

Communications Representative OPEN

Newsletter Editor Thomas Byrne L. Karp and Sons Elk Grove Village, IL

Session Notes Editor Raymond Swartz Goodyear Tire and Rubber Co. Akron, OH

Library Representative David Hittner Projects Unlimited Dayton, OH

BA-i

CL SIG Liaison Becky Burkes Financial Insurance Consultants Covington, LA

OMS SIG Liaison Joe Sciuto Army Research Institute Alexandria, VA

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

Digital Counterparts Sue Yarger Digital Equipment Corporation Merrimack, NH

Ray Arsenault Digital Equipment Corporation Merrimack, NH

SIC Mentor Bill Brindley Networks SIG Chair

SIC Review Committee Larry Jasmann Leslie Maltz Ted Bear Jeff Killeen

Spring is here• Time for the Dal las Symposium.

""hat could be more welcome right now than a week of sunRh1ne. the excitement of seeing old and making new friends. a stream of sessions that wi I I knock your socks off'

The guys responsible for putting the sessions together for this Symposium hilve done another outstanding joh 1

Special "Atta-Boy"s go to Steve Simek for putting the sessions together in a logical stream so that. hopefully. your two favorite sessions are not scheduled at the same time. In fact, they should go to the ent;re team for an extremely difficult job - wet I done' If you run into any of the Symposium Coordinators at Dallas. let them know their hard work is appreciated.

At last count. the Business Application SIC has 45 sessions set for Dallas. These cover A-Z product information. sessions on MAP and JIT. Project Management, and much, much more. Some of these sessions are repeats of past popular presentations and some are new for Dal las. Be sure to attend the Monday morning Road map Session and make sure your week is profitably spent.

In addition. the SIC is sponsoring a Pre-Symposium Seminar on Developing Lilrye Applications on a VAX. Check this out even if you don't have a VAX. Many of the principles outlined are valid for any large application.

This month's quest ion concerns Symposium and gives al I those attending a rc'-11 opportunity to help those who are not. Jr.le would like to hear from those attending about there experiences at Dal las. Did you see a session that was particularly helpful or informative? Jr.lrite up a short <or longl essay and give us the benef 1 t of your experiences. Maybe about one session, maybe about the whole Symposium. By communicating the value of Decus Symposium to those not able to attend. you can help them justify future attendance.

That raises another point. For those attending, how do you get approv~I

for funding? Is it easy, hard, tricky? I heard of one System Manager who justified it as Manager Maintenance' He said, "Jr.le pay for Hardware Maintenance, Software Maintenance, so why not Manager Maintenance•"

Let us hear from you. Anonym1n1 ty is guaranteed_

In addition to Dallas. I would like to spend a moment talking about one of my favor i le subjects_ How can you be sure that qua I 1 ty results come out of the systems you design and usP'?

As I 1alk to othe. System Managers. I find that we are al I concerned ilbout some of the same problems. The software we have is poorly designed. hard to modify. un-documented, etc. The people who use the system don't read the documentation anyhow. or don't care. or don't pay attention. The results are that many times we find ourselves put ling out fires that could have been prevented

P,)1-1

How are you hand I ing these kinds of problems? What methodologies are your using to cure/prevent problems 1n the future. I think this topic is tremendously interesting to most of the members of the SIC. Write your sulutions down and get them published.

Let's create a dialog among the membership. That is after al I the whole purpose of being a member in the first place. sharing information about how tu do things better.

Decus membership should not be a passive thing. what make it a strong and vital organization.

Your contributions are

Jr.le al I look forward to seeing you at Dal las and in the Newslet1er.

BA-2

FROM THE SIC CHAIR

SPRING 1985 DECUS SYMPOSIUM APRIL 28-MAY 2, 1986

BUSINESS APPLICATIONS HIGHLIGHTS

The DECUS Dallas Symposium promises to be of great interest to users, designers, and managers of application systems for business. The DECUS Business Applications SIC is presenting a symposium experience comprised of numerous sessions covering such diverse topics as:

o Conversion of IBM DP Systems to VAX o MRP and JIT Considerations for the Small Manufacturer o Buying 3rd Party Accounting Software o Applications in PBX and Facilities Management o In House Typesetting o Software Publishing o Technologies for Future Small Business Systems o Computer Assisted Project Management o Performance in the Small Business Environment o Designing Multi-National Software Applications o Packaged Software and the International Market o Government Procurement System Design o Electronic Order and Invoice Transmission o Simplifying Applications With State Tables o Management Concerns in Integrating VAX Applications o Application Software for DEC Systems

and many MORE.

This, AS WELL AS

A full complement of sessions covering Digital's A-to-Z Systems Integration products. Among the many A-to-Z sessions are:

o Introduction to A-to-Z o How A-to-Z Solves the Application Integration Puzzle o A-to-Z/All-In-One Differences o A-to-Z in the Business Environment o A-to-Z State of the Product Announcement o Adding Non A-to-Z Applications to the A-to-Z Environment o A-to-Z in an Application Environment o A-to-Z Communications o A-to-Z Data Management

and many MORE!

We would like you to pay particular note to session BA54 which is the Business Applications Clinic and Get-Together! This session is an informal problem solving clinic and get-together for those of us interested in business applications. Visit this session on Wednesday April 30th, at 5pm in the South 413 room of the Convention Center, and meet fellow Business Applications users and DEC Developers, in order to solve problems and share experiences. Refreshments will be available.

This brief survey represents just a portion of the Business Applications offerings during the week of the Symposium in Anaheim. Visit us at the welcoming reception Sunday night, in our campground at the convention

BA-3

center, our suite at the Anatole Hotel, at our sessions, and have a good, as well as informative time this April,

JOIN US

Monday Morning for the Business Applications Roadmap Session. At the Business Application Roadmap, we will highlight sessions throughout the week that we feel will be of interest to the business community. We will also offer at this session some tips on survival during Symposium Week, such as where to eat, where to meet, who's who, and where's our suite ...

Let's do some SIGnificant Business in Dallas! See you there!

STU LEWIS

BA-4

COBOL BASIC DIBOL RPG

COMMERCIAL LANGUAGES SIG

Chairman Jim Wilson Pfizer Inc. QC Div. Terre Haute, IN

Symposium Coordinator Ray Strackbein Palm Desert, CA

Library Coordinator Philip Hunt System Industries Milpitas, CA

Session Note Editor Bob Van Keuren Userware International, Inc. Escondido, CA

Newsletter Editor Ted A Bear Ramtek Santa Clara, CA

Ass't Newsletter Editors Beverly Wei borne LaPorte, IN

Kevin Cullen VITA-Mix Corp. Holmstead Falls, OH

Daniel Cook Userware International, Inc. Escondido, CA

Basic Working Group Members Mark Hartman Jadtec Computer Group Orange, CA

Rocky Hayden UserWare International Inc. Escondido, CA

Bill Tabor Computer Productss Pompano Beach, FL

CL-i

Cobol Working Group Members Keith Batzel Crowe, Chizek & Co. South Bend, IN

Mary Anne Feerick ROBS Inc. Kernersville, NC

Bill Leroy The Software House, Inc. Atlanta, GA

Herbert J. Matthews IV ManTech International Corp. Alexandria, VA

Jim Welborne Crowe Chizek & Co. South Bend, IN

DIBOL Working Group Members Neil Baldridge CompuShare Lubbock, TX

Becky Burkes Financial Insurance Consultant Covington, LA

Colin Chambers Software Ireland Rep. Inc. Portola Valley, CA

Mark Derrick WAAY-TV Huntsville, AL

Gary AP. Koh Is Milwaukee, WI

Ken Lidster Disc Sacramento, CA

Kenneth M. Schilling MCBA Montrose, CA

Marty Schultz Omtool Inc. Tewksbury, MA

David L Wyse Professional Business Software Dayton, OH

Marty Zergiebel The Software Gallery Brookfield, CT

RPG Working Group Members Keith Batzer Crowe Chizek & Co. South Bend, IN

Ted Bear Ramtek Santa Clara, CA

Digital Counterparts Tom Harris Nashua, NH

Jim Totten Nashua, NH

CL-ii

Joe Mulvey Nashua, NH

Shirley Ann Stern Nashua, NH

Standards Representatives BASIC Dan Esbensen Touch Technologies, Inc. Escondido, CA

COBOL Bruce Gaarder Macalester College St. Paul, MN

DIBOL Eli Szklanka TEC Newton, MA

BASIC MAGIC

Ted A. Bear

USER WARE IRTllHTIOHI

2235 Meyers Avenue • Escondido, CA 92025-1070

(619) 745-6006

Davy Crockett beat Mike Fink in the Mississippi River to New Orleans because he took a short cut through a swanp that saved him thirty miles. BASIC programners have short cuts that are called functions. Here are five functions that might come in handy.

The first function is a little number that divides a string at a specified character. It uses in string search, a system utility, to find the first occurance of the specified string and then splits the whole string into two parts - "throwing away" the specified string.

Parameters: XIJ$ is the string to be split. Xl$ is the string at which XIJ$ will be split.

Returned: FN1$ will be the left part of the string to be split, XIJ$, before the first occurance of Xl$. X2$ will be the right part of the string to be split, XIJ$, after the first occurance of Xl$.

The function:

FNl 1: DEF* FN1$(X0$,Xl$)

X%,Xl%=INSTR(l%,X0$,Xl$) X%=LEN(XIJ$)+1% UNLESS X% FN1$=LEFT(X0$,X%-1%) X2$=RIGHT(X0$,X%+LEN(Xl$))

FNEND !*SPLIT X0$ INTO FN1$ AND X2$

The second function is used to convert a string date into a RSTS system date. The system date is a integer that is 1000 times (the year - 1970 ) plus the Julian date. The returned system date can then be used to perform mathmatical functions.

Parameters: X$ is the date in rrm-<'ld-yy, dd-mim-yy or rrm:'ldyy format.

Returned: The date converted to system format. There is also a error flag. E% will be zero if the function completes successfully, a value indicates that it failed.

CI,-1

The function:

FN2 1: DEF* FN2% (X$)

FN2 2:

FN2 3: FNEND

X$=DATE$(1J%) IF X$="TODAY" X$=LEFT(X$,2%)+"-"-IMID(X$,3%,2%)+"-"+RIGllT(X$,5%) &

IF LEN(X$)=6% UNLESS INSTR(l%,X$,"-") X4%=INSTR(l%,X$, "-") X5%=INSTR(X4%+1%,X$,"-") E%=1% FN2%=-1% IF X$="1JIJ-XXX-IJIJ" THEN

X8%=-1% GOTO FN2 2

END IF GOTO FN2 3 IF X4%*X5%=1J% X6%=VAL(RIGllT(X$,X5%+1%))-70% GOTO FN2 3 IF X6%<1J% OR X6%>29% X6%=X6%*llJIJIJ% X6%=X6%+243% IF INSTR(l%,"SOND",EDIT$(MID(X$,X4%+1%,1%),32%))

IF X5%-X4%<4% THEN X7%=VAL(LEFT(X$,X4%-1%)) GOTO FN2 3 IF X7%<1% OR X7%>12% X$=MID(X$,X4%+1%,X5%-X4%) &

END IF

+RIGHT(DATE$((X7%-1%)*31%+1%+X6%),4%) X6%=X6%+(X7%-1%)*29%

X$=EDIT$(X$,34%) X$="1J"+X$ IF INSTR(l%,X$,"-")=2% GOTO FN2 2 IF X$=EDIT$(DATE$(X8%),32%) FOR X8%=X6%+1% TO X6%+366 GOTO FN2-3

E%=0% FN2%=X8%

Sometimes you might to know what day of the year it is. '!he next function is a non privileged way to get today's date in system format.

Parameters: None.

Returned: Today's system date.

The function:

FN3 1: DEF* FN3%=SWAP%(CVT$%(RIGHT(SYS(CHR$(6%)tCHR$(-3%)),27%)))

!*NON-PRIV WAY OF GETTING TODAY'S JULIAN DATE

CL-2

Now that you know what day it is, you might like to add of subtract days. This function will allow you to do just that. A positive number will add days and a negative number will subtract days.

Paraneters: Xl% is the date to be incremented, decremented, in system date format. X2% is the number of days to add.

Returned: The resulting day in system format.

The function:

FN4 1:

FN4 2:

FN4 3:

FN4 4:

DEF* FN4%(Xl%,X2%) FN4%-1% E%=1% !*DATE ADDER

FNEND

GOTO FN4 4 IF Xl%<0% GOTO FN4-3 IF X2%=0%

X4%=Xl%/1000%-70% X4%=X4%-X4%/4%*4% IF X4%=-3% AND X2%<0%

THEN X4%=0%

! *CHECK PARAMETER VALUE

ELSE X4%=-1% UNLESS X4%=0% AND X2%>0% END IF

X5%=X2% X5%=SGN(X2%)*(366%+X4%) IF (SGN(X2%)*X5%)>366%+X4% X2%=X2%-X5%

X3%=Xl%+X5%

*X4%=0 IF A LEAP YEAR *X2%=AMOUNT TO ADD OR SUBTRACT *(ONE YEAR AT A TIME)

GOTO FN4 4 IF X3%>29365% OR X3%<0% X6%=X3%-X3%/1000%*1000% IF ((X6%>366%+X4%) AND SGN(X5%)>0%) &

OR ((SGN(X5%)<0%) AND (X6%=0% OR X6%>366%+X4%)) THEN X3%=X3% + SGN(X5%)*(634%-X4%)

END IF !*ADD OR SUBTRACT THE DAYS !*TEST FOR YEAR OVERFLCM

Xl%=X3% GOTO FN4 2 IF X2%

FN4%=Xl% E%=0%

! *RESET START DATE

!*BACK TO ADD OR SUBTRACT SOME !*MORE

*FN4%=RESULTANT DATE *INTF.GER *NO ERRORS WERE MADE

And after you have a julian date, and you can add or subtract days, you might want to know what day of the week it is. To do that you have to let your program know that there are seven days in a week. This function will do that for you.

CL-3

Paraneters: Julian date

Returned: Numeric day of the week

The function:

FN5 1: DEF FN5(X) = 7 * (X/7 - INT(X/7))

These functions can be used in programs to serve sane kind of a useful purpose. This program is used to requeue a batch control file.

10 !* !* !* !* !* !* !* !* !* !* !* !* !* !* !* !* !* !* !* !*

THIS PROGRAM WILL AUTOOATICALLY REQUE A BATCH FILE TO A GIVEN HANDLER. THERE IS ONE PR<:t1PT:

INPUT FILE? TO THIS RESPOND:

filenane;days-of-the-week;time-of-reque;#-of-handler

THE DAYS OF THE WEEK IS A STRING OF DIGITS, WHERE 0 IS SUNDAY. THIS STRING CAN BE IN ANY ORDER.

EXAMPLE: TEST.C'l'L;l3205;04:00;3

WHERE TEST.CTL IS THE FILE TO REQUE 13205 INDICATES THAT THE JOB WILL BE QUEUED ON MONDAYS,WEDNESDAYS,TUESDAYS,SUNDAYS,AND FRIDAYS 04:00 IS THE TIME OF DAY TO QUEUE THE JOB 3 IS THE NUMBER OF THE BATCH HANDLER TO QUE THE JOB TO

!* ALL SEMICOLONS ARE REQUIRED. DEFAULT DAYS ARE 12345. DEFAULT !* TIME IS 04:00. DEFAULT HANDLER IS THE FIRST FREE ONE. !* !* !* IN ORDER TO EXOCUTE THIS ROUTINE, THE ! * FOLLCMING MUST BE AT THE START OF THE !* BATCH CONTROL FILE: !* !* $JOB/NAME=jobnane/NOLIMIT/CCL !* $RUN (l,4)REQUE !* ctl-filenane;days;time;handler !* $EOD !*Fl$=NAME OF CONTROL FILE INPUT--IF NO .EXT, DEFAULTS TO .CTL !*V$=DESIRED DAYS OF THE WEEK !*T$=DESIRED TIME OF DAY !*H$=BATCH PROCESSOR NUMBER !*D$=DATE TO BE USED FOR QUE~ !*D2$=CURRENT DATE + Il%, INCREMENTED BY l UNTIL IT = ONE !*OF THE DAYS IN V$ !*IF NO DAYS OF THE WEEK, DEFAULTS TCl1,T,W,T,F !*IF NO TIME, DEFAULTS TO 18:000 !*IF NO BATCH PROCESSOR, DEFAULTS TO *

CL-4

100

FNl 1:

Wl% = 2% !* THIS IS THE NUMBER OF THE lST DAY OF !* 1980, WHERE MONDAY IS ONE(l).

PRINT "INPUT FILE"; INPUT LINE Fl$ Fl$=EDIT$(Fl$,2%+4%) Fl$=FN1$(Fl$,";") V$=FN1$ (X2$, II; II) IF VAL(V$) > 7 THEN

END IF

PRINT "ILLEGAL DATE FORMAT" GOTO 32767

T$=FN1$(X2$,";") IF LEN(T$) <> 0% AND INSTR(l%,T$,":")

PRINT "ILLEGAL TIME FORMAT" GOTO 32767

END IF

H$=X2$ V$="12345" IF LEN(V$)=0% T$="18:00" IF LEN(T$)=0% H$="" IF LEN(H$)=0% !1% = 1%

0% THEN

!* THIS IS THE NUMBER OF DAYS TO SKIP !* BEFORE REQUEUEING THE NEXT BATCH JOB.

D%=FN4% (FN3%, Il%) X%=FN3%/1000% + 69% Dl%=0% Dl%=FN2% ("31-DEX:!-"+NUM1$ (I%)) & - (FN2% ("31-DEX>"+NUM1$ (!%)) /1000%) *l000% + Dl% FOR I%=80% TO X% Dl%=Dl% + Wl% + (D% - ((D%/l000%)*1000%)) - 1% D2% = Dl% - ((Dl%/7%)*7%) D2$=NUM1$ (D2%) IF INSTR(l%,V$,D2$)=0% THEN Il% = Il% + 1%

GOTO 100 END IF * THIS CALCULATION DETERMINES WHAT DAY OF

* THE WEEK THE NEW DATE IS ( l=MONDAY ) • * IF THE DAY IS NOT ONE SELOCTED THEN * IT SKIPS TO THE NEXT DAY AND

!* CHOCKS IT FOR VALIDITY. D$=DATE$ (D%) L%=32767% !* THIS IS THE LINE # TO RETURN TO AFTER THE

!* QUE ROUTINE HAS BEEN CALLED. X$=SYS(CHR$(8%)+"(1,4)REQUE"+CHR$(13%)+cvT%$(L%)+"Q BA"+H$+":/AFTER:"+ &

D$+":"+T$+"="+Fl$+CHR$(13%)) CHAIN "$QUE" LINE 31000%

DEF* FN1$(X0$,Xl$) X%,Xl%=INSTR(l%,X0$,Xl$) X%=LEN(X0$)+1% UNLESS X% FN1$=LEFT(X0$,X%-1%) X2$=RIGHT(X0$,X%+LEN(Xl$))

FNEND

CL-5

!*PARSE X0$ INTO FN1$ AND X2$

FN2 1:

FN2 2:

FN2 3:

FN4 1:

FN4 2:

DEF* FN2% (X$)

FNEND

X$=DATE$(0%) IF X$="TODAY" X$=LEFT(X$,2%)+"-"+MID(X$,3%,2%)+"-"+RIGHT(X$,5%) &

IF LEN(X$)=6% UNLESS INSTR(l%,X$,"-") X4%=INSTR(l%,X$, 11 - 11 )

X5%=INSTR (X4%+1%,X$, "-") E%=1% FN2%=-1% IF X$="00-XXX-00" THEN

X8%=-1% GOTO FN2 2

END IF GOTO FN2 3 IF X4%*X5%=0% X6%=VAL(RIGHT(X$,X5%+1%))-70% GOTO FN2 3 IF X6%<0% OR X6%>29% X6%=X6%*l000% X6%=X6%+243% IF INSTR(l%,"SOND",EDIT$(MID(X$,X4%+1%,1%),32%)) IF X5%-X4%<4% THEN

END IF

X7%=VAL(LEFT(X$,X4%-1%)) GOTO FN2 3 IF X7%<1% OR X7%>12% X$=MID(X$,X4%+1%,X5%-X4%) &

+RIGHT(DATE$((X7%-1%)*31%+1%+X6%),4%) X6%=X6%+(X7%-1%)*29%

X$=EDIT$(X$,34%) X$~"0"+X$ IF INSTR(l%,X$,"-")=2% GOTO FN2 2 IF X$=EDIT$(DATE$(X8%),32%) FOR X8%=X6%+1% TO X6%+366 GOTO FN2-3

E%=0% FN2%=X8%

DEF* FN3%=SWAP%(CVT$%(RIGHT(SYS(CHR$(6%)+CHR$(-3%)),27%))) !*NON-PRIV WAY OF GETTING TODAY'S JULIAN DATE

DEF* FN4%(Xl%,X2%) FN4%=-1% E%=1% GOTO FN2 4 IF Xl%<0% GOTO FN4-3 IF X2%=0%

X4%=Xl%/1000%-70% X4%=X4%-X4%/4%*4% IF X4%=-3% AND X2%<0%

THEN X4%=0%

! *DATE ADDER

!*CHOCK PARAMETER VALUE

ELSE X4%=-1% UNLESS X4%=0% AND X2%>0% END IF X5%=X2% X5%=SGN(X2%)*(366%+X4%) IF (SGN(X2%)*X5%)>366%+X4% X2%=X2%-X5%

CL-6

*X4%=0 IF A LEAP YEAR *X2%=AMOUNT TO ADD OR SUBTRACT *(ONE YEAR AT A TIME)

FN4 3:

FN2 4:

X3%=Xl%+X5% GOTO FN2 4 IF X3%>29365% OR X3%<0% X6%=X3%-X3%/1000%*1000% IF ((X6%>366%+X4%) AND SGN(X5%)>0%) &

OR ((SGN(X5%)<0%) AND (X6%=0% OR X6%>366%+X4%)) THEN X3%=X3% + SGN(X5%)*(634%-X4%)

END IF !*ADD OR SUBTRl\CT THE DAYS ! *TEST FOR YEAR Ol1ERE'I&

X1%=X3% GOTO FN4 2 IF X2%

FN4%=X1% E%=0%

I *RESET START DATE

!*BACK TO ADD OR SUBTRl\CT S<»iE !*MORE

*FN4%=RESULTANT DATE *INTEGER *NO ERRORS WERE MADE

FNEND 32767 END

This program returns the day of the week. This seed version returns today's date, but it can be modified to give other days.

10

600

OOSUB 600

GOTO 32767

! THIS SUBROlJI'INE WILL RETURN ! THOOAY'S DAY OF THE WEEK MTH $ = "JANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDJOC:" YR $ = EDIT$ (DATE$ (FN3%) , 32%) M'rif % = (INSTR(!%, MTH $, YR $) + 2%)/3% YR% = VAL(LEFT (NUM1$(FN3%f; 2%)) DY=%= VAL(RIGHT(NUM1$(FN3%), 3%))

DATE $(0%) = " FRIDAY" DATE-$ (1%) = II SATURDAY" DATE-$ (2%) = 11 SUNDAY" DATE-$ (3%) = II MONDAY" DATE-$(4%) = " TUESDAY" DATE-$ (5%) = 11 WIDSNDAY" DATE-$(6%) = 11 THURSDAY" DATE=$(7%) = 11 FRIDAY"

IF MTH % > 2% THEN - MTH % = MTH % - 2%

ELSE

END IF

- -MTH % = MTH % + 12% YR\ =YRl-1% M'lii_% = M'rii_% - 2%

ANS % = (INT(FN5(INT(2.6*MTH % - .2) + DY % + YR % & - + (YR_%/4%) - 32.95)) + 1%) - -

PRINT DATE_$(ANS_%)

ANS_% = 0% IF ANS_% = 7%

RETURN

CL-7

FN3 1: - DEF* FN3%=SWAP%(CVT$%(RIGHT(SYS(CHR$(6%)iCHR$(-3%)),27%)))

!*NON-PRIV WAY OF GETTING TODAY'S JULIAN DATE

FN5 l: - DEF FN5 (X) = 7 * (X/7 - INT (X/7))

32767 END

This is a modification of the seed program.

600 ! DAYCMK MODIFIID TO DETEBMINE LAST FRIDAY AND SATURDAY MTH $ = "JANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDJOC:" YR$= EDIT$(DATE$(FN3%), 32%) MTH % = (INSTR(!%, MTH $, YR $) + 2%)/3% YR % = VAL (LEFT (NUM1$(FN3%f; 2%)) DY=%= VAL(RIGHT(NUMl$(FN3%), 3%))

IF MTH % > 2% THEN - MTH_% = MTH_% - 2%

ELSE

END IF

MTH % = MTH % + 12% YR% =YR%-1% M'rii_% = M'rii_% - 2%

ANS % = (INT(FN5(INT(2.6*MTH % - .2) + DY % + YR % & - + (YR_%/4%) - 32.95)) + 1%) - -

ANS_% = 0% IF ANS_% = 7%

FRI % = FND2%(FN3%, -ANS %) SAT=% = FND2%(FN3%, -ANS=% - 6%)

FRI $ = DATE$(FRI %) SAT=$ = DATE$(SAT~) RETURN

We au have a little MAGIC

Please take the time to share your's with the other members of the Camlercial Languages SIG.

CL-8

~- - - - - - - -=i I [Q] I

I DECUS I

I I

I I

I I

I I

I I

I I

I DAARC I

I I

I I

I I

I I

I I

I I

I I

I I

I I

I I

I I

I I

---' ...__ - - - - - -,, ' ' II I 'I ' I ' ' " I 111 ·n ' I' I' I I I' I I I n1 1111111111 II I I II I 11' ' 11 ,I ,IJ:ll lll',111. II'' ' Ii.I I j~,L. ". ~. """"" " ,,.,, • .111.,"

Chairman James Deck Inland Steel Research Lab East Chicago, IN

Symposium Coordinator Mack Overton FDA Chicago, IL

Newsletter Editor Ellen Reilly William H. Rorer Ft. Washington, PA

DEC Counterpart Nancy Kilty Digital Equipment Corporation Marlboro, MA

DAARC

DAR-i

Hardware & Interfacing Peter Clout Los Alamos National Lab Los Alamos, NM

Math Statistics & Analysis Herbert J. Gould C.C.F.A. University of Illinois Med Center Chicago, IL

Process Control - Industrial Automation Bill Tippie

RS-1

Kinetic Systems Corp. Lockport, IL

George Winkler CPC International Argo IL

OMS SIG

JOIN THE WISE

Data Management Systems SIG Steering Committee April 1, 1986

SIG Chairman: Joseph F. Sciuto Army Research Institute Alexandria, VA (202) 274-9420

Comptroller: Alan Schultz Land Bank National DP Center Omaha, NE (402) 397-5040

Symposium Coordinator: Keith Hare JCC Granville, OH (614) 587-0157

Symposium Coordinator: Barbara Mann TRW Redondo Beach, CA (213) 532-2211

Communications Committee Representative/ Newsletter Editor:

J. G. Russell Poisson SEED Software Corporation Alexandria, VA (800) 428-9400

Session Note Editor: Mark Morgan Farm Credit Banks Springfield, MA (413) 732-9721

Membership Coordinator: VACANT

MIS Working Group Coordinator (Past SIG Chairman): Steve Pacheco

DMS-i

Ship Analytics North Stonington, CT (203) 535-3092

MIS Working Group (Past SIG Chairman): Sandy Krueger Key Financial Systems, Inc. Pine Brook, NJ (201) 299-6600

Working Group Coordinator/ Database Working Group:

Jim Perkins PSC, Inc. Shelburne, VT (802) 863-8825

Forms Working Group: Debbie Kennedy Land Bank National DP Center Omaha, NE (402) 397-5040

Non-Digital Working Group: Doug Dickey GTE Government Systems Rockville, MD (301) 294-8400

RMS Working Group Coordinator: Allen Jay Bennett Lear Siegler Apistan Grand Rapids, MI (616) 451-6429

Pre-Symposium Seminar Coordinator/ Black Book:

David B. Turner Korn/Kerry International Los Angeles, CA (408) 945-9600

ANSI Standards Coordinator: Herman "Spence" Spencer Army Research Institute Alexandria, VA (202) 294-9420

Member-At-Large: Larry w. Hicks Relational Database Services Kernersville, NC (919) 996-4882

Member-At-Large: Richard Arndt Cognos Corporation Houston, TX (713) 690-1105

AI SIC Liaison: David Slater Institute for Defense Analysis Alexandria, VA (703) 845-2200

Datatrieve Liaison: John Schutt J. R. Simplot Company Boise, ID (208) 336-2110

DEC Counterpart: Wendy Herman Digital Equipment Corporation Nashua, NH (603) 881-2494

OMS-ii

Contributions

Contributions to the newsletter can be sent to either of the following addresses:

Editor, DMS SIG Newsletter c/o DECUS U.S. Chapter 219 Boston Post Road, BP02 Marlboro, MA 01752

Russ Poisson DMS SIG Newsletter Editor SEED Software Corporation 2121 Eisenhower Avenue Alexandria, VA 22314

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 SPR's submitted to DEC, etc. Machine readable input is highly desirable. Submitters should keep in mind the DECUS policy on commercialism.

Calling All Hands

DMS SIG is in need of a Membership Coordinator. If you are interested in this leadership position within the DMS SIG, please call the DMS SIG CHAIRMAN Joseph F. Sciuto at (202) 274-9420.

Volunteers Needed - Volunteers are needed to participate in user panels, chair sessions, and help in the DMS SIG campground at the Spring '86 DECUS Symposia. volunteers should call the DMS SIG Symposia Coordinator Keith Hare at (614) 587-0157.

DMS-1

EXAMINER & 4~1Jj ltsputr~

The Wombat

"Increases the Circulation of Anyone in America" Volume 7 Number 8

DTR/4GL Special Interest Group - Officers

SIG Co-Chairmen Larry Jasmann U. S. Coast Guard 10067 Marshall Pond Rd. Burke, VA 22015 Joe H. Gallagher Research Medical Center 2316 East Meyer Blvd. Kansas City, MO 64132

Communications Committee Rep. Editor

Elaine McWilliams Boeing Company P. O. Box 24346 M/S 9c55 Seattle, WA 98124 Donald Stern Warner Lambert Company 10 Webster Road Milford, CT 06460

Production Editor Artist

Steve Cordiviola Kentucky Geological Survey 311 Breckinridge Hall Lexington, KY 40506 Bart Z. Lederman 2572 E. 22nd St. Brooklyn, NY 11235

Symposia Symposia Committee Rep. Chris Wool E.I. duPont Eng. Dept. Symposia Assitant Pre-Symposia Seminars Symposium Notes

Product Development

Diane Pinney Dana Schwartz

Computer Sciences Corp.

Elaine McWilliams Boeing Company

Louviers Bldg. 443 Inyokern Road 15719 Millbrook Lane P.O. Box 24346 M/S 9c55

Wilmington, DE 19898 Ridgecrest, CA 93555 Laurel, MD 20707 Seattle, WA 98124

Development Coordinator Bart Z. Lederman New Product Focal Point Diane Pinney

2572 E. 22nd St. Brooklyn, NY 11235 Computer Science Corp. Digital Equipment Corp.

443 Inyokern Road Ridgecrest, CA 93555 Digital Counterpart Andy Schneider 110 SpitBrook ZK02-2/N59 Naushua, NH 03062

Library Committee Rep. Volunteer Coordinator Campground

Computer Science Corp. Computer Science Corp. U. S. Coast Guard U. S. Army

443 Inyokern Road 443 Inyokern Road 500 Camp Street 32 Pearce Ave Special Effects

Special Consultant

Gerri Wi 11 i ams Gerri Wi 11 i ams Bert Roseberry Alex L. Lamb Phil Naecker J M Montgomery Engineers 250 N. Madison Ave

RSX,P/OS,VMS Bart Z. Lederman PRO, VMS Joe H. Gallagher VMS Joe Kelly VMS Larry Jasmann VMS James Swanger VMS Chris Wool VMS Dick Azzi VMS Chris Heinz VMS Bert Roseberry

DTR/4GL Masters List

Research Medical Center WymAn Gordon Co. U. S. Coast Guard G. D. Searle & Co. E. I. duPont, Engineering Dept. Motorola SPS

2572 E. 22nd Street 2316 East Meyer Blvd. Worchester Road 10067 Marshall Pond Rd. 4901 Searle Parkway Louviers Bldg. Box 2953 MS: P116

American Board of Family Practice 2228 Younge Drive U. s. Coast Guard 500 Camp Street

DTR-i

Ridgecrest, Ca 93555 Ridgecrest, Ca 93555 New Orleans, LA 70130 Eatontown, NJ 07724 Pasadena, CA 91101

Brooklyn, NY 11235 Kansas City, MO 64132 North Grafton, MA 01536 Burke, VA 20015 Skokie, IL 60077 Wilmington, DE 19898 Phoenix, AZ 85062 Lexington, KY 40505 New Orleans, LA 70130

2-23-86

202-426-2344 816-276-4235

206-773-0102 203-878-9351 606-257-5863 718-743-9593

302-366-4610 619-446-6585x284 301-859-6277 206-773-0102

718-743-9593 619-446-6585x284

619-446-6585x285 619-446-6585x285 504-589-4934 201-532-3318x1843 818-796-9141

2-23-86

718-743-9593 816-276-4235 617-839-4411x5480 202-426-2344 312-982-7430 302-366-4610 602-244-4316 606-269-5626 504-589-4934

Contributions

Contributions for the newsletter can be sent to either of the following addresses:

Editor, DATATRIEVE Newsletter DECUS U.S. Chapter 219 Boston Post Road, BP02 Marlboro, MA 01752

Donald E. Stern, Jr. Warner Lambert Company 10 Webster Road Milford, CT 06460

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

DECUS U. S. Chapter SIGs Newsletter, Wombat Examiner,

Volume 1, Number 8, Volume 7, Number 8

2 Chairman's Corner 2 From the Editor's Pen

APRIL 1986

3 DTR/4GL Sessions at Spring 1986 Symposia 5 VAX-DATATRIEVE Internals

12 DATATRIEVE-11 to VAX-DATATRIEVE Conversion 20 Wombat Magic, Fall 1985, Part III

About the Cover

It is April tomfoolery time and the Wombat has always been .one to enjoy a practical joke or two. In seriousness, however, we are quickly approaching the Sping DECUS Symposia, where some very good information and fun are shared by all.

DTR-1

Chairman's Corner

Joe H. Gallagher, SIG Chair Elect, Kansas City, MO

Research Medical Center,

It's almost time for another symposium. Time has really flown since last December in Anaheim. This has been a time of a lot of change for me (a new job in a new town and a new job in the DTR/4GL SIG). I am looking forward to the activities in Dallas with great expectation. I was born and raised in Fort Worth so it will be a change to return to a familiar town; Digital will have "officially" announced their new fourth genera­tion language products, Rally and Teamdata; and I will again be a SIG chair (I was SIG chair of the PDP-9 and PDP-15 group called SIG-18 back in 1974 to 1979, and I should have been smart enough to keep them from talking me into this again).

The Dallas Symposium will be the 25th Anniversary of DECUS and there will be special activities: a real Texas Bar-B-Q, a keynote by Admiral Grace Hopper, birthday cake, memorabilia show, and trivia contest in addition to the usual quality sessions. The sessions sponsored by the DTR/4GL SIG are listed elsewhere in this issue. "Karnak the Befuddled" is also scheduled to make another appearance at Wombat Magic and the SIG is trying to ar­range a special door prize for everyone for Wombat Magic.

The weather should be great in Dallas during the sympo­sium. So I'll look forward to seeing you there and greeting you with a great big Texas "Howdy."

From the Editor's Pen

Donald E. Stern, Jr., Warner Lambert Company, Milford, CT

By the time this issue of the newsletter reaches the readership, the Dallas Symposium should be rapidly approaching. The DTR/4GL SIG is once again planning a full range of sessions from Novice to Advanced/Technical in orientation. In addition, pre-symposium seminars have been organized and will be well worth attending. As always, a WOMBAT MAGIC session has been scheduled and should definitely be placed on your "must attend" list of activities.

An issue of the Wombat Examiner and 4GL Dispatch would not be complete without the editor's plea for reader participation. Please help keep the newsletter vital by contributing an article, a problem, or a solution to a problem.

See y'all in Dallas!

DTR-2

DTR/4GL SIG SESSIONS at U. S. DECUS SPRING 1986 SYMPOSIA

Chris Wool, DTR/4GL Symposia Committee Representative

This is a preliminary listing of talks scheduled for the U.S. DECUS Spring 1986 Symposium.

Attendees are warned to watch UPDATE.DAILY at the symposia for schedule updates.

================================================================

Campground ------

The DTR/4GL and Data Management SIGs will share a camp­ground in Dallas. There will be a MicroVAX II and PR0/350 in the campground and they will have DATATRIEVE, 4GL, and VIA products available for demos and aiding in solving any problems you may have.

SUITE

The DTR/4GL and Data suite at Loews Anatole Hotel although there are no hotels vention). Look for the suite tion booth.

Management SIGs will also share a (this is the official DECUS hotel, officially associated with the con-

number at the convention registra-

Bookstore ------

The DECUS bookstore will carry souvenirs including Wombat magnets and pins. The pins will have a special anniversary sale price this symposia, so be sure to pick-up a few for your friends and fellow workers back home.

Pre-Symposia Seminars ------

DTR/4GL SIG will sponsor two pre-symposia seminars on Sunday, April 27.

9:00 - 5:00 9:00 - 5:00

SESSIONS -----

9:00- 10:00 12:30- 1:30 1:30- 2:30

2:30- 3:00

Basic DATATRIEVE Advanced VAX-11 DATATRIEVE

Monday

DMS and DTR/4GL SIGs Opening Session What are 4th Generation Languages Anyway? VAX TEAMDATA and VAX RALLY: New 4th Generation Solutions What is ADE?

(Continued ... )

DTR-3

3:00- 4:00 3:00- 4:00

3:00- 4:00 5:00- 6:00

6:00- 7:00 7:00- 7:30 7:30- 8:00

8:00- 8:30

9:00-10:00 10:00-11:00 11:00-12:00 12:00- 1:00 1:00- 2:00

2:00- 3:00

3:00- 4:00 4:00- 5:00

5:00- 6:00

9:00-10:00

10:00-11:00 11:00-12:00

12:00- 1:00 1:00- 2:00 4:00- 6:00

9:00-10:00

10:00-11:00 11:00-12:00 12:00- 1:00 1:00- 2:00 2:00- 3:00

3:00- 3:30 3:30- 4:30

4:30- 5:30

5:30- 6:30 8:00-10:00

10:00-11:00 11:00-12:00 12:00- 1:00

Monday (continued) Accessing Remote Data with VAX DATATRIEVE Introduction to the A-to-Z Application Generator DECREPORTER - A Commercial Report Generator DATATRIEVE-11 Internals and Performance Optimization DATATRIEVE and RMS Tuning Using DATATRIEVE as a COBOL Code Generator A Case Study of a Job Description Reporting System The SAR Data Catalog System

Tuesday So What is DATATRIEVE Anyway? So Why use DATATRIEVE Anyway? Commonly asked DATATRIEVE Questions VAX DATATRIEVE Internals Technical Overview of the A-to-Z Application Generator Designing an Application using the A-to-Z Application Generator. Directions in 4th Generation Languages VAX DATATRIEVE to DATATRIEVE-11 Conversion Panel DATATRIEVE Novice Questions and Answers

Wednesday Design and Implementation Generation Language VAX RALLY Technical Overview

of a 4th

VAX TEAMDATA End-User Information Management TEAMDATA and RALLY Field Test Panel End User Computing with INTELLECT DATATRIEVE Software Clinic

Thursday Accessing Relational Databases through VAX DATATRIEVE VAX DATATRIEVE Record Definition Workshop DATATRIEVE Application Design Tutorial VAX DATATRIEVE Application Design Trade-offs Integrating DATATRIEVE and ALL-IN-ONE DATATRIEVE in the Epidemiological Research Environment DATATRIEVE Sequential File Record Deletes Calling DATATRIEVE-11 from High Level Languages Using VAX DATATRIEVE with the Forms Management System Customizing VAX DATATRIEVE Wombat Magic

Friday Using VAX DATATRIEVE Graphics Integrating DATATRIEVE, DECALC, DECGRAPH DTR/4GL SIG Closing Session

DTR-4

VAX DATATRIEVE INTERNALS Sue Harris, VAX DATATRIEVE Group, Digital Equipment Corp.

This article is a summary of the DATATRIEVE Internals talk which was presented at Fall DECUS 1985.

1 ARCHITECTURAL OVERVIEW

VAX DATATRIEVE is not just a sharable image, but a group of seve­ral interconnected sections we call the "BOXES". Not all of these are strictly a part of the product VAX DATATRIEVE, but the end user may see them as a whole:

o The underlying File Structures are of course, RMS, DBMS, and Rdb.

0

0

DATATRIEVE also has tightly connected interfaces to FORMS interfaces, CDD, and the DDMF (for remote proces­sing).

The main "BOX" containing most of the DATATRIEVE code consists of the sharable image (DTRSHR.EXE) and the terminal server (TERMSERVE.OLB).

o •The "top level" of DATATRIEVE consists of ADT, EDT, GUIDE, HELP, the interactive task DTR32xx.exe, and callable programs. All of these are 'separable' por­tions of VAX DATATRIEVE that can interface to the main box.

2 DATATRIEVE STARTUP TASKS

Two activities occur upon DATATRIEVE startup: image activation and DATATRIEVE initialization.

Image activation is actually performed by VMS on behalf of DATA­TRIEVE; however, since it does add to the startup time it's use­ful to review. The sharable images linked with VAX DATATRIEVE are DTRSHRxx, CDDSHR, VMSRTL, LBRSHR, SCRSHR, and optionally, FDVSHR, if you specified FMS support.

Note that the list of images is significantly smaller than in pre-V3.2 releases; now VAX DATATRIEVE does dynamic image activa­tion for DBMS, Rdb, TDMS, SORT, and EDT (VAX DATATRIEVE cannot do dynamic image activation for the FMS image).

DATATRIEVE initialization begins with initialization of a user DAB (a DATATRIEVE ACCESS BLOCK is used internally for each inter­active DTR user, as well as for callable programs). Next, DATA­TRIEVE allocates memory for its internal data structures, and loads the Hash table.

DTR-5

The Hash table is an locate (via a hashing time, DATATRIEVE must UDKs, function names,

internal data structure used to hold and algorithm) all known 'names'. At startup enter into the Hash table all keywords,

and synonyms from startup files.

The next step in initialization consists of 'signing in' to the CDD. The CDD, itself, will translate the logical name CDD$DEFAULT and will ultimately be the one to actually open the CDD.DIC file (and any appropriate subdictionary files which exist for the default pathname).

Next, DATATRIEVE initialization called SYS$SCRATCH:DTRWORK.TMD. later in processing to maintain tions, SORTs, etc.

will create a temporary work file This work file will be used

record-ids for records in collec-

Finally, DATATRIEVE will translate the logical names SYS$CURRENCY, SYS$RADIX POINT, SYS$DIGIT SEP, DTR$DATE INPUT, and will execute the DTR$STARTUP and DTR$SYNONYM files. -

3 DATATRIEVE STAGES

Datatrieve commands and statements are processed one at a time. A different path is taken depending on whether the user input to DTR is a command, a statement, or a statement involving remote access. The steps in these paths are called stages:

LEXICAL ANALYSIS

PARSING

I --------------------1------------------ I COMMAND EXECUTION I ---------------------

!STATEMENT PRECOMPILATION I

!STATEMENT COMPILATION

I ---------------------------1------------------ I STATEMENT DECOMPILATION I I ---------------------------

!STATEMENT EXECUTION

DTR-6

3.1 Lexical Analysis

The user lines typed in response to the DATATRIEVE prompt are the input to the lexical analysis phase. The object of this phase in DATATRIEVE processing is to produce TOKENS. Tokens are the low­est level syntactic element and they consist of keywords, identi­fiers, punctuation, numbers and quoted strings.

Example:

FOR FIRST 5 YACHTS PRINT BUILDER, "QUOTED STRING"

Tokens produced:

FIRST 5 YACHTS PRINT BUILDER

,''QUOTED STRING" *** END OF LINE ***

During this phase, DATATRIEVE will also do Hash table lookups. That is: names, keywords, and identifiers are checked against the values in the Hash table. If the token is in the Hash table, an association is made between the token and the Hash table value.

Remember that the Hash table contains most known 'names': key­words, UDKs, synonyms, function names from startup time; domain names, list names, and DBMS set names from READY commands; syno­nyms from DECLARE SYNONYM, collection names from FINDs, and table names from the use of VIA or IN clauses.

During this phase, DATATRIEVE will also do its line continuation ("Looking for xxx ... " messages), and !CMD and !VAL substitution for input from callable programs.

3.2 Parsing

The input to this stage is the list of tokens produced from the lexical phase. The main task of this stage is to do syntax veri­fication and to create a data structure which delineates each syntax element of the input statement. This data structure is called the 'syntax tree' because it is represented and interpret­ed internally as a hierarchical structure.

Example:

FOR FIRST 5 YACHTS PRINT BUILDER, "QUOTED STRING"

The 'syntax tree' which is built by parsing this statement:

FOR RSE

PRINT: PRINT LIST

DTR-7

The data structure obviously contains more information than is presented here, but the main point of this diagram (and subse­quent ones) is to identify the overall structure. In this case, the important fact is that the input statement has been decompos­ed by DATATRIEVE into its syntactic elements of an RSE, followed by a print list.

Another very important task of this stage is to determine whether or not the user typed a command or a statement. If the input was a statement, then the 'syntax tree' structure we just examined will be created and more stages of processing will be needed for the statement.

If, however, the user typed in a command, the processing for the command is totally different. To explore this further we need to discuss the next optional stage of processing.

3.3 Command Execution

Commands change the environment and create a link to data; state­ments are context controlled and manipulate data. Statements need stability of the environment to allow DATATRIEVE to do com­pilation of the statements, and especially, to allow optimization of the statements. Therefore, commands must be processed immedi­ately after parsing (this is also why commands cannot be embedded in statements).

As an example, consider the command READY YACHTS. The output from executing this command is that a hierarchical data structure called the 'field tree' is built to describe all the fields for the domain. This hierarchical structure is built by repeated calls to the CDD for each field in the domain, and contains ALL known information about each such field. ·

Also, as part of the READY command, the RMS file will be opened if the domain was based on an RMS source; the form library, if any, is opened; the domain name is entered into the Hash table; names for any list fields in the domain are entered into the Hash table.

Note that these results of the READY command provide context for subsequent statements.

3.4 Statement Precompilation

If the user had typed in a command, then the stage of command execution completes the processing for that input. If however, the user typed in a statement, there are additional stages of processing. The precompilation stage is the next, and takes as its input the 'syntax tree' structure which was created by the parsing stage.

The main job of this stage is to do a 'binding' to the environ­ment, since the environment is determined to be stable (for at least the rest of this statement). There are really 3 types of binding which are done:

DTR-8

o Name resolution using the Hash table. For example, if the name is not found, you might see the error message '"YACHT" is not a readied source, collection, or list'.

o Context searching and resolution.

o Expansion of the input 'syntax tree' to include infor­mation about the environment. For example, group items in print and modify lists will be expanded into the individual field items. Views will be expanded into the structure by essentially expanding the RSEs from the view into the 'syntax tree' for the statement.

The result of this binding to the environment is essentially the same 'syntax tree' but with expansions, and with contexts and names resolved.

Finally, this is the last phase during which the dictionary is accessed, and it is the phase during which plots are loaded into memory, if needed.

3.5 Statement Compilation

The input to-this stage is the 'precompilation tree' structure. The main tasks of this stage are to construct and optimize record streams, to optimize and datatype all values, to factor invariant expressions from loops, to compile Rdb requests to BLR, and to determine if this statement is a request for remote access.

The output of this stage is another hierarchical data structure called the 'execution tree'.

Example:

FOR FIRST 5 YACHTS PRINT BUILDER, "QUOTED STRING"

The output 'execution tree' is:

FOR FIRST 5 OF <get first/next record from the yachts file; nonkeyed>

PRINT PRINT-LIST (first column:l last column:l4)

PRINT FIELD: MANUFACTURER PRINT CONSTANT: "QUOTED STRING"

Note the level of detail in this example: DTR has determined that it cannot use keyed access to this file and it has analyzed the field datatypes and lengths enough to know the exact output for­mat.

When you run the DATATRIEVE image in debug mode, DTR prints out additional informational messages during the compilation stage. For example, if" DTR had decided that it could use keyed access to the YACHTS domain in the above example, it would print a message indicating the type of keyed access (EQ, GT, etc.) and the name of the keyed field.

DTR-9

3.6 Statement Decompilation

If the Statement Compilation stage had determined that the state­ment needed remote access, processing would be diverted at this point to do statement decompilation. Remember that DATATRIEVE's remote facility must interface to DTR-11 and DTR-20, which cannot interpret VAX DATATRIEVE's internal structures. So, the task of this stage is to 'decompile' the internal data structure for the statement back to an external statement suitable for sending to the remote facility (note that much of the error checking for the statement has already been done on the host system).

Since remote access is a separate and large topic in itself, it will not be discussed further here, except to note that by run­ning VAX DATATRIEVE in debug mode, you can see the commands which are sent to the remote server. The commands are also logged on the remote system in NETSERVER.LOG.

3.7 Statement Execution

Note that up until this point, only internal data structures have been built; no user data has been accessed yet.

The input to this stage is the 'execution tree' built by the compiler. DATATRIEVE 'walks' this data structure, finally doing the real work:

o Manipulates the data

0 Does output of PRINTS and REPORTS

0 All RMS locking is done at locking is done on behalf of stage

this level; Rdb and DBMS the DTR user during this

o DTR interacts with the "User" (prompts, etc.)

It's interesting to note that while this stage is finally doing the real work, it is also a "dumb" stage in the sense that it can only do what has been determined by the compiler: it can only follow the 'execution tree' and do what it implies.

Looking back at the example 'execution tree' from the compilation stage, realize that DATATRIEVE will interpret the FOR structure as a loop. It will look at the data structures which are hierar­chically subordinate to the FOR, execute each, and loop back to the FOR again, until there are no more records in the YACHTS file.

4 PROCEDURE CONSIDERATIONS

Procedures are stored as text strings, they are NOT stored in a compiled form. This is necessary because of the dynamic changing of the environment that DATATRIEVE allows: each statement is compiled based on the current set of names and contexts, not based on a 'static' set of names and contexts that existed at the time of a compile.

DTR-10

The entire procedure is expanded into tokens at one time in order to minimize dictionary access, but other stages are done a com­mand or statement at a time. This is what allows commands to create the context for subsequent statements.

Note: compound statements unit. This has important consider.

are treated implications

as a SINGLE compilable which you may want to

For example, use of loops (REPEAT, WHILE, FOR) are more efficient than executing a procedure which must repeatedly be compiled for every invocation.

Also realize that CHOICE statements are compiled as one unit -­including any sub-procedures that the CHOICE statement may in­voke. One unexpected side effect of this is that CHOICE state­ments may sometimes 'seem' slower than multiple IF-THEN state­ments. Ultimately, the same amount of work must be done for both, but the CHOICE can seem longer because ALL choice options must be compiled before any execution (any user interaction) is seen, whereas if multiple IF-THENs are used, some user interaction may be seen earlier if the chosen alternative occurs early in the list.

To avoid compilation of unused choice alternatives, you can po­tentially use logical names:

Example:

DECIDE IT= *."Value to choose" IF DECIDE IT= 1 THEN FN$CREATE LOG ("proc", "procl") IF DECIDE-IT= 2 THEN FN$CREATE-LOG ("proc", "proc2") :PROC -

In this example, only the chosen procedure is compiled by DATA­TRIEVE.

4.1 Collection Considerations

While FIND is technically rated as a statement, it also puts the collection name in the Hash table, which is essentially a kind of 'context' operation. Subsequent statements need that name to resolve context. FINDs, therefore, are not recommended in com­pound statements because collection references must be after the entire compound statement completes. This is also why SELECTs are not supported in BEGIN/END blocks.

Example (not supported!): READY YACHTS, OWNERS FIND ALL YACHTS

BEGIN

END

FIND OWNERS SELECT PRINT

~ Note: A YACHTS record is printed! stead:

DTR-11

Should use FOR statement in-

READY YACHTS, OWNERS FIND ALL YACHTS

BEGIN

END

FOR FIRST l owners PRINT

DATATRIEVE-11 to VAX-DATATRIEVE Conversion Panel

Joe H. Gallagher, Research Medical Center, Kansas City, MO 64132 Bart Z. Lederman, Greenberg Bros. Part., New York, N.Y. 10010

Transcribed by B. Z. Lederman

This session was originally planned to be a recounting of users' experiences in converting to VAX-DTR from DTR-11. Due to various difficulties which arose between scheduling the session and the symposium (such as non-functioning equipment, and jobs being eliminated), the final panel had to speak partially from experience and partially on generic terms. Nevertheless, many important points were covered, and the information was judged to be quite useful by those attending the session. This is not intended to be an exact transcription of the session: rather, it simply presents the information in a readable form. I will not attempt to distinguish which person made what contributions. I would also like to acknowledge the presence of Suellen Harris and Bill Opalka from DEC, who sat in the audience and kept us from going astray.

Major Points.

DTR-11 is an almost perfect subset of VAX-DTR.

DTR-11 is a nearly perfect subset of VAX-DTR. It was, of course, developed first and VAX-DTR was developed later using the same syntax so users could migrate. The primary point of diffi­culty has to do with a difference in how the hardware addresses memory. The PDP-11 cannot address a word which starts on an odd byte boundary, while the VAX can: therefore, such data types as REAL, DOUBLE, INTEGER, DATE, and other word, double word, and quad word variables, must be aligned to word boundaries on the PDP-11. DTR-11 will automatically do this by inserting invisible bytes where needed. Consider the following record definition:

01 RECORD. 10 FIELDl PIC X. 10 FIELD2 PIC 99 USAGE IS INTEGER. ;

FIELDl is one byte long, and FIELD2 is two bytes long. In VAX-DTR, this record would be 3 bytes long: on the PDP-11, it will be 4 bytes long, as an extra byte has to be inserted between the two fields to make FIELD2 start on an even byte boundary. DTR-11 will do this wherever necessary (and only where neces­sary), and does not issue warnings or error messages. This will become apparent if the data files are moved from one system to

DTR-12

another, and the same record definition is used on the VAX with­out taking precautions. It is possible to make VAX-DTR allocate on word boundaries by using the clause

"ALLOCATION IS LEFT-RIGHT"

within the record definition; therefore, you should change the record definition to:

DEFINE RECORD TEST REC USING ALLOCATION IS LEFT-RIGHT 01 RECORD. -

10 FIELD! PIC X. 10 FIELD2 PIC 99 USAGE IS INTEGER. ;

If you do this, VAX-DTR will allocate space in the same way as DTR-11, and there should be no problems. If you don't, you may get an error message similar to "RECORD LENGTH DOES NOT MATCH" when you try to READY the new domain on the VAX, which is an indication that you may have an alignment problem. See also the section on moving data below.

If you do get these messages, and don't do anything about it before storing new data, you will corrupt the data file. It would be a good precaution to be certain that the first time you READY the domain after moving the data that you do so READ ONLY, and look at the data. If there are any alignment problems, you will immediately see that data isn't coming out correctly, and can take corrective measures.

Planning the move: more dictionary options.

The Common Data Dictionary has more functionality than the dic­tionaries on the PDP-11, and some thought should be given to using this. On the PDP-11, there is often a separate dictionary for each application, and the data files often aren't shared. On the VAX, all definitions go into the CDD, which makes sharing easier. The CDD has a hierarchical structure, and if you have many separate projects you will want to plan which sub­directories should hold what definitions, and which definitions should go into a site common directory (for everyone to use), which should go into project wide directories, and which may be left in individual directories. The protection options are also greater on the VAX than on the PDP-11: if you are not using protection now, then you can move with no protection without making any changes. If, however, you have been using UIC type protection on the PDP-11, then you may want to change, as it is unlikely that you will keep the same UIC scheme on your VAX disks that you had on your PDP-11 disks (VMS does have UICs, but most people go to named directories and hierarchical sub-directories, as these tend to be easier to use and more closely follow the way most data is organized). Therefore, you may want to change UIC and/or password protection, and use some of the new protection options available in VMS.

You do not have to learn much about the CDD before moving if you do everything in DTR. You can put everything into one dictionary like DTR-11, but you will get better performance if you make a

DTR-13

good division from the beginning. You can move definitions from one sub-section to another later, but it's best to make some plans first. A quick read-through of the manual to understand the concepts, or attending some DECUS sessions are good ideas. For the new user, no new training is needed to begin with, as they will see a dictionary just like what they are used to (with the addition of version numbers), and can see one big dictionary or their own dictionary, whichever matches the PDP-11 installa­tion; but the person planning the move and organizing the appli­cation should know something about the CDD. The CDD structure can copy the existing PDP-11 setup, but usually matches the com­pany or application organization. Arranging the dictionary well has both performance and maintenance advantages. Note also that VAX-DTR can have startup files for individual users just as DTR-11 has, to put individuals into the proper dictionary and perform READYs or start procedures, as needed: also, the dictionary that the user sees for PLOTS can be different from that for all other dictionary elements, so the users can get all of their domains, records, procedures, and tables from an individual dictionary, and at the same time get the PLOTS from the system wide diction­ary. You might also give them a procedure to set their dictionary into the system wide DEMO library if you want them to play with YACHTS, EMPLOYEES, or other sample files supplied with DTR. There is also a command procedure NEWUSER.COM that comes with DTR that can be used to easily set up a dictionary for a new user. In addition, there is also a logical name that designates the CDD dictionary in which the user will start.

Moving the data.

One must move both the data files, and the dictionary objects (record definitions, domain definitions, tables, etc.). You can EXTRACT individual definitions, but DTR-11 is supplied with a utility called QXTR, which will extract all of the definitions in a dictionary at one time into a single command file in a manner similar to EXTRACT ALL in VAX-DTR. This utility inserts the "ALLOCATION IS LEFT-RIGHT" clause into the record definitions, which should simplify the move considerably. [This is probably true only for DTR-11 V3.0 and V3.l, and not for earlier versions of DTR. QXTR is not supplied with PRO-DTR. DTR-11 itself does not insert the ALLOCATION clause when extracting.] If you are using individual dictionaries for different users, you must ex­tract each dictionary individually. QXTR also gives you the op­tion of extracting the protection qualifiers, or not, as you choose. This single file can then be moved to the VAX and invok­ed to re-create all of your records, tables, domains, etc. One factor not covered in the original talk is that explicit referen­ces to disks and/or directories in domain definitions will proba­bly have to be changed, as your device names will change, and you will probably be using symbolic device names and/or named direc­tories, as mentioned before. To actually get the information across, there are several options.

Moving data on disks.

If you are using RSX (which in this paper includes llM, llM-Plus, IAS, and possibly llD), and you have the same kind of

DTR-14

disk drive on both systems, or are going to move the disk drive to the new system, then you can read your old disks on VMS. You will want to copy the information to a new disk, to take advant­age of some VMS features like named directories, but the files can be read while on the old disk, or copied. This applies both to the data files, and the file created by QXTR (or the DATA­TRIEVE EXTRACT command). If you are running RSTS/E, then you are out of luck: no other operating system will read your disks. If you don't have a disk type in common on both systems and are not moving the devices, you might want to consider plugging in your old disk on the VAX just long enough to copy the data, if possi­ble. If not, then the local DEC office may be able to copy the disks, or your local DECUS LUG may help you find a user who may let you do it, or you may be able to locate a commercial service company that will do it.

Moving data by Network.

If both systems run DECNet (no matter what the operating system), then any file that DATATRIEVE can read can be read over the network. You can COPY (or NFT or FTS) the file with the definitions to the VAX, define your domains, copy the data file, and be ready to go. Alternatively, you can define two domains with the same record definition, with one having a normal file specification on the VAX, the second having a file specification which includes the node name for the PDP-11 (something you can do with VAX-DTR but not DTR-11); or what may be better, if you have remote DATATRIEVE installed on the PDP-11 you can use the "READY domain AT node" feature of VAX-DTR, and simply read from the old domain on the PDP-11 to the new domain on the VAX. This will be a little slow, as DTR is not optimized for this type of operation the way DECNet utilities are, and the data will be going over the network, but hopefully it will only be done once. The advantage of doing this is that it can avoid the problems of record align­ment mentioned before. By using the DTR-11 remote server on the PDP-11, the data will be read exactly as it has always been read: on the VAX side, you can define a record without the ALIGNMENT clause, and pack the data in without worrying about hidden bytes. You may also want to consider other methods of converting data mentioned below. Remote DATATRIEVE is available starting with V3.0, not in earlier versions. If you are not using DECNet, you may not have special communications devices normally used for networking. DECNet will work over normal asynchronous lines used for terminals, however. You may have to give up 8 or 16 lines for a while, as DECNet grabs the entire device on PDP-lls, and the maximum speed may be 9600 baud so transfers may be a little slow, but hopefully you will only do the conversion once. If you don't have DECNet, maybe you can persuade the local office to let you use it just for a few days while you move your data.

Moving data on Magnetic Tape.

If both systems have magnetic tape (or you are moving the tape drive), you may be able to store the definitions and infor­mation on tape. Once again, the RSX family provides the best compatibility, with most systems writing ANSI tapes which can be read by VMS. (On earlier RSX systems, this was a SYSGEN option, so check carefully before you write out the tapes and disconnect

DTR-15

your PDP-11.) If not, you can write DOS-11 format tapes on all RSX family systems which can be read on the VAX with FLX (in compatibility mode) or the new EXCHANGE utility. Though you might possibly get indexed files over if transferred in image mode it will be much more safe if you first convert the data to a sequential file and re-construct it on the VAX, as will be men­tioned again later. If you have RSTS/E, then you are again stuck with a system which works differently than everyone else. You might be able to generate DOS-11 format tapes, or you may want to upgrade to V9.0: this is the latest version of RSTS/E, and it includes a utility which writes tapes that are compatible with the VMS BACKUP utility. For RSTS/E users this will probably be the easiest way to move files, though V9.0 is a new release and those of us on the panel have not yet had any feedback from users. Moving data from RSTS/E to other systems can be so much of a problem that some people plan to upgrade to RSTS/E primarily for the purpose of being able to use the new utility to write VMS readable tapes with the new utility.

There is an RMS utility set, BCK and RST, which is intend­ed for backing up files to and restoring files from magnetic tape. These utilities automatically convert indexed files to a form which will store properly on magnetic tape, and place error checking and other useful information on the tape for all types of files. Because they are supplied as part of RMS, they should be available on all PDP-11 systems (that can run DATATRIEVE). The problem is that VMS may not have a utility corresponding to RST to get the data off: so unless you have compatibility mode on your VMS system (and it is now an optional layered product), this may not be a viable option.

Other file transfer methods.

If none of the above are available, you may want to look into some of the communications packages which will operate over normal serial (terminal) lines. KERMIT is a public domain pro­gram available from the DECUS library (and elsewhere) which runs on virtually any computer and operating system, will work on serial lines, does error checking, and can transfer (in most cases) both text and binary files. It may be slow, but it will work. There are also other communications packages that perform similarly: you may even be able to use SET HOST/DTE/LOG on the VAX to go in to the PDP-11 and type the file out (this works best if the data is all text) or a similar "dumb" text transfer.

Re-Organizing your data.

VMS has some options not available on the PDP-11 for in­dexed files, notably Prolog-3, which allows some space saving. Since indexed files should be re-organized occasionally for best performance, and since the same data will occupy less space in a sequential file and take less time to transfer over net­works, and transfer more easily on magnetic tape, the time of transfer would also be a good opportunity to re-organize and optimize the data file by converting it to sequential, and re­populating an indexed file on the VAX. Even if you can move your disk packs and can read your old files directly, re-organizing at

DTR-16

this point is a good idea, though in this case you don't have to convert to an intermediate sequential file.

First, you need a description of the current indexed file: you can simply make a note of the record length (which you get from DTR when you define the record), and figure out where the keyed fields are in the record, but there are two RMS utilities, the older DSP and the newer DES which are designed to record file characteristics and define new files: it's a good idea to have such a description file for documentation purposes, even if you aren't anticipating a conversion. DES creates a file definition which is quite similar to that used by the VMS FDL utility: in actual tests, I was very surprised to find that FDL will actually read the descriptor file produced by DES! It may give you a few warning messages, especially if the SOURCE and TARGET fields are empty, but this shouldn't cause any serious problems. If the utility refuses to read your descriptor file and aborts, check to see that when you transferred the description file over it did not pick up trailing blanks on the description items, and that the file position qualifier says NONE with no numbers trailing. You can use a regular text editor such as EDT to go over the file before reading it with EDIT/FDL if necessary to touch it up. If you don't take this approach, then you can move the record defi­nition, define a domain and define a file: DTR will create a file that matches the record definition. You can then look at that file with EDIT/FDL if you wish, or do the optimization shown below. If you move your disk packs FDL can probably read your original data file, and may also be able to do this over the network if you are using DECNet.

Converting the data file from indexed to sequential on the PDP-11 is quite simple: the CNV utility will perform this con­version by default. Simply give the name of the indexed file on input, and the file name you want for the sequential file on output.

Once the file description and the data file are on the VAX, you can populate the file with CONVERT: however, now would be a good time to review the file design for possible performance improvements. The FDL utility (EDIT/FDL) has an OPTIMIZE script which can make the decisions a little easier, as it will look at your data file and give you some information about what can be done to improve access. The one factor which comes up quite often is bucket size: on the PDP-11, bucket size is almost al­ways the smallest possible value that will hold the record size you are using, as larger buckets use up pool space. On the VAX, this is no longer a problem, and larger bucket sizes are a viable option. If you often retrieve records which are next to each other, such as retrieving a record by the primary key and then reading the next several records in order, then a larger bucket size may improve performance. If, however, you retrieve records scattered all over the file in no particular order, then a larger bucket size won't help and may hurt, but a different index struc­ture may be of benefit. If you don't know what options to take, use the FDL utility and let it optimize: it will usually take reasonable options. Once this is done, you can populate a new file again with CONVERT.

DTR-17

Combining related domains.

Another consideration in DTR-11 is that the data is some­times separated into several domains rather than one, to prevent the record definition and buffers from getting so large as to use up all of your pool space. When converting to VAX-DTR, you may want to recombine them by moving all of the individual files (and domain definitions) over, define a VIEW to combine them and a single record definition with all of the fields, and read from one into the other. This may be a little slow, but again, this will only be done once. You will then want to use FDL as descri­bed before to optimize the new combined file.

Reports.

For reports, the VAX-DTR works very much the same as DTR-11. If you have reports which are adjusted so that field breaks occur just at the beginning or end of a page, or are otherwise 'finagled' to match a pre-printed form, you may find that you have to do a little adjustment to the lines per page or number of lines skipped qualifiers, but most straight forward reports will work with no changes.

Expanded features in VAX-DATATRIEVE.

Tables.

While VAX-DTR has dictionary tables just like DTR-11, it also has domain tables: this allows data in a domain to also be accessed like a table. One field (preferably a keyed field for good performance) takes the place of the "left" side of the ta­ble, and another field (any one in the domain) takes the place of the table entry on the "right". Dictionary tables are faster for small tables: domain tables can be faster for large tables if keyed fields are used, can take the place of several tables, and can also be accessed as a regular domain, which makes changing the table the same as modifying the data in any other domain; therefore, tables which are modified often are easier to maintain as domain tables.

Functions.

VAX-DTR has all of the functions (MIN, MAX, TOTAL, etc.) that DTR-11 has, plus several more (standard deviation, and run­ning count, for example). In addition, there is a new set of functions of the FN$xxx family which can do things like convert lower case text to upper case, move sub-sections of text strings, format output strings, get system information, do mathematical operations, and many other functions. If that isn't enough, you can add your own functions. In many cases, things that you are doing, perhaps with some difficulty, with procedures or COM­PUTED BY clauses may be much easier with the extra functions available in VAX-DTR, and a review of what you are doing may reveal some areas where improvements may be made. Though you may want to wait until your application is moved over and run­ning, this is an area where you will want to do some work quite soon after the move

DTR-18

No Pool Space Restrictions!

In DTR-11, procedures are often broken into small pieces to conserve pool space, and more things were done in command files. You may consider moving more of the work into DTR proce­dures, especially when you can get large blocks into single WHILE or BEGIN-END blocks. This may take a little longer to compile, but once compiled will execute faster than separate blocks.

In DTR-11, especially if your application was just on the edge of available pool space, things tended to be pared down to the minimum, especially in record definitions. Variable names were very short, edit-strings removed, etc. On the VAX, you have the opportunity to put more descriptive field names back in, and make the fields more self-documenting, put in query names, edit strings, and so on. Don't drop your good habits, however. Some users think they have infinite space on the VAX, and don't FINISH unused domains or RELEASE unused variables. This will cost you something eventually on the VAX (usually in paging), and it won't be as obvious as running out of pool space was in DTR-11: your application, or the whole system, just slowly degrades. You also may interfere with other users who want to access the data if you are keeping files open and are possibly locking records. You can keep domains open if you expect to use them again and save the time it would take to READY the domain, but when you are done with a domain you should FINISH it.

Other improvements.

All users will be happy to learn that VAX-DTR uses EDT when editing, rather than the built-in editor of DTR-11. If you have an EDTINI.EDT command file in your account, it will be used when you edit something in VAX-DTR; keypad and all other commands will work, etc. You will also notice that with the newer ver­sions of VAX-DTR, you have version numbers on definitions, so you can keep the old definition around until you find that the new version works. Users should be reminded to purge out old ver­sions regularly.

An option available in VAX-DTR is the use of FMS or TDMS to have form driven screens. After your data is on the VAX and working, you may want to start thinking of converting some of your old procedures, especially if they were working like menus, to form driven screens. Something you do need to consider before you do this, however, is whether to buy FMS or TDMS: they look very much the same to DTR, so the choice is often determined by what other software you are using. Some packages will require one or the other, (for example, All-In-One uses FMS) while DTR can work with either, one at a time.

There are various other features that are present in VAX­DTR (three types of concatenation rather than two, CROSS state­ments, the CHOICE statement, and all of the graphics capabilit­ies), which you will soon discover and will want to incorporate into your applications; but none are needed immediately for con­version, and you can wait to learn about them until after the problems of conversion are over.

DTR-19

Wombat Magic - Part 3 1985 Fall·DECUS Symposium, Disneyland Hotel, Anaheim.California

Session Chair: Bert Roseberry, U.S. Coast Guard, New Orleans, LA Session Editor: Donald Stern, Jr., Warner Lambert, Milford, CT

This is the third and final in a series Magic session held at the Fall symposium. is not presented in chronological order. presenter's comments are quoted.

reporting on the Wombat As reported, the magic Where appropriate, the

**** Rowland W. Fox, Digital Interface Systems ****

! ! ! 11 ! ! ! ! ! ! ! ! 2nd Prize Winner 11 ! ! ! ! ! I! 111 ! ! ! ! !

Rowland described a supervisory application at his site which included group field data.

03 GROUP! OCCURS 10 TIMES. 05 FIELD AA 05 FIELD-AB

03 GROUP2 OCCURS 5 TIMES. 05 FIELD BA 05 FIELD-BB

The problem addressed by this magic is "How do we modify the n'th value in a group field?"

FOR FOO FOR GROUP2 WITH RUNNING COUNT = n PRINT(or MODIFY) FIELD_BB

Operates on only the n'th occurance.

In order to get every n'th field in a group, the following will work:

FOR ALL FOO FOR GROUPl WITH FN$MOD(RUNNING COUNT,NUMBER OCCURANCES)=n PRINT(or MODIFY) FIELD_AB -

****Dana J. Schwartz, Department of Defense, "Moving the VAX Datatrieve Distribution Kit to Disk" ****

"Our site has many VAX systems and, of course, every one of them gets Datatrieve installed. I got tired of reading those little floppies and cassettes in every time I wanted to install Data­trieve on a system. I have taken some other hints that I got at

DTR-20

DECUS and other places and moved the save sets that are on those magtapes or floppies or cassettes onto disk."

WHY?

Installing from a disk file is much faster and reliable than floppy or tape, and if you do multiple installations on systems with DECNET interconnections or common removable disks, the kit only needs to be read ONCE (!) from the distribution media.

1. Set default to an existing directory in which distri­bution Save Sets are to be kept.

$SET DEFAULT SYS$SYSDEVICE:[KITSJ

2. Mount the DATATRIEVE distribution media.

$MOUNT /FOREIGN MTAO:

( Use appropriate device name instead of MTAO: e.g. CSAl:

3. Move the files to temporary directories.

$ BACKUP/LOG MTAO:DTR032.A/SAVE SET $ BACKUP/LOG MTAO:DTR032.B/SAVE-SET $ BACKUP/LOG MTAO:DTR032.C/SAVE-SET $ DISMOUNT MTAO: -

[ .AJ [.BJ [.CJ

( Use appropriate device name instead of MTAO: e.g. CSAl: ) ( Use appropriate version number in Save Set name DTRxxx. e.g. DTR032 is for DTR Version 3.2 ) ( With some media, you will need to mount successive volumes when prompted e.g. floppies or cassettes ) ( BACKUP will create the directories if they don't exist )

4.

5.

Recreate the Save Sets on disk and delete temporary directories.

$ BACKUP/LOG/DELETE $ BACKUP/LOG/DELETE $ BACKUP/LOG/DELETE $ DELETE A.DIR 1 $ DELETE B. DIR 1 $ DELETE C.DIR l

The resulting Save Sets etc. with DCL.

$ COPY /LOG DTR032.* -

[ .AJ [.BJ [.CJ

may

DTR032.A/SAVE SET DTR032.B/SAVE-SET DTR032.C/SAVE=SET

be copied, backed-up,

NODE12"SYSTEM pswd"::SYS$SYSDEVICE:[REMOTEKITS)

( for installation on remote system )

or

$ BACKUP/LOG/VERIFY -SYS$SYSDEVICE:[KITS)*.* -

DTR-21

MTAO:KITS.BCK/REWIND/DEN6ITY=l600

( a Save Set of Save Sets ! )

$DIRECTORY SYS$SYSDEVICE:[KITSJ

Directory SYS$SYSDEVICE:[KITSJ

CDD031.A;l 1953 23-MAY-1985 11:07 ( CDD ) DTR032.A;l 567 8-NOV-1985 13 53 ( DATATRIEVE DTR032.B;l 5418 8-NOV-1985 13 53 " DTR032.C;l 567 8-NOV-1985 13 55 FHLP043.A;l 504 18-SEP-1985 14 44 ( FORTRAN ) FORT043.A;l 882 18-SEP-1985 14 37 " GRAPH013.A;l 189 20-NOV-1985 11 17 ( DECGRAPH GRAPH013. B; 1 2205 20-NOV-1985 11 17 " PASCAL031.A; 1 2394 31-0CT-1985 15 03 ( P~SCAL PASSTR030.A;l 315 4-JUN-1985 17 00 VAXC021.A;l 2520 25-0CT-1985 13 41 ( c ) VAXFMS022.A 1 1260 8-JAN-1985 18 04 ( FMS VAXFMS022.B 1 819 8-JAN-1985 18 05 " VAXGKSOlO.A 1 2394 10-JAN-1985 17 17 ( GKS

Total of 14 files, 21987 blocks.

6. To install, give VMSINSTAL your Save Set directory name instead of the distribution volume name.

NOTE:

or

$ SET DEFAULT SYS$UPDATE: $ @VMSINSTAL DTR032 SYS$SYSDEVICE:[KITSJ

$ SET DEFAULT SYS$UPDATE: $ @VMSINSTAL

*Where will the distribution volumes be mounted: SYS$SYSDEVICE:[KITSJ

* * * * *

The files in the distribution kit ( DTRxxx.A, DTRxxx.B, and DTRxxx.C ) have been the same through the last several ver­sions, but you should check what is in any new kit before attempting this procedure on future releases. The methods I use are:

a. For tape-based kits:

$ MOUNT /FOREIGN Mxxx: $ BACKUP /LIST Mxxx: $ BACKUP /LIST Mxxx:

until End-Of-Tape, noting the Save Set names.

DTR-22

b. For disk-based kits:

$ MOUNT/FOREIGN Dxxx: $DIR Dxxx:[OOOOOO]

on each volume, noting DTRxxx.x names.

**** Rowland W. Fox, Digital Interface Systems ****

"We have a record that contains chemical analyses for about 100 elements". Input data should be validated depending upon the type of analysis being performed. For example, an analysis iden­tified by CODE 1 should have moisture content data (H20) between 0.10 and 5.12, an analysis identified by CODE 12 between 1.12 and 4.82, etc. If the limits for each code are stored in a domain, the data can be verified by a table lookup. The magic here is in the way the VALID IF clause specifies the lookup.

03 CODE PIC 99. 03 H20 PIC 9.99 VALID IF

(H20 BETWEEN ("H20 "11 CODE VIA MATLOW) AND ("H20_" I !CODE VIA MATH!)

Sample data from domain TEST LIMITS:

KEY LOW

H20 1 H20-12

Two tables are defined:

HIGH

0.10 5.12 1.12 4.82

DEFINE TABLE MATLOW FROM TEST LIMITS KEY : LOW

END TABLE

DEFINE TABLE MATH! FROM TEST LIMITS KEY : HIGH

END TABLE

****Wayne Jones, Digital Equipment Corp. -"Wine Rating System, Distribution of Ratings" ****

Wayne described a rather unique Datatrieve application that a colleague developed after making a trip through the Napa Valley tasting and rating the various wines of the area. The domain contained the data including such items as the name of the vine­yard, the type of wine, and a rating from 0 to 9.

DEFINE DOMAIN WINES USING WINES_REC ON WINES.DAT;

DEFINE RECORD WINES REC

DTR-23

03 VINEYARD 03 TYPE ... 03 RATING USAGE INTEGER.

The question of whether the assigned ratings followed some sort of a standard statistical distribution came up. In order to get a frequency of occurrence the following was done to get a count of all the unique occurrences of rating.

DEFINE FOO PIC 9 COMPUTED BY RATING.

READY WINES FIND WINES

SUM 1 BY FOO

3 2 3 4 4 6 4 9

The problem with this is that ratings of exactly 3 will produce one count, ratings of 3.5 another, and so on. In order to over­come this limitation the following was done.

DEFINE FOO COMPUTED BY FORMAT(RATING) USING 9.

SUM 1 BY FOO

3 6 4 15

In this case values between 3 and 4 are summed on one line, bet­ween 4 and 5 on the next, and so forth.

**** Jim McMillan, Arizona Supreme Court -"CHOICE in the Report Writer" ****

In his presentation, Jim reminded us that it is perfectly valid to use the CHOICE statement with the Datatrieve Report Writer.

REPORT YACHTS PRINT CHOICE

LOA GT 40 THEN "Papa Boat" LOA BETWEEN 25 AND 39 THEN "Mama Boat" ELSE "Baby Boat"

END CHOICE, PRICE, MODEL END REPORT

DTR-24

**** Leonard Herzmark, Maricopa County Health Dept, Phoenix, AZ -"Air Pollution Control Application" ****

Leonard described an application which keeps track of air pollu­tion control records. The database primarily consists of five domains: ANNUAL - containing records with data about particular plants, EMISSIONS - containing records with data about the mater­ial in process and the particular emission control devices, EQUIPMENT - containing records with data about non-electric equipment such as incinerators and boilers, ELECTRIC - containing records with data about electric equipment, and COMMENTS - con­taining records with comment data. The data in the five domains are linked together using a common field called PNUM. What is needed is a report which is given to the pollution control ins­pector when he goes to inspect a plant. The report is produced by the following ...

READY ANNUAL SHARED READY EMISSIONS SHARED READY EQUIPMENT SHARED READY ELECTRIC SHARED READY COMMENTS SHARED

DECLARE VPNUM PIC 9(7).

VPNUM =*."Plant number"

FOR ANNUAL WITH PNUM = VPNUM BEGIN

PRINT PRINT PRINT PRINT PRINT

END

**** Joe H. Gallagher -

<print <print <print <print <print

list> list> of list> of list> of list> of

EQUIPMENT WITH PNUM=VPNUM ELECTRIC WITH PNUM=VPNUM EMISSIONS WITH PNUM=VPNUM COMMENTS WITH PNUM=VPNUM

"Most Complicated Datatrieve Startup File" ****

Joe described an application which he developed for a large medi­cal facility. Part of the application was to keep track of a variety of patient skin tests. The patch test is applied and then read 24 and 48 hours later. The data is stored with an occurs clause which is redefined. The specific record defini-tion, in this case, is as follows.

Nutritional Assessment Record Definition

Define record na-record using 01 na-rec. !patient demographic and !other medical information (not shown)

03 trieep pie 99. 03 albumin pie 9V9. 03 transferrin pie 999. 03 ptests done pie x

valid if ptests done="Y","N","" 03 pateh_tests. -

DTR-25

05 cani24 pie 99. 05 cani48 pie 99. 05 trii24 pie 99. 05 trii48 pie 99. 05 ppdi24 pie 99. 05 ppdi48 pie 99. 05 mumi24 pie 99. 05 mum48 pie 99.

03 p-test redefines patch_tests. 05 p-tests occurs 4 times.

07 test24 pie 99. 07 test48 pie 99.

A nutritional index for a patient is computed by a formula which uses these values together with the number of responses to a test and the magnitude of the response. The following commands are placed in the Datatrieve startup file to produce the index.

DATATRIEVE startup file DTRSTART.COM ! set plots cdd$top.dtr$lib.plots !

!

Find the greater of test24 and test48; 99 represents a missing value. If both tests do not exist then assign 99 to x maxtest to indicate this.

declare x maxtest computed by choice of-test24 lt 99 and test48 lt 99 and test24 gt test48

then test24 test24 lt 99 and test48 lt 99 and test48 ge test24

then test48 else 99 end choice. ! !Compute the number of complete tests ! declare x ntst computed by count of p tests with x maxtest-ne 99. !number of tests ! ! Compute the number of positive tests; if the tested ! value is less than 5 then the test is negative ! declare x npos computed by count of p tests with

x maxtest bt 5 and 98. -!-! Compute the number of incomplete or missing tests ! declare x_pflag computed by count of p_tests with maxtest eq 99.

! ! Compute a weighting factor ! declare x spoint computed by (count of-p tests with x maxtest bt 1 and 5) + 2*(count of-p_tests with-x_maxtest ht 5.0001 and 98).

DTR-26

! Compute the nutritional index I declare x pni pie s999 computed by choice of-(x_p,f lag eq 0 and transferrin gt 0 and ~te~ts_done eq 'Y") then (158 - 16.6*albumin - 0.78ntr1cep -0.20*transferrin - 5.8*x spoint) else -999 -end choice. ! -! Now make the nutritional index suitable for I reporting

declare xx pni choice of -

pie xxx computed by

( x pni eq ( x-pni gt ( x-pni It ( x-pni bt else

end choice.

-999) 100 ) 0 ) 10 and

then " then "100" then " O" 99) then " "Ix pni

"lx_pni -

When manipulating the patient data, therefore, the nutritional index (xx_pni) is available.

**** B.Z. Lederman, Greenberg Bros., NY -''Gotcha'' ****

"This is one that I've done before but it's worth seeing it again. What's wrong with this field?"

01 RECORD. 10 DESC PIC X(lO) QUERY_HEADER "Description".

"This works for about a month until the first time someone says ... "

"PRINT domain SORTED By DESC DESC"

****Phil Naecker, J.M. Montgomery -"DATATRIEVE Syntax" ****

"You can type the following command into DATATRIEVE and IT WILL WORK!"

DTR> FIND FIND WITH WITH EQUAL EQUAL SORTED SORTED

[enhancement from audience]

DTR> FIND FIND WITH WITH EQUAL EQUAL SORTED SORTED OVER OVER

**************** End of Fall 85 Wombat Magic ****************

See y'all in Dallas for Spring 86 Wombat Magic ...

DTR-27

AT THE FALL DECUS IN ANAHEIM, THE ATTENDEES EXPECTED THIS . . .

INSTEAD, THEY GOT ...

--

---

g

EDUSIG

Chairman Robert A. Shive, Jr. Millsaps College Jackson, MS

Symposium Coordinator Sue Bates Northwestern Michigan College Traverse City, Ml

Communications Committee Representative Robert W. Mccarley Millsaps College Jackson, MS

Newsletter Editor Fred Bell Taft College Taft, CA

PSS Coordinator VAX Systems SIG Liaison Donald C. Fuhr 7uskegee Institute Tuskegee Institute, AL

Administrative Applications Coordinator Dave Cothrun Taft College Taft, CA

Courseware Coordinator Mary Jae Reed Off Comp Based Instruction Newark, DE

DEC Counterpart Gary Finerty Digital Equipment Corporation Marlboro, MA

-------------------------------------------

EDU-i

[Q] DECUS r- - - - - -

I

I I

I I

I GRAPHICS I

I I

.--- - .. -· I I

I

I I I I I - - I

I I L___ - - __ :

Chairman William Kramer University of Delaware Newark, DE

Symposium Coordinator Bijoy Misra Smithsonian Institution Cambridge, MA

Newsletter Editor Michael P. Anton Houston, TX

Session Note Editor Mike McPherson Michigan State University East Lansing, MI

Standards Coordinator Jim Flatten Ames Lab Ames, IA

GRAPHICS

Library Committee James M. Turner Saber Technology San Jose, CA

DEC Counterpart Susan Usilton Digital Equipment Corporation Nashua, NH

Information Officer Mike York Boeing Computer Services Seattle, WA

Human Interface Working Group Coordinator Tom Owens Graphics Research Center Baltimore, MD

Engineering Working Group Coordinator Dana Smith Wilmington, DE

GRA-i

Report on the GAPSIG GKS Working Group Jim Flatten January 11. 1986

For some time. I have been working to obtain permission from Randy Simons of SANDIA to submit his implementation of the Graph­ics Kernal System (GKS) graphics package to DECUS. I finally got permission to do so about one month before the Fall DECUS Symposium in Anaheim.

This package is a level ma implementation of the GKS standard recently approved by both ANSI and ISO. Level ma is the lowest im­plementation level of the GKS standard. It provides no input functions and no segment or bundle support.

The implementation is written in C and was originally done on a VAX running UL TRIX. The package conforms to the May 1985 ver­sion of the C binding to GKS. This binding is not yet an official standard and will not be until a standard for the C language itself is approved.

My interest in this package comes from a need in my own work at Ames Laboratory to provide standard graphics packages for use on small computers (LSI 11/23). I want to pursue the conversion of this package to RT-11. and in fact I have already done this for an earlier version of the same package.

As a SIG project. there are four areas where we can enhance the package:

1. Migrate to other operating systems 2. Add new device drivers 3. Add new bindings 4. Add functionality

We are interested in pursuing the first three

GRA-1

items now and the fourth at a later time.

We would like to see the package imple­mented with the DECUS C compiler so that it can be made available to DECUS members without requiring them to buy a C compiler. This will mean however that we will need to use the alternate, non-standard C binding. because DECUS C will not support the long names required by the C binding. nor will it support passing structures by value.

At the Anaheim meeting, we solicited inter­ested people to work on this graphics pack­age. Currently we have about twenty people on our mailing list who have indicated that they have some interest. If you are inter­ested in participating in this project. contact me or Mike McPherson our Tape Coordina­tor. at one of the following addresses:

Jim Flatten 304 Metallurgy Ames Laboratory Ames, IA 50011

or Mike McPherson Michigan State University 269 Engineering Bldg East Lansing, Ml 48824

Mike can make copies of the tape in VMS and TAR formats. I am working on setting up an account on our VAX system at Ames Labo­ratory so that you can dial in and down-load the code using KERMIT. We will be sending out more details about how to participate. directly to the people on our mailing list.

Pre-Symposium Seminars on Graphics

William Kramer

The GAPSIG is proud to present two Pre­Symposium Seminars at the Dallas Sym­posia. These seminars are day long intensive sessions held on the Sunday before the sym­posia. The are designed to investigate topics in greater detail than is allowed through indi­vidual symposia seminars.

The first seminar is entitled "Graphics on the VAXstation". presented by two DEC engi­neers. Peter George the Workstation Product Manager and Keith Cumeford a member of the GKS Development Team at DEC. This seminar will explain the use of the two major graphics interfaces on the VAXstation. GKS and UIS. GKS is the international standard implementation which is available on the en­tire VAX family of computers and worksta­tions. It is used to develop sophisticated graphics applications which are device inde­pendent and portable. UIS is the VAXstation specific interface which allows device opera­tions such as window control and pixel opera­tions. It is only available on VAXstation prod­ucts. This seminar will explain how and when these different interfaces should be used to develop graphics applications.

Our other seminar offering is "Introduction to Interactive Graphics". Bijoy Misra. a Com­puter Scientist at the Harvard-Smithsonian Center for Astrophysics is the presenter. Dr. Misra has been involved graphics program­mer and designer for over 15 years and he

GRA-2

is now involved in the development of a new graphics interface language for doing interac­tive scientific graphics. This seminar will be important to people who are developing ap­plications on VAXstations.

This seminar will be an introduction to the concepts of interactive computer graphics. It will review the current technology and with a review of viewport mapping and 2 and 3D transformations. Other topics will be projec­tion algorithms, image transformations. and hidden line and surface removal. Concerns related to color and shading will be explored and the proper way to design graphics sys­tems will be developed. Overall this seminar will be a great chance to get up to speed in advanced computer graphics and to learn the basics of designing interactive graphics sys­tems.

You can sign up for either of these seminars when you mail in your registration form for the DECUS symposia. Remember that you must register in advance for the seminars. and that walk-in registration can not counted on. The seminars will have handout material. These seminars are new this time. but from past experience. it is clear the people who attend pre-symposium seminars have found them very rewarding. Attending these either one of these seminars will be very benefical to you.

Report on the 21•~ Meeting of X3H3 Computer Graphics

Jim Flatten, DECUS Repres1H1tative February 9, 1986

The 21st meeting of the X3H3 technical CDIMli ttee on computer gr.aphics met in San Diego California during the -k Di' Fl!bru.ary 3-7, 1986. The first three d.ays _,..e devoted to task group -•tings. The plenary session was Thursday and Friday.

X3H3 is broken into five task groups .and an Ad Hoc group, soon to become a sixth task group. The task groups and their work assign111ents are:

X3H3.1 - The Programmers Hierarchical Graphics System <PHIGS>

Interactive

X3H3.2 - Formal Description, Validation and Testing Group <FDVT>

X3H3.3 - Computer Graphics Interface <CGI> I Computer Graphics Metafile <CGl'I>

X3H3.4

X3H3.5

Ad Hoc

Language Bindings

Graphical Kern.al System CGl<Sl

WindDNs Ad Hoc Task Group <X3H3.6l

During t:he plenary meeting, each task group reported on t:he st:at:us Di' their work.

I p.art:icipat:ed in t:he X3H3.1 <PHIGS> task group meetings. We worked on several items during these sessions, including&

1. A revi..,. of t:he US com-nts t:o t:he PHIGS ISO DP draft document:.

2. A review of the l.atast Product Description Exchange System (PDES> docwaent and its rel.ationship t:o PHIGS. This work is being sponsor.cl by t:he Y14. 26 ca.ii t:tee al though t:he mast: of t:ha work is done by t:he N.at:ional Bureau Di' Standards. This NDrk is a follow-on t:o t:ha tYrlier IBES standard. Tha current: document: different:iat:es between model description and present:.ation information. X3H3.1 reviewed t:ha presant.ation entities draft: and will respond to t:he PDES commit:t:-. X3H3 f-1• that it is i11Port:ant: for PDES t:o be upward compatible from t:he CGM and t:ha PHISS archive file. X3H3 is currently seeking a new 11.ason t:o Y14.26.

GRA-3

3. Preparation of the US delegates to the Frankfort meeting of ISO TC97/SC21/WG2 in March. The X3H3 goals for the Frankfort meeting are to resolve currently unresolved issues, to produce reference models and educate people about PHIGS and to begin a redraft of the PHIGS document. Jurgen Bettels of the Swiss delegation to ISO has been solicited to be the rapporteur for the ISO PHIGS effort. He will replace Terry Hewitt of the British Standards Institute <BSI> who recently retired.

4. Implementors of PHIGS <Megatek, IBM and RPI> discussed their implementations and problems they have encountered in implementing PHI GS. A reception was held on Tuesday evening, February 4, at which Megatek demonstrated their implementation of PHIGS.

5. We updated PHIGS reference models and prepared them for input to the X3H3.2 task group.

PHIGS is currently out for public review in the United States and is also being considered for DP status in ISO. Comments on the proposed PHIGS standard <ANSI document X3.144l must be made by March 22, 1986.

X3H3.2 <FORMAL DESCRIPTION, VALIDATION AND TESTING>

NBS has agreed t:o act: as the registration aut:horit:y for graphical items for ISO. The procedures are in place for registration of Generalized Drawing Primitives <GDPs> and Escapes. Language bindings for these items are likely to be a problem however. The items can be submitted by organizations that are unlikely t:o be familiar wirh X3H3 binding procedures. Preliminary indications are that binding of GDPs and ESCAPEs is likely t:o be as difficult: as binding GKS functions originally. Fut:hermore, t:he rules for developing bindings are not: documented. Submitting organizations are unlikely to have t:he neccessary expertise and NBS doesn't have t:he man power. The problem has not been resolved yet.

NBS also has a hand in t:he validation of GKS implementations. They have computer routines designed to test GKS implementations. New routines have recently been received that will test levels of GKS up to 2B. NBS is also looking for volunteers to help develope validation routines for GKS, GKS-3D, PHIGS and CBI and convert: existing routines to other languages.

NBS has the power t:o develope Federal Information Processing Standards <FIPS>. GKS will become a FIPS soon and it is anticipated that other ANSI graphics standards will follow.

GRA-4

X3H3.3 <CGM/CGI>

The Computer Graphics Metafile <CGM> Standard will soon become the second graphics standard produced by the X3H3 committee. A ballot is currently under consideration in X3 to forward the CGM Standard, ANSI document X3.122, to the Board of Standards Review <BSR>. One negative vote <DEC> is anticipated which will require extra processing depending on whether the associated comments contain new technical content or not. It is anticipated that the CGM will become an American National Standard in July or August of 1986.

The CGM is also being processed as an international standard <DIS 8632/1-4). A ballot to consider the ISO CGM document begins around February 15, 1986 and will end in August, 1986. Comments on the document will be processed at the September meeting of SC21/WG2. The final CGM text is expected in October and in November the IS text will be completed. It is expected that the CGM will be published as an ISO standard in June, 1987.

The Computer Graphics Interface <CGI> is being processed simultaneously by ANSI and ISO. At the San Diego meeting X3H3.3 prepared the U.S. position on CGI for the upcoming ISO meeting in Frankfort Germany. They also reviewed the U.S. comments to the initial draft of the ISO document.

X3H3.4 <LANGUAGE BINDINGS>

The functional specifications <semantics) for the standards being processed by X3H3 are "bound" to various programming languages. Language bindings specify the syntax for graphics functions when working in a particular programming language. X3H3.4 is working on language bindings for GKS, GKS-3D, PHIGS and CGI. Language bindings are being standardized in several languages including FORTRAN, Ada , COBOL, PL/I, Pascal and C.

Since the last meeting, SD3's <an SD3 is an ANSI project proposal> have been approved for bindings of GKS-3D to Ada , FORTRAN, Pascal and C. SD3's were approved to begin bindings of the CGI to FORTRAN and C.

The status of various GKS bindings, both in ANSI and ISO were presented. The status is:

ANSI

FORTRAN This binding is now an American National Standard <ANS>.

ADA The binding is expected to go out for public review in March, 1986.

C A letter ballot will be circulated to X3H3 to forward the binding to X3 for public review. The

GRA-5

binding would be out for public review around the first of April.

PASCAL A letter ballot will be circulated to X3H3 to forward the binding to X3 for public review. The binding would be out for public review beginning in September, 1986.

ISO

FORTRAN The document is currentlu out for DIS balloting. It is identical to the ANSI document.

ADA The document is out for a second DP bal 1 ot. The U.S. voted to approve the document.

C A DP ballot on the C binding should begin about April 1, 1986.

PASCAL A DIS ballot for this binding is currently underway. The U.S. has some major concerns about the binding and will vote NO on the document.

Work is underway on various PHIGS bindings. The status of these bindings follows.

ANSI

FORTRAN The PHIGS FORTRAN binding will go out for public review in March, 1986.

C The PHIGS C binding will be circulated for letter ballot in X3H3 in July to be followed by an anticipated public review beginning in November, 1986.

ADA The PHIGS ADA binding will be circulated for letter ballot in X3H3 in July to be followed by an anticipated public review beginning in November, 1986.

PASCAL The first draft of the PHIGS PASCAL binding should be ready in October. An SD3 for this work will be voted at the June meeting of X3H3.

ISO

FORTRAN The document will be sumbitted to SC21/WG2 in September for working draft distribution.

C The document wi 11 be submitted to SC21 /WG2 in September for working draft distribution.

GRA-6

ADA No current activity

PASCAL No current activity.

Work is underway on various CGI bindings. The status of these bindings follows.

ANSI

FORTRAN A letter ballot will be circulated to X3H3 in July on this binding.

C A letter ballot will be circulated to X3H3 in July on this binding.

ADA Work on this binding is just beginning.

PASCAL No current activity.

ISO

FORTRAN The document will be sumbitted to SC21/WG2 in September for working draft distribution.

C The document will be submitted to SC21/WG2 in September for working draft distribution.

ADA No current activity

PASCAL No current activity.

X3H3.5 <GKS>

The ANSI version of GKS has been published including the FORTRAN binding. X3H3.5 is currently working on the follow-on standard for GKS, namely the three dimensional standard GKS-3D. 6KS-3D is expected to go out for a three month letter ballot this summer. The letter ballot period is expected to end about September 15, 1986. GKS-3D wi 11 al so go out for an ISO DIS ballot around August 1, 1986.

ACM voted no with comment on the project proposal for GKS-3D. They indicated that they believe GKS is a poor model for developing a family of graphics standards. An X3H3 vote was made on the response to the ACM comment. Essentially X3H3 responded that they think GKS-3D is an important extension to GKS, but GKS is already an ISO and ANSI standard and the functionality of GKS is not at issue. The response was approved by a vote of 62-0-1.

The result of the letter ballot to forward 6KS-3D for

GRA-7

public review was 49-18-2. As a result of this letter ballot it was determined that the document sent out for public review will not be a delta document as it currently is, but a complete document that will stand on its own.

There was some discussion over whether GKS and GKS-3D fit together or not. It isn't clear whether GKS-3D will be a level of GKS or not and some people felt that if they become separate standards they wi 11 eventually di verge from one another. The question was deferred to an X3H3 letter ballot.

WINDOWS

The ad-hoc windows task group is still an ad-hoc group due to some administrative problems. It is anticipated the this group will become X3H3.6 at the next meeting of X3H3. It was reported that X3 has approved the project proposal for the group. An aggresi ve schedule was presented which would see the result of this committee's work available for public review in the Spring of 1988.

LIASDN TD X3V1

Frank Dawson of McDonnell Douglas is the X3H3 liason to the committee working on text and graphics X3V1. He reported on the work currently being done by that committee. He indicated that there appears to be two constituencies represented on X3V1. One supports the use of ODA/DDIF <Office Document Architecture/Office Document Interchange Format> and the other wants SGML <Standard Generalized Markup Language) and SDIF <SMGL Document Interchange Format> to be used as a standard for ducument layout and interchange.

He also introduced the committee to MAP/TOP <Manufacturing Automation Protocol/Technical Office Protocol>. He said that the MAP/TOP effort is being sponsored as an activity under the Society of Mechanical Engineers <SME>. He emphasized that this is a user group, not a technical standards committee, and is made up of managers and policy makers. Their idea is to speed up and influence the standard development process. They are using the ISO Open Systems Interconnection <OSI> model as a basis. A demonstration of TOP is planned by June 1987 similar to the demonstration of MAP at AUTOFACT recently.

FUTURE MEETINGS

Future meetings of X3H3 are scheduled for June 2-6, 1986 in Minneapolis MN, and October 12-16, 1986 in Saratoga NV. Plans for meetings after Saratoga have not been completed at this time.

GRA-8

Graphics Application SIG

Activity in Dallas

The theme topic for the Graphics Applications SIG at Dallas is Graphics on Workstations and we have an interesting variety of aeasions acheduled for this Symposium around this theme. Besides the sessions on Workstations, we will have sessions on graphics standards, GKS products, graphics on PC and inter­active graphics. The Symposium will be preceded by two pre­aymposium seminars on introduction t.o computer graphics and graphics on V AXstations, to be held on Sunday before the Symposium.

The keynote session will be delivered by Mr. Tom Wright of ISSCOon Monday afternoon Mr. Wright, with his long involve­ment in developing graphics software is ideally suited to di9-cuss the new orientation for graphics on Workstations. These aessions would be followed by aesaions on Digitars plan on Workstations and V AXstation internals and graphics pro­gramming interface. Other sessions on V AXst.ations include device driver software, performance guidelines and window management system.

Several aessions on interaetive gr&Phics, user interface and color graphics are scheduled on Tuesday. These will include

aessions on human interface methods, engineering graphics generator, windowing designs and the proposed standard Sessions on color graphics will be done by engineers from Tek­tronix and will include sessions on data analysis and color

graphics terminala. On Wednesday, we have acheduled sessions related to VAX GKS and GICS.related products. These will include sessions on GKS programming, GKS implementation, advanced concepts and nonstandard devices. There will be also sessions on GKS standards update and the proposed GKS.3D standards. The hardcopy related sessions are scheduled on Thursday. They include sessions on Postscript, V AXstation hardcopy output system. merging graphics and text and a tutorial on font design Finally, the sessions on graphics on per­sonal computers and sessions on Computer Assisted Drawing (CAD) and Computer Assisted Instruction ( CAJ) are scheduled on Friday. All sessions are designed to leave time for discussion and answer questions from the audience. A special session called Graphics Users' Forum is scheduled Wednesday and Graphics Question and Answer ll08Sion is scheduled on ThU111day.

Besides the sessions diseuased above, there will be a camp­ground to provide hand9-on experience on using V AXstations and opportunity of discussing various graphics problems with the Digital engineers and members of the Graphics SIG Steer­ing Committee. With strong emphasis on V AXstations and hardware and software concepts, the Dallas Symposium will be the most informative for graphics enthusiast& We hope you can make time to attend the Symposium and invite you all to join us in the Symposium activities.

GRA-9

~' [Ql ' OECUS ,,

,, ,,

---------------------------- ~ HMS

~--------------------------------·

Chairman VAX SIG Liaison Thomas J. Provost MIT/LNS Bates Linac Facility Middletown, MA

Product Planning Coordinator George Hamma Synergistic Technology Cupertino, CA

Symposium Seminar Coordinator Mike Allen Lawrence Livermore National Labs Livermore, CA

Communications Coordinator John G. Hayes Information Systems - S. Central Bell Birmingham, AL

Publications Coordinator (Edito" Bill K. Walker Monsanto Research Corp. Miamisburg, OH

Session Notes OAARC SIG Liaison

Bill Tippie Kinetic Systems Corp. Lockport, IL

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

HMS

HMS-i

Pre-Symposium Seminar Coordinator Mike Allen Lawrence Livermore National Labs Livermore, CA

TOEM (Chips% Boards) Jack J. Peterson Horizon Data Systems Richmond, VA

HHK (Hardware Hints & Kinks) Wayne Kesling Monsanto Research Corp. Miamisburg, OH

UNIBUS Hardware Ron Bogue LIV Aerospace & Defense Co. Dallas, TX

Performance Measurement Coordinator William Wallace 600 W. Washington St. Peoria, IL

CAMAC Coordinator Peter Clout Los Alamos National Lab Los Alamos, NM

CSS Coordinator Pratap Gohel E.I. Dupont Ingleside, TX

Networks SIG Liaison Sandra Traylor Target Systems Yorba Linda, CA

VAX SIG Liaison Dave Schmidt 5100 Centre Avenue Pittsburgh, PA

DAARC SIG Liaison Bill Tippie Kinetic Systems Corp. Lockport, I L

UNISIG SIG Liaison Jim Livingston 1 Results Way Cupertino, CA

SITE SIG Liaison Emily Kitchen A.H. Robbins Co. Richmond, VA

RT-11 SIG Liaison Gary Sallee Sallee Software Consulting Yorba Linda, CA

RSX SIG Liaison Hans Jung Associated Press New York, NY

Members-At-large Mike Rembis American Dade Costa Mesa, CA

Hans Dahlke Richland, WA

Jim Cutler EDS Tower, 26533 Evergreen Southfield, MI

DEC Counterparts Terminals

HMS-ii

Nina Abramson Digital Equipment Corporation Maynard, MA

TOEM (Chips & Boards) Art Bigler Digital Equipment Corporation Marlboro, MA

Diagnostic George D. Cooke Digital Equipment Corporation Maynard, MA

Storage Marilyn Fedele Digital Equipment Corporation Maynard, MA

MSD(Micro Systems Developmen~ Roy Rodgers Digital Equipment Corporation Maynard, MA

Printer Products Frank Orlando Digital Equipment Corporation Maynard, MA

DECUS Europe Liaison Hans Zoller

THE

DE VIAS

LETTER

The DeVIAS Letter Isaue 36 April 1986

Curley's Corner: News from the Chairman

Letter from the Editor

IAS users in Silicon Valley / San Fransisco

Thank You, Ken Guralnik

Meet Your Steering Committee

Getting Started with Macro-11 by Bob Curley

IAS SIG Steering Committee

Chairman Bob Curley Division of Medical Physics University of Pennsylvania Philadelphia, PA

WHIMS Commissioner Kathleen Anderson Eaton Information Management

Systems Division Hampton, VA

Library Coordinator Bob Schuldt !NCO Inc. McLean, VA

RSX Liaison Ray French Boeing Computer Services Seattle, WA

Member-at-Large Doug Reno Abbott Laboratories North Chicago, IL

DEC Counterpart Mike Reilly Digital Equipment Corp. Maynard, MA

IAS-i

Symposium Coordinator Skip Stanfield USAF Washington, DC

Librarian Mike Robitaille Grumman - CTEC, Inc. McLean, VA

DeVIAS Letter Editor John Roman McDonnell Douglas - Dept. N436 600 McDonnell Blvd. Hazelwood, MO 63042

Member-at·-Large Kerry Wyckoff LDS Church Salt Lake City, UT

DEC Counterpart Tim Leisman Digital Equipment Corp. Stow, MA

DEC Counterpart Bob Mack Digital Equipment Corp. Landover, MD

~ ~

Dear IAS Enthusiast,

Division of Medical Physics Department of Radiation Therapy University of Pennsylvania Philadelphia, Pennsylvania 25 February 1986

Congratulations are in order. Michael Garcia and his wife had a son, Matthew, last month. Mike is one of the IAS Development Team in Maynard and currently also deeply involved in answering some of the SPRs we've been sending. I'm sure that I speak for all of us in wishing Mike and his family well.

There is a group of RSX-11M people who are interested in collecting old distributions of RSX. Since we share a common heritage, I thought that one or more of you might have some in your collection. RSX-llA and RSX-11B are in particular demand. I have forgotten the details of the quest, but I recall that there was some activity in "bringing them upl" Please call me to refer you to this group of RSX historians.

Ted Smith, my partner, was trying to bring up DECnet on IAS V3.2B. He discovered one of those things that take a bunch of time that "everyone" knows about. It is time to air it again. The taskbuilder aborted when trying to build one of the DECnet components. I forget the message and the component - I think that it doesn't matter. Ted and I spent a LOT of time trying to alter the front end parameters of the DECnet 'build' file to no avail. Telephone support was unable to help - "It builds here OK." A very good friend provided the answer: There's a bug in TKB that's been there since IAS branched off from RSX. It has to do with the way TKB divides up the free space inside itself - if "something" happens (I am fuzzy on this point) TKB aborts. The answer is to INStall TKB with an INCrement of 15000. The real answer is to adjust the increment so that it doesn't abort! In the case of DECnet the value is 15000. No joke, when we did it DECnet built just fine. Talking to telephone support later we discovered that TKB is installed with an increment of 15000 on their machine.

I have included a copy of my DEC Professional article on MACR0-11 from the May 1984 issue. The Editor and the Publisher of the DEC Professional have graciously permitted me to reprint it at my request.. It is something that seems to generate some continuing interest and that particular article is now hard to find. I hope you agree that it should be included in this newsletter.

Yesterday I went to DECworld. I got up very early and was there when the doors opened so that I could sit front row center when Kenneth Olsen made the opening address. He is very impressive in person.

DECworld is not aimed at me and I was disappointed. I was in awe of the magnitude of the organization and the display. Clearly the "Exhibit Area" at DECUS Symposia are "small potatoes" when compared

IAS-1

to DECworld. That was not the problem. They were selling "Solutions" - not iron. I can not tell whether that is a real shift for Digital - or just my first DECWorld. I got an eerie sensation that Digital was making the first overt move that would squarely place them against IBM. Digital is going to win.

The disappointment derived from my feeling that the Iron Works at 146 Main Street, next to the Assabet River, is losing its interest in me, the little guy that might buy a computer every decade and try to keep it going in the interim. Everything is VAX, as if you didn't know. I went to a PDP-11 Seminar: PDP-lls: The Commitment Continues. The speakers were Lucien R. Philippon, MSD Systems Product Management and Bill Andrus, Manager, Software Product Managers, Micro Systems Development. Micro Systems Development (MSD) appears to "own• all PDP-lls and the microVAX. Mr. Philippon was the hardware person and Mr. Andrus was the software person. They had a very nice presentation that they admitted was well rehearsed in front of the Digital censors. I felt pretty good about the future of the PDP-11 even though he didn't mention IAS in the list of PDP-11 software that they were committed to. Their premise was that there will be PDP-lls as long as Digital can make money from them - I have no problem with that.

During the Q&A they said that while no one knows for sure how many PDP-lls were out there, since it was hard to know whether to count chip sets, etc. - the "official" number is "over 600,00 PDP-lls have been shipped." And there were about 30,000 shipped last year. Of the $6,700,000,000 that Digital grossed last year about 20\ is PDP-11 business. The margin was not mentioned, so it was not possible to determine whether they made money on the PDP-11 last year! I guess that we're OK for this year at least.

There were several questions from the people who buy "boards" and put them into something they sell that contains a PDP-11. I didn't understand the issues, but the questioners didn't like the answers - Digital appeared to be changing the rules on them after they had made a big investment. Clearly an issue of interest.

Finally I asked about "retiring" software. Would they do as they have done with DBMS-11 - just stop support, no sources, no recourse, just drop dead? Mr. Andrus appeared to be unable to say what came to his mind - it was a nasty question. What he did say was "there are corporate software retirement guidelines.• When I asked that he be more specific he said that he didn't know what they were. I asked if he would get them for me and he said, "Yes." I will share them with you if possible.

So, while the session started on a positive note, by the end I was disquieted again.

Mr. Philippon mentioned that IAS and RSTS do not run on an 11/84 with the Floating Point Processor chip. He mentioned the reason. The problem has been fixed, however, and they have 11/84s running IAS and RSTS with the FPP chip he said. I got the feeling that they had not been distributed yet.

IAS-2

The reason for being in Boston was the SIG Council meeting in Marlboro on Friday, Saturday and Sunday. For those of you who have avoided my little DECUS structure tutorials, the SIG Council is made up of the Chairmen of all the SIGS. In addition we have a Chairman, Sandy Krueger, and Vice Chairman (Jim Welbourne) who represent our group on the Management Council, the group that really runs DECUS. there are the leaders of some sub groups of the SIG the Product Development Committee (responsible for dealing directly with Digital on 'futures'). After a long time and after a massive effort on the part of Stuart Lewis, the Council approved the formation of the Business Applications SIG.

I have recently communicated with Carol Chorlton, whom many of you remember as the girl from Reading who pronounced "scheduler" so well. It is her memory that February 1976 was the "first ship" date for IAS. She thinks it was Vl.O. I have been unable to confirm the date, but she's been right about so many of the IAS technical details that we should celebrate: Happy Birthday IASI 10 and growing.

It is still Winter in Philadelphia; the Groundhog (or woodchuck) on Groundh.og's Day (February 2nd) predicted that "Spring is just around the corner." Fortunately, I like Winter! May Spring (and this newsletter) find you well,

Bob Curley IAS SIG Chairman

IAS-3

Letter from the Editor

Our Cross pen saga continues. we have started the process of ordering more pens, and have let Decus Central try to find the others. I hope they should be available by Dallas. (If the paperwork is moved along). So if you have been holding up your articles and waiting for the availability of these pens, wait no longer! Anything published in 1986 will count.

By the time you read this the Board of Directors election should be in full swing. I would have liked to make a very strong endorsement, but I am not able to because of Decus Policy: "Any group within DECUS that wishes to comment on the Board of Directors election in its publication(s) must provide an opportunity for all candidates to make a statement in the same issue so that all candidates will have an equal opportunity for visibility." "Candidates or other leaders who violate this policy will be held in violation of the DECUS 'Statement of Computing Ethics'."

I am for fairness as much as the next guy, and being held in violation of the "Statement of Computing Ethics" (as preposterous as it sounds) must be a real bad trip. Therefore I figuratively will bite my tongue on what I might want to say on the election. However, I will ask you to vote, and to borrow a quote from Doug Boher's area of the country: "Vote early and vote often." It appears that if you only favor one candidate that you should only vote for that one, voting for more will only dilute the effect.

The DeVIAS Letter needs your help to be an effective forum for issues related to IAS. Please send all contributions to:

John Roman McDonnell Douglas Corp. - Dept. N436

600 McDonnell Blvd. Hazelwood, Missouri 63042

IAS-4

IAS Users in Silicon Valley / San Fransisco

I am looking for names and phone valley / San Fransisco Bay area questions. Attending DECUS gave questions answered, but there learn how IAS works.

Dena Shelton Systems Industries

numbers of people in the Silicon that I could contact regarding IAS me the opportunity to have my are always more that pop up as I

1855 Barber Lane, M/S 401 Milpitas, CA 95035 (408)942-1212 Ext. 259

IAS-5

Thank You, Ken Guralnik

Shown is Bob Curley (left) IAS Sig Chair presenting a plaque (below) to Ken Guralnik for his contributions to the IAS SIG

IAS-6

Meet Your Steering Committee

Mike Robitaille Librarian

Mike Reilly DEC Counterpart

IAS-7

Skip Stanfield Symposium Coordinator

John Roman Editor DeVIAS Letter

Bob Mack DEC Counterpart

IAS-8

Kerry Wyckoff Member-at-large

Getting started with MACR0-11

Robert F. Curley Department of Radiation Therapy

University of Pennsylvania Philadelphia, Pennsylvania

I think that most of us become fluent in a programming language by using it, not by studying it in a text book. MACR0-11 is no different. Writing the first program in the PDP-11 Assembly Language is more difficult than most languages because there is no single reference. Most places that you look contain no examples that work. There are very few simple, getting started programs. There are many device drivers and examples of that ilk - too hard to be useful to a beginner.

The I/O is the real problem, the assembly language itself is pretty well documented. By restricting ourselves to two "black boxes" or "system macros" or "system directives" we can get quite a way into the most useful second language for PDP-11 high level language programmers. A system directive is a request of the operating system for some service. In our case we'll ask for the operating system to move a character from our programming space out to our terminal. And, we'll notify.the operating system that we're done with the program. The directives that I find least intimidating are from RT-11: ".TTYOU" and ".EXIT". To use these two requests for system services on other systems it is necessary to translate them into the correct form for that system. We'll emulate .TTYOU and .EXIT under several operating systems {l).

Create your first program in a file ONE.MAC{3}:

.TITLE ONE RED: .WORD 101 BLUE: MOV RED,RO

.TTYOU

.EXIT

.END BLUE

This is your first program. You may immediately assemble it and link ("taskbuild" if you speak RSX) it and execute it.{2}

The program prints an upper case letter A on your terminal. The grace with which it happens varies with operating system. Some perform a carriage return, line feed sequence before your program starts executing; and another as the program exits. Some operating systems allow the 'A' to be printed over the prompt on the left margin. If you have one of these, you might wish to modify your program to print a carriage return, line feed sequence before and after the main part of your program. For example, create the file TWO.MAC:

PINK: CR:

.TITLE

.WORD

.WORD

TWO 101 15

IAS-9

LF: .WORD 12 START: MOV CR,RO

.TTYOU MOV LF,RO .TTYOU MOV PINK,RO .TTYOU MOV CR,RO .TTYOU MOV LF,RO .TTYOU .EXIT .END START

Program TWO prints five characters on your terminal: carriage return, line feed, upper case A, carriage return, line feed.

A discussion of the components of Program ONE and TWO is in order. The syntax of MACR0-11 is simple: four fields, label, operation code (opcode), operands, comments. Labels begin the line and are terminated by a colon. Opcodes are next, terminated by a delimiter: space, tab, carriage-return. Operands next, separated by commas if there are more than one. I'll ignore comments. I use these rules: a label goes at the left margin, a tab, the opcode, a tab, the operands. No label? Tab to the opcode field. There are more elaborate schemes, this will get you started.

The '.TITLE' is an example of a class of program components called "assembler directives". It is a command (request) to the assembler, evaluated or executed at assembly time. In this case, the '.TITLE' tells the assembler to call this program 'ONE'. The use of this naming varies with your operating system but the assembler uses it to title the listings and the linker (taskbuilder) uses it on the map listing. For the beginner programmer it performs no useful function - if you leave it out the program works the same. I recommend the use of the .TITLE directive as a good habit for later benefit!

The next line, starting with 'RED:' asks the assembler to reserve a word of memory (the '.WORD' assembler directive), call that word 'RED' and start the program with RED containing the octal value 101. Unlike most high level languages MACR0-11 associates two values with a memory location: the address and the contents. Here the address is 'RED' and the contents, 101. The value, 101, is assumed to be octal; as are all numeric constants unless you explicitly notify the assembler otherwise.

The next line, starting with 'BLUE:', is a PDP-11 instruction 'MOV'. The details of the move instruction mnemonic, MOV, may be found in the "Processor Handbook"{4). In fact, that is the place to find the definitive description of all the PDP-11 instructions. The MOVe instruction takes two arguments: Source and Destination. At BLUE we have 'MOVe the contents of RED into Register Zero'. It is a copy operation, the original contents of RED are intact. Sixteen bits are MOVed - most of the PDP-11 operations can be

IAS-10

conceived as 16 bit parallel operations. A register is storage place in the CPU, as opposed to a storage space in main memory{S). There are eight "general purpose" registers on every PDP-11, usually called RO, Rl, R2, R3, R4, RS, SP and PC. Guessing from the names, registers six and seven are special and not general purpose at all - correct. Generally a register and a memory location may be used interchangably. Access to a register is faster than memory. And, there are some instructions that require the use of a register.

The next line contains the invocation of the macro '.TTYOU'. The Language Reference Manual (7) explains that you may use any of the alphabetic characters, the ten numeric characters and dot and dollar sign to form symbol names. It recommends that you not use dot and dollar. Digital has bound itself to the convention that ALL the symbols that they use (that might be accessible to you) will contain a dot or a dollar sign. This convention makes is easier for you to avoid "reserved words". In this case I have suggested that you create a macro, .TTYOU, in a file MACROS.MAC, that breaks this convention. Here the .TTYOU tells the assembler to replace the .TTYOU with whatever has been defined as .TTYOU. Since you have created the macro .TTYOU with the incantation necessary to output a character for your operating system, the assembler will do the sleight of hand for you and we can all talk about a .TTYOU without being concerned about the lower level rubric. .TTYOU is a "system directive", it requests the operating system to move the contents of register zero (RO) out to the terminal. Usually there is an ASCII (6) character there, which the terminal interprets and prints. Thus the octal 101 is interpreted as an upper case A. The octal value lS is translated by the terminal as "carriage return", etc.

The next exercises are: (!)Modify program ONE to print a z instead of an A. (2)Modify program ONE to print an A followed immediately by a Z. (3)Modify ONE to print an A directly over a Z, that is, A on one line, and z at the left margin on the next line.

It is true that one ASCII character is contained by eight bits, and that there are 16 bits in a PDP-11 word. When you put both the A and the z in one word and ask the operating system to print it on the terminal, the operating system only prints the one character in the "low byte" of "right hand byte" of the word in Register O. Thus, it is necessary to have one MOVe instruction and one .TTYOU system directive for each character that is to go to the terminal, printing and control. Examine program TWO for example.

The '.EXIT' is a system directive that informs the operating system that the program is done, return the computer to the operating system. There may be several .EXIT's in a program, indicating several points in the logic where the program can finish. Only one .EXIT is ever executed for one RUN of the program.

The '.END' is an assembler directive indicating the end of the program. The difference here, is that .END is a message to the assembler saying "This is the end of my program, ignore anything

IAS-11

else in this file." or "Stop assembly here." .EXIT is a message to the opertaing system, .END is a message to the assembler. There must be only one .END in your program. (Occasionally, the file MACROS.MAC for example, where there will be no .END.) When the file you are creating is the Main program, rather than a subroutine, the .END takes an argument - the address of the start of the program, the transfer address. In program ONE the computer wil start executing the program at the address BLUE.

unlike most high level languages, MACR0-11 permits you to mix data and instructions. The assembler would not protest if we were to place RED after BLUE. The computer might protest when we tried to RUN the program, because the data in RED might not make any sense when interpreted as an instruction. Thus, at the beginning I recommend that you organize your program to place the data at the front of your program file, before the start of the program. Or, at the end after the .EXIT.

What to do next? There are several textbooks (8) that will lead you through or you may just wrestle with the Language Reference Manual and a self imposed project. or you may find a college nearby that offers a course in MACR0-11 at night. Such a course is probably more productive than the one week intensive courses offered by Digital's Educational Services; learning a language takes most people longer than a week.

The attached subroutine, RDUMP (9), is included to be used as a tool in debugging your early programming efforts. Digital's Octal Debugging Tool (ODT) is available with most operating systems, but is confusing to learn at the same time you are struggling with the assembler. Use RDUMP until you are comfortable with the jargon of assembly language; then take on ODT. A sample program using RDUMP:

.TITLE THREE

.GLOBL RD UMP Nl: .WORD 1 N2: .WORD 2 N3: .WORD 3 N4: .WORD 4 NS: .WORD s GREEN: CLR RO

MOV Nl,Rl MOV N2,R2 MOV N3,R3 MOV N4,R4 MOV NS,RS CALL RD UMP .EXIT .END GREEN

The .GLOBL assembler directive indicates that the argument, RDUMP, is a symbol that is defined somewhere else, and the linker will connect any references to RDUMP correctly. RDUMP will print the contents of all the registers and the status of the condition codes that are found in the Processor Status Word. This subroutine may

IAS-12

be executed by a non-priviledged user on a time sharing system, without direct access to the PSW. There should be no change to your program by the introduction of RDUMP, it saves all the registers and condition codes and restores them before returning to your program. So, while the example, THREE, uses RDUMP at the end of the program, that is not necessary.

Good luck and perseverance in your pursuit of fluency in MACR0-11. Your effort will be rewarded by greater understanding of your high level language and a power to perform impossible tasks in a high level language by using assembly language subroutines to do the 'impossible.'

* Notes *

{l} For a RSTS/E system, use the RT-11 emulator. MACROS.MAC that contains:

Make a file

.MACRO EMT BCS • ENDM

.MACRO EMT .ENDM

.TTYOU 341 .-2

.EXIT 350

For an RT-11 system make the same file MACROS.MAC as above. arguable that one should us~ the system library, but, for it this way.

It is now, do

For an IAS system or a VMS system, using the PDP-11 emulator. I think that this will work on RSX-llM and RSX-llD too. Create a file MACROS.MAC that contains:

A: B:

• MACRO .MCALL MOV BR .BLKW QIOW$S .ENDM

.MACRO

.MCALL EXIT$S .ENDM

.TTYOU, ?A,?B QIOW$S RO,A B l IIO.WLB,15,ll,,,,<#A,#l,IO>

.EXIT EXIT$S

{2} The assembly process is very similar to a compiled high level language, but quite different from using an interpreted language:

For RSTS/E:

IAS-13

For IAS or RT-11:

For VMS:

MACRO ONE•MACROS,ONE LINK ONE•ONE RUN ONE

MACRO/OBJECT:ONE MACROS+ONE LINK ONE RUN ONE

MACRO/RSX/OBJECT•ONE MACROS+ONE LINK/RSX ONE RUN ONE

On some of the above systems there are other possible command sequences and abbreviations. These work on the systems that I have access to.

{3} I am presuming, of course, that you understand the basics of using your operating system and the use of a text editor. The editor that I use is TECO and I recommend it. It is consistent across most of the PDP-11 operating systems •

{4} There have been numerous PDP-11 Processor Handbooks. Any of them is sufficient for the beginning MACRO programmer. If you have older ones, save them - they sometimes contain details that have been removed from the newer ones. A sampling from my bookshelf: "PDPll/04/05/10/35/40/45 Processor Handbook" EB-05138-75 (1975) "PDPll/70 Processor Handbook" EB-05962-20 (1976) "PDP11/04/34a/44/60/70 Processor Handbook" EB-17716-18 (1979) "PDPll/04/24/34a/44/70 Processor Handbook" EB-19402-20 (1981) The most recent edition seems to follow the example of VAX, the volume is now called: "PDP-11 Architecture Handbook" EB-23657-18 (1983)

These books detail the instructions of which the PDP-11 is capable . In some cases there are also hints on assembler syntax for some of the instructions that was left out of the Assembly Language Reference Manual. Whichever edition you have, it is a valuable reference to the MACRO programmer. Note, for example, the fine print under the MOVe Byte instruction.

{5} "Main Memory" is what used to be called "core memory." The stuff made of little ferrite donuts called cores, not the core of an Apple (pardon the expression). Today, main memory is usually made of etched silicon chips, as are the registers "within" the CPU. The principle difference, then, is where the memory cells are in the computer's organizational chart. Registers are close to the center of power and have a simple addressing mechanism - making access to them quicker. The main memory is usually in another physical section of the computer, on another board, in another cabinet and the addressing of a single cell more time consuming. The actual timing considerations will vary with the model of the

IAS-14

PDP-11 and the considerations.

presence of cache memory and other such

{6} American Standard Code For Information Interchange. An arbitrary code to represent printing and control characters in numbers which can be stored in a computer. There are other codes, but this is the one most widely used in the PDP-11. The full scheme is on the back of the PDP-11 Programming Card. The ones used here: lOl•A, 12•<line feed>, lS•<carriage return>.

{7} "PDP-11 MACR0-11 Language Reference Manual" AA-V027A-TC (1983) is the most recent in a long line of such manuals. While the most recent is nice, the older versions will get you started as well as they have most of the MACRO programmers doing it today. Another example: "IAS/RSX-11 MACR0-11 Reference Manual" DEC-11-0IMRA-B-D (1976). The language has evolved and the older manuals do not mention the newer features, but the essential parts of the language were well designed and have been left intact.

{8} These are textbooks discussing the PDP-11 and MACR0-11: Thomas S. Frank; "Introduction to the PDP-11 and its Assembly Language"' Prentice-Hall, Inc. Englewood Cliffs, NJ; 1983. Charles A. Kapps and Robert L. Stafford; "Assemble Language for the PDP-11", Prindle, Webber & Schmidt, Boston; 1981. Michael Singer, "PDP-11 Assembler Language Programming and Machine Organization", John Wiley & Sons, New York; 1980. Arthur Gill, "Machine and Assembly Language Programming of the PDP-11", Second Edition, Prentice-Hall, Inc., New Jersey; 1983. Harry R. Lewis, "An Introduction to Computer Programming and Data Structures using MACR0-11", Reston Publishing company, Reston, Virginia; 1981. Systems -Organization, Programming, and Applications (PDP-11)", Second Edition, Prentice-Hall, Inc., New Jersey; 1979. Harrold S. Stone and Daniel P. Siewiorek, "Introduction to Computer Organization and Data structures: PDP-11 Edition", McGraw-Hill Book Company, New York; 1975. R.W. Southern, "PDP-11 programming Fundamentals", Southcroft Publications, Ottawa, Ontario; 1972. Harvey Lee Shapiro, "Introduction to Assembly Language Programming on the PDP-10 and PDP-11", Myfield Publishing Company, Palo Alto, California; 1982.

{9} The following is a listing of the file RDUMP.MAC. You must edit this file to select the correct operating system. About two thirds the way down the first page is the statement SYSTEM=XXX Edit the XXX into the appropriate symbol for your operating system: RTll, RSTS, IAS, VMS. Then it should be used with your program as follows:

For RSTS/E:

MACRO THREE•MACROS,THREE MACRO RDUMP•RDUMP LINK THREE•THREE,RDUMP RUN THREE

IAS-15

For IAS and RT-11:

For VMS:

MACRO/OBJECT:THREE MACROS+THREE MACRO RDUMP LINK THREE,RDUMP RUN THREE

MACRO/RSX/OBJECT•THREE MACROS+THREE MACRO/RSX RDUMP LINK/RSX THREE,RDUMP RUN THREE

IAS-16

File: RDUMP.MAC Assembler: MACR0-11 Programmer: Robert F. Curley

******************************************************* * * * DIRECT INQUIRIES TO: * * Computer Facility • * Department of Radiation Therapy • * School of Medicine • * University of Pennsylvania • • Room 410 • * 133 South 36th Street • • Philadelphia, Pennsylvania 19104 • * * * * * • • * • • • *

NO WARRANTY OR REPRESENTATION, EXPRESS OR IMPLIED, IS MADE WITH RESPECT TO THE CORRECTNESS, COMPLETENESS, OR USEFULNESS OF THIS SOFTWARE, NOR THAT USE OF THIS SOFTWARE MIGHT NOT INFRINGE PRIVATELY OWNED RIGHTS.

NO LIABILITY IS ASSUMED WITH RESPECT TO THE USE OF, OR FOR DAMAGES RESULTING FROM THE USE OF THIS SOFTWARE

• • • * • • • * • • • *

*******************************************************

(Most Recent Edit) 10 January 1984

;--; Subroutine RDUMP - print the contents of the registers on

the terminal ;--

CALL RDUMP prints the contents of the registers (in octal) at the time of the CALL. It does not alter the registers nor the condition codes.

Output Format:

Register Dump RO•nnnnnn Rl•nnnnnn R2•nnnnnn R3•nnnnnn R4•nnnnnn R5•nnnnnn SP•nnnnnn PC•nnnnnn

Condi ti on Codes N•n Z•n V•n c-n

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;-----------------------------------

.TITLE RDUMP

.IDENT /7/

.DSABL GBL

version number

this is the way MACR0-11 on RSTS works.

IAS-17

RTll•l

RSTS•2

IAS•3

; ;••• Define The Operating System ***

RT-11 or RT-11 emulator under RSTS/E with the RT-11 system macro library added to the RSTS/E system library.

RSTS/E under the emulator mode.

IAS operating system.

VMS•4 SYSTEM•XXX

RSX emulation on VAX Select One

A: B:

Q: STAT BUFF SKIP

.IF NDF,SYSTEM

.ERROR; ** You must define the symbol SYSTEM in the

.ERROR; •• statement above, SYSTEM•XXX, by changing the

.ERROR; ** XXX to RTll or RSTS or IAS or VMS so that

.ERROR; •• the appropriate macro for .TTYOU is defined .

.ERROR; **

.ERROR; ** use a text editor to change this file and

.ERROR; •• and re-assemble it .

.ERROR; **

.ENDC

.IF EQ,<SYSTEM-VMS>

.MACRO

.MCALL

.GLOBL MOV BR .WORD QIOW$S .ENDM .ENDC

.IF EQ,

.MACRO

.MCALL MOV DIR$ BR QIOW$ .BLKW .BLKW

.ENDM

.ENDC

. TTYOU, ?A, ?B QIOW$S IO.WLB RO,A B 0 ; #IO.WLB,#5,#1,,,,<#A,#l,#0>

<SYSTEM-IAS> ; .TTYOU ?STAT,?BUFF,?SKIP,?Q QIOW$,DIR$ : IAS code RO,BUFF #Q SKIP ; <IO.WLB!IO.WAL>,5,2,,STAT,,<BUFF,1,000> 2 1

.IF EQ, <SYSTEM-RTll>

.MCALL .TTYOU RT-11 code, use the library

.ENDC

.IF EQ, <SYSTEM-RSTS>

IAS-18

CLEAR•O SET•O

.MACRO EMT BCS .ENDM .ENDC

.TTYOU A0341 .-2

.MACRO PUSH,REGLIS

.IF NB,<REGLIS>

.IRPC REG,<REGLIS> MOV %REG,-( SP) .ENDM .IFF . IRPC MOV .ENDM .ENDC .ENDM

REG,<012345> %REG,-(SP)

.MACRO POP,REGLIS

.IF NB,<REGLIS>

.IRPC REG,<REGLIS> MOV (SP)+,%REG .ENDM • IFF .IRPC MOV .ENDM .ENDC .ENDM

REG,<543210> (SP)+,%REG

.MACRO SAVE,Z,N,V,C

.IF EQ, N CLEAR•AB1000

.IFF SET•AB1000

.ENDC

.IF EQ, Z CLEAR•CLEAR I ABlOO

.IFF SET-SET ! ABlOO

.ENDC

.IF EQ, V CLEAR-CLEAR ! ABlO

.IFF SET•SET I ABlO

.ENDC

.IF EQ, C CLEAR•CLEAR ! 1

.IFF SET•SET I 1

.ENDC

RSTS/E code

;-----------------------------------<« PUSH »>

Invocation: PUSH <012> or PUSH Push the indicated registers onto the stack. If no register list is used a PUSH <012345> is assumed .

;-----------------------------------«< POP >»

Invocation: POP <210> or POP The order should be reversed from the PUSH specification if specific registers are named . A POP without argument is assumed to be POP <543210>

;-----------------------------------<« SAVE »>

Create bit masks of the condition codes. The bit mask for the bits to be set is stored in SSAVE. The mask for bits to be cleared is stored in CSAVE.

IAS-19

RDUMP::

16$: 14$:

20$: 12$:

24$: 22$:

26$: 10$:

34$: 32$:

40$: 30$:

44$: 42$:

46$:

RED:

MOV #SET,SSAVE MOV #CLEAR,CSAVE JMP RED .ENDM

;-----------------------------------; <<< Entry Point >>> i ; Save the Condition Codes

BNE 10$ i z branch if Z•O BPL 12$ i N branch if N•O BVC 14$ i v branch if V•O BCC 16$ i c branch if C•O SAVE 1,1,1,1 ; Zl,Nl,Vl,Cl SAVE 1,1,1,0 ; Zl,Nl,Vl,CO BCC 20$ ; c branch if C•O SAVE 1,1,0,l i Zl,Nl,VO,Cl SAVE 1,1,0,0 i Zl,Nl,VO,CO BVC 22$ ; v branch if V•O BCC 24$ i c branch if C•O SAVE l,0,1,1 ; Zl,NO,Vl,Cl SAVE l,0,1,0 ; Zl,NO,Vl,CO BCC 26$ i c branch if C•O SAVE l,0,0,1 ; Zl,NO,VO,Cl SAVE 1,0,0,0 i Zl,NO,VO,CO BPL 30$ i N branch if N•O BVC 32$ i v branch if V•O BCC 34$ ; c branch if C•O SAVE 0,1,1,1 ; ZO,Nl,Vl,Cl SAVE 0,1,1,0 ; ZO,Nl,Vl,CO BCC 40$ ; c branch if C•O SAVE 0,1,0,l ; ZO,Nl,VO,Cl SAVE 0,1,0,0 i ZO,Nl,VO,CO eve 42$ i v branch if V•O BCC 44$ ; c branch if C•O SAVE 0,0,1,1 i ZO,NO,Vl,Cl SAVE 0,0,1,0 ; ZO,NO,Vl,CO BCC 46$ i c branch if C•O SAVE 0,0,0,1 i ZO,NO,VO,Cl SAVE 0,0,0,0 i ZO,NO,VO,CO

i PUSH <0123> ; save Registers

;The Stack now looks like: PC (from JSR instruction)

RO Rl R2

SP>-- R3 i

MOV #STRl,Rl JSR R2,PRINT

JSR R2,RNAME .WORD "RO MOV 6( SP) ,Rl ; Register Zero JSR R2,0CTAL

IAS-20

JSR .WORD MOV JSR JSR .WORD MOV JSR JSR .WORD MOV JSR

CALL

JSR .WORD MOV JSR JSR .WORD MOV JSR JSR .WORD MOV ADD JSR JSR .WORD MOV JSR

MOV JSR

JSR .WORD BIT CALL

JSR .WORD BIT CALL

JSR .WORD BIT CALL

JSR .WORD BIT

R2,RNAME "Rl 4 (SP), Rl R2,0CTAL R2,RNAME "R2 2( SP) ,Rl R2,0CTAL R2,RNAME "R3 (SP) ,Rl R2,0CTAL

CRLF

R2,RNAME "R4 R4,Rl R2,0CTAL R2,RNAME "RS RS,Rl R2,0CTAL R2,RNAME "SP SP,Rl U2,Rl R2,0CTAL R2,RNAME "PC lO(SP) ,Rl R2,0CTAL

#STR2,Rl R2,PRINT

R2,RNAME " N #'BlOOO,SSAVE BIT

R2,RNAME " z #'BlOO, SSAVE BIT

R2,RNAME "v t'Bl0,SSAVE BIT

R2,RNAME n C

U,SSAVE

Register One

Register Two

Register Three

Register Four

Register Five

Stack Pointer calculate original value

Program Counter print address of the next inst. in the calling program

N bit

z bit

v bit

c bit

IAS-21

CRil: CRI2:

CALL

CALL

MOV MOV BIS BIS

POP .BLKW .BLKW RETURN

BIT

CRLF

#000240,CRil #000260,CRI2 CSAVE,CRil SSAVE,CRI2

<3210> 1 1

Create instructions to restore condition codes to the pre-RDUMP values.

The instruction in CRil will Clear the required condition codes while the instruction in CRI2 will set any that should be set. If none need to be set, each is left a NOP. Note: 260 is an undocumented NOP. Restore Everything

Created Instructions to restore condition codes

EXIT ;-----------------------------------; «< Data »> ,

STRl: .ASCIZ STR2: .ASCIZ SPACES: . BYTE

<15><12>/Register Dump/<15><12> <15><12>/Condition Codes/<15><12> 40,40,40,40,40,40,0

.EVEN SSAVE: .BLKW CSAVE: .BLKW

1 1

RNAME:

MOV #40 ,RO .TTYOU .TTYOU MOVB (R2)+,RO .TTYOU MOVB (R2)+,RO .TTYOU MOV #'•,RO .TTYOU RTS R2

CRLF: MOV US,RO .TTYOU MOV U2,RO .TTYOU RETURN

BIT: BNE 10$ MOV #'0,RO

;-----------------------------------< « RNAME » > Print the sequence: Space, Space 2 character register name, equal sign. 40•space

get 1st argument character

2nd, now R2 points to return address

;-----------------------------------«< CRLF >» print carriage return· and line feed

;------------------------------------<« BIT »> print a 1 or 0 for the condition

IAS-22

10$: 20$:

OCTAL:

10$:

20$:

PRINT: 10$:

DONE:

BR MOV .TTYOU MOV JSR RETURN

PUSH CLR MOV BR CLR ROL ROL ROL ROL ROL ROL ADD .TTYOU DEC BNE POP RTS

PUSH MOVB BEQ .TTYOU BR POP RTS

.END

20$ #'l,RO

#SPACES,Rl R2,PRINT

<02> RO #6,R2 20$ RO Rl RO Rl RO Rl RO #60,RO

R2 10$ <20> R2

<0> (Rl)+,RO DONE

10$ <0> R2

code status.

;-----------------------------------< « OCTAL » >

Invocation: JSR R2,0CTAL with the value to be printed in

octal in Rl.

;-----------------------------------<« PRINT »>

Invocation: JSR R2,PRINT with the address of the string to be PRINTed in Rl. The string must be be terminated by a zero byte.

IAS-23

STEERING COMMITTEE MEMBERS LANGUAGES AND TOOLS SIG

Mark Bartelt HSC - Research Denlopment Ctr 555 Uni1'ersity Avenue Toronto, Ontario, Canada M5G 1X8

Gordon Brlmble Bldg 180 Labs Area Defence Research Centre Box 2151 GPO Adelaide, S.A. Australia 5001

Barb Chase 9619 Belford An # 3 Los Angeles, CA 90045

Earl Cory Cory Computer Srstems 366 North Nueve Court Camarillo, CA 93010

Rod Creason, Jr. 3336 Bradshaw Road, Suite 340 Sacramento, CA 95827

Jack Davis Philips Home Interactive Srstems 1111 North Shore L'rin Knoxville, TN 37919

Jim Flatten Ames Lab 304 Metallurgr Ames, IA 50001

Alan Folsom, Jr. Fi.ocher & Porter Co. E. County Line Rd. Warminster, PA 18974

Bob Gable Lear Siegltr 1 Instrument DiYi1ion 4141 Eastern SE MS 121 Grand Rapids, Ml 4%08

Bernd Gllss Max-Planck-Institute Heisenhergstra8e 1 7000 Stuttgart 80, W. Germany

Keith Hare JCC PO Box 381 128 West Broadway Granville, Ohio 43023

UNISIG Interface {416)598-5955

Australian L&T Interface {61)(8)276-7892 (home) (61)(8)259-6119 (office)

Vice-Chair (213) 641-5434 (home)

Symposium Coordinator Session Chair Coordinator (818) 889-2211 (work) (805) 484-7705 (home)

UNIX Coordinator (916) 363-i385

Modula II Coordinator (615) 558-5206 (work) (615) 588-5800 (switchbd)

GAPSIG Interface (515) 294-4823

New1letter Editor Publication CommlttH (215) 674-7154 (work) (215) 443-7063 (borne)

Ada Coordinator (616) 241-8273

European Methods, L&T Interface

(711) 735-1929 (home) (711) 686-0251

DMS & DTR Liaison (614) 587-0157

Howard Holcombe RCA Front & Cooper St. Camden, NJ 08055·

Kathy Hornbach Lear Sieirler /Instrument Division 4141 Eastern SE MS 121 Grand Rapids, Ml 49508

Mark Katz GTE Govt Systems 100 First Ave. Waltham, MA 02154

Jim Livingston Measurex Corporation l R .. ults Way Cupertino, CA 95014

Dave Martin Hughes Aircraft Company PO Box 92426 Bldg RI, MS C320 Los An~eles, CA 90009

Shava Nerad Systems Alternatives 43 State St Montvelier, VT 05602

AIRlnuto EMC Control, Inc PO Box 242 Cockeysville, MD 21030

Don Rosenthal Space Telescope Science Institute Homewood Campus Baltimore, MD 21218

Tony Scandora Argonne National Laboratory CMT 205 Ar~onoe, Illinois 60439

Bill Segal Digital E'luipmeot Corp. 110 Spit Brook Rd. ZK02-3/N30 Nashua, NH 03062

George Stuart Ogden-Weber/ AVC Ogden, UT 84404

DEC Personnel Coordinator (609) 338-4946 (work) ( 609) 654-9603

Chair Productivity Tools Coordinator Pre-Symposium Seminar Coordinator (616) 241-8800 (616) 454-8716 (borne)

Session Notes Editor (617) 466-3437 (617) 964-1836 (home)

Past Chair ( 408) 255-1500 X4468 (408) 253-5227 (home)

Tape Librarian STUG Interface (213) 648-9927 (213) 641-8382 (home)

Steering Committee (802) 22~-0823

Wlshllst Coordinator (301) 667-8315 (work) (717) 456-5302 (home) (717) 456-5014 (recorder)

LISP/ Al Coordinator (301) 338-4844 (work) (301) 235-6998 (home)

RSX Interface (312) 972-7541 (312) 653-3885 (borne)

Digital Counterpart (603) 881-2056

RSTS Interface (801) 621-2373

L&T-i

Pat VanMunn Measurex Inc. One Results Way Cupertino, CA 95014

Jay Wiiey Bechtel Power Corp 12400 East Imperial Hirhway Norwalk, CA 90650

JR Westmoreland Custom Software Products 67 48 Acoma Rd Midvale, UT 84047

Melodee Westmoreland Custom Software Products 6748 Acoma Rd Midvale, UT 84047

Sam Whidden American Mathematical Society 201 Charles St PO Box 6248 Providence, RI 02940

Ed Whipple Lawrence Berkeley Labs University of California Berkeley, CA 94720

Louise Wholey Measurex Corp One Results Way Cupertino, CA 95014

Jim Wiison QZ Division PO Box 88 Terre Haute, IN 47808

Michelle Wong 3336 Bradshaw Road, Suite 340 Sacramento, CA 95827

Methods Coordinator PSS Committee Representative (408) 255-1500

Standards Coordinator Fortran Coordinator (213) 807-4016 (work) (714) 525-2533 (home)

Assistant to the Chair C Coordinator Commercialism Task Force (801) 535-4784 (801) 262-5251 (home)

Recording Secretary (801) 533-2350 (work) (801) 262-5251 (borne)

1l;;X Coordinator S6 bit Coordinator Store Liaison (401) 272-9500 (work) (401) 333-06i9 (home)

CMS/MMS Coordinator Session Chair Coordinator (415) 486-7167

VMS Interface (408) 255·1500 X4452

Commercial Languages lnterrace

(812) 299-21?1 X271

RT-11 Interface (916)363-7385

[Ql DEC US

DIGITAL EQUIPMENT COMPUTER USERS SOCIETY

The Newsletter of the Large Systems SIG

SIG STEERING COMMITTEE SIG Chairperson

Leslie Maltz Stevens Institute of Technology Computer Center Hoboken, NJ 07030 (201)420-5478; BITNET:LMALTZ@SITVBX; ARPANET:SIT.MALTZ@CU20B

Symposium Coordinator Robert c. McQueen Stevens Institute of Technology Computer Center Hoboken, NJ 07030 (201)420-5454; BITNET:RMCQUEEN@SITVXB; ARPANET:SIT.MCQUEEN@CU20B

Newsletter Editor Michael D. Joy The First Church of Christ, Scientist Christian Science Center A31 Boston, MA 02115 (617)262-2300 x3903

Menu Coordinator Charles R.T. Bacon National Institutes of Health Building 12 B Room 2N207 Bethesda, MD 20205 (301)496-4823

Hardware Coordinator Clive Dawson Microelectronics & Computer Technology Corp. 9430 Research Blvd.; Echelon Bldg. #1, Suite 200 Austin, TX 78759 (512)343-0860; ARPANET/CSNET:CLIVE@MCC

Languages Coordinator David Edwards DPEX, Inc. 240 Pamela Drive, Mountain View, CA (415)965-3739

Suite #1 94040

LS-i

TOPS-20 Coordinator Pete Galvin University of Texas at Austin Computation Center Austin, TX 78712 (512)471-3241

Networks Coordinator Richard Janick Abbott Laboratories AP14, D-0048 Abbott Park, IL 60064 (312)937-4305

Systems Software Coordinator Betsey Ramsey American Mathematical Society P.O. Box 6248 Providence, RI 02940 (410)272-9500 x295

Special Projects Coordinator Osman Ahmad Assiciation of American Railroads 3140 S. Federal St.; Technical Center, Research & Test Dept. Chicago, IL 60616 (312)567-3627

DEC Counterparts Dave Braithwaite Digital Equipment Corporation Marlboro, MA

Jack Buckley Digital Equipment Corporation Marlboro, MA

Reed Powell Digital Equipment Corporation Marlboro, MA

LS-ii

CHAIRPERSON'S ARTICLE Here we go again. Time for the Spring Symposium in Dallas. All of you should have received information on the symposium including registration, hotel, and schedule details. Dallas should present an opportunity for attending some interesting activities. The SIG is sponsoring sessions to begin to acquaint new highend VAX sites with some of the information needed to make their systems really work. These sessions should be of significant value to Large Systems SIG members who have chosen to follow an integrated path that includes VAX systems as well as to new highend VAX sites. Both managerial and technical issues will be presented. A significant number of sites have now ordered and/or installed highend VAX systems and clusters to supplement or replace 36 bit systems. A track of sessions has been scheduled to meet the needs of highend system installations. We are attempting to meet the needs of this growing community that has many common concerns, and will be supporting additional activities, products, and services even more so in the future.

The Dallas symposium will certainly include those session that we normally present to serve the needs of the installed base of 36 bit systems. In particular, sessions will be held to identify the precise details of what we want to see as development efforts from DEC in our final years of the promised five years of active development. We are nearly three years into the five year period, and can assume that time is rapidly disappearing for inclusion of new features/functionality. These sessions in Dallas are intended to be perhaps the final opportunity for voicing desires and concerns for development oriented efforts. Please give this area considerable thought in preparation for attending these sessions. Other issues, particularly dealing with long term support, will be emphasized also.

The Large Systems SIG is sponsoring a special attraction that no one will want to miss. As requested, a new version of our extremely popular VAXBUSTER shirts will be available for purchase in the DECUS store. The 1985 version was so popular at the Anaheim symposium that the entire stock of shirts sold out - most on the first day. We're sure you'll love the 1986 model. So be sure you get yours before they sell out.

1986 marks a milestone in the life of DECUS. It is the 25th anniversary of the society. To mark the occasion, DECUS is sponsoring a number of special events, some of which are similar to those presented when we celebrated our 20th anniversary in 1984. There will be exhibits of memorabelia, special sessions, and a gala Texas-style of celebration. If you'd like to participate or if you've got a DECUS artifact that you're willing to loan to us for the exhibit, please contect me or just bring it to the symposium.

Nothing in Texas is small, and we expect the symposium to be a big success. The Large Sytems SIG will live up to the expectations of presenting a big Texas-style of symposium. See you there soon.

LS-1

ONE USER WRITES

Open Letter to the 36-Bit Community c/o Leslie Maltz ComDuter Center Stevens Institute or Technology Hoboken, NJ 07030

Dear Leslie,

PANDA PROGRAMMING 180~ Hackett Ave .. Raintiow Suite Mountain View, CA Q1043-H31 USA +1 (115) Q68-1052

Mark R. Crispin, Pr°'ident

Friday, 3 January IQ86

I was disturbed by the results or the SDflng 85 Large Systems Menu. I Interpret what happened ln two ways. First, the •everybody can vote• as opposed to •per site• voting policy was not made clear. Second, sites which have picked non-VAX alternatives may no longer care about what DEC

does, and abstained from voting. The result Is clear; the results represent primarily those sites which are staying with DEC and hence are migrating to VAX/VMS.

I wish to remind everyone that there Is less than 2 1/2 years left In DEC"s promised 5-year period or 36-blt development. We should do our best to Induce DEC to use this time to our maximum advantage. I have several suggestions to allow us all to use our menu most effectively:

First, those of us who are migrating to V A.."X/VMS should bring VAX-related Issues In the VAX Systems SIG Menu and not the Large Systems SIG Menu. That way, our needs would be known by

the entire V A..X/VMS community. The 36-Mt community knows quite well what VMs· limitations are for large sltes: It Isn't clear that the V~fS community does. Remember that most of the latter sites came from the PDP-11 world and see \'MS as a completely fantastic reimplementation or RSX. Our

preser1ce In their forum Is the best way to educate them.

Second, we should give serious consideration to what DEC can (and Is willing to) do In 2 years. I'm sure all TOPS-20 sites would like a native mode MACRO and LINK. rm sure all TOPS-10 sites woul·J like extended addre~sing !ani;uages. All of us would like to see the KL trade-in offer continue forercr. These things hare 1bout as much chance of happf'ning as DEC's deciding to •uncancrJ• the

36-l•it product lin{'. It is a waste of votes to ask DEC for thin:;s they will ~-3.Y •no• to.

Third, we should not waste votes on solvrd problems. Several of the menu it~ms referred to ch:rn:;es DEC has alrf'ady made. or to :::oftware enhancements :ilrf'ady done by customers and freely

distributed (more on this below). DEC should be adopting drslrable changes from customers without being asked. E'i·cn if DEC doesn't. we should have DEC working on projects that are best (or can only

be) <lone by DEC. This leads me to ..

Fourth. we should concentr:He our votes on language development. It·s a waste of the llttle time we have left to have DEC continue to play with the oper1tlng systems. \\'e might as well ha\'C DEC rreeze them now and concentrate on l·orrectlng the dl:::m1l state or TOPS l1nguages. I suggest a single menu item. to avoid the current fr:igmentatlon of our concerns In this area -- "Finish languages: 'upport up to latest .4NSI ,1a11dards (at least up to current l".-lX/\'AIS nipport let'cl}. Extrndrd addrr.~,<:i11g n..1ppnrt in all languagr~; at lra~t 1 uction rodr+m!l.lti uction d,1ta on TOPS-!!0. and

LS-2

Page:!

preferably multi-«ection code/data on both TOPS-1!0 and TOPS-10." [Why not? Maybe there'll be enough time Jeft for the brillant TOPS-JO hackers to do extended languages after all ... J

Fifth, help yourselves in your on-site support and help the outside vendors who plan on offering development and support or 36-blt hardware and software In the rost-DEC era. Menu Items 1.5 and 1.7 are particularly Important -- TOPS license fees ror third-party CPU's should be reduced now. When development end, TOPS and all associated software (utilities, languages. etc.) should be placed In the public domain and sources provided to all customers.

To elaborate on t.hls last DOlnt, there are organizations whtch are wllllng and eager to take over TOPS operating system and uttllty development for a.s long as there are sites that are willing to pay for It. DECUS commercialism guJrtellnes keep me from naming any names, but at least one hardware vendor Is building fast (and physically small) 36-blt CPUs that run TOPS. At least one software vendor has Incorporated the public-domain •solved problems• mentioned above (along with many other Improvements) Into an enhanced TOPS-20 (distributed as REDIT updates). There Is no longer a need to wait on DEC to Improve the operating systems. Once DEC releases Its proprietary rights to TOPS these vendors will be rree to develop and distribute these enhanced versions as complete packages to the entire community.

As a nnal plug, please remember language development. I am arrald that once DEC throws In the towel language development will end for good. It it doesn't get done now it may never get done!

Warmest regards ror the New Year, and keep the faith.

Sincerely,

~ 1';,;;k R. Crispin -

LS-3

DOCTOR TOPS Dear Doctor Tops, I have a vintage KI-10 console that I want to hook up to my VAX, and make operational. I have taped over four of the lights, and four of the switches, giving me 32 bits. What do I do next?

Bare Metal Debugger

Dear BDM,

1)

2)

3)

4)

5)

6)

You are off to a good start! What you need to do next is as follows:

Renumber the lights, from left to right starting at "31" and ending at ''O'', to be like powers of two. This gives you the correct bit numbers. Do the same for the switches.

Turn the voltage margin knob to one extremety or the other, since the power supplies of the 11/780 are non-ajustable anyway.

Turn the speed control ''coarse'' knob to 11 1 11 for SLOWEST operation. Turn the speed control "fine" knob CCW to stop as per above.

Tape over all the "PI" lights, since the priorities on the VAX are all software anyway.

Relabel the "USER CONCEAL" light to be ''EXEC". Relabel the EXEC MODE and USER MODE labels to "PROCESSOR MODE".

You might want to use the 11 Pl 11 lights to complete the PROGRAM COUNTER display which needs 32 bits.

You are now ready to perform the hardware interfacing to the UNIBUS! Since the UNIBUS is only 16 bits wide, you will need some fancy hardware to make this work. I Suggest a MC68020 with 256KB ROM and lMB RAM at 12 MHZ, since you can get a UNIBUS to MULTIBUS converter at a reasonable price. This has the added advantage of allowing you to address the bits and bytes in left to right order. The VAX speaks right to left in most cases. Consult with manuals #6 (I/O User guide) and "Guide to writing a device driver" for information on getting at the unibus. You will need to read all the VAX manuals though, since what you want is NEVER in just one manual. Since this is a DMA type device, you will need to cut a wire wrap from CBl to CB2 on the unibus slot that your adapter will plug into. NOTE: Field Service may want to do this for you.

You will further need to pull some signals off the backplane of the 780. Consult the print set provided with the machine for the real pins to monitor.

Then and only then, take 40' of duct tape and tape the console to the side panel of the processor. Be sure not to cover the on/off keyhole on the front panel since you may have a fire and want to turn off the VAX! The bottom line is you can't pack 36 bits into 32, even though you use duct tape. Besides, when they upgrade to the next releasd, all your drivers will break anyway.

Dr. Tops

LS-4

Dear Doctor Tops, I have a largish FORTRAN program that I am running on my 2060 that

I want to move to my 780. The program uses 6 sections for data, and 2 for code. It takes about 3:15:00 for a short run and 5:30:00 for a long run in CPU time. The elapsed time is very close to CPU time. When I run this program on the VAX, it takes 4:30:00 for the short run in CPU and 10+ hours of real time. The VAX is otherwise IDLE when this program runs. What can I do to help this program run in less real time on the 780?

Big Simulator

Dear Big Sim, In investigating your program, I see you are doing several things

that VMS does not handle as well as TOPS20. The first is page faulting, the second is DIRECT i/o. Most of your array references are to new pages because of the size of your arrays and the order you index them in. To correct this would take a much greater effort in re-programming than is really desirable. A simpler step would be to increase your WORKING-SET size to at least 2048 pages, and 4096 pages would be better (the program alone takes up 8,000 pages without the RTL images). This should cut down on the page faulting and reduce your real time to runtime ratio. If you don't have 8MB on your VAX, you should get it or more. The AUTHORIZE utility can change your WSQUO.

The second problem is in the amount of ACCESS=DIRECT i/o you are doing. RMS has to do a lot of running around for every i/o request it gets. In running a test case of your program I noted some 900,000 of these. You only had 400,000 page faults. Either you re-write your code and remove these (sequential) direct i/o calls, or you can change your RMS parameters with SYSGEN. Since the VAX has a lot more address space than the 20, you might consider reading in the WHOLE database you are working with. This will eliminate all those i/o calls.

The real time change going from a 20 to a 780 is suprising. A real VMS guru could make the program run better by additional tweaking, but only at the expense of making some other application run worse.

Dr. Tops

PS: I will gladly answer most any TOPS to VMS conversion questions or any related topics. Send your questions or comments to Dr. TOPS in care of the Large Systems SIG newsletter editor:

Michael D. Joy The First Church of Christ, Scientist Christian Science Center A31 Boston, MA 02115

LS-5

MUMPS

MUMPS SIG STEERING COMMITTEE

Chairman Mark Berryman Plessey Peripheral Systems Irvine, CA

Symposium Coordinator Chris Richardson Computer Sciences Corp. Ridgecrest, CA

Communications Rep. Mark Hyde Advanced Computing Services DeWitt, NY

Newsletter Editor Janet Berryman Plessey Systems, Inc. Irvine, Ca

VAX Liaison Coyett A.J. Dese VA DM&S Verification & Dev. Ctr. San Francisco, CA

Digital Counterparts Beatrice Walther

MMP-i

Digital Equipment Corp. Marlboro, MA

Diane Brown Digital Equipment Corporation Marlboro, MA

Application

Presentation

Session

Transport

Network

Data Link

Physic: al

Bill Brindley Chairman Naval Security Group Command (202) 282-0527

Jim Ebright Communications Coordinator Software Results Corporation (614) 421-2094

Vickie Hancock Newsletter Editor (214) 495-7353

Sandy Traylor Symposia Coordinator Target Systems, Inc. (714) 921-0112

Bi 11 Hancock T echno 1 ogy/

Standards Coordinator (214) 495-7353

Carole Greenfield DEC Counterpart Digital Equipment Corporation

The Networks Special Interest Group (SIG) is one of 25 SIG's within in Digital Equipment Computer User's Society (DECUS). The main purpose of the Networks SIG is to promulgate information concerning the use, development, and standardization of network products that function or involve Digital Equipment Corporation systems. Additional functions of the SIG include the coordination and scheduling of symposia sessions, providing methods for free-flow communicatlons, publication of the Networks SIG newsletter NETWords, participation in domestic and international standards committees, input to Digital for new products and corrections to existing products, promotion of working groups for special network needs and topics, and many, many other functions.

The Networks SIG Steering Committee invites you to participate in the Networks SIG. There are many ways that you can help the Networks SIG. Some of those include chairing sessions at symposium, participation in the various Networks SIG working groups, partlcipation in special research projects, and others. If you are interested in devoting your time and expertise, contact any of the steering committee members.

DECUS is run entirely by volunteer leadership. Help us make DECUS and the Networks SIG better - take an active part in your SIG!

NTW-3

r - - -/,·-""-- - - ; , "

I / OFFICE ,, I I /' ~, I

I I I I

I I I I

I J ~ /' I ,, , I I ,, ,/ i I ,, ,/ I

- -,, ''''" "'''" '"'"""'"'''''''""'''"'''' ''''' ''""""""''""'"'"""''''"'""'"''"'"'''''''"""'"""'''"'""'""""' '"' ,,,..,,. . ., .. ,, ....... .,,,,,,,,,.,,, '

OFFICE AUTOMATION SIG STEERING COMMITTEE

Chairman Katherine' Kit' Trimm Pivotal, Inc. Tucson, AZ

Vice Chairman Ralph Bradshaw Johnson and Johnson Raritan, NJ

Communications Committee Representative E. Catherine Ditamore ARA Services Philadelphia, PA

Symposium Coordinator Mitch Brown Gen Rad, Inc. Waltham, MA

Special Projects Gene Leclair HQ Dept. of Army Washington, DC

BOF Coordinator Ray Kaplan University of Arizona Tucson, AZ

Newsletter Editor Therese LeBlanc Wheeling, IL

Library Bob Hassinger Liberty Mutual Research Center Hopkington, MA

Tape Copy Coordinator Randall Buck Columbia Savings Irvine, CA

OA-i

ALL-IN-1 Working Group Leon E. Ottley Evans and Sutherland Salt Lake City, UT

Symposia Assistant Sal Gianni Northeast Utilities Hartford, CT

Store Coordinator Mike Jackson Air Force Operational Test and Evaluation Center Kirtland AFB, NM

Personal Computer SIG Liaison Cheryl Johnson Grinnell College Grinnell, IA

Networks SIG Liaison Gene LeClair HQ Dept. of Army Washington, DC

DECUS Europe QA SIG Andreas Verbay Telinco AG Spiegelstrasse 20

Digital Counterparts Les Agigian Digital Equipment Corporation Merrimack, NH

Geof Bock Digital Equipment Corporation Merrimack, NH

Session Notes Martha Rudkin GM F Robotics Troy, Ml

In This Issue

From The Editor ........................................ l Therese LeBlanc

OA SIG Services ........................................ 2 - Informational

First Time Attendees ................................... 2 - Informational

Symposium Session Outline .............................. 3 - Mitch Brown

Call For Tape Submissions .............................. 4 - Randy Buck

'

OA-1-1

From The Editor

Our April issue offers some useful information about the OA SIG's services during Symposia and throughout the year. We also have a feature article by Randy Buck, our new Tape Copy Coordinator and a final review of the sessions being offered by OA in Dallas.

Hope to see you all in Dallas.

Wheeling, IL 60090 (312) 459-1784

OA-1-2

QL§.!.fLg!Y!.f.!§.

As we approach another Symposium, we would like to take a moment to review the services offered by the Office Auto­mation Special Interest Group (OA SIG). These services are provided during the symposoium and throughout the year to serve DECUS members interested in OA.

* Over 50 hours of OA sessions will be offered at the naiias-sympositi;~--contact-Mitch Brown <116) 890-4900 if you would like to find out more about giving a session at the next symposium.

* Birds Of a Feather (BOF) meetings will be scheduled as infor;al-sessions-during Symposia at your request.

* !~!£~!!~!_!£!£~-~!!' for Senior Management. The OA SIG and Digital will once again sponsor an Executive Track Day during the Dallas Symposium. This is an opportunity for executives to share insights and develo~ new ideas for their company's Office Automation. If you would like your senior management to participate, please contact Kit Trimm (602) 886-5563.

* Q~!-~!l_f£~=§.l~£2~i~~-§.~~i~!£~_lf§.§.l are offered on Sunday before the start of the symposium. They address specific topics in greater detail than a one hour symposia session can. The OA SIG is sponsoring the PSS "Why All-In-1 is Not Office Automation". For more information on attending or giving a PSS, contact Sal Gianni (203) 665-5652.

* Q!_!!£~-~~!£' For more information on the Tape Swap see Randy Buck's article in this issue.

* Q!_~££!!._Q~!£~~-~££~£_l~Q~l· The first OA LUG has been formed in the Washington DC area. For more information on starting a LUG in your area contact Tom Orlowski, HQ Dept. of Army, Alexandria, VA.

* ~l~!~~-!.~££2~~~~g!_!~~~~~!_l~!.!l· SIR's are presented to Digital twice a year by the AO SIG. Anyone can submit an SIR either in person at the Dallas Symposium "OA Wishlist Session" on Friday, May 2nd, or by completing the SIR form in the tear-out section of this newsletter. For more in­formation contact Catherine Ditamore (215) 574-7161.

* OA Newsletter. The OA newsletter appears each month in this publication~- It is a forum for you, our readers, to share ideas and information with one another. Contact Therese LeBlanc (312) 459-1784 with submissions.

OA-2-1

Services Page 2

We invite each of you to introduce yourselves to the OA SIG Members (listed in the front of our newsletter) during the Dallas Symposium. We would like to meet you and answer any questions you may have regarding these services. If l£~ have an idea for a service that is not listed here, . please tell us about it, new ideas and volunteers are always welcome!

****************************************

I!.!§.!_!!.~!_!!!!~~!!~

Is Dallas going to be your first symposium? Confused by all the things to see and do? Wondering how you will find your way around amid all the 'old pros'? We would like to help you!

Please make sure you attend the Welcoming Reception on Sunday, April 27th, from 9:00 P.m. - 10:00 P.M. in the Chantilly Ball­room, lobby level, Loews Anatole Hotel. Come to the OA area and introduce yourself as a first timer, we will help answer many of your questions and introduce you to other people with similar interests.

Also make sure you attend the First Timers Meeting Sunday at 6:30 P.M. in the same Hotel.

OA-2-2

9:00 - 9 30 9:30 - 10 30

10:30 - 11 30 11:30 - 12 30 12:30 - 1 30

1:30 - 2 30 2:30 - 4 00 5:00 - 6 00 6:00 - 7 00 7:00 - 8:00 8:00 - 9:00 9:00 - 10:00

9:00 - 10:00 10:00 - 11:00 11 :00 - 12 :00 12:00 - 1:00

1:00 - 2:00

2:00 - 3:00 3:00 - 4:00 4:00 - 5:00 5:00 - 6:00

9:00 - 10:00

10:00 - 11:00 11: 00 - 12:00

12:00 - 1:00 1:00 - 2:00 2:00 - 3:00 3:00 - 4:00

4:00 - 5:00

5:00 - 6:00

0006 0021 0019 0059 0026 0049 0022 0050 0051 0048 0044 0025

0040 0012 0020 0007 0002

0027 0004 0009 0042

0037

0038 0039

0060 0035 0062 0063

0064

0061

M 0 N D A Y

OASIG ROADMAP Keynote: OA -- The State of the Art The Strategic use of Executive Information Systems TLC With a "Lean And Mean" system The Mail Architecture and strategy Strategic Directions for Business Office Systems Office Automation Systems Update Word and Document Processing Update Compound Documents and High Quality Ofc. Publishing Customizing ALL-IN-1 User Documentation PCs in Office Systems Programming a Message Router Application

T U E S D A Y

VAX Teamdata and VAX Rally: Ofc. Info. Solutions Selling OA: ALL-IN-1 Meets Madison Avenue ALL-IN-1 System Customization Panel OASIG General Meeting Computer Conferencing: The Next Step in Business

Communications Human Factors for Off ice Products Videotex for Managers Why ALL-IN-1 is Not Office Automation user Support Groups for OA Products

W E D N E S D A Y

Videotex, Solutions

Taking Advantage of the New Features in VAX/VTX V2.0 and V2.l

Taking Advantage of VAX/VALU Features Distributed Videotex Infobases in the Off ice and the

Corporation worldwide Electronic Mail WPS-PLUS List Processing Digital's Business Solutions Strategy Digital's Solutions for Sales and Marketing

Departments Digital's Solutions for Finance and Business

Operations Digital's Solutions for Human Resource or Personnel

Departments

OA-3-1

9:00 - 10:00 10:00 - 11:00 11:00 - 12:00

12 00 -1 00 -2 00 -3 00 -4 00 -5 00 -

9 00 -10 00 -11 00 -12 00 -

1:00 -2:00 -3:00 -4:30 -6:30 -

1 00 2 00 3 00 4 00 5 00 6 00

10 00 11 00 12 00

1 00 2 00 3 00 4:30 6:30 8:00

0047 0030 0031

0053 0034 0032 0058 0011 0036

0023 0016 0052 0033 0024 0045 0041 0015 0043

W E D N E S D A Y

Technical

The Power of Modifiable Printer Tables ALL-IN-1 as an Application Generator Introduction to Application Development Using

ALL-IN-1 External Applications and WPS-PLUS ALL-IN-1 for People Who Write Device Drivers Application Development Tidbits Real Programmers Use ALL-IN-1 Integrating Local Applications Into ALL-IN-1 ALL-IN-1 scripts

THURSDAY

ALL-IN-1 System Management (Digital's View) ALL-IN-1 System Management (User Panel) ALL-IN-1 on VAXclusters The ALL-IN-1 Skill Set Managing Your Mail Network User Communications: Problems and Solutions ALL-IN-1/WPS-PLUS Performance Update Advanced ALL-IN-1 Programming Management Planning for OA Systems

6:30 - 9:00 0057 Damper -- The Data Management Game

9:00 - 10:00 10:00 - 11:00

11:00 - 12:00 12:00 - 2:00

0005 0003

0046 0008

F R I D A Y

Don't Panic! Training the Non-Technical user Techniques and Tactics of ALL-IN-1 version 2

Training Customizing ALL-IN-1 User Documentation OASIG Wishlist and Wrap-Up

OA-3-2

CALL FOR TAPE SUBMISSIONS

I would like to bring everyone up to date (within 30 days or so) on the OASIG tape project. First of all there will be a small tape available shortly. Secondly, I need your input for the next tape.

- No submission is too small (or too big) If all you have is one little file that does something special for an OA user, go ahead and send it in.

- Documentation should not prevent you from submitting something All you need to do is create an AAAREADME.TXT file with enough information to use your submission. Include your name and phone number so I may contact you if I need to add something.

- Contributions do not have to be ALL-IN-1 specific Office Automation includes many products. Enhancements for Datatrieve, DECALC, DECGRAPH, DECSLIDE, DECSPELL, DECTALK, WPS+, and so on are welcome.

HOW DO I SUBMIT MATERIAL?

Create a tape of your contributions with VMS BACKUP. Please record the tape at 1600 BPI. Even though your contribution may only require a few blocks, use a 2400 foot reel. Package your tape in a re-usable container or include a large padded envelope that the tape can be returned in.

On the tape: Use a directory tree to separate large or multiple submission

Include an AAAREADME.TXT file in each directory. This text file should contain a brief description of your submission, w it does, and how to use it.

Use file and directory names that can be used on VMS 3.x.

If your submission includes FMS forms, put them in a USER.FLB file.

Please fill out and include the DECUS Program Library Submittal Form with your submission. For the small amount of time it takes to fill out this form you will be rewarded with a very nice plaque acknowledging your contribution to the DECUS library. The entire OASIG tape will become available from the DECUS library only if everyone fills out the submittal form.

When you send your submission on tape, I will return to you the entire OASIG collection. At this time a 600 ft reel would be adequate but I expect the OASIG tape project to grow rapidly over the next year or so. Who knows, it may become as large as the VAX sig tape!

OA-4-1

One of the things I can do to aid in the creation of the tape is to allow submissions in formats other than mag tape. At this time I have access to a RAINBOW PC and an IBM PC which can be used for downloading files to the VAX. If you have a short .SCP or .COM file (less that 100 lines) I would be willing to type it in from hardcopy.

Send your submissions to: Randall Buck Columbia Savings and Loan 17911 Von Karman Avenue Irvine, CA, 92714

OA-4-2

DECUS

PERSONAL COMPUTER

SIG NEWSLETTER

PERSIJ-IAL COHPUTER SIG STEERING CCll111TTEE

ChaiTman

Barbara Maaskant UT Health Scianca Cantar 7703 Floyd Curl Drive San Antonio, TX 78284 (512) 691-7351

Sympo1i1 Coordinator

Rick Eliopoulis 5258 Vicki• Drive San Dia90, CA 92109 (619) 225-7867

DEQn1t1 Working Grouo Ch1irm1n

Charyl Johnson Grinnell College P. O. Box 805 Grinnell, IA 50112-0810 (515) 236-2570

Pro Working Group ChaiTman

Thomas R. Hintz U. of Florida IFAS Computer Natwork 1022 McCarty Hall Gainasvilla, FL 32611 (904) 392-5181

Rainbow Working GToyp Chairm1n

Lynn Jarrett Union TTibune P. O. Box 191 San DI ago, CA ( 619) 299-3131

Pub. Co.

92108 (x1130)

Nrwslattar Editor/Comm Comm Rfp. Carolina M. Mack 9007 Maars Straat Fairfax, VA 22031 (703) 280-4404

Session Not•s Editor

Alan Bruns Allied Electronics 401 E. 8th Street Fort Worth, TX 76102 (817) 336-5401

National LUG Or91nization Reo

Pi•rre Hahn Sll-IY HSC-Tl0-02808101 Stony Brook, NY 11794 (516) 444-1362

Library Comm. Rep/PC Librarian

Fraderick (Fritz) Howard Eastman Kodak Company 901 Elmgrove Raod D345-LP Rochaster, NY 14650 (716) 724-5331

Camoaround Coordinators

Ron S. Hafnar Hafner and Assoclatas P. 0. Box 2924 Livermora, CA 94550 (415) 449-4178

Jim Wilson National Technical lnstituta for th• Daaf Rochaster lnstituta of Tachnology Box 9887 Rochaster, NY 14623 (716) 475-6241

PC/RSX Liuon

Patar Flack Computar Sciancas Corp. P. O. Box 12233 Rasaarch Triangle Park, NC 2770g (919) 541-4669

PC/Graphjcs Llason

PC-i

Dr. Khln Maung Yin Kint St•t• UniYersity 1411 Clarlndon-Troy Road Burton, OH 44201 (216) 951-1447

RSX-1

Pre-Symposia Session Coordinator

Frederick G. Howard Eastman Kodak Company 901 Elmgrove Road D345-LP Rochester, NY 14650 (716) 724-5331

Members-at-Large

Jim Christine SPSS, Inc. 1815 S. Cuyler Berwyn, IL 60402 (312) 329-3580

Russ Wertenberg Sandia National Labs Div 8352 Livermore, CA 94550 (415) 422-2663

Michael Bowers University of California Animal Science Department Davis, CA 95616 (916) 752-6136

Digital Counterparts

DECmate

PRO

Rainbow

Ron Gemma Digital Equipment Corp.

Lynn Olsen Digital Equipment Corporation 146 Main Street ML21/2/U2 Maynard, MA 01754

Katrina Holman Digital Equipment Corp. LJ02/I3 30 Porter Road Littleton, MA 01460

PC-ii

~~

'~ '~ '~ '~ , __

'~ '~ '~ .....___________________________ ~

RSTS

'-'"''"" "''' """' """"""""""""·"··--··--· ... ,·-· .. ,_,, __ ,,,,.--... ·-"-""''""' ....... -·-·-·-"''""'-' ...... ., ... ,, ...... ~--... -···-"""""•""'"''""'""""'" "'"""""" "''"'"' "'''" '' ,. "'"' '"'"''"'"""

Chairman Charles Mustain Stark County School System Louisville, OH

Symposium Coordinator Scott W. Pandorf Kittie's Home Furnishings Indianapolis, IN

Assistant Symposium Coordinator Wet Fleischman Software Techniques Cypress, CA

Newsletter Editor

Open

Library Representative Susan Abercrombie Ventrex Laboratories Inc. Portland, ME

DEC Counterpart Joel Arker Digital Equipment Corporation Merrimack, NH ··

Pre-Symposium Seminar Coordinator Bruce Gaarder Macalester College St. Paul, MN

Wish Lists Coordinator Neal E. Goldsmith Software Techniques, Inc. Cypress, CA

RSTS

RST-i

Vice SIG Chairman Wish Lists & Tape Copy Coordinator

Philip Hunt System Industries Mi I pitas, CA

EDUSIG Liaison George Wyncott Purdue University Computing Center W. Lafayette, IN

RSTS Product Planning Coordinator Errol E. Ethier Shrewsbury, MA

Members-At-Large Ed Beadel Instructional Computer Center Oswego, NY

Scott Daily Great Lakes Chemical Corp. W. Lafayette, IN

Mark Gilmore Cal State University Long Beach, CA

Mark Hartman Jadtec Computer Group Orange, CA

Jeff Killeen Information Design & Management Hopedale, MA

Newton J. Munson Rochester Institute of Technology Rochester, NY

RSX

MULTI-TASKER

[Q] DEC US

Chairman Dan Eisner Perkin-Elmer Corp. Garden Grove, CA

Vice-Chairperson Elizabeth Bailey Tennessee Valley Authority Muscle Shoals, AL

Symposium Coordinator Rick Sharpe Toledo Edison Toledo, OH

Pre-Symposium Seminar Coordinator Hans Jung Associated Press New York, NY

Communications Committee Representative Allen Bennett Lear Siegler Rapistan Grand Rapids, MI

Newsletter Editor Dominic J. Di Nol lo Loral Electronics Yonkers, NY

Store Coordinator Bob Freeborn Savin Corporation Binghamton, NY

Session Note Editor Burt Janz Northern Telecom Inc. Concord, NH

Librarian Glenn Everhart Mt. Holly, NJ

Campground Coordinator Jerry Ethington Prolifix Inc. Frankfort, KY

DEC Counterparts Tim Martin Digital Equipment Corporation Maynard, MA

Dick Day Digital Equipment Corporation Nashua, NH

Bruce Webster Digital Equipment Corporation Nashua, NH

Working Group Coordinator Ed Cetron Center for Biomedical Design Salt Lake City, UT

RSX

RSX-i

Working Group Chair Evan Kudlajev Philadelphia Electric Co. Philadelphia, PA

RSX Group Chair Software Clinic Coard. Roy S. Maull U.S. Air Force Offutt AFB, NE

Software Clinic Coordinator Bruce Zielinski RCA Moorestown, NJ

Volunteer Coordinator Gary Maxwell U.S. Geological Survey Menlo Park, CA

Multi-Processors Working Group Coordinator Bruce Mitchell Machine Intelligence & Indus. Magic Hudson, WI

Networks Working Group Coordinator Mark Podany Case Western Reserve University Cleveland, OH

SRO Working Group Coordinator Bob Turkelson Goddard Space Flight Center Greenbelt, MD

Accounting & Performance Working Group Coard. 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

Jim Hopp Carleton Financial Comp. South Bend, IN

Table of Contents

From the Editor The RSX System Manager Modifying PRT's Print Buffer Correction to FORTRAN-77 OTS for I/D Tasks

Using Virtual Arrays User Written Drivers and RMS Block Locking SEE Utility How to Use the RSX Full-Duplex Terminal

Driver with Terminals

From the Editor

An Apology

1 3 7

8 11 12

14

I would like to take this time to apologize for missing the February 1986 issue. The issue was assembled and sent via Express Mail on December 27, 1985. Where it went is not known - not even by the Post Office. If I receive further information from the Post Office, I will pass it on.

How to Contribute to the Multitasker

The Multitasker publishes articles and notes on all topics dealing with or relating to RSX based systems. If you are doing something new or innovative with RSX we would like to hear from you.

Please send all correspondence for publication in machine form. A list of acceptable media and formats follow. formats are a problem for someone, please call. arrangements such as electronic transfer may be possible.

readable If these

Alternate

Magnetic Tape: 1600/6250 BPI

Floppy Disk: 8 Inch

5 Inch

TU58 Cart

RSX-1

BRU, PIP, FLX, VMS BACKUP

RX01/RX02 ODS-1 or ODS-2

RX50

RSX MULTITASKER

TK50 cart

Please send all Multitasker submissions and correspondence to:

Dominic DiNollo Loral Electronic Systems Engineering Computer Center Ridge Hill Yonkers, New York 10710 (914) 968-2500 ext 2210

RSX-2

RSX MULTITASKER

The RSX System Manager

Following a lQng respite on the checkpoint file, the System Manager column returns to the Multi-Tasker. This column appears semi-regularly, and presents short articles dealing with the day-to-day management of RSX systems. Suggestions and comments are welcome!

... And Still More on Undeleting Files

In the May, 1985 issue, I discussed methods for recovering that had been deleted unintentionally (1). One of the tools mentioned was written by P.G. Hansell, and had appeared in December, 1980 issue of the Multi-Tasker (2). Since I did not a copy of that issue, I could not describe Hansell's program.

files I had

the have

James M. Rengel generously sent James included a source listing DECUS Library.

of the University of Kansas Medical Center copy of Hansell's article. Additionally, a program, SOS, which is available (in only) under program number 11-507 in the

me a copy of format

Hansell's program, UNDELETE, scans a device for a particular filename and filetype, and dumps each matching deleted file header to a list file. After user verification, UNDELETE modifies the deleted file header to make a deleted file appear as though it were not deleted. The user may then copy the file by file ID to another device, and then delete the "undeleted" file for good.

SOS is very similar to Kirkman's UND program (3). A deleted file is copied to another device by interpreting the retrieval pointers in the deleted file header and using logical I/0 to read the blocks of the file. SOS will recover only one file at a time, which may be better at times than recovering an entire directory using UND.

In future columns, methods of recovering from other types of disk disasters will be explored.

*********************************************

RSX-llM-Plus: The System Disk and Volume Valid Processing

RSX-llM-Plus users who have inadvertently spun down their system disk while the system is running notice a funny thing: the system becomes unusable and must be rebooted, even after the system disk is spun back up and becomes ready. This will happen whenever the

RSX-3

RSX MULTITASKER · ..... , ...

system sags, can be should

disk momentarily becomes "not ready" due to vibration, power or momentary loss of servo. Other disk drives on the system dismounted and remounted to recover from this situation; why this be a fatal condition with the system disk?

1 BACKGROUND: VOLUME VALID ON M-PLUS

M-Plus uses a "volume valid" processing thread to facilitate disk volume integrity. Volume valid processing is performed by all M-Plus disk drivers when a function is dequeued from the I/O queue. The routine $VOLVO, which is located in Executive module MDSUB, is called by a disk driver after dequeueing an I/0 packet. When invoked, $VOLVO checks the software volume valid bit (US.VV) in the Unit Control Block. If the bit is off, then volume integrity cannot be assured, and an I/0 error code of Device Not Ready (IE.DNR) is forced. Typically, software volume valid is set when a volume is mounted and is cleared when the volume is dismounted.

In addition to software volume valid, most disk drives employ a "hardware volume valid," which is set when the drive is commanded to clear error conditions and the drive control logic determines it is operating properly. The hardware volume valid is cleared when one of many error conditions, or faults, occurs within the drive. One of these conditions occurs when a manual or automatic spin down request is honored. The disk drive will subsequently refuse all commands, even if the drive has become ready again, until the controller manually clears the error condition.

2 THE PROBLEM, AND ONE SOLUTION

So, why does the system go down when the system disk goes down? First, the hardware volume valid is cleared when the drive control logic realizes there is a problem. Subsequent I/0 requests are rejected by the drive, resulting in IE.DNR completion errors. Since the only RSX-llM-Plus software that issues a request to reset the hardware volume valid is MOU (and VER, which we will examine later), and MOU cannot be loaded from the system disk, the only recourse is to reboot the system.

A simple workaround is to have copies of MOU and DMO installed from another disk. Then the system disk could be dismounted and remounted in the event of a failure. The workaround becomes less simple, however, if other system activities, such as console logging, queue management, and checkpointing, are active on the system disk. The support tasks for these subsystems would also require copies to be installed on another disk. Additionally, a privileged user would be required to perform the recovery.

Applying the Remount Verification Task (VER .•. ) to this situation

RSX-4

RSX MULTITASKER

did not seem feasible. VER ••• is designed to operate exclusively with the RC25 subsystem and the MSCP driver (DUDRV). VER... is invoked directly by DUDRV when remount verification is necessary. Modifying all other disk drivers to invoke VER... when necessary would be a clumsy solution.

An automated workaround to this problem is simple, in principle. Setting software and hardware volume valid can be accomplished by using a QIO directive with an IO.STC (Set Characteristics) function with the second parameter word set to the logical value VV$SET. When the driver calls $VOLVO with an IO.STC and VV$SET combination and a series of tests are passed, $VOLVO will set the software volume valid bit and return to the driver. Next, the driver issues the appropriate command to the disk drive to reset the hardware volume valid. The drive is now receptive to subsequent I/O requests.

We have implemented this automated workaround in a "volume valid daemon" that monitors the state of the system disk and resets the volume valid bit when the drive momentarilly goes down. The program, VVC (Volume Valid Control), is activated when the system is started. At five second intervals, VVC issues an IO.STC QIO request with the VV$SET parameter to the system disk. The QIO causes the drive to be interrogated, with a successful status returned if the drive is operational. If the drive happens to be down, VVC enters a recovery mode of operation. Recovery of volume valid is actually a tricky process, due to the checks that the $VOLVO routine performs and the desire to keep other system tasks and users from accessing the drive until it is made operational.

In order to keep system tasks (such as COT ..• , ERRLOG, QMG ... , etc.) from accessing the system disk after loss of volume valid, vvc employs the same "trick" used by the Remount verification Task (VER ••• ) when remounting RC25 multi-drive, single spindle units. The trick is to set the "Stall I/O" bit, US.SIO, in the UCB of the system device. When this happens, the $GTPKT routine will not dequeue any I/O requests for the system disk UNLESS the requesting task is VER ••• (The system compares the TCB in the I/O packet with the contents of $VERTK, a reserved word in the Executive.) VVC temporarily replaces the contents of $VERTK with its own TCB address. At this point, all I/0 to the system disk is "stalled" with the exception of I/0 requests from VVC.

VVC now issues IO.STC QIO requests with the VV$SET parameter every second until a successful status from the system disk is returned. Once the disk has recovered, VVC verifies that the volume has not changed (i.e., the disk pack is still the same). This is accomplished by reading the Home Block on the system disk, verifying the checksums in the Home Block, and comparing the volume label stored in the Volume Control Block with the volume label in the Home Block. If these tests pass, vvc clears the stall I/O bit, calls the driver to resume processing I/O requests, restores the contents of $VERTK, requests VER... (in case any verification work

RSX-5

RSX MULTITASKER

is required for another disk), and prints a message on the console indicating that volume valid has been reset.

3 SUMMARY

This program has been tested and operated continuously on a PDP-11/70 running RSX-llM-Plus V2.1E for four months. The system disk on this system is a DEC RM03. The program has also been tested on an LSI-11/73 with a third party MSCP-compatible controller and Winchester disk. VVC occupies 768 words of memory (including external header), and (of course) is not checkpointable. The program is availble on the Fall 1985 RSX SIG tape in UIC (307,20).

4 ACKNOWLEDGEMENTS

I would like to thank Larry Baker for his advice during the development of the Volume Valid Control program, and to thank Larry and Tim MacDonald for reviewing this paper. I would also like to thank those users who, while mounting their magtapes, have bumped into the RM03 "START" button, bringing the disk and the system down. This software was developed at the National Strong Motion Data Center, located at u.s.G.S. in Menlo Park, California.

References:

[ l) Maxwell, Gary, "The System Manager: Recovering From Disk Disasters, Part I," Multi-Tasker, May, 1985, pp. 4-10.

[2) Hansell, P. G., "UNDELETE Program for RSX Multi-Tasker, Vol. 14, No. 1, December 1980.

Disks,"

[ 3) Kirkman, Richard, "UND, a Program to Multi-Tasker, Vol. 15, No. 1, July Program source availabilty: Spring 1983 [370,210).

Undelete Files," 1981, pp. 12-18.

RSX SIG tape, UIC

*********************************************

Please send questions, comments, ideas and submissions for this column to the following address:

Gary Maxwell U.S.G.S. M/S 977 345 Middlefield Road Menlo Park, CA 94025

RSX-6 c····

RSX MULTITASKER

Modifying PRT's Print Buffer

Paul Matteoni Northern Micrographics 3110 International Lane

Madison, WI 53704

PRT wiil truncate lines too large to fit in tis buffer. This can happen when PRT tries to print RUNOFF output of underlined text.

This patch describes how to enlarge the print buffer for the single queue print spooler (PRT).

1. Set your UIC to [l,24]· and create the file IOPRT.PAT:

.TITLE

. IDENT

.MCALL

GETLUN••4

.PSECT

$INPPT::

BUFl::

BUF2::

FDBDF$ FDRC$A FDOP$A

.PSECT

.BLKB

.BYTE

. BLKB

.BLKB

.BYTE

. BLKB

.END

2. Assemble the Patch:

MAC IOPRT.POB•IOPRT.PAT

IOPRT /07.0lA/

FDBDF$, FDOP$A, FDRC$A

INPPT,D,GBL

,,256. GE TL UN

INPBUF,D,GBL

5 11

256 . 5 11

25b .

RSX-7

RSX MULTITASKER

3. Extract the original module from the PRT library:

LBR IOPRT•PRT/EX:IOPRT

4. Patch the module

PAT IOPRT;2•IOPRT;l/CS:061561,IOPRT.POB/CS:014463

5. Replace the module in the library

LBR PRT/RP•IOPRT

6. Rebuild PRT with the latest version of your RSX system

TKB @PRTBLD

Correction to Fortran-77 OTS for I/D Tasks Using Virtual Arrays

Gary L. Maxwell Lawrence M. Baker

U.S. Geological Survey Menlo Park, California

c -

In the course of our separate investigations on using PLAS directives and in developing Supervisor mode libraries, we have discovered a bug in the Fortran-77 V5.0-12 OTS. Symptoms of the bug include a "Virtual array initialization failure" message from Fortran or a segment fault caused when Virtual arrays are first accessed by an I/D space task. This problem can occur when the Instruction Space of the task i$ between 28K and 32K words in length, or when a resident library (such as FCSRES) is linked into the I/D task using APR 7.

The following program will exhibit the problem:

File TSTBUG.FTN:

c

c

Program TSTBUG

Virtual Ivfill(8192)

Do 1000 I • 1, 8192 Ivfill(I) •I

1000 Continue Do 2000 I = 1, 8192

If (Ivfill(I) .ne. I) Stop 'Verify error'

RSX-8

RSX MULTITASKER

2000 Continue Stop End

File FILLIS.MAC:

.title fillis

Build a 28 KW instruction space array

.psect fcode,i,ro

.blkw 28.•1024. Load it up, folks

.end

compile, assemble, and build as follows:

>F77 TSTBUG•TSTBUG/TR;ALL >MAC FILLIS•FILLIS >TKB TSTBUG/IDsTSTBUG,FILLIS

The above program will fail with a Virtual array initialization error.

The problem is due to an error in the Fortran OTS routine $VINIT. When the Virtual array PLAS window is created, Fortran uses information provided by the Task Builder to determine which APR to use to map the Virtual array window. For I/D space tasks, the Task Builder correctly determines which D-Space APR should be used by Fortran for Virtual arrays. However, Fortran does not make any distinction between I/D and non-I/D tasks. Fortran will always attempt to map the Virtual array in I-Space.

For I/D tasks that are not using APR 7 for instructions or data, Virtual arrays still work correctly. This is because the Executive will automatically map the D-Space APR along with the I-Space APR if the D-Space APR is not currently in use. However, if the task uses APR 7 for instructions, or is mapped to a resident library through APR 7, Fortran will try to remap APR 7 I-Space, causing an eventual failure.

The correction to $VINIT which follows will work regardless of whether a task is or is not built as an I/D space task. This is possible by the use of an undocumented bit mask in the status word of the Window Definition Block, WS.EDS (Effective Data Space). This mask is the sum of WS.UDS (User Data Space) and WS.SIS (Supervisor Instruction Space). When used, the M-Plus Executive will map the window based on whether the task uses Data Space: if it does, the window is mapped in D-Space; otherwise, the window is mapped in I-Space.

RSX-9

RSX MULTITASKER

When the OTS is corrected, the program example above will work correctly.

Correction file VINIT.PAT:

.Title

.Enabl

.Ident

$VI NIT Le /F7705Z/

VINIT.PAT -- Correction for F77 OTS module $VINIT (Original Ident: F77005)

Corrections:

GMLBOl Use W&.EDS bit mask to set up mapping in I-space for non I/D tasks and D-Space for I/D tasks.

Original file checksum: 25372 Correction file checksum: 5712

.Mcall Wdbdf$

Wdbdf$ ; Window Definition Block Offsets

.Psect $$0TSI,CON,RO,REL,LCL,I

$$$ -• - $$$ + 62

Mov #<WS.64BIWS.MAP!WS.EDS!WS.WRT>,(r0)+ ; Store window status

.End

To correct the OTS, follow the instructions in the Fortran-77 Installation Guide, or use the following command sequence:

>LBR VINIT.OBJ;l•SYSLIB/EX:$VINIT >MAC VINIT.POB•VINIT.PAT >PAT VINIT.OBJ;2•VINIT.OBJ;l/CS:025372,VINIT.POB/CS:005712 >LBR SYSLIB/RP•VINIT.OBJ;2 Module "$VINIT" replaced

>

' . :: : .. - A c 1 -

RSX-10

RSX MULTITASKER

User Written Drivers and RMS Block Locking?? II

Carl T. Mickelson Goodyear Aerospace Corporation

Akron, Ohio 44315

For those of you who write your own RSXll-M device drivers, here is a review of another "gotcha" of RSX. In the module IOSUB after the label $IOFIN, there exists the following sequence of instructions:

20$:

.IF DF MOV BEQ CMP BHIS DEC

.ENDC

R$$LKL I .PRM+l6(R3) ,RO 20$ R0,!1140000 20$ (RO)

If RMS block locking in the exec Get last parameter from IO packet If its zero, continue below If a KAPR 6 buffer address continue below else, decrement memory at (RO)

This code will decrement memory I.PRM+l6 of a finished IO circumstances:

at the request

address contained in under the following

Your system supports RMS-11 block locking, and I.PRM+l6 is non-zero and not a kernel APR 6 data buffer virtual address.

Should a user written driver use all eight available words in the parameter portion of an IO packet for its own purposes (QIO functions marked as control functions, or functions requiring multiple data buffers, etc), the I.PRM+l6 word of the IO packet should be cleared before calling $IODON, $IOALT, or $IOFIN. Otherwise some random location in executive address space will be decremented any time such a QIO is completed. Presuming that RS points at the device UCB,the following code will clear the required word before returning to the executive:

.IF DF MOV MOV MOV CLR MOV .ENDC CALL

R$$LKL R5,-(SP) U.SCB(R5),RS S.PKT(RS) ,RS I.PRM+l6(R5) (SP)+,RS

$IODON

If RMS block locking in the exec Save UCB address Get SCB address Get IO packet address Clear last parameter Restore UCB address

RSX-11

RSX MULTITASKER

C A_. - ) We experienced this "gotcha" when a user program odd-auu•9•• trapped. It just so happened that our device driver left the value 4 in I.PRM+l6 for some QIO functions. This caused address 4, the odd-address trap vector, to be corrupted and when the user program trapped, the exec couldn't recover. worse yet, when location 4 was odd (50% of the time), the CPU, an ll/34a, would keep trapping, until a fatal stack error occurred. This wiped out all the interrupt vectors, making it impossible to take a crash dump. The symptoms looked at the time like a hardware device was holding a UNIBUS signal (SSYN) off, continuously causing the CPU to trap!

What was actually happening follows. The processor kept trapping to 4 because location 4 was odd, filling the stack until location 177776 was to be written. At this point, the 11/34a trap micro-code hung on non-existent memory, making it impossible to halt the processor without forcing maintenance mode on the programmers console and executing a micro-step halt.

SEE Utility

Michael E. Mazzoni Process Control Systems, Inc.

1300 S. Calhoun Road Brookfield, WI 53005

SEE as a small debugging aid has been written to permit real-time display (a la RMDEMO) of the octal contents of any location in core of the machine it is running in, I/O page, executive, or any task or partition. At 1/10 second intervals, it opens the block of core specified and, if any changes have occurred since the previous snapshot, it updates the display on the VT-52 terminal. It runs under any RSXllM mapped system.

Up to 256 bytes of core can be displayed. This can be located in as many as 8 separate areas, with actual displayable sizes limited by the screen capacity. The display in each area can be in word, byte or character mode.

The user can move the windows around with simple octal commands at any time while running. It is oriented toward displaying a module (with its assembler relative addresses) at a location within a task partition, although absolute display of the effective addresses can also be done.

RSX-12

RSX MULTITASKER

The program keeps a copy of the content of each location to be displayed in an internal buffer. Each tenth second, in a fast loop, it copies the displayed words to another buffer as a snapshot. Then, after restoring its mapping to normal, it compares the two buffers. Only those words which have changed since the last snapshot will be displayed. If a slow (1200 baud) terminal is used to display a large rapidly changing display, the one tenth second sampling rate will not be achieved due to the time required to update the terminal display. Thus the tenth second update rate is a maximum, only achieved with fast terminals or slowly changing data.

On very active displays, CTRL s and CTRL Q can be used in way to freeze the data, if needed. On inactive displays changing in the core being watched) the CRT cursor immediately after the last word changed.

the usual (not much will be

SEE is found on the Fall, 1981 RSX SIG tape in UIC (343,70].

There is one easily fixed bug in SEE: it doesn't work on RSX-llM+ systems with I/D space mapping. However, a one line change to the MACRO code will make it work. Details:

1.

2.

3.

About 80 lines from the start of SEE.MAC, the symbol UDSARO is defined (the original definition works for any RSX-llM system or M+ w/o I/D space). Locate this symbol.

Change the value of UDSARO from 177640 to 177660 for an RSX-llM+ system with I/D space. 177640 is the user mode INSTRUCTION space page address register number 0 of the KTll memory management unit. For an M+ system with I/D space the SEE program needs the data mapped by 177660, the user mode DATA space page address register number 0.

Re-assemble and re-taskbuild.

This modified SEE has been in use at PCS for several years, and has been tested on RSX-llM+ vl.O, v2.0, v2.1, and v3.0.

This very useful RSX utility was written by:

Jack Harvey, Vice President National Data Systems 299 Market Street Saddlebrook, NJ 07662

RSX-13

HOW TO USE THE RSX

FULL-DUPLEX TERMINAL DRIVER

WITH TERMINALS

Dale R. Donchin

Digital Equipment Corporation

RSX-14 (

GENERAL TERMINAL QIO FORMAT

MACR0-11

QIO$ FUNCTION,LUN ,FLAG,,STATUS,AST, <PARAMETERS>

WHERE FUNCTION IS ONE OF: IO.A TT 10.RLB 10.RVB SF.GMC 10.RPR 10.EIO

10.DET IO.WLB 10.WVB SF.SMC 10.RTT 10.HNG

STATUS IS THE ADDRESS OF A TWO-WORD STATUS BLOCK

PARAMETERS IS A LIST OF UP TO SIX PARAMETERS DEPENDENT ON THE FUNCTION

FORTRAN

CALL QIO (FUNCTION,LUN,FLAG,,STATUS,PARAMETERS)

WHERE FUNCTION IS AN INTEGER*2 VARIABLE EQUAL TO THE APPROPRIATE FUNCTION CODE

STATUS IS A TWO ELEMENT INTEGER*2 ARRAY

PARAMETERS IS A SIX ELEMENT INTEGER*2 ARRA

RSX-15

~ ·- •. '· -·-·· ....

EXAMPLES I

MACR0-11

QIOW$ 10.ATT, 5, I,, IOSB

QIOW$ IO.DET, 5, 1,, IOSB

QIOW$ IO.RVB, 5, 1,, IOSB,, <IBUF, ILEN>

QIOW$ IO.WVB, 5, 1,, IOSB,, <OBUF, OLEN, OVFC>

FORTRAN

PARAMETER IOATT = "1400 PARAMETER IODET = "2000 PARAMETER IORVB = "10400 PARAMETER IOWVB = "11000

CHARACTER*80 IBUF, OBUF DIMENSION IOSB(2), IPARAM(6) BYTE IOSBP(4) EQUIVALENCE (IOSB(l), IOSBP(l))

CALL WTQIO (IOATT, 5, I,, IOSB,, IDSW) CALL WTQIO (IODET, 5, I,, IOSB,, IDSW)

CALL GETADR (IPARAM(l), IBUF) IPARAM(2)=80 CALL WTQIO (IORVB, 5, I,, IOSB, IPARAM, IDSW)

CALL GETADR (IPARAM(l), OBUF) IPARAM(2)=80 IPARAM(3)= ''40 CALL WTQIO (IOWVB, 5, 1,, IOSB, IPARAM, IDSW)

RSX-16

EXAMPLES II

MACR0-11

QIO$C IO.RPR, 5, 1,, IOSB,, <IBUF, ILE~,, OBUF, OLEN, OVFC>

QIO$C IO.RTT, 5, 1,, IOSB,, <IBUF, ILEN,, TTABLE>

FORTRAN

PARAMETER IORPR = "4400 PARAMETER IORTT = "5001

INTEGER*2 TTABLE(16) DAT A TT ABLE/ 16*0/ CHARACTER*SO IBUF, OBUF Dll\IENSION IOSB(2), IPARAM(6) BYTE IOSBP(4) EQUIVALENCE (IOSB(l), IOSBP(l))

CALL GETADR (IPARAM(l), IBUF) IPARAM(2) = 80 CALL GET ADR (IPARAM(4), OBUF) IPARAM(5)=80 IPARAM(6)= "40 CALL QIO (IORPR, 5, 1,, IOSB, IPARAM, IDSW)

TTABLE(l) = "20210

CALL GETADR (IPARAM(4), TTABLE(l)) CALL QIO (IORTT, 5, l,, IOSB, IPARAM, IDSW)

RSX-17

EXAMPLES III

MACR0-11

BUFFER:.BYTE TC.TTP, .BYTE TC.SLV,

LENGTH = . - BUFFER

0 0

QIO$C SF.GMC, 5, l,, IOSB,, <BUFFER, LENGTH>

QIO$C SF.SMC, 5, 1,, IOSB,, <BUFFER, LENGTH>

FORTRAN

PARAMETER SFGMC = "2560 PARAMETER SFSMC = "2440 PARAMETER TCTTP = "10 PARAMETER TCSLY = "50

BYTE BUFFER(4) DIMENSION IOSB(2), IPARAM(6) BYTE IOSBP(4) EQUIVALENCE (IOSB(l), IOSBP(l))

BUFFER(l) = TCTTP BUFFER(3) = TCSLY

CALL GETADR (IPARAM(l), BUFFER(l)) IPARAM(2)=4 CALL QIO (SFG'.\'IC, 5, l,, IOSB, IPARAM, IDSW)

CALL QIO (SFSMC, 5, 1,, IOSB, IPARAM, IDSW)

RSX-18

TF.RAL TF.RNE TF.RST TF.TMO TF.XOF

TF.CCO TF.RCU TF.WAL TF.WBT

TF.AST TF.NOT TF.XCC TF.ESQ

TF.BIN

SUBFUNCTIONS

READ

READ PASS-ALL READ WITH NO ECHO READ WITH SPECIAL TERMINATOR READ WITH TIME-OUT READ FOLLOWED BY XOFF

WRITE

WRITE AND CANCEL 'O WRITE AND RESTORE CURSOR WRITE PASS-ALL WRITE BREAK-THROUGH

ATTACH

ATTACH FOR UNSOLICITED INPUT ATTACH FOR INPUT NOTIFICATION ATTACH FOR INPUT EXCEPT 'C ATTACH FOR ESCAPE SEQUENCES

READ AFTER PROMPT

READ WITH PASS-ALL PROMPT

NOTE: SUBFCIVCTIONS CAN 01\'LY BE USED WITH LOGICAL 110 FL'NCTIONS

RSX-19

EXTENDED 1/0

MACR0-11

MODIFR = TF.RPR ! TF.RDI ! TF.RTT ! TF.TMO

ILIST: . WORD .WORD .WORD .WORD .WORD

ISIZ = . - ILIST

MODIFR, IBUF, OBl'F, TT ABLE, DEFBUF,

DEFBUF: .ASCII /Default input/

0 ILEN, TIMOUT OLEN, OYFC TTABLN DEFLEN

QIO$C IO.EIO!TF.RLB, S, 1,, IOSB,, <ILIST, ISIZ>

FORTRAN

PARAMETER IOEIO = "17400 PARAMETER TFRLB = "2 PARAMETER TFRNE = "20

CHARACTER*80 IBUF DI~IENSION IOSB(2), IPARAM(6), ILIST(24)

CALL GETADR (IPARAM(l), ILIST(l)) IPARAM(2) = 24

ILIST(l) = TFRNE ILIST(2) = 0 CALL GETADR (ILIST(3), IBUF) ILIST(4) = 80 CALL QIO (IOEIO+TFRLB, S, l,, IOSB, IPA.RAM, IDSW)

RSX-20

TYPEAHEAD

CIRCULAR BUFFER

ONE PER TERMINAL, SETTABLE PER TERMINAL

MUST BE ENABLED WITH ATTACH OR SERIAL MODE

INPUT SAVED UNTIL: READ POSTED AST GIVEN FLUSH QIO ERROR ENCOUNTERED Ac ENTERED 'X ENTERED

FIXED SIZE FOR NON-1/D-SPACE SYSTEMS (ALLOCATED FROM DRIVER OR PRIMARY POOL)

VARIABLE SIZE FOR l/D-SPACE SYSTEMS (ALLOCATED FROM SECONDARY POOL)

BELL SOUNDED WHEN OVERFLOW OCCURS

NEW SETTABLE HOST AND TERMINAL SYNCHRONIZATION

CAN POLL TO SEE IF NON-EMPTY OR QUEUE AN AST OR READ CONTENTS

RSX-21

MODEM SUPPORT I

LOCAL

TC.DLU = 0 OR SET NOREMOTE COMMAND

DTR AND RTS DISABLED (DATA ONLY)

DIAL-IN AND DIAL-OUT CALLERS NOT RECOGNIZED

ALL QIO FUNCTIONS ALLOWED

REMOTE

TC.DLU = 1 OR SET REMOTE COMMAND

DTR AND RTS ENABLED

DIAL-IN CALLS ACCEPTED

ATTACT /DETACH/CHARACTERISTIC QIOS ALLOWED

READ/WRITE ALLOWED WHEN A CONNECTION IS MADE

DON'T CALL US, WE'LL CALL YOU

TC.DLU = 2 (NO COMMAND LEVEL INTERFACE)

DTR AND RTS ENABLED

DIAL-IN AND DIAL-OUT CALLS ACCEPTED

ALL QIO FUNCTIONS ALLOWED

RSX-22

MODEM SUPPORT II

WHEN A CALL IS ANSWERED:

TERMINAL TYPE SET TO UNKNOWN

BUFFER WIDTH SET TO 72 CHARACTERS

MCR SET AS THE CLI

LOWERCASE TO UPPERCASE CONVERSION FORCED

MANY CHARACTERISTICS RESET

REMOTE SPEED SET OR AUTO-BAUD PROCESS BEGUN

WHEN A CALL IS TERMINATED:

TYPEAHEAD BUFFER FLUSHED

ALL ACTIVE 1/0 IS ABORTED

USER IS LOGGED OUT

DTR/RTS MODEM SIGNALS ARE CYCLED OFF AND ON

RSX-23

ESCAPE SEQUENCES

USE

ALLOWS COMMUNICATION OF CONTROL INFORMATION AS PART OF THE DATA STREAM

GENERATED BY: FUNCTION KEYS CURSOR CONTROL KEYS NUMERIC KEYPAD IN ALTERNATE MODE TERMINAL INQUIRIES APPLICATION TO CONTROL TERMINAL

FORMAT

ESCAPE CHARACTER FOLLOWED BY OPTIONAL INTERMEDIATE PARAMETERS AND TERMINATED BY A REQUIRED FINAL CHARACTER

ACTIVATION

SET TC.ESQ TERMINAL CHARACTERISTIC

ATTACH TERMINAL WITH TF.ESQ SUBFUNCTION

OR

(NEW WITH V3.0) READ WITH TF.RES SUBFUNCTION

RSX-24

ADVANCED FUNCTIONS

FULL-DUPLEX MODE

SIMULTANEOUS READS AND WRITES

REAL-TIME CONTROL

SPLIT-SCREEN APPLICATIONS

CURSOR POSITIONING

DEVICE INDEPENDENCE

POSITION CURSOR BEFORE OUTPUT

CLEAR SCREEN BEFORE OUTPUT

RESTORE CURSOR AFTER OUTPUT

V3.0 NEW READ SUBFUNCTIONS

READ PASS-THRU

READ DEFAULT INPUT

READ TYPEAHEAD BUFFER

V3.0 NEW ASTS

MODEM HANGUP NOTIFICATION

TERMINAL MANAGEMENT MODE

DEFINABLE OUT-OF-BAND CHARACTER AST

RSX-25

BUFFERED 1/0

ALLOWS TASKS WITH OUTSTANDING 1/0 TO REMAIN CHECKPOINTABLE

ONLY AFFECTS ACTIVE REQUESTS

BUFFERS ARE ALLOCATED FROM TERMINAL DRIVER PRIVATE POOL OR PRIMARY POOL

BUFFERS ARE FIXED IN SIZE AND ARE ALLOCATED AS NECESSARY

READS MAY BE BUFFERED OR UNBUFFERED

WRITES ARE ALWAYS BUFFERED

DMA IS DONE A BUFFER AT A TIME

RSX-26

THE I I "' " e DECUS la1kc1i1111111111111111111111111111111111 RT-11 SIG NEWSLETTER 11111111111i1111111111111111111111

~ DDEOJS

ua DtN'TEA

RT-11 Mini-Tasker

"SECNDS" Subroutine by John Crowell ........................................... 1

Announcing BASIC-PLUS/RT-11 ................................................. 4

"DISCRETE" for the DECUS Library ............................................. 5

Auto Sysgen on a Floppy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

DECUS U. K Response to VAX/RT Position Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

RT SIG Steering Committee

SIG Chairman John T. Rasted JTR Associates Meriden, CT

Symposium Coordinator Ned Rhodes Software Systems Group Rockville, MD

Communications Committee Representative FMS Contact

Susan Rasted_ Software Dynamics, Inc. Wallingford, CT

Newsletter Editor COBOL Contact

Bill Leroy The Software House Inc. Atlanta, GA

Pre-Symposium Seminar Coordinator Suite Manager

Bruce Sidlinger Sid linger Computer Corp. San Antonio, TX

Standards Coordinator Kenneth L. Aydlott Teledyne Hastings-Raydist Hampton, VA

Digital Counterpart Diana L Miller Digital Equipment Corporation Maynard, MA

Tape Copy Generation Contact Ralston Barnard Sandia Laboratories Albuquerque, NM

APL Contact Doug Bohrer Bohrer & Company Wilmette, IL

MACRO Contact Nick Bourgeois NAB Software Services, Inc. Albuquerque, NM

RT-i

Teco Contact Product Planning Contact

John Crowell Crowell Ltd. Los Alamos, NM

DECNET Contact Ken Demers Adaptive Automation New Haven, CT

UNIX Contact Wish List Contact

Bradford Lubell LA. Heart Lab Los Angeles, CA

RT-11 Hardware Contact C Contact

Carl Lowenstein University of Calif., San Diego San Diego, CA

TSX Contact Jack Peterson Horizon Data Systems Richmond, VA

Library Contact Tape Copy Distribution

Tom shinal General Scientific Corp. Rockville, MD

BASIC Contact Ed Stevens EMDA Inc. Pasadena, CA

CAMAC Contact J.W. Tippee Kinetic Systems Inc. Lockport, IL

Personal Computer Contact LUG Contact

William K. Walker Monsanto Research Corp. Miamisburg, OH

FORTRAN Contact RUNOFF Contact

Robert Walraven Multiware, Inc. Davis, CA

CROW4ELL, L-d. • 14 5 Andanada Los Alamos, N.M. 87544 505/662-3893

SECNDS Subroutine

John M. Crowell Crow4ell,Ltd.*

145 Andanada Los Alamos, NM 87544

(505) 662-3893

The SYSLIB function subroutine SECNDS returns only an integer number of elapsed seconds. The following subroutine is offered as a replacement. It returns fractional values of seconds, truncated to the last clock tick. An optional section of code is included to accomodate both 50 Hz and 60 Hz line clocks. The code is position-independent, so it can safely be used in system and foreground jobs.

The assembly conditional FPU$$ must be non-zero if this routine is to replace the SECNDS routine for FORTRAN-77. It may be set non-zero if the FORTRAN-IV usage is strictly for processors with the floating-point instruction set (FPU). Otherwise, if FPU$$ is zero or undefined, the assembly will assume that SYSLIB function AJFLT and FORTRAN-IV OTS routines DIF$SS and SUF$SS are available.

If you have any problems with this routine, please send their description to me in writing. I tend to get rude and sarcastic on the phone!

* but not very

•but not very. RT-1

.ENABL MCL

.MODULE SECNDS,RELEASE=JMC,VERSION=Ol,COMMENT=<Returns Time-of-day>,LIB=YES

Tl = SECNDS( TO

Returns (time of day - TO) in seconds (Floating Point)

Unlike SECNDS routine distributed in RT-11 SYSLIB, this routine returns fractional values. Resolution is one clock tick.

If this routine is to be used with FORTRAN-77, the conditional FPU$$ MUST be non-zero. (i.e. delete the semicolon in the following line.)

;FPU$$=1

If this routine is to be used exclusively in FORTRAN-IV systems with floating-point instruction set (FPU - not FIS), the semicolon may be removed .

. IIF NDF FPU$$, FPU$$ = 0

.PSECT SYS$I

.IF NE FPU$$ F0=%0 .IFTF

SECNDS:: .IFT

STFPS SETF SETL

.IFF HOV

.IFTF CMP HOV HOV HOV HOV EMT CMP

.IFT LDCLF

.IFF HOV HOV HOV HOV HOV HOV HOV HOV JSR ADD HOV HOV HOV CLR

.IFTF

-(SP)

R5,-(SP)

-(SP),-(SP) SP,RO RO,-(SP) #21*400,-(SP) SP,RO 375 (SP)+, (SP)+

(SP)+,FO

(SP)+,RO (SP)+,Rl RO,-(SP) Rl,-(SP) SP,RO RO,-(SP) #l,-(SP) SP,RS PC,AJFLT #8. ,SP (SP)+,RS Rl,-(SP) RO,-(SP) -(SP)

Save Floating Point Status

Time-of-day is long ingeter

Here's where it goes HOV SP,-(SP) is processor dependent Set up .CTIM argument block

.GTIM Ignore argument block

Convert ticks to floating point

Convert ticks to floating point

RT-2

;***********AAAkAAkkAAA*******************************************************

If you want to get fancy, you can allow for both 50Hz and 60Hz line clocks by including this code. You'll probably want to omit it.

CONFIG ~ 300 CLK50$ - 40

MOV #CONFIG,-(SP) MOV #34*400,-(SP) MOV SP,RO EMT 375 ; Get configuration word CMP (SP)+,(SP)+ BIT #CLK50$,RO : 50 Hz clock? BEQ 1$

; .IFT ; DIVF #50. ,FO ; Divide by 50 to get seconds ; .IFF ; MOV #AF50. ,R4 ; 50 ticks/sec ; .IFTF

BR 2$ ;1$:

; *************AA A AA A A A A AAA****************************************************

.IFT DIVF #60. ,FO Divide by 60 to get seconds

.IFF MOV #AF60. ,R4 60 ticks/sec

.IFTF 2$: .IFT

SUBF @2(R5),FO Subtract TO STF FO,-(SP) Put result on stack

.IFF JSR R4,@(PC)+ Divide to get seconds .WORD DIF$SS .WORD .+2

MOV 2(RS),R4 MOV 2(R4),-(SP) MOV (R4),R4 JSR R4,@(PC)+ Subtract TO .WORD SUF$SS .WORD .+2

.IFTF MOV (SP)+,RO Return as floating-point function MOV (SP)+,Rl

. IFT LDFPS (SP)+

.ENDC RTS PC

.END

RT-3

Announcing BASIC-PLUS/RT-11

Digital is announcing a new release of BASIC on RT-11 called BASIC-PLUS/RT-11 V3.0. A follow-on product to BASIC-11/RT-ll V2.l, BASIC-PLUS/RT-11 V3.0 is an interactive, incremental compiler operating under the RT-ll Operating System. It is based upon BASIC-PLUS, the popular and widely-used BASIC language supported with Digital's RSTS/E Operating System. The significantly enhanced features and functionality of Version 3.0 make it an attractive choice for technical, commercial and educational applications. In addition, a level of compatibility has been attained between the BASIC products on RT-11, RSTS/E and VAX/VMS which enables users to migrate BASIC applications back and forth among all these system environments.

Some of the product features available with BASIC-PLUS/RT-11 V3.0 include:

- Incremental compilation - Multi-statement lines, multi-line statements - 31 Character variable and function names - Statement modifiers - Support for manipulation and testing of logical values, and for

manipulation of integers at the bit level - Block I/O, including direct access to individual blocks of a disk

file - IF ••• THEN ••• ELSE and other extended, flow-control constructs - Programmable error handling - Mechanisms for control of arithmetic precision: scaled arithmetic

and string arithmetic - Matrix manipulation operations - New, re-organized documentation - Line-by-line comments - Extended debugging aids: BRAKE and TRACE commands - Logical expressions - Multi-line function definitions - Alias, to improve upward and backward compatibility - 6 New commands - 13 New statements - 7 New operators - 37 New built-in functions

BASIC-PLUS/RT-ll Version 3.0 and BASIC-PLUS/RT-11 on the Professional Version 3.0 will be available in February, 1986. Contact your local sales or service representative for pricing and ordering information •

Ord er Number

QJ913-UZ QY913-UZ

QB9l3-A3

BASIC-PLUS/RT-11 BASIC-PLUS/RT-11

BAS IC-PLUS/RT-11 on the Professional

RT-4

Single-Use License Category H Single-Use License Category L

License, Documentation and Media

CA SE WESTERN RESERVE UN IV ER S IT Y • CLEVE LAN D, 0 H I 0 4 4 1 O 6

Bi 11 Leroy The Software House, Inc. 470 E. Paces Ferry Road Park NE 1020 P .0. Box 52661 Atlanta, Georgia 30355

Dear Bi 11:

January 24, 19B6

I recently submitted a curve-fitting program DISCRETE for the DECUS library. This program by Steve Provencher extracts the parameters for any exponential decay process and is by far the best available. Marilyn Gervais at DECUS tells me it should be out in a month.

I thought this brief description would alert potential users to its availabilitv under RT-11. The sources are in FORTRAN IV and can be adapted to RSX etc. It is available directly from Dr. Provencher for the VAX, I believe.

TH/jsr

Enclosure

School of Medicine

Department of Physiology

2119 Abington Road Telephone: 368-3400

Yours trul.v,

-6~ Tomuo Hoshiko, Ph.P. Professor

P.T-5

DISCRETE, S.H.Provencher'a proqraa to fit a aua of exponentiala.

by T. Hoshiko, Dept. of Phyaioloqy

Case Heatern Reaerve University School of Medicine

Cleveland OH 44116, U.S.A.

One of the moat difficult but aeeminqly easy curve-fittinq

taaka ia to fit a aum of exponentiala of the form:

n Y<kl "' t

jsO

where ks 1,2, •

~<jl EXP<-~<j>•T<kll

to a pointa, and n ia the numl>er of ex-

ponentiala. Thia taak ia alao one of the moat common aince the

expreaaion ia a aolution of linear f irat order proceaaea auch

as iaotopic decay, or pharmacokinetica of druq diaappearance from

the blood atream. The proqram to be described, DISCRETE, written

by Stephen Provencher, haa to be one of the beat if not THE BEST

proqram for fittinq auch a curve and ia now available throuqh

DECUS.

Before the availability of computera, the aoat common aethod

to reaolve the componenta of an exponential decay curve waa the

peelinq aethod. The data pointa were plotted on aeailoqarithmic

paper and aucceaaive atraiqht linea were aubtracted off. Subjec­

tive biaa and error are inherent in thia aethod and it waa aoon

abandoned.

RT-6

In o,rder to fit a non-linear function the common procedure

has been to linearize around a given point T<ko> using a Taylor's

series expansion as a function of the fitting parameters ~Cjl

and XCjl <see Bevington,1969>. By taking the first term, we ob­

tain an estimate of Y<kl as the product of the rate of change of

Y at Tlkol with respect to each parameter and its corresponding

increment ~(j) < or X(j) ), The chi square is used to estimate

the deviation. By the method of least squares, chi square is

minimized with respect to each parameter increment by successive

approximation to obtain a set of parameters to best fit the data.

The problem with this approach is that convergence to a minimum

chi square occurs only when the initial estimates for the fitting

parameters are very close to minimum since only first order terms

in the expansion are used. Thus the method was combined by Mar­

quardt with the gradient search method which approaches the

minimum rapidly, giving the popular algorithm associated with his

name. Although the Marquardt approach works well with many

non-linear functions, it often tends to diverge <blow up> when

applied to sums of exponentials. The difficulty is the

nonorthogonal behavior of exponential functions. The end result

is that small variations in the data lead to significant effects

on the parameters and rather different sets of parameters can

produce very similar values of chi square when the data are not

extremely accurate.

This situation led to proposals to transform the function to

the complex plane where entirely new properties are exhibited by

RT-7

the fitting function. An exact formal solution by Fourier

transforms is theoretically possible to give a spectrum with

sharp peaks at each X(j). No initial guesses as to magnitude or

number of components is needed. However, problems of truncation

of the data and lack of accuracy has limited the usefulness of

the initial attempts. Provencher has overcome these difficulties

by use of specified convergence parameters and the use of a Gaus­

sian taper window. In addition, noise reduction was accomplished

by autocorrelation data smoothing. The resulting program DIS­

CRETE requires only the raw data and initial guesses as to the

number or values of parameters are neither needed nor accepted.

DISCRETE is designed for the automatic analysis of discrete spec­

tra consisting of a sum of exponentials <up to 9l with provision

for a possible constant term.

The RT-11 version of DISCREI'E was compressed to fit in the

PDP-11 address space under RT-11. Input data can be either

equally spaced in time, in which case the time points need not be

specifically given, or at arbitrary intervals, requiring specific

time points. I have not tried fitting more than 4 exponentials

plus a constant and am uncertain whether the maximum of 9 ex­

ponentials can be handled. It is limited to handling only 50

data points and stores intermediate data on FORTRAN direct access

disk files, which makes things very slow. The speed no doubt

could be increased by using the virtual overlay feature of RT-11

version 5, etc.

RT-8

One feature which is a little disconcerting is the large

amount of print out of intermediate results. If the print in­

struction flags, PRL, PRPREL, PRFINL are set equal to F, there is

no possibility of examining the intermediate results. TSX moni­

tor command ASSIGN allows attaching the logical unit LP: to a

disk file for later printout. You save a lot of paper and not

have to leave your printer on all night.

PRVTSX.COM can be used to set this up.

The command file

The documentation in PRVTXT.DOC applies to the RT-11 version

which can run on VS.Ole. [Note that escape sequences for summa­

tion signs and underlining (pages 2,7,8,9 and 14l are for the

LAlOO printer.] Not included in PRVTXT.DOC but with the printed

material are Provencher's Update2 and original printout from the

Univac 1108 supplied by Provencher. Additional notes are in­

cluded in the command files PRVBLD, PRVFOR and PRVLNK. The com­

mand file PRVBLD.COM will make the ASSIGNments needed to run the

two command files PRVFOR.COM and PRVLNK.COM which compile and

link the programs. PRVBLD must be modified to conform to your

volumes which hold the sources and in which you wish the ~.SAV,

etc., to be stored.

As mentioned above I have been using TSX to run these pro­

grams in order to defer printing the output. RTll does not allow

this kind of ASSIGN instruction and prints out the material

directly. I have included the original UNIVAC 1108 output from

the Provencher's first and part of the output of the second data

RT-9

set to allow verification. The first data set PRVTSl.DAT took 24

minutes and some seconds to run and most of it was spent in

FANLYZ. The second data set PRVTS2.DAT took almost SO minutes.

The output from the second data set are stored in the files

DISCRT.Fn <n=O,Sl for comparison.

R E F E R E N C E S

Bevington,P.R. 1969. Data Reduction and Error Analysis for the

Physical Sciences. McGraw-Hill.New York. 336pp.

Marquardt,D.H. 1963. An algorithm for least-squares estimation of

nonlinear parameters. J.Soc.Ind.Appl.Math. 11<2>:431-441.

Provencher,S.H. 1976. A Fourier method for the analysis of

exponential decay curves. Biophys. J. 16:27-41.

RT-10

Automatic System Generation on Floppy-Based Systems

Chapter 3 of the RT-11 System Generation Guide says that it is not

possible to perform an automatic system generation on a PDP-11 with

only dual floppies. Since I have a MINC-23, I found that statement

very discouraging. However, a little investigation showed that, while

that restricton may apply to RX01 drives, the following procedure

(based on a method developed by Mike Demers of Polaroid> makes it quite

easy to automatically sysgen one monitor at a time with dual RX02 (or,

apparently, RX50l floppies. <The procedure works when the reduced

storage capacity of RX50 floppies is simulated by carrying a 188

block dummy file on each RX02, but I don't have access to an RX50

system to confirm this.) Read through the whole procedure once to see

your options before you begin.

Begin by formatting and initializing two RX02 or three RX50 diskettes:

one will be a system diskette and the second will be a data diskette.

<On an RX50 system, you may need two data diskettes.) Copy the

following files (from your working system and distribution backups) to

the system diskette:

RT11SJ.SYS or RT11FB.SYS DY.SYS or DZ.SYS SWAP.SYS TT.SYS <if necessary) LP.SYS or LS.SYS (if appropriate) IND.SAV DIR.SAV PIP.SAV DUP.SAV MACRO.SAV LINK.SAV SYSMAC.SML SYSGEN.COM (from distribution backup vol. 3).

RT-11

Copy the bootstrap, squeeze the diskette, then boot this system.

C[gnore the error message that the startup file can't be found.)

Run SYSGEN.COM as described in section 3.2 of the SYSTEM GENERATION

GUIDE but assign diskette drive 1 CDY1: or DZl:l for the source input

and drive 0 for the binary and map output, and refuse to keep the

system .OBJ files. CThere is enough room to keep the answer file and

the working files, and they are very handy.>

When SYSGEN.COM completes, the system device should contain the files

mentionad near the end of section 3.2. Copy SYSGEN.CND and SYSGEN.TBL

to the Cemptyl data diskette <and SYSGEN.CND to the second RX50 data

diskette, if you need onel, delete SYSGEN.CND, SYSGEN.TBL, SYSGEN.COM,

and IND.SAV from the system diskette, and squeeze the system. (Ignore

the "start file not found" error message again.)

TYPE or PRINT SYSGEN.MON and SYSGEN.DEV as indicated in section 3.3.1

to determine just what source files MACRO will require. Copy these

.MAC files, and only them, from distribution backup diskettes 4 and 5

to the data diskette then squeeze it, if necessary. <If all the

required source files won't fit on a single RX50 diskette, put the

files needed by SYSGEN.MON on the diskette containing SYSGEN.TBL and

the files needed by SYSGEN.DEV on the other data diskette.)

RT-12

If you are using a single data diskette, put it in drive 1 and the

system diskette in drive O, type @SYSGEN.BLD, and go away for about 45

minutes. When you come back, all the nasty stuff through the LINKing

of files in section 3.4.2 will have been done by your trusty PDP-11.

<If two RX50 data diskettes were required, you'll have to put the

first data diskette in drive 1 then type [email protected]. When that

command file finishes (after about a half hour>, put the second data

diskette in drive 1 and type [email protected]. A little more involved, but

much easier than the procedure described in the manual.> Just backup,

store, rename, and reorganize the files as indicated in the second

half of section 3.4.2 and you'r~ all done in about an hour and a half

total time, including the time to "'""'''"" the sysgen questions.

If your generated system is so large that you get a device full error

during LINKing, simply edit the SYSGEN.MON file to assign drive 1 as

the MAP: device (doubling the space available for the monitor) and,

depending on whether your time is more valuable than clock and system

time, either delete the .OBJ files and restart SYSGEN.BLD or type in

the LINK and DELETE commands from SYSGEN.MON then type [email protected] to

generate the device handlers. (With the reassignment of the MAP:

device, you will almost certainly need a second data diskette on an

RX50 system.)

RT-13

1111 THE PROPOSED VAX/RT REAL-TIME OPERATING SYSTEM 1 1 1 1

DECOS UK "RTSIG" REPLY TO THE DECOS USA RT-11 SIG VAX/RT POSITION PAPER

1111 INTRODUCTION 1111

This paper is a reply to the DECOS RT-11 SIG paper from the USA based on the "Murphy" meeting held at Albuquerque on March 22, 1985. The input to this document has come from UK users and was formulated at a meeting held in London on July 15, 1985. (An additional, written, technical contribution to the discussion at this meeting from Ian Hammond of Hammond Software (UK) Ltd is gratefully acknowledged and attached in an appendix). The format of this document is similar to that of the "Murphy" document with the exception of an additional section at the beginning to justify the need for VAX/RT, followed by a list of those architectural features of the proposed operating system that were felt to be fundamentally necessary. The remainder of the document deals with features of VAX/RT that are deemed essential on first release followed by a general conclusion.

Any correspondence relating to this document should be addressed to the "RTSIG" Chairman, Lawrie Godfrey, at DECOS UK, P.O.BOX 53, READING, BERKS RG2 OTW, UK.

1111 THE NEED FOR VAX/RT 1111

When PDP-11's were introduced they were relatively expensive. Now they are relatively much cheaper. The same thing will happen to the VAX range. We have observed part of this process already which has reached the MicroVAX II stage. By this time next year significant further progress along this path will undoubtedly be visible to the ordinary user. The key difference between the PDP-11 development and the VAX development in software terms is that when the PDP-11 emerged operating system concepts were in a very raw state. Hence a number of parallel lines of development occurred. Also the true development costs of operating systems were not known. When the VAX hardware was developed it was in full knowledge that the hardware and software form an operating combination. Also that the whole process was now known to be so expensive as to prohibit parallel lines of software development. Hence VMS. The VMS operating system is excellent. It does (almost) everything. It is necessarily complex and this means that it is overcomplex for the user who wishes to interact more directly with the operating system and the hardware. Eventually the VAX hardware/firmware will become available to a much larger spectrum of users as the price and physical size fall. Where is the operating system for the hardware based user interested in real-time activities ? If DEC do not provide such an operating system then someone else will. This will not necessarily be to the benefit of the user community as previous experience has shown. VMS is a "standard" in all senses of the word, to the credit of DEC. VAX/RT could also be a similar "standard" of equal credit.

Cost is an important factor. There are two costs. The cost to DEC to develop VAX/RT and the selling cost to the user. It is unrealistic to expect ordinary members of DECOS to be able to present marketing plans which show that VAX/RT is a commercial proposition. Indeed we doubt whether any plan of this nature can be accurate since few market analyses for a decade ahead have been shown to be correct a decade later. Statistically there is a low probability of getting such a forecast right based on past experience. The marketing faction will disagree. That is natural. Who could have forecast in 1975 that RT-11 would have numerically outsold all other DEC operating systems a decade later ?

RT-14

The second cost is the cost to the user, Eventually there will be a spectrum of VAX hardware from very large expensive systems down to much lower level systems, Ordinary users can only guess at the lowest level at which VAX's will be used, Perhaps they will not be used in washing machines, but they might be used as home computers or small industrial controllers. The point is that cost of the operating system, and VAX/RT would be the operating system of choice, would be important. We believe that an initial pricing at the RT-11 level is sensible, Another important factor is the cost of layered software, This would also need to be priced at a lower level than the corresponding VMS software,

To turn to slightly less general matters, DEC has achieved an impressive penetration into the scientific/laboratory/academic area. Although there is undoubtedly much more revenue in the business area, the scientific area and it's industrial connotations cannot be ignored, A software upgrade path onto the VAX hardware is needed that mimics the performance and facilities of RT-11 but on 32 bit systems. The sales potential is obvious, A very large number indeed of scientific users use or know RT-11. What is this group looking for in general ? There are three main areas, the first of which is self evident :-

ONE - The abolition of the 16 bit addressing limit, The ability to run very large programs written in scientific languages, of which FORTRAN is (still) the prime example. Perhaps not so obvious, the ability to map large areas of memory for dual use between VAX/RT and external devices, bit-mapped graphics devices are the obvious example. The ability to "throw-away• the operating system if necessary, whilst still being able to recall it as needed. RT-11 is very good in this area,

TWO - The lowest possible interrupt latency, Or, to put it another way, the highest possible rate of response of the operating system to external events, whether these are generated via peripherals or special purpose interfaces,

THREE - Minimal complexity of operating system software. It should be possible for ordinary technically competent users to boot the system immediately on delivery, to be doing useful work in a few days and after some time to write a device driver, All of this is commonplace under RT-11. System manager should be a non-existent post on VAX/RT sites,

Most importantly, it is not necessary that VAX/RT should be a clone of RT-11 but that rather it should embody the same philosophy as RT-11.

**** THE FUNDAMENTALS OF VAX/RT **** The UK "RTSIG" see the following as vital :-

VAX/RT should be a single user multi-tasking real-time operating system.

VAX/RT should be designed with networking capability as an integral part of the design. On release it must support DECNET as an end node and eventually support the fUll OSI protocol as a through node,

VAX/RT should support paging jobs on first release, mainly for those who want to write huge FORTRAN programs that exceed the size of the installed memory, but it is important that the paging feature can be excluded or turned off,

VAX/RT should have the entire operating system executive in memory at all times, The executive should be as small and fast as possible, like RT-11.

RT-15

VAX/RT should make extensive use of ancillary control processors (ACP's) to support file structures on I/0 devices, By this means any file structure can be supported, The fullest documentation of this feature should be provided so that users may write their own ACP 1 s, On first release the RT-11 and VMS (Files-11) ACP's should be supported, Ne attempt should be made to devise a special or extended file structure for VAX/RT based on any other file structure, if required this will come later as a result of user pressure or being user-written, The executive should contain the basic mechanisms that interface to ACP 1 s so that users who wish to bypass ACP 1 s can do so, ACP 1 s must also contain enough functionality to enable PIP, DUP, DIR etc (or their VAX/RT equivalents) together with any user programs that support wildcards etc to be ACP independent,ACP 1 s all work through the same device drivers, and it should be possible to have different units on the same controller (and hence driver) to be mounted with different ACP 1 s,

VAX/RT should not implement sophisticated task (job) protection and the task (job) priority structure should be simple. Job shuffling should be avoided, Purchasing memory for extra tasks (jobs) should be regarded as being a realistic solution.

VAX/RT should be distributed, like RT-11, with the source code for the executive, ACP(s) and device drivers on the magnetic media.

VAX/RT should be designed so that it is possible to implement some degree of multi-processing, The ultimate availability of peripheral processor boards to add extra VAX and/or PDP-11 CPU processors onto QBUS machines must not be overlooked. In particular this could provide the ultimate PDP-11 to VAX upgrade path i,e, run your RT-11 software under the control of VAX/RT on a peripheral processor board with access to RT-11 devices via the RT-11 ACP.

**** VAX/RT ESSENTIAL FEATURES ON FIRST RELEASE **** Some of these features have been mentioned earlier, but are repeated

here for completeness :-

EXECUTIVE - RT-11 like user interface, ACP support, Paging support. Fully memory-resident, Multi-processing "hooks", High-speed vectored interrupt support. Virtual console (windowing ?) hooks, like TSX virtual lines,

ANCILLARY CONTROL PROCESSORS - RT-11 file ACP (without any attempt to alter or extend the existing file structure), DECNET ACP supporting an end node. VMS (Files-11) ACP. Support for non file structured (fast?) I/O ; direct to driver.

DEVICE HANDLERS - Device handlers should be relatively simple (as in RT-11), although it is desirable that there should be proper support for internal queuing (particularly desirable with RQDX/KDA50 type devices, where many disks may be hung onto the same controller) and forking (via VAX interrupt request hardware), Support should be provided for all currently available DEC devices, including the RL02 (through any ACP since all use the same drivers),

UTILITIES - Assembler, Linker. Librarian, Editor, Backup, SRCCOM, BINCOM. SIPP. (Or the VAX/RT equivalent of the last three RT-11 utilities),

LANGUAGES - VAX/RT MACR0-32 (Obvious - you use it to write the operating system I), FORTRAN-77. PASCAL,

RT-16

•••• CONCLUSION ••••

There is a final point. An inevitable reply to the VAX/RT proposal is to say that VMS does everything that is needed already. It is true that a substantial fraction of the functionality discussed above already exists within VMS. It is also true that there is an identifiable need for something more suited to real-time and low-end systems. The VAX/RT proposal needs serious consideration. Can VMS possibly satisfy all the VAX market in software terms ? If so, why ULTRIX ? The PDP-11 bas RT-11, RSX, RSTS, UNIX & HUMPS all supported by DEC. Obviously DEC would not be keen on supporting the same number of operating systems on the VAX, The support problems would be unmanageable in an economic way. However there is another aspect to this, Another vendor may develop a VAX/RT type of product. The reason another vendor bas not developed a rival VMS type of product, and UNIX/ULTRIX is not a rival, is that it would have to be better than VMS to compete. The same is not true of the VAX/RT arena, there is no product from DEC. If DEC do not supply VAX/RT then another vendor will, this will not be to the advantage of the user coDDDunity in the long term, A proliferation of •foreign" operating systems is to be avoided. The hardware manufacturer's support is vital.

Appendix - Technical Submission from Ian Hammond

RT-17

APPENDIX - SUBMISSION FROM IAN HAMMOND

VAX/RT and the rest of the world - the RT-11 architecture RT-11 is an inrustry standard because it defines the baseline model for a PDl'-11 operating system and file-structure. RT-11 has been reimplemented by DEC and others marry times (RSTS, RSX, VMS) and is the basis of other systems (MPP etc.). The RT-11 file-structure is implemented by every serious DEC system.

RT-11 has survived because it is an inrustry standard. VAX/RT should supply the Sil'Tle kind of baseline model for the VAX.

1. VAX/RT should be able to be emulated on other VAX systems. Thus VAX/RT system services should be implemented so that they can c"""'xi st in a VMS system.

2. VAX/RT should support standard RT-11 disk volumes.

RT-11 and real-time - the RT-11 implernentatim RT-11 supplies its architecture to a broad section of the c~uting c00TT1unity. However, the actual implementations of DEC RT-11 are solidly aim..d at the real­time world (with layered products like CTS adapting it to other markets). VAX/RT must retain this implementational grip V.'1 the real-tine-market.

Each version of RT-11 has added additional overhead to RT-11's response time. VAX/RT would have the opportunity to streamline.

In the meetings I have attended the users who 'needed VAX/RT were real-time users who wanted to collect large amounts of data very quickly. The size of address spaces has grown over the last decade - but systems have gotten slower, not faster. VAX/RT needs to deliver all the speed of the machine to real-time users.

1. VAX/RT needs to be structured like RT-11 with the equivalent of a very small, very fast SJ system.

2. Paging needs to be optional (including stack extension).

3. A fast file-system is required.

4. Kernel-mode/System-space programs should be supported.

s. Direct vectoring of interrupts to an application should be supported.

6. Track/cylinder disk allocation should be supported.

VAX/RT and CORT Good old RT is over ten years old. The PDl'-11 could do with a new implementation of RT-11. If this ever happens the most useful model for the new system would be VAX/RT (if miracles strike twice in the S""1e place).

1. VAX/RT should be designed with an eye on a culturally compatible PDf'-11 implementation at some point in time.

RT-18

m1A and R111B 1he 'M~hy report' suggests that VAX/RT support a new file:-structl.l'e (RTI18), that RTI1B be the bootable and primary file:-structl.l'e. Other structl.l'es, includ­ing RTI1A should be supported with loadable ACP' s.

Obviously VAX/RT supplies the right opportunity for a new file structl.l'e that can overcome sane serious limitations of RTI1A (for exanple the six character filename). But, VAX/RT should also support RTI1A as a bootable and prinary structl.l'e.

1. It is going to take a long tine for all the other systems to support RTI1B. We already have enough CO'l1>atibility problems without adding more. For example, consider a shop that wants to combine RTEM on one VAX with VAX/RT on dedicated machines. They will want to configure bootable disks.

2. RTI1A is smaller and smpler than RTI1B and therefore satisfies the mininal requirements of sane dedicated systems more fully.

l. Most sites will find that they have to have both RTI1A and RTI1B loaded for the first 'l"'ar or so. This costs them additional space.

4.. Mien will RT-11 support RTI18? Will RT-11 support an RTI1B ACP or will it only be available via an exchange utility!

VAX/RT is to RT-11 what VAX/VMS was to RSX-11. VAX/VMS supports both F11A and F11B as bootable devices and as the prinary file-system, mainly because of the reasons given above.

VA>VRT and an RT-1'1 AME VAX/VMS supplied an AME for its predecessor RSX-11 systems. Consideration of an RT-11 AME for VAX/RT should be made even if the newer models do not support com­patibility mode.

1. Hooks should be available to support CO'l1>atibility mode

VA>VRT and networks Networks are the biggest CO'l1>uter futl.l'e. Networks are part of the system. RT­n•s support of DECnet represents one of its weakest areas. VAX/RT should be designed with efficient support for real networking.

1. VAX/RT needs very strong network support

VA>VRT and VAX/ELN At first glance VAX/El.N might seem to answer the needs of prospective VAX/RT users. It has better real-tine facilities than VMS and does not hog memory or disk sµ;:ce.

However, VAX/El.N does not remove the requirement for VMS. A VAX/VMS system is required for VAX/El.N progran development.

Further, PASCAL is the language of choice for a relatively small nl.l'nber of users. VAX/El.N is only sensible if you use PASCAL.

Finally, VAX/El.N does not supply the real-tine parameters being requested. ELN puts the system between the hardware and the application. VAX/RT wants inter-. rupts delivered directly to the application.

lhe increasing sophistication of computer applications requires larger address 'space' (an additional address bit each 'l"'ar). Real-time programmers need more than space to deliver new functionality - they need to be able to take direct advantage of faster CPIJ s.

RT-19

[Q] DEC US

/\ ;' ,, ;' ,,

/'SITE'\

,, '\ - - - -·

SITE

Chairman 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

Symposia Coordinator VAX SIG Liason

Michael Weaver OJCS/JAD/TSD Room 1D940 Washington D.C. 20301-5000 <202> 694-6772

Communications Committee Representative AI SIG Liason

Terry C. Shannon Digital Review 160 State St. 6th Floor Boston, MA. 02109 (617) 367-7190

Newsletter Editor Networks SIG Liason OA SIG Liason

Gregory N. Brooks Washington University Behavior Research Labs 1420 Grattan St. St.. Louis, MO. 63104 <314> 241-7600 ext. 257

Session Note Editor Large SIG liason

Gary Bremer Emerson Electric Co. 8100 W. Florisant St.. Louis, MO. 63136 (314> 553-4448

Product Coordinator HMS SIG liason

Jim Corrigan KI Research 2116 E. Arapaho Suite 521 Richardson, TX. <214> 960-5674 or <714> 633-9308

Assistant Library Coordinator RSTS SIG Liason

Timo'thy Frazer Specialized Bicycle Components 15130 Concord Circle #77 Morgan Hill, CA. 95037 <408) 779-6229

Library Coordinator DMS SIG Liason Large SIG Liason

Larry W. Hicks Relational Database services P.O. Box 644 121 S. Main St. Kernersville, NC. 27285-0644 <919) 996-4882

Hardware Coordinator HMS SIG Liason

Emily Kitchen A.H. Robbins Co. 1211 Sherwood Ave. RT-2 Richmond, VA. 23220 (804) 257-2925

Staff Management Adam Zavitski 720 N. Zenith Tulsa, OK. 74127

Pre-Symposia Seminar Coordinator Phillip Ventura

Members-At_Large

DEC

George Hilton Compucard International 777 Summer St. Stamford, CT. 06091 (203) 324-9261

Debbie Boole Texas Instruments 13510 N. Central MIS 437 Dallas, TX. 75266 <214> 995-4629

Coun'terparts

SonJa Sokal Digital Equipment Stow MA.

Lil Holloway Digit.al Equipment Bedford MA.

Susan Porada Digi'tal Equipment Marlboro, MA.

Gary Siftar Digit.al Equipment Tulsa, OK.

Corp.

Corp.

Corp.

Corp.

SIT-i

DEC US

UNISIG Chair James W. Livingston, Jr. Measurex Corporation 1 Results Way Cupertino, CA 95014 408-255-1500 x5556

ihnp4!decwrl!jwl

UNISIG Symposia Coordinator

Stephen M. Lazarus Ford Aerospace, MS X-20 3939 Fabian Way Palo Alto, CA 94303 415-852-4203

ihn p4 !fortune !w dll !sml

UNISIG Session Notes Editor

Kurt L. Reisler Hadron Incorporated 9990 Lee Highway Fairfax, VA 22030 703-359-6100

decvax!seismo!hadron!klr

UNISIG Newsletter Co-editor William Toth Harvard-Smithsonian

Center for Astrophysics 60 Garden Street, P-353 Cambridge, MA 02138 617-495-7181

harvard!hrvsmth!toth

UNISIG Newsletter Co-editor

James W. Livingston, Jr.

UNISIG Administrative Daemon Dorothy Geiger The Wollongong Group 49 Showers Drive, 451 Mountain View, CA 94040 415-948-1003

ihnp4!decwrl!dgeiger

UNI-i

UNISIG Tape Librarian

Carl Lowenstein Marine Physical Laboratory Scripps Institute of Oceanography, P-004 La Jolla, CA 92093 619-294-3678

(ihnp4ldecvaxlakgualdcdwestlucbvax) !sdcsvax!mplvax!cdl

UNISIG Usenet Liason Joe Kelsey FlexComm Corporation 711 Powell Ave. SW Renton, WA 98055

allegra!fluke!joe

UNISIG Standards Coordinator

Jeff Gilliam National Semiconductor 2900 Semiconductor Drive, MS C2303 Santa Clara, CA 95051 408-721-3801

ihn p4 !nsc !voder!j eff

UNISIG Minister Without Portfolio Norman Wilson Bell Laboratories, 2C-529 600 Mountain Avenue Murray Hill, NJ 07974 201-582-2842

( decvaxjihnp4 )!research!norman

UNISIG DEC Counterpart Roseann Maclean DEC, MK02-1/H10 Continental Boulevard Merrimack, NH 03054 603-884-5702

decvax!maclean

NEWSLETTER OF THE VAX SYSTEMS SIG

~ '~.s'J-:

I~- .s'J-~~.s' CDEa.JS

Security Hole in VMS 4.2 •••••••••••• VAX-3 Editor's Workfile ••••••••••••••• VAX-4 A Concern about Security and DZ Ports ••••• VAX-5 A User's Experience with Terminal Servers ••• VAX-8 European DECUS Question and Answer Session VAX-13 VAX System SIG Committee List • • • • • • VAX-61 INPUT/OUTPUT • • • • . • • • • • • VAX-64

Forms at the End

INPUT/OUTPUT Submission Form • • • • • System Improvement Request Submission Form VAX Systems SIG Spring 1986 SIR Ballot ••

QU-1 QU-3 QU-5

US CHAPTER

PAGESWAPPER - April 1986 - Volume 7 Number 9

General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to:

Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA

Preference is given to material submitted as machine-readable text (best is Runoff source) • Line length should not exceed 64 characters. Please do not submit program source, as that is better distributed on the VAX SIG tape.

Change of address, reports of non-receipt, and other circulation correspondence should be sent to:

DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BP02) Marlborough, MA 01752 USA

Only if discrepancies of the mailing system are reported can they be analyzed and corrected.

VAX'-2

PAGESWAPPER - April 1986 - Volume 7 Number 9 Security Hole in VMS 4.2

Security Hole in VMS 4.2

Art Mcclinton Mitre Corporation

McLean, Va

Every feature of an operating system that is designed to allow a user access to data that he would not otherwise have access to has the potential of leading to pitfalls for the system manager. Normally this would only come into play if you take over a system that was installed by someone else. It is very easy to install a few Access Control List (ACL) entries that can be used at a later date to perform extensive damage. The first thing a new system manager should do is analyze all ACL's in the system for potential side effects.

Additionally, VMS 4.2 has a bug that dllows to obtain SYSNAM privilege. The hole may the system manager. The remainder of this describe the hole, its impact, and how that users cannot get in through the hole.

non-privileged users be easily plugged by brief article will

to fix your system so

Normally I would not write about security holes but this one is so widely publicized at this point that not to write about it would be the worse of the two evils. ACL's may be placed on files, devices or logical name tables. In the case of the logical name table, the system default is to allow any user the privilege of placing an ACL on any logical name table. This enables a non-privileged user the ability to set an ACL on the LNM$SYSTEM table to allow read+write+control. This enables the same user to modify entries in the table. This is fully equivalent to SYSNAM privilege. It does not take much imagination to write a trojan horse if you have SYSNAM privilege. The details will be left to the hacker.

Like most security holes, it is very easy to close it once it has been discovered. The following code should be added to the system startup command file to close the hole:

$SET ACL/OBJ=LOGICAL/ACL=(ID=[*,*] ,ACCESS=READ) LNM$SYSTEM TABLE $SET ACL/OBJ=LOGICAL/ACL=(ID=[*,*] ,ACCESS=READ) LNM$SYSTEM DIRECTORY

Similar lines of code should be added for any other site specific system logical name tables that you have created.

Digital is aware of the problem and plans to fix it in a future release of VMS. They have installed a tech tip at the Telephone Support Center. This information has also appeared on ARPANET. With such wide exposure, I feel that we need to communicate the problem and solution to as many system managers as possible so

VAX-3

PAGESWAPPER - April 1986 - Volume 7 Number 9 Security Hole in VMS 4.2

that they may protect their systems.

Editor's Workfile

by Larry Kilgallen, Pageswapper Editor

Don't Forget to vote -

The System Improvement Request list is in the issue of two months ago, and the ballot is reprinted at the end of this issue. Photocopies of the form are quite acceptable; it is your membership number which validates the ballot as being yours.

Isn't it nice -

that a European DECOS member put in the effort to share their VAX Q & A with everyone who did not attend their symposium? Isn't it too bad it has been so long since anyone from the US has put in the effort to transcribe the similar sessions which are held at US Symposia?

VAX-4

PAGESWAPPER - April 1986 - Volume 7 Number 9 A Concern about Security and DZ Ports

A Concern about Security and DZ Ports

by Jean Pollock and Jim Haskett Bloomington Academic Computing Services

Indiana University Bloomington, IN 47405

The Problem

DZll terminal ports are polled for dial-up and hang-up events, as a result of which VMS connects users to or disconnects them from interactive terminal sessions. When this polling window is too large, a new user can slip into an existing session following a non-standard disconnect by a previous user. Such a disconnect can occur for users connected to a VAX via a terminal network. When the window is too small, there is a significant increase in CPU overhead. The width of this window is determined by a VMS operating system parameter called TTY SCANDELTA.

The polling interval is currently 1/20 sec. on our VAXs. VMS requires TTY SCANDELTA to be larger than 1/100 sec. The default value is 1 second.

The Benchmark

An attempt was made to determine the optimal setting for the polling interval which would keep the CPU overhead and the security window at a minimum. To this end, benchmarks were run under VMS 3.7 (on Node Orange) and VMS 4.1 (on Node White). Both are VAX ll/780s. All unnecessary processes were terminated while the benchmarks were run. A benchmark program was written in non-standard FORTRAN to start an interrupt timer and then increment a counter until the timer expired. The value of the counter was recorded as an indicator of the amount of overhead lost to polling. Thus, smaller values of the counter are expected for frequent polling (i.e. smaller polling windows). Different values were assigned to TTY SCANDELTA for each run. Generally, for each value of TTY SCANDELTA, the program was run three times for one minute each. The largest variation in the results obtained for each parameter value was approximately 0.1%.

VAX-5

PAGESWAPPER - April 1986 - Volume 7 Number 9 A Concern about Security and DZ Ports

The Recommendation

The results of these benchmarks follow. As a result of these benchmarks, we have recommended reducing the polling time from .05 sec. (i.e. TTY SCANDELTA = 500,000) to 0.03 sec. (TTY SCANDELTA = 300,000) on our machines. This will result in an increase in CPU overhead of approximately 0.6%

We would like to thank Dave Schwab for his AST code and John Stockton for his help in executing the benchmark.

Polling Interval

.01

.02

.03

.04

.05 0.10 sec.

Polling Interval

.01

.02

.03

.04

.05 0.10 sec.

The Results

TTY SCANDELTA

100,000 200,000 300,000 400,000 500,000

1,000,000

TTY SCANDELTA

100,000 200,000 300,000 400,000 500,000

1,000,000

VAX-6

Counter Value Orange

VMS 3.7

29,114,516

29,572,458

29,659,082 29,734,726

Counter Value White

VMS 4.1

29,106,293 29,438,817 29,559,069 29,609,928 29,634,821

Per Cent Change in Counter Value

1. 55

0.29 0.25

Per Cent Change in Counter Value

1.13 0.41 0.17 0.08

29750000

2971il01illillil

29650000

29600000

29550000

29500000

c 0 29450000 u n t 29400000 e r

29350000 v a 1 29300000 u e

29250000

29200000

29150000

29100000

29050000

29000000

+

I +

I +

I +

I +

I +

I +

I +

I +

I +

I +

I +

I +

I * + #

I +

I

PAGESWAPPER - April 1986 - Volume 7 Number 9 A Concern about Security and DZ Ports

TTY SCANDELTA Benchmark

*

* #

#

* #

#

* Orange VMS 3.7 # White VMS 4.1

+---+---+---+---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 7

TTY SCAN_DELTA (X 100,000)

VAX-7

8 9 10

PAGESWAPPER - April 1986 - Volume 7 Number 9 A User's Experience with Terminal Servers

A User's Experience with Terminal Servers

Stanley M. Rose Vice-President, Distributed Processing Technical Support

Bankers Trust Company New York, New York

The purpose of this article is to outline the experience of Bankers Trust with terminal server technology. This article is not intended to be a tutorial on Terminal Servers as many excellent articles have been written on that subject.

After evaluating the DECSA, DECserver-100, and non-DEC units, the Bank chose the DECserver-100 and the decision has been substantiated by our subsequent experience.

Background

Bankers Trust is a large user of DEC equipment. At present we have 18 PDP-ll/70s (RSXllM-PLUS), and approximately 40 VAX systems, ranging from 3 MicroVAX-II to 7 VAX-8600. These systems have a terminal population of over 2500 terminals . Because of the criticality of the systems to our business most applications have a backup processor, which has, in turn, resulted in a good deal of terminal switching between primary and backup processors. In some cases there are secondary levels of backup, making the switching all the more complicated.

The net result is that we had developed a very complex, and costly, investment in matrix switches, patch panels, etc. The complexity of the switching had become quite labor intensive as well.

Compounding costs was the expense to install each point to point line. Due to the high costs of labor in New York it was not uncommon to have the costs of the line exceed the costs of the terminal, sometimes by a factor of two.

To address these issues the Bank embraced the concept of Terminal Server based communications. After a detailed evaluation of several alternatives, which included installing and using foreign vendor equipment, as well as participating in Field Tests of the DECSA terminal server software and DECserver-100 products, the decision was made to use the DEC technologies. Subsequent work has further refined that decision to our usage of the DECserver product.

VAX-8

PAGESWAPPER - April 1986 - Volume 7 Number 9 A User's Experience with Terminal Servers

We felt that although, at times, other vendors might have had products that better handled certain niche situations, in the long run a better strategic decision was to use the DEC technology. We have found that the DEC products act as an extension of the system in a symbiotic relationship with VMS.

Some of the advantages of the DEC products over the non-DEC units are:

> No modifications to VMS, and no problems with lagging support for operating system upgrades.

> Simple connection through standard DEUNA.

> Easy installation of units.

> Very easy network control.

maintenance and

> Knowledge of VMS (now RSX), with the server does automatic connection processor without the necessity of commands.

configuration

result that a to the backup

issuing any

> The software is centrally maintained on the VAX, rather than at each individual server.

Some of the key features of both DEC units, that are now being used include:

> Load balancing by automatic connection to least loaded processor.

> Automatic connection to backup processor.

> Preferred Service

> Autoconnect

> Multiple sessions

Some specifics of each unit follow.

DEC SA

The first server that we received was the DECSA (or PLUTO) box based Ethernet terminal server. This unit supports up to 32 lines with modem control and reverse LAT.

VAX-9

PAGESWAPPER - April 1986 - Volume 7 Number 9 A User's Experience with Terminal Servers

Reverse LAT is the ability to use the server with a CPU that does not have native mode LAT support (such as from another vendor). Each port of the server is connected to individual asynchronous lines on the CPU. The terminal is connected to another port on the same or different server and can issue a connect to a group of ports which are assigned to a series of physical terminal server ports. Since we were only using the servers with VAX systems at the time, this was not a feature that we needed.

For security reasons we have not installed dial-up access on the Ethernet, and therefore do not presently need the modem control feature either.

Functionally, the DECSA supported all the features we needed, but was rather large for locating in a user area. The cost per port was higher than the cost on the DECserver-100, and since we did not need its added functionality we made the decision to standardize on the DECserver-100 instead.

DECserver-100

As with the DECSA, the DECserver-100 has satisfied virtually all of our functional requirements. Installation has been very easy and takes no more than a few moments to set up the characteristics. The multi-system access has significantly reduced the overhead and labor intensive activities involved in system switching.

One design feature that we find appropriate for our use is the 8 line size of the DECserver-100 . We have found this size to be a good trade off between economy of scale, system overhead, and minimization of single points of failure.

The unit has been extremely reliable, and with close to 100 installed units we have experienced no more than 2 or 3 failures. Our maintenance strategy has been to purchase several spare units, and the minimum level of field service coverage. In the event of a failure, we simply swap in a spare unit and have field service replace the spare.

Ethernet overhead is quite low, and with as many as 50 servers and 350 terminals on one cable, we have seen no perceptible impact on response time.

The physical size and lack of special environmental requirements has made it easy to locate the DECserver-100 in office areas. Where we have had many units to co-locate, we have removed the outer plastic shell from around the inner metal case and shelf mounted them in standard EIA electronic racks along with DELNis for concentration onto the Ethernet.

VAX-10

PAGESWAPPER • April 1986 - Volume 7 Number 9 A User's Experience with Terminal Servers

The Field Test of the DECserver based line printer support has progressed very smoothly and has provided an additional functionality that will be used extensively. All-in-all, we have been very happy with the units.

Wish List

No one is give us we would software

ever completely satisfied with what is available a hand and we want an arm. There are several features

like to see implemented in the future; some may be just enhancements, while others will require new devices.

The most important new software feature we need is host identification of the physical access port. This is a vital security feature to allow applications to be able to determine which physical terminal, at which server and port, is accessing the system. This has been the one feature we have lost in moving away from hard wired terminals.

Another software feature we would like to have implemented is LAT support of multiple Ethernets to avoid a single cable failure affecting large numbers of terminals. We have developed a non-standard and, of course, unsupported patch to handle multiple LATs on several DEUNAs, but would like to have a supported method.

A hardware feature that would complement the multiple Ethernet support would be a server that connected to two Ethernets, and did hot fail-over in the event of a cable failure. Note that we are addressing here the problems of cable failure, not server failure.

Not actually a terminal server future, but one needed to support additional servers, is a high speed bridge between facilities. we have a need to locate the processors in one building, and the terminals in another - beyond the accessibility of fiber optic repeaters. As the number of devices increases, our need for more bandwidth grows with it. A device allowing us to connect remote Ethernets at Tl speeds is becoming more necessary.

A capability that would off-load work from the central processors would be the implementation of the terminal driver in the server itself, especially on input. The READ QIO is actually a quite deterministic process, namely getting a set of characters until some condition is reached, and this could be moved out into the server.

Once the terminal driver is implemented in the server, the various forms control packages, FMS and TOMS, should be implemented in the server as well. TOMS seems to lend itself quite well to this capability since it is full-screen oriented.

VAX-11

PAGESWAPPER - April 1986 - Volume 7 Number 9 A User's Experience with Terminal Servers

And, of course, we may find a use for reverse LAT and modem control and would like to have those implemented as well in the DECserver.

Summary

We have installed approximately 100 DECserver-100s in the last year and have been extremely happy with the unit. We are continuing to migrate terminals from point-to-point line interfaces to DECserver-100s and expect to double the number of installed units in the next year.

VAX-12

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

European DECUS Question and Answer Session

Transcribed by Tony Arnold VMS SIG Chairman, DECOS UK, Ireland and Middle East

University of Manchester, Computer Graphics Unit Oxford Road, Manchester Ml3 9PL, England

Transcript of VAX SIG Q and A session held at the DECOS European Symposium at Cannes, France. September 1985.

Chairman

Good evening ladies and gentleman. My name is Alan Silverman and I foolishly volunteered last year to the System Improvement Request in Europe. This time last year I stood up and asked why we had sent out 2,000 forms last year and only had 76 replies. I complained, and said I thought you could do better. Well I should have kept my mouth shut because this year we got 766 replies and it took me a long time to count them! so, next year you will be asked to vote on the top 5, not the top 10. Okay. We did count all of them, and sent the top 5 to Digital. Andy Goldstein is here tonight to present the reply to the top 5. We will do them one at a time. The top one was number 30 on the list, which was split screen editing. This got 2402 votes including 53 first choices and was voted for by 370 people. Over to Andy.

Andy

I am pleased to report that we actually managed to get one right. Split screen editing is available in the new VMS editor VAX TPU and that is available in VMS 4.2 TPU is a completely programmable editor and it is intended to be used not so much as an editor by itself, because in fact it looks very much like a programming language rather than what you would view as an editor. Rather it is meant to form the basis of other editors. In fact, we already have several editors that are built on TPU and there are more coming. We provide 2 general purpose editing interfaces with TPU. There is an EDT emulator which is our way of eventually phasing out the existing EDT. We will provide the equivalent compatible EDT function through TPU. There is a new editor called EVE which was developed with extensive consulting with our human factors group and the EVE editor does support multiple window editing. It also supports arbitrary extensibility through TPU callouts and all kings of good stuff like that. EVE was designed specifically to be used in either a single editing or a multiple window editing environment. Any questions or comments?

VAX-13

PAGESWAPPER - April 1986 - Volume 7 Number 9 Europea~ DECUS Question and Answer Session

Question from audience.

Presumably this is all VT200s and all that fact that the VT100 is and scrolling when you

Andy

going to be supported on VT100s and good stuff. How are you coping with the

not really all that good at split screens have got them mapped together?

Okay, well I haven't been directly involved with EVE, but basically, the VT100 does support split screen scrolling regions and about the best you can do is swap them around and just set up the area that you want to scroll for scrolling. I haven't actually used it myself, so I can't comment personally on the performance.

Chairman

The second most popular item was number 50, which was one that we have seen before, and that is on line disc compression.

Andy

SIR number 50 relates to on line disc compression and observes that the increasing use of Winchester discs, in particular single disc systems makes it increasingly impractical to reorganise your storage space with Backup, and of course that is also a problem in that you have to take down your system or at least your application to do that, and also as the discs get larger, again using tape as the intermediary storage becomes less practical because of the tape volume and simply because of the length of time it takes. so the request is for a utility that allows di~c compression and free block consolidation and preferably on line as concurrently as possible with system activity. We agree that's a fine idea. We obviously haven't done it yet! This is a relatively new SIR request. This has not come up in past United States SIR ballots. We certainly intend to take a good hard look at this problem. I have some experience with it. I actually worked for RSX back in the old days when we had a gadget called DCU which some of you may remember.. I think DCU was a very good demonstration to us all that this is not an easy problem. One of the interesting problems other than simply interpreting the file structure correctly is coordinating the compression with ongoing file activity, and of course clusters add a unique twist to that. Also the performance problem is quite difficult because inplace disc compression is to the best of my understanding an inherently n squared problem and so with some very large discs you run into some very serious performance problems. Obviously you can do intelligent things to make it run faster and we are going to have to spend some considerable time and attention in getting reasonable performance out of it. Any comments or questions?

VAX-14

Chairman

The next one terminals.

Andy

was

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

a request for the log out of inactive

The reason I got to do this session, by the way, was because I guess I ended up writing 4 out of 6 of the SIR responses. This has been a feature that has been requested for a long time. we have been thinking about it. One of the reasons we have not done it is because it is not quite as easy as it looks. At the same time it hasn't bubbled up as high on the priority list because it is the kind of thing that can be supplied by the installation. It is simple to build an extra watcher process that performs this function. Obviously we understand that you would rather see something like this provided by DEC and be general enough to handle everyones problems but that is exactly where the rub lies. The difficulty is coming up with a correct decision that a terminal is actually inactive. You might start out by saying that if there are no !Os over a certain period of time then that terminal is inactive, then you raise the question, what if there is some kind of long running job on the terminal in question? you can follow these through several levels. You can argue that maybe there is a server process connected to the terminal and in fact all of the active computation is being done in sub processes and you can dig yourself as deep as you like. I think one of the thing that we are looking for in terms of guidance, is what level of intelligence people feel is really necessary in such a facility, and I am certainly willing to entertain suggestions from the floor.

Long silence.

This is going to be a very boring session unless people get up and start saying something! What more can I say about this capability except we have had it in mind and as soon as we get out of the way what we consider some of the more pressing security features, we are going to look at it. It has appeared on the bottom end of some of our project plans in the past and so far it has always ended up below the cut off line. The fact that it has been specifically requested by a couple of SIR ballots should influence our decision on that.

G. s. Bal, University of Liverpool VMS 4.1

we have the problem that the architecture of VMS does not have any timeout feature built into it. We have a network controlled by Gandalf PACX and the contention device. At times it is possible to switch the controller off or the terminal off. That switches the terminal port off on the contention device and leaves the whole port in. Anybody who comes in next gets into

VAX-15

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

somebody else's session.

Andy

I would answer that by suggesting that the terminal lines that you have connected to the terminal switch are incorrectly configured in that you do not have modem control enabled. When a line has modem control enabled and goes into any kind of terminal switching state, VMS should treat that as a modem hang up and either log out the job or disconnect the process depending upon whether you have disconnectable terminals enabled or not. If we leave processes floating that someone else can accidentally reconnect to that is the result of the modem signals not being correctly handled.

D. Bal

This system did work on 3.7?

Andy

This is true on 3.7. Obviously 3.7 did not have disconnectable terminals but a properly configured terminal set up in 3.7 should disconnect the lines to the best of my knowledge.

D. Bal

DMF 32 interfaces have got modem signals on both 0 and 1 not on the 6 lines on the same board. How do I put the modem signals on those 6 lines?

Andy

The DMF supports modem control on port 0 and 1 only. If you use the other ports on a switched connection you are running at your own risk.

D. Bal

The risk is that this is an undergraduate teaching service. You know the challenge of the undergraduates to explore the system and wreck it if they can possibly do it, and it hampers our resources time and time again to sort the things out. Hence the requirement.

Chairman

The next one is batch checkpointing with 785 votes.

Andy

VAX-16

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

This SIR is a request to be able to stop and resume long running batch jobs in case the system needs to be shut down for whatever purpose and the considerations are obvious. When you have a batch job that runs for a number of hours or a number of days, perhaps even weeks, you cannot afford to lose that investment in time on that particular job if the system either crashes unexpectedly or needs to be shut down for any reason.

we have been hearing about the desire for this ever since we announced the future existence of the VMS checkpointing facility which I think must be close to two years ago now. That's part of the data integrity features that we are working on for future VMS releases. we have had the checkpointing facility, that is what we have implemented on VMS, pretty wel ready to go for a while and it was a casualty of the deferment of the journaling facility. It turns out that checkpointing makes use of recovery units which in turn makes use of journals and as a result of that set of dependancies we have not been able to ship checkpointing yet. We do intend to ship checkpointing some time in the near future and it will be followed shortly thereafter by the checkpointing facility.

Now I need to point out that the checkpointing facility that we intend to provide is not going to be as fully general as people would like. The reason is that saving and restoring the state of a job is a very difficult problem and the more transparent you try to be about it the more difficult it gets. We started with the level of dealing with assigned channels and open files and the address spece and things like that, that we felt were doable. However, when you get to the level of saving the complete DCL context when you have a job that has IOs that might be currently in progress and other side effects of that sort, things start to become extremely difficult and we found it necessary to defer that set of problems to another time.

So there are a number of restrictions that will be in effect on the initial checkpointing capacity. The job must declare checkpoints by itself, you cannot from an operator terminal enter a command that causes the job to be checkpointed, the job must be checkpointed itself. It must request the checkpoint voluntarily. Secondly the job cannot run in the full DCL environment; it must be run as a separate process by itself. It is obviously not the best that people would like but it is the best that we felt we were able to build at this point and we are going to continue to look at this. Comments or questions?

Chairman

The last of our top five was the request for disc quotas by groups.

VAX-17

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Andy

This SIR requests that quotas be allocatable by groups of users, that is, by the group field of OIC as well as by the individual OIC. The primary rationale of this appears to be that people want to allow disc space to be charged to, say, a project as a whole rather than to the individual members of that project, since presumably the file space in question is owned by the project at large rather than by the individual people. Now in V4 we have provided the identifier mechanism that allows the assignment of arbitrary project groups and arbitrary project membership, membership in multiple projects by one person and related features. One of the features that goes along with that mechanism is the ability to charge disc space to a project identifier. This means that you can assign an identifier to a person with resource priviledge and that allows that person to create files owned by that project identifier. To make use of that, then, what you would do is set up a project library directory where the directory file is owned by the project identifier. Access control lists make that directory and the files in it accessible to the project members and the file ownership defaulting rules in the file system will cause files that are created in that project directory to be owned by the project identifier, provided that the person creating the file holds the project identifier with the resource priviledge. I guess my question to you is: Did we do it right? Is this what you wanted?

Questioner (no name).

We are using this feature with partial satisfaction. It is fine as far as it goes, but if you have somebody using one of these identifiers with resource attribute, each individual user still needs a disc quota of their own. It is required by some of the utilities like the sort merge and certain Dataretrieve functions. So irrespective of the fact that you can have this group accounting, each individual still requires their own disc quota.

Andy

That's correct for things like temporary files, effect belong to the individual user. So you that you would also like just for simplicity of to hand out the quota to the group rather than to persons. Thank you, we'll take that back.

New questioner.

files that in are suggesting authorisation, the individual

Yes, we made use of this to try and set up a project account. It had several side effects with some of which it didn't actually work. In the book, I can't remember which guide it was, it sets up the file ownership with the file ACL with "no

VAX-18

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

propagate" so if you then edit your file it doesn't propagate the access control list and you lose touch with it.

Andy

Let me just explain for those of you who are not quite so familiar with the mechanism. In a circumstance like this, where the file system creates a file whose ownership is not the OIC of the person creating it, the file system automatically adds an access control list entry to the file that gives the creator access to the file. That is based on the principle that you really ought to have access to what you just created. That access control list entry is marked with a no propagate attribute so that it is not propagated to future versions of the file. I believe that is actually the right way because every time a new version of that file is created the access control list entry that grants access to the creator will in fact be added to it. What that means is that for the general project accessibility to the file you have to make sure that the file's access control list otherwise grants access to the project but if we did not mark the ACES no propagate, what would happen is that as different individuals created different versions of that file, the ACEs would pile up. Every time somebody created a new version, we would pile up a new access control list entry that granted access to that new person and we felt that was just incorrect behaviour. So rather you get full access to the particular file instance that you created and you rely on the project access controls for the general access for the project.

Questioner

So you are actually saying that you can't edit the file. It means the user that created that file can't successfully edit that file.

Andy

No, that should not be.

Questioner

As he edits that file he creates the higher version of course. And it is that higher version that does not propagate the ACL.

Andy

That's right. It does not propagate the access control list entry that we put on it. Rather, it gets a new one, which is appropriate to the person that has created that new version.

Questioner

VAX•l9

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Then maybe there is a bug hanging around certainly does not progogate anything. identifier on the ACL but not the owner.

Andy

in 4.1 because it It has the project

Okay, yes, something is wrong. There are some other wrinkles. If you are running with something like sysprv then also we don't put it on. The rules are somewhat complicated but they are complicated to work right in the greatest number of cases.

New questioner

I have installed this facility, too, and I have had a lot of problems. You have to be very careful if you edit this feature for files or directories which no longer exist, because if the users are allowed to edit under this new identifier, they have the files and if they first change the owner, they can do nothing with the file. So they first have to add the ACEs and then have to set the owner and if they don't do it this way they always come to me as system manager and say, "please give me access to my file". The other difficulty we had: the normal user who is allowed to access disc space via such an identifier cannot see the used disc quota of the identifier. So if the quota command says "no privilege" for a certain operation, the only way is to give all users access to quota so every user can see this quota for every other user.

Andy

That is an oversight which we should fix.

New questioner

I was going to ask the same point because I have found the same problem: you cannot find out the quota. But in addition, the previous comment about the propagating ownership. When the file is edited by different users with a version limit on the disc, say version limit of 5, when the sixth edit is done you can't get out of the edit because you can't delete the sixth file.

Andy

Okay yes, because you don't have permission to delete the file and .• I guess my answer to that is that the project access then should be giving you permission to delete the file. It simply means that you have to set up your project access control lists correctly for that to work.

New questioner

VAX-20

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Is there any way of stopping that behaviour of the new access control list? Is there any way of preventing the access control list entry being added on creation of the file. Because it also gives control to the creator. We have applications where we would like a user to be able to create data files but not be able to delete them or change any attributes of the file. Is there any way of stopping them doing this?

Andy

At present, no, there isn't. We will have to take that back as a suggestion. I would suggest that if you want protection behaviour different from the default that you make use of the VMS services to make the file protection what you want it to be. There are any number of services available to you so that you can set the protection to what you feel is right and override whatever the file system does.

Questioner

It's a long way round, though, isn't it.

Chairman

Thank you

Alan

To all those of you who sent in responses to the SIRs, thank you very much. If you have ideas for new SIRs please send them to your chairman or to Peter, and we will try and do the same thing next year. I will send for publication the top 5 of the replies and list all of the votes to the Pageswapper so you should see that in a few months time. Thank you. Over to Peter.

Peter

Before you go Alan, we would like to thank you very your hard work. Now. The busy part of the evening. to call out the names of the questioners.

Christiane Letertre, CERN. VAX VMS 4.1

much for I am going

we have a problem with quorum disk in a cluster. Each time the system was rebooted we got the disc improperly dismounted. Is that normal or did we do something wrong?

Peter

This is something which a number of us have had. I get it with RM05s. I think it must be normal.

VAX-21

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Andy

Do you have any kind of error messages that might indicate that the rebuild on the disc in question is failing?

Christiane

We do not. Apparently the disc is good.

Andy

Obviously the disc will get rebuilt and will require rebuild any time a node crashes in the cluster. Are you also seeing this when you reboot after a perfectly normal shutdown?

Christiane

When we reboot after a normal shutdown.

Andy

And you are running 4.1. It does not sound completely normal. I can't really say very much more about. It does sound as if something is out of phase in the volume storage control block. That is where we track the information about whether the volume needs to be rebuilt or not. We do that by keeping track of the count of the number of nodes that currently have the volume mounted and that is supposed to be reset by the rebuild function. If the rebuild function is not properly resetting that value then the volume will rebuild every time you mount it. About the best I can say is that we will have to take that back to see if we can identify any problems.

Mr Dramer

We have had the same problem, but we made a backup and cleaned the disc. We put 5 backed discs with BACKUP/IMAGE and we have not had any problems up to now.

Andy

That certainly suggests to me that there is something in the storage control block that is not properly being cleaned out by the rebuild. When you copy the disc with Backup the storage control block does get completely rebuilt, and so I guess I would suggest taking that approach and seeing if that clears the problem. That also gives us some additional information as to what might be wrong.

Questioner

VAX-22

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

I would like to add that it has nothing to do with clusters because we had the same thing on a perfectly normal RM03.

New questioner

Could I say that in the 4.2 documentation it indicates that at least some instances of this have been corrected.

New questioner

As a note I have found that if your quorum disc is not your system disc a normal system shutdown does not dismount it. That could be the cause of the problem.

Andy

Ordinarily simply marking the disc for dismount should be sufficient to clear the bits in the storage control block but again I think we will have to look at it.

No 2

What could be recommended in between the time between now and the eventual standard utility that could become available to reorganise discs without backup-restore actions.

Peter

At present what we recommend is shutting down the use of that disc and doing an image backup, meaning either a disc to disc image copy or if you don't have a second disc to do an image save to tape and then stand-alone backup image restore from the tape back onto the disc.

Questioner

And if you want to provide a 24 hour service?

Peter

I have to admit that is not possible and we don't have the ability to do that at present.

No. 3 Anders Lyngarth, TSL data, Sweden. MONITOR, SHOW DEBUG. VMS 4.1

I have a question about how to implement foreign terminals on the VAX VMS 4.1. I have tried it by way of using the module in sys examples called SCRFT.MAR which is the same module as the VMS 3.x. The module doesn't work as is stated. Where could one find information on implementing foreign terminals, if SCRFT.MAR is obsolete? Or is there an error in SCRSHR? It could be said, too, that the SMG$ routines don't work as the documentation

VAX•23

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

suggests in defined foreign terminals.

Peter

The old SCRFT was always an undocumented unsupported interface and although in V4 there is an attempt to make it upward compatible I have heard at least a couple of reports that it is not 100% upward compatible. We do recommend that with V4 you use the SMG foreign terminal package.

Anders

I do that, but DEBUG doesn't use the SMG.

Peter.

Correct. It is going to take VMS a while to get its utilities using SMG. It will take us a while. We have had that requirement from US DEC users as well. You mention here that there are problems with the documentation. We are aware of several of those problems and there are a couple of bugs in 4.0 and possibly 4.1 that are being cleaned up in 4.2.

• Anders

May I mention one thing. If you have another terminal with the line drawing character sets consisting of two characters you define the line drawing characters in the SMG document as strings which only yields the first character and that is not a string. What have you changed between V3 and V4 in the SCR interface?

Peter.

In the SCRFT? The old screen package, the SCR entry points still exist in V4 but the code that is behind them is completely different. Although the intent was that they be replacement routines, it was a total rewrite from MACRO to BLISS so things like counting on R6 having the right data structure pointing to it and things like that which people did do is not true when it was rewritten in BLISS and that was what gave most people problems. There was a data structure which was around most of the time which was what people used.

Anders

Okay, so I will close the openings for foreign terminals to work as display terminals on VAX for the moment. Until you come up with the utilities ••

Peter

VAX•24

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Correct.

Anders

Do you know how long this will take?

Peter

No, it probably won't happen at the same time, we move our applications to SMG as time allows. One been suggested is that an ambitious customer SCRSHR with a SCRSHR which called SMG and via could get things that called SCR really calling would get the foreign terminal support.

Another voice

will thing could that SMG

probably that has

replace route you then you

I believe DEBUG for 4.2 is now using SMG. You could talk to the people downstairs at the software house tomorrow morning to make that sure but I believe DEBUG for 4.2 has been converted.

Anders

I thought it a little bit funny because you said it was totally new but it didn't use SMG. Wasn't the DEBUG totally rewritten for V4.

Answer

Yes it was, but it was considerably rewritten before the SMG package existed. It was a timing problem.

No 5 Harneit Jeus

How can I have an SYLOGIN that is effective for users that log in both under the DCL CLI and MCR? If I am using a system wide log in procedure I cannot write it only for DCL.

Andy

What we normally recommend is that you define SYS$SYLOGIN to point to SYS$MANAGER:SYLOGIN and leave off the file type. What will then happen is the CLI will supply its own default file type for opening the command file, DCL will use .COM and MCR will use .CMD, and that you allows you to have separate login files for each one, and then you can either make them functionally the same, one in DCL, one in MCR, or you might have completely different ones, even an empty case if you didn't want it.

No 7. A Marriott. Contraves Ag. Zurich

VAX-25

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

How may a program at run time define a process permanent message file to supplement the existing system messages? That is to achieve the equivalent of the DCL "set message" command.

TAPE ENDED HERE - ANSWER NOT ON THE TAPE.

No. 8 Cino Crepaldi; Germany

Under RSX there is a command $SET TERM/SLAVE. We have a couple of Perifold devices connected via terminal to VMS and we would like to break that protocol between username and user authorisation failure when you reboot the system. And you added index file support to DCL, however how can I delete a record in these index files?

Peter

The answer to the first problem is SET TERMINAL/NOTYPEAHEAD, one of the more intuitive DCL commands. The action of turning off typeahead disables the login. The second question was how can I delete an ISAM record from DCL. I don't remember the syntax. There is a way to do it. It may be something like a qualifier on the read command or something like,

.comment from audience ••

Peter

It is WRITE/DELETE. I know it is there because we use it on some of our own DCL hacks and so it is a matter of perusing the manuals. The READ and WRITE commands are the only ones that DCL operates on at that level so it has got to be a qualifier to one of those two.

No. 9 Drozak, Belgium. VMS 4.1

When you use the shut down command it asks you if you want to spin down the discs. If I answer yes to the question all my discs spin down except the system disc.

Peter

We can't spin down the system disc. The problem is a kind of "you can't get there from here" situation. The problem is that the system disc remains in use until very, very late in the shut down process. The very last phase of the shut down process involves making sure that all of the modified pages on the modified page list are flushed back to the backing files on the disc. This is particularly important when you have had user processes that have had files open as global sections or whatever. Obviously you want to make sure that the global sections are properly written back to the files. That is done in the very last phase of shut down by the OPCRASH utility

VAX-26

program.

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Immediately after that OPCRASH does a bug check. We write out the system dump file and again you might argue that it is not necessary to write out a system dump file for an operator shutdown. On the other hand there is one piece of information that must be written out which is done using that mechanism and those are the error log buffers. Once we are into bug check we no longer have the regular system disc driver available. In fact, the bug check is even written out using the boot driver, which is what we booted the system with and the boot driver does not have the capability to spin down the disc, so - to make a long story short - by the time it is possible to spin down the system disc, we no longer have the ability to do so.

Drozak

Well can anybody help? Because I must stop my machine when there is nobody in the room and I am afraid to stop the power on the machine when the system disc is still running.

No 10 (no name)

One of my users used EDT to edit a directory file and EDT got confused and the directory got corrupted so I have a directory file that I cannot delete.

Peter

Despite the documentation, this is the purpose of the SET FILE/NODIRECTORY command. This command was specifically put in place to allow you to delete a corrupted directory and you issue that command naming the bad directory file. That clears the bit in the file header that identifies that file as a directory. Subsequently you can delete it and then reclaim the files under the directory with ANALYZE/DISC. The documentation for SET FILE/NODIRECTORY has been fixed in 4.2.

No 13 W P Ingenegeren. Utrecht. VAX/VMS 4.0

This has happened to me today, I demonstrated it. Some people are told they have new mail when they log on but there is no mail. It looked almost as though it was counting pages and decrementing files. I have been receiving these questions, mainly SIRs, from the VAX info file and I have been getting ••• when I finally finished I think I had six more mail messages but no mail.

Andy

I can't point to the specific event that might have caused this problem. This problem can result because the new mail count is not stored in the mail file. In VMS V3 it was stored as a field

VAX-27

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

in the authorisation record. In VMS V4 there is a separate file called VMSMAIL.DAT in SYS$SYSTEM which is MAIL'S general purpose database file. The new mail counts for all of the users are stored in that file. Obviously if that file gets out of sync, somehow with an individual's mail file (which might happen, for example, if somebody cpanges system discs or boots the system off a different system root at some point) then the mail count will get out of phase~ The way that you reset the mail count is to do a READ/NEW .when there are no new messages and that wi 11 force the mail count back to zero and get it back in phase.

NO 12 Mats Jansson, Sweden

I have tried to make possible to print out in both 6 and 8 lines per inch through DEFINE/FORM with set up file that does the necessary things with the printer. I have found that it was not possible to define the reset module to be printed out at the end of the printing at the form. It was necessary to do this at the queue. I think it is not what you always want, a blank page at the end of every file printed. I want to have a switch on the DEFINE/FORM to make it possible to just after this file with this form to reset the printer. Is this planned or must I reset after every file in the future?

Peter

You are sending a setup module?

Mats

Yes. On V4.l.

Peter

And what is the content of this setup module? escape sequence in here?

Mats

Yes, defining a number of lines on the printer.

Peter

Is there any text in that set up module?

Mats

No.

Peter

VAX-28

Is there an

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Just an escape sequence?

Mats

Yes.

Peter

I believe this problem is fixed in 4.2. We have a problem in which the symbiont should recognize the fact that it is receiving strictly a setup sequence and there is no text to be displayed on the paper and it is still saying, "I have received more than zero characters therefore I need to issue a form feed to get to the top of the form".

No. 13 Sally Antill, Vickers Design. U.K. VMS 4.0

Do DEC really believe that it is acceptable to remove commands and system services in a new version? And to change commands such that command files, etc., uddenly give errors?

Andy

I would like to see a more documented example of what the problem is.

Voice

She mentioned this in her session. One of the examples was in the MAIL utility where the EXTRACT command replaced the FILE command. She used the FILE to extract mail now it is EXTRACT to file.

Andy

Yes, we changed the command in mail. Certainly in DCL in system services I believe we have been as careful as we can possibly be to preserve compatibility between releases.

Comment

With the exception of the INITIALIZE/QUEUE command where you change the /PRIORITY to a /BASE_PRIORITY. It makes no sense.

Andy

The fellow who did that is no longer with us ••• (LAUGHTER)

Peter

With regard to /PRIORITY and /BASE PRIORITY I think the rationale for making that change was-that in V3 the /PRIORITY qualifier was used to mean two distinct things: the relative

VAX-29

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

schedule and priority of a job within a queue and also the execution priority of that job. We got a lot of SPRs and questions at DECUS sessions where people were getting that concept confused, and I think that was one of the motivations for making that change. I can't read the guy's mind ••

Andy

Every once in a while we do make a change in behaviour. MAIL for example: I use the excuse that we really were presenting a significantly different MAIL version than we had in V3. You can either accept that or not as an excuse. In other circumstances, we have made some changes and they have often been by substantial popular request. One of the ones that I recall was changing the default setting of /REWIND in Backup. I think from the general level of feedback that we got, I believe that the change was right. The level of complaints when we made the change was actually relatively low. I was pleasantly surprised.

Comment

May I give a comment on the MAIL thing we just discussed? In V3 VMS when you use the FILE command you create a text file which is in fact a mail file with a form feed at the beginning. So if you wish to print it you just print it. But if you use the file command with the same name it in fact creates a folder and a lot of people using V3 do not know this. So if you type "FILE", then message 1, 2 and 3 with the same file name, you will notice you don't have the message file created because all these messages are added one after the other and in fact the file command creates a folder. With V4 VMS it also creates a folder.

Andy

Frankly my comment is that I wish the person who implemented the MAIL facility were here to speak for it. Bill tells me that he (Ben Schreiber) will be here tomorrow morning.

Comment

All the layered product people - they had a Q&A already today if questions come up during the VMS Q&A for the layered product people, of which Ben Schreiber is now one, they can be directed tomorrow on the demo floor.

No 14 Qar 357

Since we run a fairly open shop (being a large international scientific lab), we decided not to implement password lifetimes, so these are set to zero in the UAF. Recently, however, a neighbouring system had a malicious break-in on an account where username=password. So we decided to issue all future accounts with pre-expired passwords. We found that indeed all new

VAX-30

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

accounts were marked as pre-expired but VMS did not care. No warning message on login, no requirement to change the password, nothing. Only when we made PWDLIFE non zero (we chose 3650 days) did pre-expiry do what the documentation says it should dC>. Either this is a bug or the documentation should be changed tC> point out that the pre~expiry flag depends on finding a non-zero PWDLIFE.

Andy

That is a cute little wrinkle that had not occurred to us and we will take it back.

NO. LS Eva Larsson, University of Stockholm VMS 4.1

The problem I seem to have with my VAX 785 might be very site specific but may be interesting if someone here has come across it before. As I said I have a 785 which is equipped with one Unibus, 8 DZll and 96 Emulex DMF32. This worked fine under V3.7 but now on V4.l there seems to be a problem with hanging. If there are more than 35 users on the system, eventually the processes will hang one after the other until the entire system is hung. You can't get through the Emulexes, nor even the console. The only way to manage this is with control•P and rebooting the system. This is very irritating as it happens something like 3 times a day. I have heard at a computer conference system that there is a machine in Germany and another in U.S. which seem to have the same problem. At least they have similar symptoms.

Peter

I think every system in the U.S. that had either Emulex or Able ports started hanging when V4 came out. In V4 we enabled a feature that DMF had but we had never turned on in V3 called auto xon/xoff which allows the hardware to do the xon handling. DMF apparently had had the bugs fixed by the time we got to use it., and Emulex and Able had never had that feature turned on and hangs occur with that situation. It is my understanding that both of the companies have been very good about giving out new microcode to people who had those boards and you should probably contact your company. Another work-around that we don't have a whole lot of faith in, but seems to work (we don't have Emulex boards, that is why I seem to hesitate), is there is a special SYSGEN parameter, TTYDEFPORT, not DEFPROT which is default ptotection but DEFPORT which is a port control word. If you set the low bit of that •••

Eva

We were aware of this before installing V4.l so that is not a problem.

VAX-31

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Peter

You still get hangs. I guess take a crash and send us dump.

Eva

I have spoken to the entire system department in DEC Stockholm and they seem just as puzzled as I am. The problem is new even to you?

Andy

In the problem description you said you find a long XQP queue, meaning which queue? Are you talking about a request queue inside a particular process?

Eva

Yes. I am not very good at VMS internals but if you look at the system dump analyser at the crash dump you can see that the request IO queue is empty and the request XQP queue is normally empty as well but when you force the crash you get quite an amount of requests queued up in the XQP queue.

Andy

When I read the problem description I started thinking of something altogether different. we have noticed that a good way to get the entire system bottled up is to have the disc driver subsist and lose an IO on you. When this happens, chances are very good that it is a file system IO. What happens then is that the process who is executing the file function that is responsible for that IO obviously hangs in the middle of whatever they are doing. They are presumably holding some set of file system synchronisation locks. Any other process which subsequently comes through a similar path in the file system will then get hung behind that lock and, for example, if that is the volume allocation lock you are guaranteed to bottle up the system fairly rapidly. Now the way you would backtrace that is to look at all of the processes making no progress. Do a SHOW PROCESS/LOCK on a couple of those to identify what they are waiting for. The file system locks are all identified by a resource name beginning with FllB. Take one of those locks, do a SHOW RESOURCE/LOCK=, giving the lock id. That will tell you who is holding the lock. Then you go to the process who is holding the lock, again do a SHOW PROCESS/LOCK on that, to establish what that process is waiting for. You may have to trace through several levels of locking dependencies. Ultimately you will find a process who has no lock dependencies who is waiting for some other reasons. One of the things to look for here is a busy IO channel. See if there is an IO outstanding, then look at the device to which the busy channel points and see if you can find either the stray or stopped IO

VAX-32

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

packet. If you want to go to that level of chasing, that is what you can do. Alternatively if there is a stray undiagnosable hang, it should come to us with an SPR.

Peter

When your system is in this state do your terminals echo control O, output on, output off? Does that work?

Eva

No they don't.

Peter

That happens at driver IPL. Sounds like hardware to me, like it is the Unibus. If the system is hung in the Andy is describing it is going to be looping at a lower the terminals will be able to do output on, output off. can't do that your system is sick.

Comment

sounds way that IPL and If they

I have had the same situation. I switched off the Unibus and it didn't help anything. I have Emulex only on one Unibus and I switched it off. Bill Travers told me it would help but it didn't. It must be something different.

Comment

We also have this beast called Camak. It causes us many problems. This is a SYSGEN configuration map of the Unibus of an 8600 with Camak on it and DMZ lines. What we don't understand is that at TXB it jumps up from vector 320 to 450. Then it carries on up to 600 where it overflows onto the Camak and gives us a hardware problem. What I would like to know is: How does autoconfigure work and could anyone explain why it suddenly jumps from 320 to 450?

Peter

Your question is: Why do the interrupt vectors go from 320 to 450. Well you got me. I don't know (much laughter). I wrote the code (more laughter) • If you configure your system like that, does it ever configure?

Questioner

This is autoconfigure.

Peter

VAX•33

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Is that a show configuration or is that the result of ••• ?

Questioner

That's AUTOCONFIGURE ALL. I looked at the drivers manual and there were some very strange devices which had very peculiar names with vectors in that area so I did exclude these devices and it made no difference. Where can I look? Do you test the vectors?

Peter

Everybody in VMS is on SYSGEN some time or another. We test CSRs. Vectors just kind of follow along merrily. The computing of the interrupt vectors is really quite simple. It's just is there a device here ••• no •..

Questioner

That could be a clue because this Camak thing has a large number of CSRs.

Peter

That's the little CAA device down at the bottom.

Get rid of it! (much laughter)

There are a couple of things you can do when you are debugging these configurations. There is a SHOW/UNIBUS command. Do it on hard copy because it is going to generate a lot of output. It gives a complete map of what AUTOCONFIGURE sees and how it makes its decisions. Also when you do AUTOCONFIGURE, you can do AUTOCONFIGURE/LOG and if you see any strange devices pop up •• 5 line printers, its devices found that if it doesn't find a driver, if it is not a supported driver it doesn't complain.

Questioner

We actually figured that out and we do see 5 line printers so we exclude line printer.

Peter

You have got things set up in such a way that you are confusing autoconfigure.

Questioner

What devices have you got in that space, between 320 and 450.

VAX-34

Peter

PAGESWAPPER ~ April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

It is not the vectors that are doing that.

Andy

I think there is a jump in the CSR space there between the two. What AUTOCONFIGURE is doing is seeing CSRs there and thinking there is some line printer device, and it is also allocating vector space as it is allocating those devices. It goes to load the driver, finds there is no driver, this is an unsupported device, just keep going.

QLiestioner

So I actually have to configure by hand every device.

Tony

A follow up to this very problem. We have a KMSll-PX, the single line version of the KMS 11 and if you do an AUTOCONFIGURE ALL it very intelligently loads the XS driver whereas PSI requires the XN driver. So I did what I did on V3 which had the same problem and I did AUTOCONFIGURE ALL/EXCLUDE=XS. It then loaded the XN driver. At that point I gave up excluding devices and I had to do an AUTOCONFIGURE ALL and select each individual device which seems to defeat the purpose of AUTOCONFIGURE ALL.

Andy

The algorithm that SHOW/UNIBUS uses, it sniffs around through Unibus IO space and does a test word on a particular location and if it finds something there, if memory responds, then it says ah ha, you're a DZ, because it knew what it was looking for at a particular location. If your special device is in a range of CSRs that AUTOCONFIGURE looks at then it is going to confuse AUTOCONFIGURE. There are user reserved CSR locations which are up above the line printer locations.

No 17 Jan Schoubo, Denmark

I should like to modify the print symbiont with the new PSM$PRINT routines and write an input field in Pascal. I have not yet met anyone who has actually done it although Larry Kilgallen says he has some people working on it now. Are there any reasons why it should not work, writing this program in Pascal, rather than the example in the manual which is in Macro and doesn't work.

Answer

VAX-35

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

I know of customers that have written a modified symbiont in Basic and FORTRAN but I don't know what the problems might be in Pascal.

Jan

Could this end with the suggestion at least that a better example might be in high level language next time.

Answer

Actually that is on our work program to do that, to give a high level language example. You are right that the Macro example does not work and we are trying to get that out in the next update.

Jan

Has anyone in the audience modified symbiont?

No 18

Now that the VAX has moved into the mainframe league with clusters and 8600s which require somebody to do a system manager function, it ought to be possible for this system manager to manage mag tape resource allocation. The currently available tools - REQUEST, REPLY, MOUNT and ALLOCATE - do not provide this sort of function in the way that most people want to do in a large tape shop.

Andy

We are well aware of the shortcomings and are in the process of working up a design for a tape management facility and the like, so we intend to provide that kind of capability in future versions of VMS. I can't make any promises yet as to how long it is going to take us.

NO 19 Niall Mansfield, Heidelberg VMS 4.0

In some applications and in languages like Pascal and C, but especially in C, you would like to write a primitive that deals with relative files, you would like to say, "Get me block N", or something like that. The SYS$SPACE primitive gets you a block relative to where you are now and the question is is there any way to get a relative block from the beginning of a file without closing the file and reopening it? In other words you don't want to have some global datastructure telling you where you were because you are going to call this primitive from all over your program.

VAX-36

Andy

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

You want to simply present a record number to RMS and read that file. If I remember my RMS correctly, you specify key to access and give the relative record number as the key. The capability is definitely there. Try and catch me tomorrow and we can go through the manual. When I use RMS I usually go to the manual.

No 20. Mats Jansson, Sweden

We now have the restart feature on batch jobs. Would it be possible to write a program in a way to make it restartable if you have a very large computation?

Peter

We agree that is a good idea and we will take that back with us. DCL does communicate that information, translates the restart value call into a send to JBC system service call so you should be able to use that supported interface.

N0 21 Sally Anthill, Vickers WPS/+ utility

Why are all the keys in different places to KED & EDT? Are there any plans to fix this? If not, why not?

Peter

The KED and EDT were built with different targets in mind and really what we are promoting is TPU as the new editor and TPU has the capability of remapping the keys. So does EDT for that matter, so they could set up EDT to look like KED. Is the person who asked the question in the audience?

No 22. Mike Waters Rutherford Lab, UK

Identifiers again. I have set up lots of identifiers as they come out of authorisation, two in particular: one called AC750E which is set to [l,*] and identifier 750E which doesn't have the AC in front of it, set to [1,45], or [45,45] and then trying to RUN/UIC=[AC750E,750E] and it fails and CREATE/OWNER=[AC750E,750E] also fails trying to parse that string. If you use that string on something like DISKQUOTA it works fine. It seems to be things with an identifier starting with a numeric character. It is not clear whether it doesn't always fail.

Andy

Well we will have to take that back. I think I can tell you at least where the problem lies. The problem is that the identifiers and the symbolic UIC expressions are parsed in a couple of different places. The place that is accepting it

VAX-37

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

properly, that is allowing you to get it through DISKQUOTA, is the $ASCTOID security service. The place that is not working is the command line parsing in DCL which does not apparently accept all of the identifiers that it should. I will take that back.

No 23. G P Kristjansson, Iceland, RMS utility

My programmers claim that there is no way to scroll or step backwards in a keyed RMS file. They make a mirror key, they take keys and convert them so when they want to scroll backwards the program always looks at the mirror key. But it is no solution for my programers - they are very heavily loaded.

Andy

The answer to that is that we are working on that feature. In case some of you didn't hear the requested feature is to be able to read in opposite key order in an RMS ISAM file. We are workin~ on that feature and expect to have that available in a future VMS release. It is not in 4.2.

No 24. Peter Holderman

Written software can make use of the system communication service for a high speed task to task communication inside the VAX cluster.

Andy

At some point in the future it may be possible. At present it isn't, for a couple of reasons. First of all we do not provide driver access to the system communications layer. Secondly we do not even document it at present and the reason is that the SCS protocol at the moment is a very new design. We do not yet feel comfortable at the moment with its stability. We suspect that the SCS protocol is going to change at some point in the future as we discover new requirements. In addition there are some interesting security problems. The SCS protocol is a system internal protocol and as such has no security controls on it. Obviously that may not be a concern for a real time application.

Questioner

This is not a problem for a communication class driver. For instance for a standard conventional driver there is no security at all.

Andy

The point is that certainly we would feel uncomfortable at providing user QIO access to the SCS protocol. The difference between that and writing a user driver is of course that the

VAX-38

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

user driver is of course installed by the system manager. That is somewhat different than our just providing access to this internal layer of the system. We have had a number of requests to make scs public and so we understand there is a lot of desire for it. At present you might consider seeing what you can get out of the CI DECnet, whether its performance would be adequate for your needs.

No 25 Daniele Cuzin, Schulberger EPS, VMS 4.1, 4.2, MSCP utility

We have a problem on a cluster of four machines with local discs. Two of the machines still have local discs and we have not found the right way to boot those discs. In fact when we boot all the cluster the local discs boot on their own machine and all the other machines but if one of the machines which has a local disc on crashes or is stopped then when we boot that machine the local discs on that machine are not recognised by the other machines. This is a problem because we have users on both machines on those discs and the only solution we have is to mount the discs manually. Is there another way?

Andy

I do not completely understand the problem but from my experience with clusters I would guess that what is happening to you is that on the other systems that are making use of this local disc that is served by the system that has gone down, is that those other machines are timing out mount verification. Mount verificiation is the process that holds IOs to a disc base temporarily unavailable until that disc becomes available again because, if disc IOs were held, any lock dependencies that potentially pile up behind those can also cause other processes to hang and, in general, if they are not resolved in some way can end up with significant parts of the system bottled up. We do have a time out on mount verification and I forget exactly what the default is but it is somewhere between 5 and 15 minutes. If that time out period is shorter than the time it takes for the system serving those discs to reboot and get those discs back in service, then mount verification will time out, the IOs will be failed and the only way to recover the disc is in fact to dismount and remount it. So to prevent that problem what you have to do is set the sysgen parameter MVTIMEOUT to be greater than the length of time it takes one of the systems in the cluster to reboot - greater plus some safety margin.

No 26

I have got a distribution medium from decatel with a recoverable read error on it but VMS install aborted installation. Is it necessary to abort installation if it is a recoverable read error?

VAX•39

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Andy

I would call that a bug in VMSINSTAL and I would take that back. VMSINSTAL intercepts the messages that come out of Backup in the process of restoring the product save sets. It does that so that it can detect certain specific conditions and from what you say it sounds to me like it is not properly handling those messages coming out of Backup. I agree that if the error is recoverable it should allow you to install the kit.

No 27 h. Kennedy, Oadweald Ltd VMS 4.1

I was looking at some of the code structures and on the terminal CIA$. That was compound intrusion find out where KGB$ comes from and

Andy

on security services data driver came up with the name

analysis. I am curious to where NSA$ comes from.

You are wondering what possible justification did we have for picking those acronyms. KGB is the structure prefix name used for the rights database records and it stands for "key grant block". NSA stands for "non discretionary security audit". The best one of all, which you may or may not have stumbled across is the break-in detection list that is maintained by login, those blocks are called CIA which stands for "compound intrusion analysis".

Questioner

Thank you very much, at least someones got a sense of humour!

Andy

Thank you! We haven't quite figured out yet what to do with OSS and NKVD.

No 28 Kurt Jensberg, Switzerland

We used on VMS V3 the utility "wat". DEC, but from DECUS library probably. available on V4.

Andy

I know that is not from Is there anything similar

To the best of my knowledge there are versions of WAT floating around the dee engineering net that has been pretty thoroughly upgraded to V4 so my guess is that the fellow that wrote it has it running on V4 and just needs to be motivated to release the new version to DECUS. The guys name is Stanley Rabinowitz. Perhaps write to Stan through DECUS and see if you can persuade him to ship a new version. It is a DECUS item and not a supported part of VMS.

VAX-40

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Kurt

Are there are plans to integrate that into VMS and make it available to everybody. We found it very useful, especially in real time application and when you want to look at different parameters from different processes it helped a lot and we had problems for example with ast limits that were too low and processes just hung and with this utility at least we found the problems.

Andy

We have no plans at the moment to incorporate into VMS, certainly it is worth taking back as a suggestion, either that directly or similar capabilities. We would want to look at what that is providing that some of our existing facilities are not.

Bob Real, U.S. Air Force in Germany

I can answer that for you. DEC Munich has taken the old V3 of WAT and completely modernised it to completely support on V4. It is offered through Franfurt free of charge, you can get in Franfurt or Munich. It has complete window encapability, along with supporting of just about every function you have under the normal SYSUAF. You can display interactively on the new WAT.

No 29 Daniel Cuzin TA78 utility on cluster

We have upgraded a TU78 to a TA78 and we have discovered that some IBM sysmic tape cannot be read on the TA but could be read on the TU and apparently the application program which reads the tape uses a code on the TU and we do not have any documentation about the TA.

Comment

I think we can help you, we have drivers put some garbage on don't discover it, using Digital on a Digital mag tape station says thats garbage and skips it.

Comment

the same problems. Some active the beginning of the tape. You tapes but if you write the tape and go to the IBM, then the IBM

There's another possibility and that's the famous byte swap problem. The TU78 drives post byte swap, the TA controller and TMSCP protocol do not support byte swap.

Daniele

So that means we have to write a program to do the byte swap. Why is there not a program.

VAX-41

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Answer

As for the documentation I cannot answer that. The TMSCP protocol which is supported on HSC controllers, does not support byte swap, I mean, why not.

Peter

We can take that back for documentation.

Daniele

I have another question. Is it possible to dual port a TA78 on 2 HSC50.

Andy

At present VMS will support static dual porting of the TA78 meaning that you can hook it up dual ported to the 2 HSCs but we will handle the tape drive correctly only if you have only one of the ports enabled at any one time. VMS does not yet support the proper coordination of the two access paths, so if you are willing to use it in a static sense and just change the port switches manually, should one HSC go down and use it on the other, then you can use it that way. Do not use it with the ports set up in both port positions because in effect VMS will then see two ta78s in its IO data base, not recognize that they are the same and you will have resulting confusion.

Daniele

Do you plan to enable VMS to be able to support two.

Andy

It has been suggested, it is one of the things we are considering in the future.

Voice ?chairman

Two things. First of all we have a TA driver dual ported to 2 HSCs and it doesn't seem to cause problems. But it is static. The other thing was, you said you had taken this back to documentation. we would prefer you took it back to your developers and changed TMSCP to support byte swapping. We have a requirement for that.

No 31 Johan Hamaker, SRZM, Netherlands VMS 4.1

I frequently use spawn/nowait/notify/output as some log file to do for instance little compilation jobs and that sort of thing. Since we have started with V4 I find these jobs die as if they have had a heart attack! At unpredictable moments. When you

VAX-42

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

look at the log file you sometimes see that the compilation has been done but then after compilation has been stopped, another time you will see that it has done a compilation and a library replacement. Then it has stopped. Sometimes it will run right through, sometimes it won't do anything at all. Now somebody suggested that there might be a problem there with pooled file quota or something like that. That does not sound unreasonable except in that case I would expect to find an error message in the log file and I don't.

Andy

You are saying that there is absolutely no message in the log file at all; it just arbitrarily stops. We have not made any changes in the way, for example, file quotas or log quotas or anything like that are handled. On the other hand with some of the changes in RMS the same file operations in V4 require a greater enqueue limit. It is conceivable that having gone to V4 your job is running out on enqueue limit or something like that and for whatever obscure reason the error is not being reported •••

Voice

Could he be running into the control Y problem being delivered into the subprocess and then they go away and if you don't know that happens you have to say input=LAN0, otherwise you spawn and you are doing something else and you completely forget this if you are used to V3 and you hit control y and the sub process is blown away and you never know it? Or am I misremembering something?

Andy

I wasn't sufficiently familiar enough with spawn to realise that was even a problem. But that is an interesting point.

Johan

But wouldn't that problem have appeared on V3 as well.

Answer

No, we wrote the way control-Y asts are delivered to avoid that problem actually. There were a good deal of trouble in V3 with out-of~band characters and spawn processes and we did a good deal of work to clean that up. It may be that there is a hole there. I suspect if there is that the DCL person has gotten complaints and by 4.2 it will be fixed. If you still see this in 4.2, try and get a little more data together to send us.

VAX-43

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Johan

I would have been willing to send an SPR but idea what supporting documentation to send.

No 33 Jaume Sole, G.D.S., Barcelona VMS 4.1

would have no

It's a dual system, 2 VAXes 2 750s connected with Ethernet. System hangs for 2 to 3 minutes. After doing nothing, activity continues normally. During the hang there is no control c, no control y response, no echoes prompts, no user name prompts, no spool activity, typeahead does not work meaning the characters are lost.

Andy

The fact that the typeahead characters are being lost means that the system is going into a loop at rather high IPL. Jake suggests that it might be a false power fail problem, something to that effect. It is conceivable that the Ethernet interface is misbehaving and is causing the driver to become sick which in turn might cause a lot of execution at driver IPL which is the kind of thing which would block this activity. To analyse this sort of problem, we really have to catch the system in the act, force a crash and then analyse the crash dump.

The other thing to look at is, if possible, does the problem persist while the net is shut down, something like that, see if you can isolate the cause by isolating components.

No 34 (no name)

In VMS 4.1 there was a patch to COBRTL.EXE which I believe is part of VMS not COBOL that fixed an apparent buffer overflow problem in display verb. The fix increased the buffer allocation from approximately lk to 64k bytes on the user stack. I have an application that multithreads with a p user stack stuffed in a global section. The problem is that my TSC say that this fix is not a problem. I find 64k of stack for an output buffer is a little bit excessive. I think it's ECO no 1. Incidentally perhaps the guy who wrote the patch should have started out on PDPll then he would appreciate what 64k bytes were.

Andy

Unfortunately organisation library, so I and basically

we have no representatives here from the responsible for either COBOL or the run time think the best we can do is to take your comment ask them what's all this then.

VAX-44

No 34

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Just as a side point on the same matter, is there any other thing that any of the panel know of that is COBOL from a user program which will allocate an excessive amount of stack.

Andy

There is none that I know of but then I am not familiar with most portions of the run time library in general. The code in the base VMS system and most of the base library modules allocate stack that pretty much amounts to what they really need.

No 35 (no name)

A machine having a UDA50 and a Versatec 121 DMA interface on the same Unibus regularly clashes with all sorts of different bugchecks. Field service say this can be caused by an incorrect delay setting on the UDA. Have we got a hardware man that can tell us what a delay setting could be doing.

Panel member

My first answer! Depending on the memory band within the buffering characteristics of the device, if the device under question does not have sufficient internal buffering it is possible for UDA to dominate the IO bandwidth of Unibus. There is a setting on the UDA which is hardware settable to delay the time that the UDA will vie for arbitration of the Unibus. By default I believe it is set to 6.2 microseconds which means that it will pause for that length of time before arbitrating again to gain control of the bus. It could be that the other optional settings are zero microseconds and 10 microseconds. I think it is worthwhile for the hardware service representative to have a look at that and make sure there is sufficient bandwidth left for the other devices on the Unibus.

No 36 Peter Humble, Leicester University

From time to time we get problems with an interactive user running a job which really ought to be a batch job and is just aitting there in compute for hours and hours on end, somewhat ··ogging the machine. With the exception of restricting the CPU time available to anybody, in the SYSUAF for example, or spending some time whenever we see it has happened to try and find out who has done it and sort something out personally, is there any mechanism to make it difficult for them to do this sort of thing, and if not, would it be a good idea if something was in there, for example some sort of dynamic lowering of base priority for people who didn't do any io to a terminal from an interactive job.

VAX-45

PAGESWAPPER ~ April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Peter:

Well the system does have some dynamic lowering of the priority in that when you do IO you in fact get a priority boost. Now obviously whether this is a serious problem or not depends on how you have your: batch keys configured. If you are running your batch queues at a lower priority, let us say priority 3, then clearly doing heavy compute down work for an interactive session would constitute abuse of the system because it would seriously interfere with the batch jobs. I think the real solution for: this requires a class scheduler which is something that would actually allow you to allocate CPU time in a proportional way between the service classes. That would in fact allow you to make sure that an interactive user could not get more than a certain share of the CPU. we are looking at that kind of scheduler for future VMS versions. At present what you can do is put a CPU time limit into the users UAF record which limits the amount which he can accomplish in one login session and then override that with a larger CPU limit on the batch queue, so that jobs requiring larger amounts of CPU must then be run through the batch queue. Of course the other thing that you can do is filter the accounting records, looking for interactive logouts that have accumulated a large amount of CPU time which is what you referred to in terms of chasing after the matter: personally.

Comment

It has been noted to me that some people put ACLs on certain images so that they only can be run from batch so if it is running the compiler for: example, and you don't want compilers run interactively, you could put an ACL on the image for: the compiler:.

Questioner:

Unfortunately it is nearly always the users own application.

No 37 Ugor Er:gun, Turkey

My company is the representative of DEC in Turkey. One of our customers wants to use C for their transaction processing. Is it easy (as in COBOL) to handle RMS organisations in c. How does C compare with COBOL.

Andy

It is not that difficult to do RMS from C and the documentation is pretty good. C will work in the transaction processing product that we support acms so I think all that is possible and not that difficult.

VAX-46

No 38 (no name)

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

How is it possible to make printers (connected via serial tty lines) available from other VAX systems connected via Ethernet?

P.nswer

I think all I can say on this question is that we have some work going on to potentially extend the capability of the lab server to support remote printers, such that a connection could be established from that host but that support is not here currently.

No 39 Terse Grevle, Norway VMS 4

When will the function 'delete to end of line' be implemented (or is it already)?

Peter

Probably never. It was not a matter: of being so much code or something like that but the work that we did with our line editing staff was the result of a human factor: study done within Digital for: what novice users need to get by with the system editing functions. All of the things that we did were based on that study. Although it is not as powerful as EDT there is not as much code there. We think we have a good balance between usability and the functions that we provide so we do not plan at this time to add any more functions.

Andy

One of the things that I would like to add is that one of the results that came out of that human factor: study is that one of the important aspects of the command line editing was that it be simple and therefore it was important that we only provide the minimum set of functions necessary and not clutter up the keyboad with a lot of fancy editing functions that people would not use very often.

No 40

This may be a hardware problem but I will go anyway. I have an VT200 which I use in VT100 mode because thats all my iden will support and I have to login into some DEC systems which do a SET TERMINAL/INQUIRE. And SET TERMINAL/INQUIRE on a VT200 in VT100 mode sets the terminal to VT200 and my terminal starts speaking me in Swedish. I have enough problems in English, I can't answer: in Swedish. If the VT200 is set to VT52 mode and you do SET TERMINAL/INQUIRE it stays in VT52 mode. Where is the bug.

VAX-47

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Peter

The VT200 tells us even when it is in VT100 mode that it is a VT200 and so VMS says ok, you are and if it is in VT100 mode becomes a VT200. We do that because it is the only way that the characters that SET TERMINAL/INQUIRE sets up can be truthful, it tells us that it has soft characters and various things and unless we force it to VT200 mode we can't really guarantee applications that those characteristics are there. We complained to terminals engineering about the design and they didn't listen to me and the VMS group. The customers complain and they listen to the customers, so you can get a v2 of your VT200 microcode which will allow you to change the set up to answer back VT100 when it is in VT100 mode. So contact your local office.

Comment

Do not change our terminals because they turn into English! (Swedish gentleman).

No 41 Jean Yves Le Poec

Have you got any plan to support Ethernet on stand-alone Backup. If you crash the MicroVAX you have to reload up the 50 floppies and Ethernet stand-alone Backup you would only have to load stand•alone Backup and then take it over the Ethernet.

Andy

We do not have any plans to do that. The real problem with that is the amount of mechanism necessary to get the network up. To use the Ethernet in stand-alone Backup we need a lot more than just the NI driver, we also need all of DECnet because that is how Backup accesses its files over the net. I think at that point we also need RMS which is not in stand-alone Backup. We end up with a large number of system components that are currently not there and I think all told we would probably about triple the size of the stand-alone Backup kit and if you think booting it off tu58s is bad now .•• What it boils down to is that stand-alone Backup runs in a very restricted environment and any changes of that sort require very substantial extensions to the environment which are of a magnitude as to be impractical. In terms of MicroVAXs on Ethernets failing and getting the software serviced we are looking at some other options. I think it is premature to talk about some of the things we are thinking about but there is work going on in that area.

No 42 Hans Magneson, Sweden VMS 4.1

VAX-48

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

On our system we have set up the printer with the flags feed and flag page and when users want to get rid of this flag page then they qualify no flag but nothing happens on the printer, it still has a flag page.

Peter

Then you initialize a queue there is a qualifier called /SEPARATE which takes a key word list and it can take a flag burst trailer type keywords and this represents the flag burst and trailer pages which will be put on the job. On a job wide basis. There is a separate qualifier on the queue commands /DEFAULT which takes the same keywords and this pertains to the file level flag separation and trailer pages. Now the print command also has these qualifiers as distinct qualifiers including feed and it is able to override the setting specified with the /DEFAULT qualifier on the XNIT QUEUE. That is, your print command can override the flag on the file level separation page policy but it can not modify or change override that which you have set up for the job.

End of tape, part of speech missing.

Continues in middle of speech.

- because of the buffer, I am guessing but that is probably what it is. The host system where you set host to is probably in the same range, it is the QIO that the application does which it is going to have to do anyway and then a DEC IO every now and then but that is not even a QIO, thats an internal !RP mechanism which is very efficient. I don't think that the overhead is that severe, especially with V4 so I wouldnt worry about it.

Comment

Just a couple of additional comments with file transfer. The overhead on our micro? 70 for doing a sustained file transfer operation, I am talking about say a thousand block file where you are not worried about the overhead for opening and closing and connection and all that stuff is really not too bad. I am trying to remember this. On 2 780s with Ethernet connection where there was nothing else really going on, I was able to get sustained file tranfer rate of approximately half a megabit. The maximum that you can get with task to task file transfer is a little over 1 megabit over Ethernet cable. You are really limited by the transceiver. Now there is a special case, and that is with MicroVAX in that there is a end to end CRC check done between RMS and the remote file and on the MicroVAX, MicroVAX 1 in particular, where the CRC structuring is emulated it can soak up quite a few cycles on a systeme file transfer for that MicroVAX. But then again you are probably in a single user mode there and it is probably not that important for you.

VAX-49

PAGESWAPPER ~ April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

Also, just on file transfer is that there is a parameter, SET RMS DEFAULT command that you can use to specify a parameter called network block count I believe and that is a parameter that RMS uses to determine how big a QIO it should issue when doing a block mode file transfer and I think we set that to 8 blocks by default which is quite sufficient.

No 45 G S Bal, University of Liverpool VMS 4.1

The terminals which used to log out and drop the lines do not work on V4. Earlier a mention was made parameter TTYDEFPORT and if I heard it correctly, you lower bit value to l. If I were to do that can assurance that it would restore the behaviour of the handler to the same level as it was on v 3.

Andy

on the V3 of system set the

I have an terminal

It restores the behaviour with respect to the class doesn't tell the port driver to turn on auto xrx. you think your problem is.

driver, it Is that what

G. Bal

My problem is that if the terminal is switched off and the lds box switch is switched on and the contention device my session stays on but I would like to terminate my session.

It used to work on the 3.7, if you could hold the line independently for 25 to 30 seconds the system used to kill the process, which I could control from the contention device, not activate that device for the next 30 seconds.

A~y

Okay, basically you are saying that the gandalf hangs up but the VMS doesn't. There are no known problems in this area in VMS and haven't been since V2 I believe. Anything that is a hang up problem is generally traced to a hardware or wiring problem. There is one thing you could modify, that is tty dial type. If you set the low bit of that it shortens the amount of time that it actually cancels the terminal drivers debouncing of carrier signal, so that if it sees carrier go at all it will drop the line.

Larry

There is a problem associated with the upgrade to V4 in that it destroys your default modem settings in your default hang up settings and everything if you had them in the default characteristics word for the tty. It could just be in the transition that those things need to be set up again, in your default terminal projections.

VAX-50

G bal

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

All the lines have been set up with modem signals and even we tried the other day with a /DISABLE, and that didn't work either.

Andy

This is a thing where you really have to get a breakout box and play with the signals and get a field service tech out there to check your wiring and that sort of thing.

No 46 N. K. Mooljee Edinburgh University

Some computer systems that I know and very often in a university environment keep a record of terminal dialogue between user and computer in a physic file if the user so chooses. Is DEC seriously considering this question or the provision of such a facility for interactive users and is there a way of getting round this problem at the moment.

Andy

SET HOST/LOG 0, which will log you in on the local node and keep a log file of the events that happened while you were logged in.

Nerris

And this is a user facility which any user can use.

Andy

As long as you have DECnet running. That is a part of DECnet you can use without having the DECnet licence. SET HOST/LOG 0, no name, just gets you back to the same node and that will allow you to do that. It turned out easier to do it there than in the terminal driver so that was the quick fix.

No 47 P V Diennen ITT, Netherlands

I think it is question pertaining to the REPLY/LOG. We try to print out the operator log at daily intervals and we do that by a batch job that runs daily. If the operator logging is active you can't print the file so we have to re open the file using REPLY/LOG. This is not working from the batch. It returns successful but it does not do anything. In a desperate moment I turned on all privileges but it doesn't help.

Andy

I don't see anything on the face of it why this shouldn't work. we will have to take this back. Shouted comment, couldnt hear it.

VAX-51

ii

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Andy

The comments from the floor are that the REPLY/LOG command must be entered from an operator terminal, that is a terminal that has been enabled as a operator terminal and obviously a batch job is not enabled as an operator terminal. The work around for that is that the reply command uses the logical name SYS$COMMAND to direct what the operator terminal is that it is working against so by doing a logical name definition, say, define SYS$COMMAND OPA0: I believe you can make that work. For example thats how we enable OPA0: as an operator terminal from the system start up file. Because the system start up file is in effect a batch job, we do a define SYS$COMMAND OPA0: REPLY/ENABLE so I am not going to guarantee it but it sounds as if that is the sort of thing that should solve the problem.

No 48 no name

When we reboot 8600 after a crash or a shutdown/reboot we get the message "micro"code not up to level required for VMS" we watch it and it continues to boot and seems to run okay without any problem. So we called in our engineer and he said it's okay it's not a problem, but we had him check it out and he came back and said the CI microcode is too advanced for VMS. So we changed it for an old version of CI microcode and in the next boot the message was still there. We did notice that when you do a boot from the console in console mode the message does not appear, We would like to know where the message is coming from and should we worry about it.

Trudy Matthews

It has nothing to do with the CI microcode. Actually VMS during bootstrap will enquire of the CPU (in the 8600) that the console keeps the microcode version and so we enquire of the console what the current microcode version we expect. However there is a bug in the 8600 console microcode which will be corrected with the next update of the 8600 console microcode in that at times, and I can't even remember under which circumstances, it will give us back a wrong value for the microcode. But it is really safe to ignore that message.

Again, end of tape, part of conference missing.

Continues:

Andy

How much of a program is this that is required to reproduce this.

VAX-52

Questioner (unknown)

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer session

Well unfortunately some of the tools were written some time ago and we don't have the original source code for it. Program is about 700,000 lines of FORTRAN.

Andy

Boy you got me. The only idea I have is get it in that state and take a crash dump and send us the details of what the application is trying to do in terms of qios and so forth, the general philosophy behind the program maybe. And also include which DZ line was hung so we don't have to go all through the dump trying to figure out which terminal line was hung, that is a big help, and we will take a look at it, but it doesn't sound like the kind of thing we will be able to track down.

Questioner

Our operators tend when they shut down the machine, to start using carriage returns, and when you are in a cluster environment and you do that, if you don't type in "REMOVENODE" then you end up with a hang in that cluster until they all decide that that node is indeed shutting down. I recommend that you put a little check in the shtudown and if the node you are shutting down is a cluster member, make the remove node the default.

Comment

I have a comment on this gentleman's question. I have some problems with a DMF32 port, the first two ports on it have the full modem control and I have also a small problem in the source code, but it won't run on the first two ports of DMF32 because of some changes in the driver. I have had spoken to the field service engineer and he was pretty sure that the changes in the driver were the cause of my problem. I have changed to another port.

Andy

Do you know offhand what the rev level of your DMF is.

Commenter

No.

Andy

There are no problems known with the current VMS V4.

VAX-53

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Commenter

Actually I can fix it in my program, quite easily, I have to do something which I didn't have to do earlier, so it was just an inaccurate program at first and so now I have to improve it a little to make it work on the first two ports. It may be that the problems look alike.

Andy

It is my understanding that very old versions of DMF like rev c or rev d of the microcode in the DMF did have the same XON/XOFF problem but if you are on a field service contract you should be way beyond that at this point.

Another comment (no name)

I have a similar problem with a DZll port hooked up to a 240. Under certain circumstances, especially when it is in VT52 mode the VT driver crashes the VAX, and it does it consistently. It works for a while and then all of a sudden several pages of garbage are sent to the terminal and it crashes.

Andy

We fixed some strange conditions in the DZ driver, I think it was in 4.1 but maybe it's 4.2.

No 58 (no name)

In a cluster when one member dies members are stopped for a while. that dead time.

Andy

for any reason the other What can be done to decrease

In this case are you actually getting a crash, or is it stopping and rebooting?

No 58

I booted one voluntarily to see what happened on the other one and the other one stopped doing anything for 50 to 60 seconds.

Andy

When you simply stop and reboot a node, one of the problems that you can run into is that the CI port hardware has a 99 second timeout on its virtual circuit. Usually an unjam command on a 780 will break that virtual circuit. However, lets say the operating system simply hangs or something like that, then there is a 99 second timeout in the CI port, after which the CI port finally gives up and decides that its processor is dead. That

VAX•54

PAGESWAPPER • April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

time out can not be modified ••• microcode. So the best you can do is that time out. For example when particular, give it an unjam command down the CI port and eliminates that that you are right, the next time interval so you can shorten that up the time it takes to fail the machine

No 58

it is built into the CI to try to avoid hitting

you reboot a machine, in which immediately shuts

time out interval. Beyond out is the reconnection and then that will shorten out of the cluster.

Is it a problem, to shorten down this value?

Andy

The only problem that you can run into is that you increase your exposure to things like transient power failures or potentially transient communications failures, lets say, something goes wrong for a few seconds with the CI communications or lets say that the machine looses power for a very short period of time. Normally we ship it with reconnection intervals set up so that a very brief power outage will allow the machine to remain in the cluster. Of course the problem is that while that machine is out the rest of the cluster has to wait for it to come back. If you take the other option of shortening the reconnection interval, then if the machine takes a power failure, it will immediately leave the cluster, but it cannot re-enter. It means that the machine must then be rebooted, even it managed to survive the power fail. That is really only the significant negative effect of shortening re connection interval.

No 61 Bojan Dremelj, Yugoslavia, VAX/VMS 4.1

Why does the error command not work as it is described in the help facility?

$help errors ••• for a more detailed explanation of the error and suggestions for error recovery, type error followed by the ident portion of the error message •••

$error ident ••• %dcl~w-iwerb, unrecognised command ••• /error/

Andy

That certainly sounds like we left some loose ends in our help file. The help files are prepared by our documentation group, we will have to take that back to the documentation group and ask them what is going on. I think what has happened is that you have been led astray by a very minor error in the help text.

Clearly the way it should work to find help on a particular error message is that you should say •• "help error" and then the error identification rather than simply error identification.

VAX-55

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

That doesn't work either.

Trudy Matthews

According to the UK TSC it never did work and the entry pointing you up to it is removed at V4.2.

No 63 W Kegel, Dynaflow Software Systems, Holland

I have processes having sysprv privileges for various reasons and up to V3.7 those processes were creating files specifying uic [0,0], they would be created on the user's account. As of V4 they are created on the owner of the directory instead. My question is this a temporary process or is it going to go away.

Andy

This is an intentional change. This is part of the new ownership and protection defaulting rules in the file system. In general, we felt that it made more sense to default the file ownership to be the ownership of the directory that you are creating the file in, provided that the person creating the file has the privileges to charge space to that UIC. For example what that does, is it allows the system manager to create a file in some user's directory and have that file be owned by the user. This is the sort of rationale, we felt it was a more consistent way for things to work. We apologise for the inconvenience. We made the change feeling that a greater number of users would benefit from it.

W. Kegel

Then I would suggest that you do something about your documentation because your documentation just says that you need sysprv to create a file on another account on your own but it doesn't state that if you have the privilege it will be done.

Comment

The documentation was fixed in 4.2.

No 65 Larry Kilgallen VMS 4.2

What is the policy regarding distribution of VMS 4.2 source kit updates?

Andy

There will be V4.2 source kit. The project leader was still banging getting the thing to build properly.

VAX-'56

last I heard, the 4.2 his head against the wall,

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECOS Question and Answer Session

Larry

That's a technical question Andy. The real question has to do with whenever it happens.

Andy

It is our intention in the future to provide source kits for the functional updates.

Peter (I think)

For 4.2 in particular, I believe it is going to be an update to the 4.0 source kit as opposed to a remastered source kit.

Larry

What I am really trying to do is dance around the issue of prices. People who already bought a 4.0: get this .••

Peter

forbidden Will they

We talked to our product management about that, we being the people worried about trying to put the kits together.

Larry

I have the greatest faith that they will get the kit together, it is just getting it out to the field that I am questioning.

Peter

It is under discussion from what we can see and there will be resolution shortly.

Andy

It turns out, Larry, that I was just recently looking in the price book about source kits anyway and noticed that even for 4.0, the upgrade price from V3 is considerably less than the price of a new source kit, so without knowing any of the details, never mind mentioning them, I would guess that we would do something similar.

Larry

To repeat something that has been said before, regardless of how much money you hope to make out of source kits, it would be a lot nicer on our end if it were a monthly charge that we pay forever, because we can sell that to management. We never know when VMS is going to come out and having to, all of a sudden, when the stuff comes out, run in and get a purchase

VAX-57

PAGESWAPPER - April 1986 • Volume 7 Number 9 European DECUS Question and Answer Session

authorisation is a lot more cumbersome. Certainly with doc sets we pay a certain amount per month, never knowing how many pages we are going to get per dollar how often, and if a similar policy could be instituted for source kits it might be nice.

Peter

That is a very good suggestion and we are looking at some of the licencing policies and that is one of the alternatives.

Larry

Someone else in the organisation might like an even revenue flow as well, regardless of whether software is produced, and that is one way to do it.

No 66 (no name)

We occasionally have processes having an outstanding read on the mail box and we then ask them to terminate by means of a $FORCEX system service. That worked fine until 3.7 but then all of a sudden those processes didn't go away any more. Instead they returned an IO error which, after the usual fiddling around, trying to convert a FORTRAN IO error to a system service error, we found to be "activity precludes operation" and the exit handlers are never activated any more. Can you explain why?

Andy

You are using RMS to read the mail boxes?

No 66

Implicitly. It is a FORTRAN read.

Andy

I don't remember the details, I know we went through some mayhem in getting RMS rundown to work correctly and I know it has been changed several times. It has to do with RMS keeping track of whether or not there is IO on a particular RMS open file at the time you are doing rundown. The problem is, you enter your exit handler and you are now attempting to do IO on an RMS channel that already has IO pending. I believe what is likely to have happened in 3.7 is that they tightened up some of those checks, where you used to get away with things that maybe you were lucky with, but in other circumstances can crash RMS and I know we have been tightening up the checks on that sort of thing recently.

No 66

VAX-58

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

I am pretty sure that it doesn't enter my user written exit handlers. All those processes have one, I force one to be there by doing LIB$INITIALIZE.

Andy

I think we are going documentation on that. deal with here.

No 66

to have to have an SPR and some I think it is too complicated for me to

I did a work around by using a $DELPRC instead which worked fine.

No 67 Bengt Eriksson, Stockholm County Council, Utility: Backup

Normally when a user makes a mount request that request is of course spread round to all the terminals that have been enabled as operator terminals but when I perform backup, and especially backup onto a tape station which requires many reels of tapes, Backup issues the message

%BACKUP-I~READYWRITE, please mount next volume

or something like that, but that message is not broadcast round to other terminals. That has the consequence that I as system manager have to be in the vicinity of the terminal or the console from where the backup is invoked. It would be very handy if I could sit in my own room and just go into the VAX every now and change tape reads. Is that possible?

Andy

That is a worthwhile suggestion. Backup in fact has the logic in it to use the operator request for tape mounts and at present it is coded so it only uses that when you run it in a batch job. I think that is a worthwhile suggestion, we have heard it in the past, that there at least be a qualifier to cause it to use the operator messages for tape mounts. It was done the way it was done originally, based on the assumption that things like multitape backups would most likely be done by operators who would be logged in near the tape drive anyway. That assumption holds true in many cases but obviously not all.

No 69 David Roberts, Univ. of Leicester, VMS 4.1 mag tapes.

I have no need to ask the question, because the question was answered in a different form earlier on.

No 88 (no name)

VAX-59

PAGESWAPPER - April 1986 - Volume 7 Number 9 European DECUS Question and Answer Session

This one is so simple that I am sure it must have been asked before in some context but I did not hear the answer. Is there ever going to be in SYS$ACTIVATEIMAGE service, which will do just the image activation, nothing about creating processes or spawning etc?

Andy

Obviously that service exists and so what it really boils down is when are we going to get round to be willing to document the thing. The answer is as soon as we feel that we have the interface to that service frozen. We have in fact changed the interface to the image activation service a couple of times as we have added features to the image activator. Because we feel that the interface is not fully stable yet is why we have not documented it. Obviously documenting it means committing to that service. We do plan to stabilise that at some point in the not too distant future so that we can document it.

No ·88

Would it possible to map images and call them as subprograms but we couldn't recover the space?

Andy

What you want to do is recover the space after the image. That turns out to be very very difficult. At least from the point of view of the system, because once you have activated a sharable image or whatever and called into it, there is really no way for VMS to tell that that image has become truely idle. It is possible for it to have any number of ASTs outstanding for example, because of terminal driver events or whatever.

No 88

Is that true if it is a subprogram?

Andy

Well no, thats not true because subprograms can have side effects that last way beyond their invocation and about the only thing we can recommend is that, in the case where you have done that, you know the piece of address space that that has been loaded into. If you want to get rid of it do a $DELETVA on that address space and then it is your responsibility. Then something has gone wrong. In fact you del€ted the address space when the thing that you were using was not fully idle and that is exactly the kind of problem that we feel unable to solve.

PAGESWAPPER - April 1986 - Volume 7 Number 9 VAX System SIG committee List

VAX System SIG Committee List

As of January 8, 1985

Osman K. Ahmad - Large Systems Integration Working Group Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616

Joe Angelico - Assistant Symposium Coordinator US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA 70130

Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660

June Baker - Advisor Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046

Joe L. Bingham ~ Librarian Man.tech International 2320 Mill Road Alexandria, VA 22314

Bob Boyd - Commercial Working Group GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709

c. Douglas Brown - Security Sandia Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185

Jim Caddick - VAXcluster General Datacom Strait Turnpike Middlebury, CT 06762~1299

Jack Cundiff - Symposium Coordinator Horry-Georgetown Post Office Box 1966 Conway, SC 29526

VAX-60 VAX-61

PAGESWAPPER • April 1986 - Volume 7 Number 9 VAX System SIG Committee List

Tom Danforth - Handout Editor woods Hole Oceanographic Institute Woods Hole, MA 02543

Jim Downward - Migration and Host Development, VAXintosh working Group KMS Fusion Incorporated 3941 Research Park Drive Ann Arbor MI 48106

Jane Furze • Campground 3830 West Cochise Phoenix, AZ 85064

Dennis Frayne - Real Time/Process Control working Group McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646

Carl E. Friedberg - Internals Working Group In House Systems 165 William Street New York, NY 10038

Don Golden - Communications Committee Representative c/o Shell Oil Company Westhollow Research Center Post Office Box 1380, Room D2132 Houston, TX 77001

Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693

B. Hancock - Network Working Group Dimension Data Systems, Incorporated 2510 Limestone Lane Garland, TX 75040 (214) 495-7353

Jeffrey s. Jalbert - Historian J c c Post Office Box 381 Granville, OH 43023 614-587-0157

Ray Kaplan - MicroVAX Working Group Pivotal Incorporated 6892 East Dorado Court Tucson, AZ 85715

VAX-'62

PAGESWAPPER - April 1986 - Volume 7 Number 9 VAX System SIG Committee List

Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139•0901

Margaret Knox • Chair Computation Center University of Texas Austin, Texas 78712

Art McClinton - Advisor MITRE 1820 Dolley Madison Boulevard McLean, VA 22102

Ross w. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202

Eugene Pal - Multiprocessor Working Group US Army CAORA (ATOR-CAT-C) Fort Leavenworth, KA

Susan Rehse - System Management Working Group Lockheed Missiles 3251 Hanover Street Palo Alto, CA 94301-1187

Bob Robbins - Advisor Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582

Larry Robertson - Real Time/Process Control Working Group Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA

David Schmidt - LUG Coordinator, Hardware Working Group Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232

Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693

D. Slater - Artificial Intelligence Working Group Institute for Defense Analysis 1801 North Beavregard Street Alexandria, VA 22314

VAX-63

PAGESWAPPER - April 1986 - Volume 7 Number 9 INPUT/OUTPUT

INPUT /OUTPUT

A SIG Information Interchange

A form for INPUT/OUTPUT submissions is available at the back of the issue.

INPUT/OUTPUT 486

Caption: TeX DVI post-processor for terminals

Message: We are looking for a way to direct TeX output to a terminal, rather than to a hardcopy device. Ideally, this could be routed to a high-resolution graphics terminal (i.e., Tektronix 4107), but support for ANSI (VT100) terminals would suffice (not supporting special features, just the text). Does anybody have this capability or has anybody heard of it?

Contact: Mr. Brian R. Shamblin Medical Sciences Building Mayo Foundation

Date:

200 First Street Southwest Rochester, MN 55905 Telephone (507) 284-4069

February 12, 1986

VAX-64

[Q] DEC US

LIBRARY

DECUS PROGRAM LIBRARY

NEW LIBRARY PROGRAMS AVAILABLE FOR THE PROFESSIONAL-300 SERIES OF COMPUTERS

DECUS ORDER NO: PR0-148, Title: KERMIT for P/ OS, Version: December 1 985

Submitted by: G. Thomson, PRAXA, Jolimont Vic­toria, Australia, 3002 Operating System: P/OS V1 .7. Source Language: MACR0-3, Memory Required: 512 KB

Abstract: Kermit-11 on the PR0-3xx allows for a stan­dard form of file transfer from these systems to about 120 other implementations of Kermit on other sys­tems, including the PDP-11, VAX, DECsystem 1 0/20, Rainbow-100 and other manufacturers equipment.

Two versions are provided - one menu orien­ted and the other command driven.

Sources not included Documentation on magnetic media

Media (Service Charge Code): One RX50 Diskette (JA), Format: Fl LES-11

NEW LIBRARY PROGRAMS AVAILABLE FOR THE DECmate II

DECUSORDER NO: DM-110, Title: DECmate II& Ill Games, Version: 1.0, December 1985

Submitted by: Digital Equipment Corporation, Operat­ing System: OS/278 V2.0, Source Language: BASIC, Memory Required: Standard System

Abstract: Tired of processing words and spreading spreadsheets? Then you are ready for the" DECmate II & Ill Games Diskette". You can play Blackjack (watch it; the computer might cheat), possibly be king for a day (don't forget to feed the people), or travel through space(look out for the Klingons).

This menu driven package brings you some relief from the hassle of the everyday routine. Everything you need is on one diskette. Just boot it up and ENJOY!!!

Remember, all input must be uppercase (use the LOCK key).

Complete sources not included.

Documentation may or may not be on magnetic media

Media (Service Charge Code): One RX50 Diskette (JA), Format: OS/8

NEW LIBRARY PROGRAMS AVAILABLE FOR THE PDP-11 COMPUTER FAMILY

DECUS NO: 11-817, Title: SETDTM - Set Date and Time Utilizing Digital Pathways TCU-150 Clock, Ver­sion: V1 .0, November 1985

Submitted by: John C. Gibbons, Macedonia OH, Operating System: RT-11 V4.0 or later, Source Lan­guage: MACR0-11, Memory Required: 581 Words Special Hardware Required: Digital Pathways TCU-150 UNIBUS Clock

Abstract SETDTM is a program designed to read the Digital Pathways, Inc. TCU-150 battery operated UNIBUS clock and set the system date and time accordingly under the RT-11 V4 or later monitor.

The TCU-150 has the hardware capability of providing the Julian year, month and day as well as the hour, minute and second. Leap years are accoun­ted for by the TCU-150 in hardware as well.

This program employs a unique feature in that it also provides for an optional Daylight Savings Time (DSl) set-ahead (typically in the Spring) by manually setting a storage location (DSTFLG) in this program to a non-zero value. This allows the user to account for the time change WITHOUT resetting the clock registers in the TCU-150 directly. Leap years are also accounted for when there is a month roll-over for the DST calculation. Indirect command files are pro­vided with th distribution to accomplish the task of changing from Standard Time to Daylight Savings Time and vice versa.

Constants are also provided in the source lis­tings to accomodate the use of either the 50 HZ or 60HZ line frequency clocks. The distribution has both 50 HZ and 60 HZ versions already compiled for the users convenience.

Documentation on magnetic media

Media (Service Charge Code): Users Manual (EA), One RX01 Diskette (KA), Format RT-11, 600', Mag­netic Tape (MA), Format: RT-11

DEC US NO: 11-818, Title: Programs from 'Statistical Computation', Version: December 1985

Submitted by: J.H. Maindonald, Applied Maths Div, DSI R,AucklandNew Zealand, Operating System: VAX/ VMS V4, RT-11, V5, Source Language: BASIC-11, Memory Required: (MULREG& NORMEO) 185008, other programs much less

Abstract Apart from one omission and three additions (marked with*), these are the programs listed in chapters9and10 of Maindonald, J.H.(1984): 'Statis­tical Computation'. Wiley, N.Y.

LIB-1

Included are:

• MULREG and NORMEO:Thesetwoalterna­tive programs use modern algorithms to han­dle multiple regression calculations. MULREG uses Givens rotations, avoiding NORMEO's explicit formation of the normal equations. There are minor improvements on the lis­tings in 'Statistical Computation'.

• GAMMA*: Evaluate log n'

• GAUSS*, GAUSS1, GAU1 2, GAUSS3, GAUSS4, and GAUl5: These approximate the cumula­tive normal or its inverse.

• CHIS06:Approx1mates the cumulative chi­square distribution.

• TDIS7 and Tl NV8:Approximate the cumula­tive !-distribution and its inverse.

• F* and FDIS9:Theseapproximatethecumu­lative F-drstribution.

• FDIS10: Approximates the non-central F­distribution.

• BINLIM:Approximate binomial confidence limits.

• CORREL Confidence limits forthe product­moment correlation.

• SVD:Singular value decomposition, using Nash and Lefkovrtch's modification of method due to Kaiser.

Documentation on magnetic media

Media (Service Charge Code): One RX01 Diskette (KA), Format RT-11, 600' Magnetic Tape(MA), For­mat RT-11

DEC US NO: 11-825, Title: Plot Calendar, Version: V1 .0, December 1 985

Submitted by: William W. Sugg, Defense Mappping Agency, St Louis MO, Operating System: RSX-11 M V3.2, Source Language: FORTRAN 77 Memory Required: 25504 Words, Software Required: Versaplot Sub­routines Special Hardware Required: Versatec Plotter 8236 or larger

Abstract: Plot Calendar(PC) will plot a 12 month calen­car on a Versatec or similar plotter. PC will accept years from 1583 to32766 and a leap year check will be made for whatever year rs entered. Each month will be plotted to a size of 8.75 inches rn the X drrectron and 9.00 inches in the Y direction. The plotter must have a minimum X plotting range of 50.0 inches and a minimum Y plotting range of 32.0 inches.

The user is allowed to annotate from 1-365 days of the year. Each day may have up to 6 lines of annotation with up to 15 characters per line. PC runs on a PDP 11 I 44, RSX-11 M version 3.2 operating system and with the Versaplot software version 07, edition #5, dated October 1978. To run the PC program, 25504 Kwords of memory are needed and two files are generated when the an­notation option is picked.

Restrictions: Plotter must be able to plot at least31" in Y direction and 50" rn X direction.

Documentation on magnetic media

Media(Service Charge Code): One RX01 Diskette( KA), Format: FILES-11, 600' Magnetic Tape (MA), Format: FILES-1

NEW LIBRARY PROGRAMS AVAILABLE FOR THE VAX/VMS FAMILY OF COMPUTERS

DECUS NO: VAX-152, Title: MOVE PASSWORD Utility, Version: November 1985

Submitted by: Tom F. Coe, Naval Weapons Center, China LakeCA, Operating System: VAX/VMS V4.2, Source Language: MACR0-32

Abstract Software Required: DECnet (non-licensed single-node operation is adequate)

The MOVE PASSWORD utility permits a user to move a system generated password from one account to another across DECnet With this, users can have the same system generate password on several accounts, yet still obtain a new system gener­ated password for all these accounts whenever de­sired, without assistance from a system manager. Either a primary or secondary password can be moved from any account requiring passwords to be system generated, if the user knows the password to be moved and the password to be replaced. Certain other re­strictions are also enforced. Password expiration dates are not extended.

The included DECnet remote server does not provide passwords or encryptions to accessing nodes, only limited information and status.

The utility and remote node server each com municate only with nodes which are listed in special files.

Restrictions: Source code patch (as described in documentation) needed for VMS releases other than 4.2. (For mapping to a VMS copy of the password encryption routine).

Documentation on magnetic media

Media (Service Charge Code): 600' Magnetic T•pe (MA), Format: VMS/BACKUP, Blocked at8192

LIB-2

DECUSNO:VAX-153, Title:"DEP' DEC ENC- Decrypter/ Encrypter, Version: V1 .0, December 1985

Submitted by: Soft-Keyz, Cameron MO, Operating Sys­tem: VAX/VMS V4.1, 4.2 Source Language: VAX-11 FORTRAN

Abstract:" DEP' permits a user to decrypVencrypt any VMS file with a record length less than or equal to8180 bytes. The "DEP' is best utilized in internal security.

A minimum 10 character key must be provided for encryption and although there is no maximum number of characters which a key may have, it will be hashed into a 512 character key.

The user may encrypt a file to as many levels as desired, that is; an encrypted file can be re-encrypted.

The" DEP" also allows the user to expand the input text with random garbage thrown into the output text. The ratio of expansion per encryption is from 31 bits in, 32 bits out(adding 1 bit garbage), up to 1 bit in, 32 bits out(adding 31 bits garbage per bit). Decryption(s) must proceed in the exact reverse order of the encryption(s).

Keys may be entered from the keyboard with/ without echo or from a file. Most file types currently sup­ported by VMS can be used as a key as long as the record length is less than 81 92 bytes.

Release Notes are distributed with each order.

Restrictions: Needs at least VMS 4.1.

Documentation on magnetic media

Media(ServiceCharge Code): 600' Magnetic Tape(MA), Format: VAX/ ANSI, Blocked at 2048

DECUS NO: VAX-154, Title: Screen Management System Subroutines, Version: December 1985

Submitted by: Kenneth Messer, Allied Electronics, Ft Worth TX, Operating System VAX/VMS V4.2 re­quired, Source Language: VAX-11 BASIC

Abstract This submission consists of a group of sut>­routines written in VAX BASIC V2.3, comprising a system allowing the (relativel}'l simple usage of the new VAX Screen Management System under VMS version 4.2. Also, included is a demonstration pro­gram using it With this system, a programmer can create up to 1 0 virtual displays and manipulate them quite simply, by keeping track of the sequence num­ber of the intended virtual display (0 through 9) and passing that number as an argument 1n the subroutine call. Specific information about the routines, as well as argument layouts and more detailed explanations, are to be found in SMGDOC.MEM, which is included in the submission.

Restrictions: Software is known to work satisfactorily, but as with any new system, unforseen bugs are sure to arise.

Documentation on magnetic media

Media (Service Charge Godel: 600' Magnetic Tape (MA), Format VMS/BACKUP, Blocked at 8192

DECUS NO: VAX-157, Title: Clinimetric Data Manage­ment Software for Interactive Data Entry, Version: V5.5, March 1 985

Submitted by: Messrs. W. Dupont & W. Plummer, Van­derbil\ University, NashvilleTN, Operating System: VAX/ VMS V4.1, Source Language: MACR0-32, FORTRAN 77

Abstract: The CLINIMETRIC Data Management Sys­tem(CDMS) facilitates interactive data entry and editing by people without previous computer skills. The user first writes a simple program that defines the data d1c­t1onaries of the data fries that are to be entered. This pro­gram is then compiled to create control files that enable the package's utility programs to be customized to the user's needs.

Data may then be entered, edited and reviewed using the interactive data entry ulllity. Prompting messages obtained from the data dictionaries guide the user through each data form. One or more data values may be entered in tree format between prompting messages. This makes data entry and editing tasks easy to learn and perform. Entry errors can be detected and corrected 1mmed1ately. Lists of remaining edit checks can be generated for subsequent verification and correction. Data points that are not entered are automatically assigned missing value codes. The user may alter the order of data entry to skip missing entries or change previously entered values.

An indexed file structure allows rapid and con­venient access to any record in each file. Interactive inter-file edit checks can enforce consistency between fries in a multi-file data base. Other features include interacllve help messages, relational edit checks, date variables, record certification, and automatic case con­version. CDMS data files may be accessed as sequen­tial files with fixed data formats. Documentation files provide the column locatio and format of each variable in the file and summarize the data dictionary. A utility converts existing sequential files into a CDMS system

Release Notes distributed with each order.

Documentation on magnetic media

Media(Service Charge Code): Users Manual( EC), 2400' Magnetic Tape( PA), Format VMS/ BACKUP, Blocked at 8192

DECUS NO: VAX-158, Title: GDADL-Ada-Based Design Language Processor Version: V2.2, November 1985

Submitted by: Computer Systems Design, Claremont CA, Operating System: VAX/VMS V4.1 , Source Language: C, Memory Required: 512 K

LIB-3

Abstract GDADL is an Ada-based Program Design Language. The GDADL processor analyzes Ada pro­grams (both executable Ada code and POL pseudo­code) in order to produce documentation which describes the design at any stage of development. The GDADL processor consists of over 25 software tools which pro­duce such reports as:

• Pretty-print design and source code • Program unit invocation tree • Type cross reference report • Object cross reference report • Generic instantiation report • Data-dictionary • Areas of the design which are To Be Defined

(TBD) Up to ten additional user-defined pro;ect manage

ment reports can be used to identify such items as: • Requirements traceability to the program units • Identification of areas which have been re­

vised • Responsible designers. etc.

The cycllomatic complexity of both the pseudo­code design and the executable Ada code rs analyzed and reported for each program unit

The designer does not need to have access to an Ada compiler to use GDADL, or the GDADL processor However, designs expressed 1n GDADL are fully com­pilable using any Ada compiler

Sources not included Documentation available in hard­copy only.

Media(Service Charge Code): Users Manual ( E DJ. 600' Magnetic Tape (MA), Format: VAX/ANSI, Blocked at 2048

DECUS NO: VAX-159, Title: FONT2XX, Version: V1 .0, October 1 985 .

Submitted by: William Porteous. Operating System: VAX! VMS V4.2 Source Language: VAX-11 FORTRAN

LIB-4

Abstract: FONT2XX is a program which helps one generate character sets for the Digital VT200 series of terminals. Instead of trying to determine the bit patterns associated with custom character sets, one uses an editor(any editor will do) to create the characters. From the data file containing the characters, FONT2XX will create an output file with all the escape sequences re­quired by the VT2 XX terminal for character generation.

Sample character sets are included which corres­pond to the Digital symbols se\ the Digital technical character set and the Apple Macintosh extended charac­ter set.

Documentation on magnetic media

Media(Service Charge Code): 600' Magnetic Tape( MA), Format: VMS/BACKUP, Blocked at 8192

DECUS NO: V-SP-48, Title: Best of PC-8088 Collec­tions 1-8, Version: Vl December 1985

Submitted by: Glenn Everhart Ph.D .. Operating Sys­tem MSIDOS, CP/M Source Language: PASCAL, FORTRAN 77, FORTRAN IV, FOCAL, C, BASIC. APL Software Required MSIDOS, CP/M

Abstract This submission contains about 400 disks worth of utilities from the PC-SIG library for I BM PC and MSIDOS machines and from several bulletin boards. The fries were transferred to VMS in KERMIT hletype Binary mode and can be restored to PCs in the same way.

VMS Kermit (and other Kerm1tsj are NOT in this submission

Restrictions: Some programs need close replicas of IBM PC.

Complete sources not included. Documentation on magnetic media

Media(ServiceChargeCodej: 2400' Magnetic Tapes (PB). Format VMS/BACKUP. Blocked at 16384

REVISIONS TO LIBRARY PROGRAMS

DECUS NO: Revision20-183, Title: ANSI MT A Utility to Transfer 7-Bit ASCII Files, Version: V1 .02-2, December 1985

Submitted by: Jeffrey Blomberg, U.H. Computing Cen­ter, Honolulu, HI Operating System: TOPS-20 release 5.1 , Source Language: PASCAL Memory Required: 251011, Software Required: Rutgers PASCAL version 14 Edit 331 (or late~ with the CM ND jsys interface developed by Charles Hedrick of Rutgers University, only required for recompilation., Special Hardware Required: 800 BPI, 1600 BPI or6250 BPI Tape Drive

Abstract: ANSI MT is a TOPS-20 Tape utility whose func­tion is to easily transfer 7-bit ASCII files between disk storage and 9-track magnetic tape. ANSI MT supports fixed formatted tape files on 800/1600/6250 bpi ANSI standard labeled tapes and can also read from EBCDIC labeled tapes. Features include stripping trailing blanks while restoring from magtape, padding tabs while stor­ing to tape, and producing directory listings of the tape. ANSI MT uses the full command recognition features of TOPS-20. A help file is included.

Changes and Improvements: Removed the depen­dency on the Rutgers Pascal Sharable Runt1mes. ANSI MT.EXE andANSIMT.HLP are all that is needed to run the utility. We are providing a complete copy of our submittal and supporting files.

Restrictions: Must use Rutgers PASCAL Version 14, Edit 331 with COM ND jsys interface to rebuild. Writes fixed format ANSI labeled tapes only, reads EBCDIC but can't write EBCDIC; can read ANSI D-Format tapes.

Documentation on magnetic media

Media(Service Charge Code): 600' Magnetic Tape(MA)

DECUS PROGRAM LIBRARY CHANGES:

DECUS NO: 11-816 TITLE: Update Suite PROGRAM STATUS: On hold DATE: 20 Feb 86

::,IB-5

HOW TO SUBMIT TO A SPECIFIC SECTION OF THE NEWSLETTER

The following is a listing of the Newsletter Editors with their addresses and phone numbers. All sub­missions to the newsletter should be submitted directly to the appropriate Editor.

ARTIFICIAL INTELLIGENCE Terry Shannon 160 State Street Boston, MA 02109 (617) 367-7190

BUSINESS APPLICATIONS Thomas Byrne L Karp& Sons 1301 Estes Elk Grove, IL 60007 (312) 593-5705

DATA MANAGEMENT SYSTEMS Russ Poisson Seed Software Corp. 2121 Eisenhower Avenue Alexandria, VA 22314 (703) 783-4944

DAARC Ellen Reilly William H. Rorer 500 Virginia Drive Ft Washington, PA 19034 (215) 628-6547

GRAPHICS APPLICATION Michael Anton

IAS

P.O. Box 591293 Houston, TX 77259-1293 (713) 928-4838

John Ross Roman McDonnell Douglas 600 McDonnell Blvd. Hazelwood, MO 63042 (314) 234-0984

LARGE SYSTEMS Michael Joy 1st Church of Christ Scientist Boston, MA 02115 (61 7) 262-2300 x 3903

NETWORKS Vicki Hancock 2510 Limestone Lane Garland, TX 75040 (214) 495-7353

PERSONAL COMPUTER Caroline Mack

RSX

9007 Mears Street Fairfax, VA 22031 (703) 280-4404 [Upload submissions to Wash-A-Rug Fido (703) 359-6549]

Dominic DiNollo Loral Electronics Engineering Computer Center Ridge Hill Yonkers, NY 1071 O (914) 968-2500 x221 0

SITE MANAGEMENT & TRAINING Gregory Brooks Washington University Behavior Research Lab. 1420 Gratton St. St. Louis, MO 63104 (314) 241-7600 x257

VAX SYSTEMS Larry Kilgallen C/O DECUS Office 219 Boston Post Road. (BP02) Marlboro, MA 01752

HOW-i

APL Doug Bohrer Bohrer& Company 903 Ridge Road, Suite 3 Wilmette, IL60091 (312) 251-9449

COMMERCIAL LANGUAGES Ted Bear RAMTEK 2211 Lawson Lane Santa Clara, CA 95950 (408) 988-2211

DATATRIEVE Donald E. Stern, Jr. c/o Warner Lambert Company 1 0 Webster Road Milford, Ct 06460 (203) 783-0238

EDUSIG Fred Bell Taft College 29 Emmons Park Drive P.O. Box 1437 Taft, CA 93268 (805) 763-4282

HMS William Walker Monsanto Research Corp. P.O. Box 32 A-152 Miamisburg, OH 45342 (513) 865-3557

LANGUAGES& TOOLS Alan Folsom Jr. Fischer & Porter Company E. County Line Road Warminster, PA 18974 (215) 674-7154

HOW-ii

MUMPS Janet Berryman 2405 N. Bush Santa Ana, CA 92706 (714) 953-1025

OFFICE AUTOMATION Margaret Drake Univ. of TX Health Science Ctr. 7703 Floyd Curl Drive San Antonio, TX 78284 (512) 691-6105

RSTS

RT

Bill Hobbs ComManD. Inc. 6535 E. 82 nd St., Suite 1 02 Indianapolis, IN 46250 (317) 842-5320

Bill Leroy The Software House, Inc. 2964 Peachtree RDNW #320 P.O. Box52661 Atlanta, GA 30355 (404) 231-1484

UNISIG William Toth Harvard-Smithsonian Ctr. for Astrophysics 60 Garden Street P353 Cambridge, MA 02138 (617) 495-7181

Bruce Bergman UserWare International 2235 Meyer Avenue Escondido, CA 92025-1 070 (619) 741-8825

SUBMITTING ARTICLES TO THE HMS SIG NEWSLETTER

The purpose of 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 are interested in publishing it in the newsletter. It is intended that the HMS SIG Newsletter be published at least four times a year.

There are newsletter:

several ways to submit material for the

o The Hardware Submission Form in the back of the newsletter can be used for brief items (there is not enough room if you have a lot to say).

o You can send me camera-ready hard-copy <this saves me a lot of typing).

o I will accept submissions on floppys. I can handle RXSO's or 8" diskettes (either density, single or double sidedl. I prefer RT-11 format, if possible, but I can probably handle RSX or VMS stuff somehow. I will return your diskette(s). of course.

o Those of you that have things to username WALKER.

access to DCS can send I check DCS daily.

o I am also on CompuServe as "Bill Walker 71066,24".

In any event, if you have anythij'}g_ to submit, send it! If it is a mess, but I can read it, I will get it in the newsletter somehow. Finally, if you have any question about submitting material, call me. My telephone number is listed below.

Contributions can be sent to:

HMS Editor DEC US BP02 249 Northboro Road Marlboro, MA 01752

OR William K. Walker Monsanto Research Corp. P.O. Box 32 A-152 Miamisburg, OH 45342 (513) 865-3557

If you need to get something to me quickly, send it to my work address.

HOW-1

Cl DEC US DECUS SUBSCRIPTION SERVICE

SIGs NEWSLETTERS U.S. CHAPTER 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. • No refunds will be made. • The address provided below will be used for all DECUS 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 ______________ _ _ DECUS Member No._ Company _________________ _ Address ____________________ _

---------------

City _________ _ _ __________ State Phone _____________________ _

Subscription Service Offering

SIGs Newsletters Fall '85 Proceedings (FA5) Spring '86 Proceedings (SP6) Fall '86 Proceedings (FA6) Spring '87 Proceedings (SP?)

TOTAL COST OF SUBSCRIPTION

Qty. Unit Price

$35.00 15.00 15.00 15.00 15.00

D MASTERCARD D VISA D DINERS CLUB/CARTE BLANCHE®

___________________ Exp. Date_

___ Zip __

Total

I understand that there will be no refunds even if I decide to cancel my subscription.

Signature: _

FOR DIGITAL EMPLOYEES ONLY FOR DECUS OFFICE ONLY

Badge No~-------------------- CC: __ _ Check No. ___ _ CC Mgr. Name _____ _ Bank No. ___ _ CC Mgr. Signature _________________________ _ Amount$ _____ _

Subscription Service, DECUS( BP02), 219 Boston Post Road, Marlboro, MA 01 752-1850, (61 7) 480-3418.

HOW-3

DECUS U.S.CHAPTER APPLICATION FOR MEMBERSHIP

I I

D New Membership D Update to current membership profile Current DEC US Member. # ------------

NOTE: PLEASE PRINT CLEARLY OR TYPE! PLEASE PROVIDE A COMPLETE MAILING ADDRESS, INCLUDE ZIP CODE IN ACCORDANCE WITH POSTAL REGULATIONS FOR YOUR LOCALITY.

4RE YOU AN EMPLOYEE OF DIGITAL EQUIPMENT CORPORATION?O YES 0 NO

(first) (Middle lntial) (Le1t,'Family Name)

Company·~------------------------------------~

Address~· -------------------------------------~

City/Town: ______________ State: _____________ Zip: ____ _

Telephone: Home ( Work

HOW DID YOU LEARN ABOUT DECUS? Please check applicable item.

4 D DIGITAL SALES 13 D LOCAL USER GROUP 1 D ANOTHER DECUS MEMBER 2 D SYMPOSIA 8 D DECUS CHAPTER OFFICE

10 D DIGITAL STORE

5 D HARDWARE PACKAGE 6 D SOFTWAREPACKAGE

12 D ADVERTISING

14 D SPECIAL INTEREST GROUP 7 D SOFTWARE DESPATCH

(DIGITAL Newsletter)

DO YOU WISH TO BE INCLUDED IN MAILINGS CONDUCTED BY DIGITAL(for Marketing purposes etc.?) D Permission D Refusal

TYPE OF DIGITAL HARDWARE USED: Please check those applicable to you.

20 D DECMATE 82 D DECsystem-10 83 D DECSYSTEM-20

52 D LSl-11 3 D PDP-8 FAMILY

50 D PDP-11 FAMILY

21 D PROFESSIONAL 22 D RAINBOW 54 D VAX FAMILY

MAJOR OPERATING SYSTEMS? LANGUAGES USED: Please check those applicable to you

1 D ADA 26 D CORAL-66 47 D FOCAL 67 D 2 D ALGOL 28 D cos 48 D FORTRAN 68 D 5 D APL 34 D DATATRIEVE 51 D GAMMA 72 D 7 D BASIC 35 D DBMS 110 D IAS 92 D

17 D BLISS 38 D DECnet 53 D IQL 81 D 19 D c 43 a DIBOL 58 D MACRO 83 D 22 D COBOL 45 [J DOS-11 65 D MUMPS 91 D

HOW-5

5 D WPS-8 51 D Wi>S-11

OS/8 109 PASCAL 97 PL-11 70 RPG 71 RSTS/E 104 RSX 107 RMS

D RT-11 D TECO D TOPS-10 D TOPS-20 D VMS D WPS-8

TYPE OF BUSINESS (ENVIRONMENT}/COMPUTER APPLICATIONS Please check that which best describes your business/application

21 0 ACCOUNTANCY 1 0 EDUCATION/PAI MARY 73 0 NUMERICAL CONTROL

7 0 BANK 2 0 EDUCATION/SECONDARY 68 0 OEM-COMMERCIAL

64 0 BUSINESS/COMMERCIAL 61 0 EDUCATION· TECHNOLOGY 78 0 OEM-TECHNICAL

74 0 BUSINESS/INFORMATION SYSTEMS 3 0 EDUCATION/UNIVERSITY 56 0 PHYSICAL SCIENCES

57 0 CHEMISTRY 67 0 ENGINEERING 20 0 RESEARCH/DEVELOPMENT

54 0 CLINICAL LABORATORY 65 0 FINANCE/ACCOUNTING 10 0 RETAIL

63 0 COMPUTATION 77 0 GOVERNMENT 76 0 SOFTWARE DEVELOPMENT

11 0 CONSUMER ELECTRONICS 75 0 GRAPHICS 53 0 TELECOMMUNICATIONS

18 0 CONSULTANT 4 0 HOSPITAL 19 0 TELEPHONE/UTILITIES

72 0 DATA ACQUISITION 62 0 INDUSTRIAL 51 0 TIMESHARING

52 0 DATA COMMUNICATIONS 55 0 LABORATORY/SCIENTIFIC 80 0 TRAINING/INSTRUCTION

13 0 DATA PROCESSING SERVICES 14 0 LIBRARY 66 0 TYPESETTING/PUBLICATION

71 0 DATA REDUCTION 58 0 LIFE SCIENCES 17 0 DIGITAL EMPLOYEE-ENGINEERING 70 0 MANUFACTURING 15 0 DIGITAL EMPLOYEE-MARKETING 79 0 MARKETING 16 0 DIGITAL EMPLOYEE-SERVICE GROUP 59 0 MEDICAL RESEARCH 60 0 EDUCATIONAL ADMINISTRATION 6 0 MILITARY INSTALLATION

SPECIAL INTEREST GROUP (SI Gs) ENROLLMENT I wish to participate in the following DECUS U.S. Chapter Special Interest Groups.

33 0 APL SIG 11 0 HARDWARE AND MICRO 36 0 PERSONAL COMPUTER

2 0 COMMERCIAL 35 0 IAS 18 0 RSTS/E LANGUAGES 31 0 DAARC(LABS) 17 0 RSX

6 0 DATA MGMT.SYS. 27 0 LARGE SYSTEMS 19 0 RT-11

5 0 DATATRIEVE 16 0 LANG. AND TOOLS 32 0 SITE MGMT.& TRNG 7 0 BUSINESS APPL 14 0 MUMPS 21 0 UNISIG

8 0 EDU SIG 15 0 NETWORKS 26 0 VAX SYSTEMS

10 0 GRAPHICS APPL 34 0 OFFICE AUTOMATION

JOB TITLE/POSITION - Please check:

1 0 CORPORATE STAFF 101 0 CORPORATE DIRECTOR OF DP/MIS 2 0 DIVISION OR DEPARTMENT STAFF 102 0 ADMINISTRATIVE ASSISTANT 3 0 SYSTEMS ANALYSIS 103 0 TECHNICAL ASSISTANT 4 0 APPLICATIONS PROGRAMMING 104 0 SERVICES COORDINATOR

5 0 SYSTEMS ANALYSIS/PROGRAMMING 105 0 MANAGER

6 0 OPERATING SYSTEM PROGRAMMING 106 0 ANALYST 7 0 DATABASE ADMINISTRATION 107 0 PROGRAMMER 8 0 DATA COMMUNICATIONS/TELECOMMUNICATIONS 108 0 DATABASE MANAGER 9 0 COMPUTER OPERATIONS 109 0 DATABASE ADMINISTRATOR

10 0 PRODUCTION CONTROL 110 0 MANAGER OF DP OPERATIONS

CITIZEN OF UNITED STATES OF AMERICA? D Yes D No

Signature:------------------Date: _________________ _

Forward To: DECUS U.S. CHAPTER, MEMBERSHIP PROCESSING GROUP 219 BOSTON POST ROAD MARLBORO, MA 01752, USA PHONE: (617) 480-3418

HOW-6

PAGESWAPPER ~ April 1986 - Volume 7 Number 9 INPUT/OUTPUT Submission Form

INPUT /OUTPUT Submission Form

A SIG Information Interchange

Please reprint in the next issue of the Pageswapper

If this is a reply to a previous I/O, which number?

Caption:

Message:

Contact:

Name

Address

Telephone

Signature Date

Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139~0901, USA

QU-1

PAGESWAPPER - April 1986 - Volume 7 Number 9 INPUT/OUTPUT Submission Form

Tear out or photocopy reverse to submit an I/O item

Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA

PAGESWAPPER - April 1986 - Volume 7 Number 9 System Improvement Request Submission Form

System Improvement Request Submission Form

Page 1 of

Submittor: Firm:

Address: Phone:

How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request.

Abstract (Please limit to four lines):

Description and examples (use additional pages if required)

QU-3

PAGESWAPPER ~ April 1986 ~ Volume 7 Number 9 System Improvement Request Submission Form

Tear out or photocopy reverse to submit an SIR

Gary L. Grebus Battelle Columbus Division Room 11.:.6011 505 King Avenue Columbus, Ohio 43201-2693 USA

PAGESWAPPER • April 1986 ~ Volume 7 Number 9 VAX Systems SIG Spring 1986 SIR Ballot

VAX Systems SIG Spring 1986 SIR Ballot

DECUS membership number (six digits)

Our site uses the following VAX models (check all that apply)

8600 11/730,11/725

11/782 -- 11/780'11/785 11/750 MicroVAX

We use VAX's in the following applications (Check all that apply)

Business EDP Education Data Acquisition/Control Service Bureau ~~

Scientific/Engineering Telecommunications Other

Software Development Computer Science Research CAD/CAM Hardware Development Office Automation

I support the following as the most important System Improvement Requests. (List from zero to fifteen SIR's):

SIR Number:

I oppose the following SIR's as detrimental. (List from zero to five SIR's):

SIR Number:

Mail to:

Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, OH 43201

To be counted, you ballot must be received by April 1.

QU-5

PAGESWAPPER - April 1986 - Volume 7 Number 9 VAX Systems SIG Spring 1986 SIR Ballot

Tear out or photocopy reverse to vote on SIRs

Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA

Page I of __

OFFICE AUTOMATION SIG

SYSTEM IMPROVEMENT REQUEST SUBMISSION FORM

Name Address ----------------Firm

Telephone ------------~

INSTRUCTIONS: System Improvement Requests (SIR) can be either hardware of software; please check the category addressed by this SIR. Under ABSTRACT, give a brief definition of the capability you would like. In the DESCRIPTION section, give a detailed description and examples of what you want. Be specific; don't assume that we know how other products function. Justify the usefulness of the capability and give an example of its use.

HARDWARE IMPROVEMENT SOFTWARE IMPROVEMENT

DECmate ALL-IN-I WPS ------ ------

PRO-Series ----- CP/M (DECmate) ----- P/OS ____ _

Rainbow ------ CP/M (Rainbow) ----- MS-DOS ----Other Other ------- ---------

ABSTRACT _______________________________ _

DESCRIPTION ----------------------------~

QU-7

E. Catherine Ditamore ARA Services Corp MIS Independence Square West Philadelphia, Pa. 19106

DRTRGBRm DAT AGRAMs ere short messages, comments, requests, or answers th et ere publl shed in NETwords. Please fi 11 in the sect i ans below end send the DAT AGRAM to:

Your Nome: Address:

Telephone:

. V1 ck1 e Honcock NETWords Ed1 tor 251 o Limestone Ln. Gorlond, T>e. 75040

If th1s is o reply to a previous DATAGRAM_, what •7 _

Signoture: -------------- Dote: __

Vickie Hancock NETWords Editor 2510 Limestone Ln. Garland, Tx. 75040

fol<J Here

Place Stamp,

' Here :

Printed in the U.S.A.

"The Following are Trademarks of Digital Equipment Corporation"

ALL-IN-1 DEC DECnet DEC mate DECsystem-10 DECSYSTEM-20 DECUS DECwriter DIBOL

Digital logo EduSystem IAS MASS BUS PDP PDT P/OS Professional Rainbow

RSTS RSX RT UNIBUS VAX VMS VT Work Processor

Copyright ~DECUS and Digital Equipment Corporation 1986 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 docu-rnent.

POLICY NOTICE TO ALL ATIENDEES OR CONTRIBUTORS "DECUS PRESEN­TATIONS, PUBLICATIONS, PROGRAMS, OR ANY OTHER PRODUCT WILL NOT CONTAIN TECHNICAL DATA/INFORMATION THAT IS PROPRIETARY, CLASSI­FIED UNDER U.S. GOVERNED BY THE U.S. DEPARTMENT OF STATE'S INTER­NATIONAL TRAFFIC IN ARMS REGULATIONS (ITAR)."

DECUS and Digital Equipment Corporation make no representation that in the interconnection of products in the manner described herein will not infringe on any existing or future patent rights nor do the descriptions contained herein imply the granting of licenses to utilize any software so described or to make, use or sell equipment constructed in accordance with these descriptions.

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 arethoseoftheauthorsand do not necessarily express the views of DECUS ot Digital Equipment Corporation.

Ada is a trademark of the U.S. Government, XEROX is a trademark of Xerox Corporation, IB M, PROFFS are trademarks of International Business Machines Corporation, UNIX is a trademark of AT&T Bell Laboratories, CP/M, PUI aretademarks of Digital Research, Inc., MS-DOS is a trademark of Microsoft Corporation, TSX­PLUS is a trademark of S&H Computer Systems, Inc.

------------------------· 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 Member) DECUS Membership No: ______ _ Name: ____________ _

Company: ____________ _

Address: ____________ _

State/Country: _________ _

Zip/Postal Code: _________ _

Mail to: DECUS - Attn: Subscription Service 219 Boston Post Road, BP02 Marlboro, Massachusetts 01752-185

lJSA :::.w _....::.- ...... ili = :::J ::?. -· ..... Ill 0 "' -!!!.6'[o :::i ~ :?_:::icoC:9.~

I I I I I I I

~-----------------------~

s::~oo o[O] l>mG)m ~ ~OJ=i() c OJOl>55 en oen•en :JJ-imc oOoOJ - Zc '=:I" - en ::::.. ""O ""O () )> 0 s:: :JJ o en -~ -im ""O -.....l:JJZ-i 01 0-iO "}l )> () z ~oo oo- '=:I" en 01 _::::..m

OJ ""O :JJ O""OC

0-i< I\) m () - :JJ m

en 0 ()

m ~

ID' "O 0 CD C 3 .., . CD 0--3-a~c :;;:~::.,.-a~

~ !t ~ a la ~ .. . I» =-i: - IQCD > CID CD