MTS NEWSLETTER
9 OCTOBER 1979 NUMBER 55
TABLE CF CONTENTS NTS Newsletter #55
Newsletter Notices. General. System Software. Support Software... Hardware Documentation. Index.....................
......1 5 ...............13 ...............31 ..........85 .......125 135
E d i t o r ' s Note: The f i r s t t h i n g t h a t I hope you've noticed i s t h e new c o v e r . I f you d o n ' t l i k e i t , t e a r i t off and throw i t i n the g a r b a g e . When I s t a r t e d t o g a t h e r the v a r i o u s g o o d i e s foe t h i s i s s u e , I thought they would make a meagre p i l e of paper. The nuaber of i t e m s from MTS:FORUfl changad a l l t h a t , and I spent over a day f i g h t i n g with the network to being a c r o s s good c o p i e s . Grant Crawford
1
MTS NEWSLETTER The MIS Newsletter is is edited and published by the University of Alterta Computing Services Department on behalf of all of the MTS installations. Articles about software, hardware, and documentation developments at installations using the Michigan Terminal System are contributed by the staff of the installations via the correspondents listed or. page 3. The SHARE installation codes shown will be used where necessary to gualify names and projects mentioned in the Newsletter. The first section of the Newsletter deals primarily with general matters. Subsequent sections contain contributions loosely organized into the areas of Systems Software (UMMPS, MTS, CLS's, etc.). Support Software (compilers and other application type things) , Hardware (the stuff in those big tin boxes that go beep and blink), Documentation (what you can't find when you want it), and the Index (which some people find useful). NFWSLffTTEfi SCHEDULE The following deadlines are planned for future issues of the MTS Newsletter: #56 December 3,79 #59 June 2,80
#57 February 4,80 #60 August 4,80
#58 April 7,80 #58 April 7,80
We have prearranged printing for these dates and will stick to this schedule, distributing whatever has been received prior to the deadline. Any recipients of this newsletter wishing to submit communications should address them to Grant Crawford at UQV. Please copy the Mia Newsletter on all you correspondence relating to the MTS system. This responsibility rests with the originator of the correspondence. If you notice errors or omissions in the index, please pass them to the editor for correction in the cumulative index. Newsletter 57 (Feb 1980) will contain a cumulative Index (in addition to and seperate from the index for #57) . A cumulative. Index will be provided yearly.
2
NEWSLETTER CORRESPONDENTS
iffi!P!?wN
UM
Gary Pirkola The University of Michigan Computer Center Building 10 75 Beai Avenue Ann Arbor, Michigan 48105 U.S. A. ' Telephone: (313) 764-9595
UBC
Jeff Berryman Computing Center The University of British Columbia 2075 Wesbrook Mall Vancouver, British Columbia CANADA, V6T 1N5 Telephone: (604) 228-3942
UNE
John Law NUMAC Computing Center Computing Laboratory The University of Newcastle upon Tyne Claremont Tower, Claremont Road Newcastle upon Tyne, NE1 7RU ENGLAND Telephone: Newcastle 29233 Extension 2771
UQV
Grant Crawford Computing Services The University of Alberta Edmonton, Alberta CANADA, T6G 2H1 Telephone: (403) 432-2261
HSU
Natalie Frazis Computing and Data Processing Center Wayne State University Detroit, Michigan 48202 U.S.A. T e l e p h o n e : (313) 5 7 7 - 4 7 4 7
BPI
Wilson D i l l a w a y O f f i c e of Computer S e r v i c e s Kensselaer Polytechnic I n s t i t u t e T r o y , New York 12181 U.S.A. T e l e p h o n e : (518) 2 7 0 - 6 2 7 9
SFU
Charlie Benet Computing Centre Simon Fraser University Burnaby, British Columbia CANADA, V5A 136 Telephone: (604) 291-3234
EMB
Claudio Police Spiguel Flora Program Supervisor CNPq - S.I.P. W3 Norte Quadra 507 Bloco B 70 000 Brasil 1A D.F.
???
Julio L. Botelho CBPF/CNPq AV. Wenceslau Bras 71 CEP 2 2 . 2 9 0 Rio de J a n e i r o - RJ BRAZIL
LOCAL INTERFACE PERSONS DM UBC UNE UQV WSU BPI SFU EMB ???
-
Scott Gerstenberger Bon Hall John Law Daryl Webster Natalie Frazis Wilson Dillaway Charlie Benet Claudio Police Speguel Julio L. Botelho
4
'r.o •• r
#y
%M
^f^ltVl'%,
..i ::. •-, r
t'VS. i
*,-; n
-
•:
t
ITEM 409 18:44 Sep24/79 23 LINES ?RIME=324 CGDEN, JEFF (UM) M i n i - r e d i s t r i b u t i o n of MTS t o r e p l a c e MTS change forms I plan t o be s e n d i n g a m i n i - r e d i s t r i b u t i o n of MTS t o a l l of t h e MTS i n s t a l l a t i o n s sometime the week of 6 October. This w i l l c o n s i s t a o s t l y of CDDPDATE decks for MTS. The i d e a i s t o do t h i s r a t h e r than make o a t change forms for a l l of t he r e c e n t ( p o st RD16) changes to MTS. I'm w i l l i n g t o i n c l u d e d a s m a l l amount of o t h e r p e o p l e s suff on t h e t a p e a s long a s i t i s n ' t too much work for me and i t w i l l a l l f i x on t h e t a p e .
Bather than call this Redistribution 17 of MTS we will be calling it RD4.22 (BD16 would have been RD4.21). The idea (suggested by Jeff B.) was to use one scheme for all of the tapes. Because volume names are limited to 6 characters we'll be dropping the prefix RD or D from the volume labels giving: Old S t y l e New S t y l e Volume Name Name Name Full Distribution D4.0 D4.0 4.0Tn Partial » D4.2 D4. 2 4. 2Tn Redistribution BD17 BD4. 22 4. 22Tn L e t me know i f you d o n ' t l i k e something about any of this. BEF TO ITEMS 324 REF BY ITEMS 411 12 VOTES/FEELINGS 3? LBT. What happens on r e d i s t r i b u t i on t a p e s i f we g e t D1
I l i k e S c o t t ' s i d ea too . . . Gav/UM I d o n ' t s e e why we have t o change t h e naming scheme. Redistributions a r e enough d i f f e r e n t from d i s t r i b u t i o n s t h a t t h e y should have r e c o g n i z a b l y d i f f e r e n t names. (MTA) Should t h e New St./le Name be D4. 2R2 (or BD4.2/2 o r . . . ) ? I know w e ' l l never g e t t o D4.22 but t h a t ' s what t h e name l o o k s l i k e now. Paul P How about D4.2A, D4.2B e t c . f o r r e d i s t r i b u t i o n s ? Seems more obvious to me (and i t s o l v e s the D10 problem). ( S c o t t G./UM) S c o t t ' s got a good one. - Fred Swartz I f ve have t o change t h e names, I l i k e S c o t t ' s s u g g e s t i o n . (Don /WSU) If we must c h a n g e , I would l i k e t h e e x t e r n a l l a b e l and volume l a b e l to remain t h e same a s each o t h e r . I t has always been my f e e l i n g t h a t t h e s t a t u s of r e d i s t r i b u t i o n s was s u f f i c i e n t l y d i f f e r e n t from d i s t r i b u t i o n s to warrent d i f f e r e n t sequences . (CFE-UM) I am n o t t h a t hung up about the name change, but i f ve do i t , I too l i k e S c o t t ' s s u g g e s t i o n . JHH/um I a s very much i n favour of adopting some scheme which i n d i c a t e s a t a g l a n c e where RD t a p e s f i t i n t h e o r d e r ed D t a p e l i s t . Antoine V e r h e i j e n (UQV) J e f f , could you i n c l u d e t h e c u r r e n t CONFER f i l e s on FORUM f i l e s (MTS and TXTF, a t l e a s t ) . . . t h a n k s , chb/sfu I ' l l be s e n d i n g t h e RD4.2B t a p e s out t h i s week with VOL=4.2B and the FORUM f i l e s . ( - J e f f Ogden/UM)
ITEM 411 17:19 Sep26/79 4 1 LINES PRIME=409 BERBYMAN, JEFF (UBC) Defense of New Redistibution Numbers The reason that I suggested the new redistribution numbering setup was to attempt to move toward a single, unified version identification scheme in MTS without making too many waves. I am surprised at the objections, since they mostly seem to be on aesthetic grounds. An aesthetic change was not the essence of my idea. The original point is that having two parallel numbering schemes for (re)distributed material causes unnecessary problems of version identification for the receivers, if not the transmitters, of that material because you can't tell by inspection which two distributions a given redistribution is between. Admittedly, there is nothing in the basic logic of distributions and redistributions that requires redistributions to be between distributions at all—it would be possible (and not unreasonable) to send out a redistribution and a distribution in the same mailing. However, as a practical fact, distributions always contain intermediate versions of things, and some numbering scheme is required that allows for that fact. I'm currently in the middle of setting up a revised, relatively comprehensive Software Library facility here at UBC. One of the things that is absolutely essential to the proper functioning of that facility is the existence of a reasonable system for telling which version of a program is which. Whether that version comes off a distribtion tape or a redistribution tape is not nearly as important as whether it is older or newer than some other version that one might be considering at the same time. I had intended to key my version numbering system to the distribution system, since MTS distributions and redistributions are the clocks that we in the MTS hinterlands run our lives by. In order to do this, some new scheme such as the ones we are talking about is required. Furthermore, it seems to me that whatever scheme is chosen should be reasonably easy for programs to deal with as well as people, since programs may well have to increment and decrement version numbers, particularly if and when we get a program management facility or facilities. Along these lines, it seems to me that 4.22, 4.23, etc. is somewhat better than 4.2A, 4. 2B, and so on, but clearly either scheme would suffice. What would not work is what we have now. REF TO ITEMS 409 REF BY ITEMS 412 5 VOTES/FEELINGS Keying by DIST# (4.22) follows the *CNFGINFODSECT convention. Keying by DATE leads to the EP269 form. Use the former for major stopping points, the latter for development (PHF usage?). I'd rather not deal with versionf 4.2238 of anything !! Gav/UM What does the Software Library facility look like, we all could use a good version manager. Paul P See my response in item 412. (Scott G./UM) Version numbers must be usable by people as well as programs. This is why I like 4.2A much better than 4.22. Another possibility (which I don't like as well) is 4.2.1 etc. (MTA) What is the difference between 4.22 and 4.2.2? Also, see my response to 412 /Jeff B.
7
ITEM 412 12:34 Sep27/79 40 LINES PRIME=411 GEBSTENBERGER, 8. SCOTT Why distribution tape names are inadequate as program version numbers. My feeling is that, although I see no objection whatsoever to changing the way in which we name distributions, I'm not sure that any naming scheme is really going to provide a good enough system for telling which version of a program is which (as Jeff Berryman wants for his Software Library facility—see item 411). It is not unusual to have exactly the same version of a program distributed on multiple distributions. Increasingly, we have tried to deal with this problem (on the generating end of the process) by taking the (unchanged) version of a program off of the same FS tape as it was previously taken from (if it normally resides on tape), or by taking it from the previous distribution tape (if not). In this way, the FS date and time on the distribution tape being generated are the same as they were on the previous distribution (s) of the same program. Liz and I have routinely spent many hours checking the FS time and dates (on trial runs of partial distributions) to see if those programs coming from FS tapes belonging to our staff really represent later versions or are the same thing that was distributed on the previous distribution. When we find something which is the same, it represents either something which probably shouldn't be on the partial distribution at all (since it's not changed) or a mistake in location (the wrong tape, FS file name, etc.). obviously, it is more difficult to do this for things coming from files, but there again we try to do some checking, principally by looking at last change dates. In the case of full distributions, it is normal to have many programs which ar unchanged since the previous distribution. We try where possible to take such things off earlier distribution tapes so that the FS time and date stay the same. Due to the magnitude of the job however, I'm sure we are not always (or perhaps even mostly) successful. Nevertheless the FS time and date are bound to be better than the distribution name. My purpose in entering this item is to indicate that I don't really care if and how ve change the distribution tape names, but that any scheme of tape naming is likely to be inadequate for what I perceive to be the intended purpose. REF TO ITEMS 411 4 VOTES/FEELINGS My vote in item 411 carried some of these feelings. The 'model* nuaber is useful, but it isn't formally maintained anywhere - maybe PHF/SLF(s) should use it. Because they are keyed to dates each site will generate different ones -> PROBLEMS ... Gav For some redistribution, some programs from other univerities may not work on the current distribution D4.2 but work on the previous distribution D4. 1, and vice versa. LBT. Distribution version numbers alone aren't enough—my scheme is only KEYED to them. There's more to the story. Stay tuned. Jeff B. Hurry my screen is starting to flicker!
•«0
8
H ' ">
f^
TO ': FROM: DATE:
^ E L O
.
Software Committee John Stevens September 1 9 , 1979. GENERAL PROGRAMMING PROJECT REPORTS CONSULTING
-
Many c a l l s on PASCAL SPIRES c o n s u l t i n g low-medium. DOCUMENTATION
-
Surface r o u t i n e h e l p f a c i l i t y updated UBC-TAPE b e i n g e d i t t e d . UBC-RG b e i n g r e v i s e d and u p d a t e d. UBC-SURFACE b e i n g r e v i s e d UBC APL r e v i s e d UBC-TEKBASIC r e v i s e d . UBC-IG and UBC-PLOT r e - o r d e r e d . GRAPHICS
HARD COPY PLOTTING - Work done on O p e r a t o r ' s p l o t r o u t i n e s l o o k i n g f o r Houston P l o t t e r problem f i n a l l y t r a c k e d t h e problem down- to h a r d w a r e . IG - 3278 support written - will be installed in NEW:lG. LANGUAGES «•
ASSIST - A new v e r s i o n of the macro l i b r a r y (*ASSISTMAC) i n s t a l l e d i n NEW:ASSISTMAC.
>>
COBOL - W i l l b e g i n t h e p h a s e - o u t of t h i s i n favour of COBOLVS. COBOL-VS - NEW:COBOLVSCOMP=new compiler ( s m a l l changes i n d e f a u l t s ) which now i s a v a i l a b l e v i a NEW:COBOLVS ( i n t e r f a c e r o u t i n e f o r VSS). FORTRAN I/O - Converted the e x p l a i n f i l e to upper and lower c a s e . v e r s i o n i n the r e s i d e n t system on S e p t . 1.
9
I n s t a l l e d our l a t e s t
- 2 LANGUAGES ( c o n t ' d ) IF - F i n i s h ed study of the f e a s i b i l i t y of making the i n t e r p r e t e r more e f f i c i e n t . See SOFT minutes. SPITBOL - Our updates have been merged with UM's. T e s t i n g has begun. SORTING SORT - Variable l e n g t h record f i x has been shipped by UM. STUDENT SYSTEM -
New y e a r has begun - the number o f courses using t h e Student System i s way down - only 4 s o f a r ! TAPES
TAPECOPY - D4.1 v e r s i o n i i . s t a l l e d i n NEW:TAPECOPY.
-^\
UTILITIES BATCH - Coding has begun on t h i s PLUS p r o j e c t . i
LINKEDIT - RD16 version installed which fixes QUIT on warning message. LISTER - Small bug concerning the page width f i x e d . MICROFICHE -
U t i l i t y program to put users data on a user owned mag tape and e n t e r i n t o the production job schedule to request the tape to be s e n t to the f i c h e producers. Have got a s e t of f i c h e back - our f i r s t t e s t took a week to get back (got l o s t on Campus).
&
OBJUTIL - A f i x s e n t from UM has been i n s t a l l e d i n NEW:OBJUTIL.
^\
:io
TO FROM DATE
SOFTWARE COMMITTEE JOHN STEVENS OCTOBER 3 , 1 9 7 9
GENERAL PROGRAMMING PROJECT REPORTS
CONSULTING
-
FORTRAN c o u r s e b e g u n , u s i n g t e r m i n a l l a b . 32 a t t e n d e e s . MTS c o u r s e begun ( a b o u t 100 p e o p l e showed up) - s p l i t i n t o 3 . D i s c u s s e d w i t h P e t e r some m o d i f i c a t i o n s t o HELP f a c i l i t y .
DOCUMENTATION
-
COBOL-VS document b e i n g p r e p a r e d . UBC-RG b e i n g updated - handed o v e r to Documentation Group.
-
UBC-PLOTSEE
-
UBC-TAPE e d i t t e d and g i v e n t o Systems f o r
,
proof-reading.
GRAPHICS
HARD COPY PLOTTING - More f e a t u r e s added t o t h e SURFACE g r a p h i c s
routine.
LANGUAGES APL - A l b e r t a ' s v e r s i o n 2 . 1 has b e e n i n s t a l l e d i n a t e s t - Shared v a r i a b l e s t a p e j u s t a r r i v e d .
file.
FTN - Closing of f i l e s required? - FTN c a l l s FREEFD i n w e i r d c i r c u m s t a n c e s on v a r i o u s u n i t s c a u s i n g programs which LINK t o i t t o l o s e u n i t s .
( s u c h as SPRINT)
thus
PASCAL
-
Set up a sample job for Computer Science to show use with FORTRAN programs. Have received a 250 program source used to give a rigorous testing of the compiler.
PLC -
Studen t System v e r s i o n found an o l d s t a n d i n g bug - backed o f f , bug and f i x e d .
t r a c k e d down t h e
SPITBOL - Our SPITBOL u p d a t e h a s c a u s e d a d d r e s s a b i l i t y problems i n two s e p a r a t e s e c t i o n s . Solved 1 s e c t i o n .
11
- 2 SORTING SORT - "Average record length" feature has arrived.
Installation will
UTILITIES LISTER - Code has begun on this PLUS project. MISCELLANEOUS PROJECTS MICROFICHE - Discussions with Systems regarding some design details.
-
12
3YSTEM SOFTWARE I
O
.
J
;.'•'•
18
\
ITEM 371 18:06 Aug14/79 HANSEN, JIM (UM)
112 LINES
PRIME=268
HASP priorities again: A firm proposal. The time has come to make an official statement and proposal regarding changing the priority scheme in HASP. The way it vorks nov: 1. HASP uses prio 0 for all LOW and DEFER jobs. Prio 0 is strictly a FIFO que, vithout regard for DEFER or LOW class and based on submition time only (ignoring time of execution completion for print). Prio 0 is used for all phases of batch jobs, vhile normal priority assignments are used for *PRINT* from terminal sessions regardless of class. 2. Priorities for NORMAL execution and all terminal initiated PRINT jobs are assigned from assembled in tables in the range 1 to 10. UM uses a "doubling" factor for quantity vs. priority in this range. I.e.: the limit for each priority doubles for each increment of priority. 3. Punch for LOW and DEFER batch is 0, for all others it is 8. 4. Prio 15 is used for jobs with immediate queing of print caused by errors in the "job card" detectable by HASP (e.g. missing user ID). 5. Prio 11 thru 13 are not used. Of course, priorities may be modified by operator control. With the exception of the intermixing of LOW and DEFER class jobs, this is exactly the way priority assignment worked when I took over HASP at UM too long ago. The way I did DEFER class batch jobs was intended to be temporary until ve could develope a better algorithm for queing. This situation has several objectionable characteristics: 1. The intermixing of LOW and DEFER jots in the que is an abomination vich MUST be fixed in any event! 2. The equal footing of terminal LOW class *PRINT* vith normal class batch output J S unfair to the batch users vho pay a higher rate for no better service and to LOW and DEFER batch users who get slower turnaround than terminal users for the same price. 3. The queing of LOW and DEFER batch jobs for printing based on the SUBMISION order rather than time of execution completion is inconsistent with the algorithm for NORMal batch jobs. 4. The current scheme prevents small LOW and DEFER batch jobs printing on the priority printer, since they are prio 0. 5. Very small LOW and DEFER batch print jobs must wait until all NORMAL class jobs print, regardless of size. This is an extreme penalty to pay for a small decrease in cost for a small job. 6. The queing of LOW and DEFER hatch jobs for execution based on submit time only is inconsistent with the treatment of NORMAL class batch jobs vhich are ordered first by estemated execution time. 7. The fact that a huge normal priority job must begin execution before a small LOW or DEFER priority job is allowed to start again is again an extreme penalty for LOW and DEFER users to pay. 8. Setting all punch jobs to one of two priorities based on job class is inconsistent vith all other HASP queing principles. It would be more equitable to que punch jobs using, the same sort of priority scheme used for printed output. HASP ques NORMAL class jobs for execution, print, and punch using a priority scheme based primarily on "quantity" of desired resource and based secondarily on time of completion of the previous job phase. The primary justification for this scheme is, I believe, that it is better to keep one person waiting vhile many are working than to keep many people waiting while one works. Since LOW and DEFER classes were created to help shift the load toward times when the system is less hevily used, it seems this principle should apply similarly within those classes. Currently it does not! The decision to permit users to specify a higher class of operatioii for batch jobs durring LOW or
DEFER periods was made, I understand, to allow people with sufficient funds who are in a hurry to pay extra for improved service. If one accepts the arguments for priority assignment within a class, it can be applied equally well, I believe, across classes. I submit, therefore, that "improved service" need not mean, as it does now, an absolute preference for one class over another, regardless of job size. I suggest that a more equitable and operationally better view of "improved service" would be that for jobs of similar "sizes", the higher class job is selected over the lower class job. To overcome the above deficiencies and provide more equitable service to batch users of LOW and DEFER class batch jobs, I propose the following new scheme for priority assignment: 1. All classes of jobs have a priority computed based on the "quantity" of service requested. 2. For lower classes of service, this priority will be decremented by a factor designed to reflect the difference in cost of for the given service and class. 3. The same algorithm vould be applied to all services, including punched output. 4. LOW and DEFER class execution vould continue to be limited to restricted hours. This scheme could be "coerced" to vork just like the current scheme by selecting appropriate priority computation tables and priority decrements. If the above proposal is acceptable, I further propose the following more specific characteristics at UM: 1. Prio 15 be reserved for special service, accessable only via intervention. 2. Prio 14 for print be used for immediately printed batch jobs with batch control card (i.e. $SIGNON, #LIST, etc.) errors. 3. NORMAL class jobs be assigned priorities in the range 4 thru 13. 4. The priority decrements be as follows (for both batch and terminal users) for the service requested (cost differential/decrement): class execution print punch ~~x1.5/-2~ x1.3/-2 x1. 1/-1 LOW DEFER X2.7/-4 x1.3/-2 X1.1/-1 notice that the rates for printinq and punching are the same for LOW and DEFER class jobs. I vould like to undertake these changes as soon as possible to improve service, to allow for documentation changes this fall, and to stop complaints. REF TO ITEMS 268 REF BY ITEMS 378 389 7 VOTES/FEELINGS "Queue" is proper spelling because French people spell that way for the vord "TAIL". I like the proposed change if it isn't too much vork. (-Jeff Ogden/UM) This is a major policy change which vill have to be approved by Emery and Finerman (among others). "Objectional characteristics" 5 and 7 are intentional and probably shouldn't be changed. (MTA) I agree with Mike. And if you are going to change things, what I think is really needed is a vay to print my 100 page job after 200 pages of 5-page jobs are printed or some such. (CFE-UM) Too bad ve don't seem to be able to coerce UMMPS to knov vhether a user vas "NORMAL" "LOW" or "DEFIRRED". If it did, the time slices could be allocated appropriatly. DanG/UM I'm not French and this is not France. I like QUE! Gail: I've heard most of the complaints listed in the item. JHH/UM What sort of complaints do you currently get? (ghl/UM)
15
ITEM 373 14:03 Aug15/79 53 LINES HANSEN, JIN (UM) HASP: Hov about WAITUNTIL or HOLDUNTIL? THE PROBLEM: For many good reasons, which will not be enumerated here, users need to be able to do something in a batch job at (or after) a specific time or date. Users currently do this by submitting a batch job for LOW or DEFER class execution, vhere this is adequate, or by doing a timed wait in the batch job. The former solution is often less than satisfactory for the user and the latter less than satisfactory for the system. If a DEFER or LOW job does not run during the usual time because the system is dovn, it may not run in time to do its required task. Currently UM allows a minimum of 3 batch jobs to run at a time under heavy load conditions. If 2 batch jobs are doing long timed vaits, only one "slot" is available for "active" batch jobs. A PROPOSED SOLUTION: I propose a new parameter for the signon card to permit the job to be held until a specified time, then released for standard execution procedures. The keyword to be used is a bit sticky. Perhaps "WAITUNTIL" or "HOLDUNTIL" with 4 letter abbreviations accepted. I suggest that initially the syntax be restricted to a simple time/date format, and later expanded to a more general time/date format. The first time HASP gets the CPU after the specified time/date, the job vould be released from the special hold. This vould behave as if the job had just been submitted at a card reader or *BATCH* at the release time; it vould not guarantee execution by any specific time and vould be totally independent of the job class. (I.e. LOW or DEFER jobs vould still be required to execute during the appropriate hours.) We could also limit the delay period to something reasonable, say 72 hours. The initial time format vould be hh:mm:ss with the seconds optional. The date format vould be mmmddyy vhere the month is a 3 letter month abbreviation, the day is required, but the year is optional, defaulting the the year vhen that date NEXT occurs. If the time is omitted, it vould default to 00:00:00 on the given date. If the date is omitted, it vould default to the next the current date if the time has not passed, or the next day if it has. EXAMPLES: IAITUNTIL=12:30 WAIT=JAN01 HOLDUNTIL=(17:00,JHL01) HOLD=(AUG15,05:30) IMPLEMENTATION: I can see no impact on MTS except to ignore the parameters. HASP vould do all the holding and releasing. Specifically, the checkpoint processor or a nev processor would do the actual releasing of the job, tho it might be releasable by operator cqmmand. If anyone has a better idea for the keyword, PLEASE let me hear it. This should be quite easy to implement in HASP. 14 VOTES/FEELINGS Sounds good to me. JAN01 and JAN1 should work and could you allow something betveen the day and year say JANT/79 or some such? (-Jeff Ogden/UM) Oops! *FORHAT zapped the slash I had between the day and year, Jeff. R.e. job B, job A can *BATCH* job B. JHH/um I like the idea although I am less than happy about the date notation. (CFE-UH) If job B must run not after time X but AFTER job A,(A&B may be in different prio. classes): if B is held til time X, A A still not started for some reason, short B could still run 1st. Seems this vould be more common. WAITUNTIL is nice but doesn't help
16
Sounds r e a s o n a b l e . I t ' s not t he n i c e s t vay to v r i t e d a t e s , b u t I c a n ' t think of a n y t h i n g b e t t e r . How does t h i s r e l a t e t o Howard's job s c h e d u l i n g p r o p o s a l ? (ghl/UM) The keywords a r e ok, b u t I d o n ' t l i k e HOLD a s an a b b r e v i a t i o n f o r HOLDUNTIL. HOLD should be used for a r e q u e s t t o hold t h e j o b for operator intervention . (MTA) Good i d e a . I t would be n i c e t o be a b l e t o do something s i m i l a r for d i r e c t i n g t o * p r i n t * , e t c . from a t e r m i n a l . I l i k e WAIT b e t t e r than HOLD. (bob) I l i k e t h e i d e a . How about "QUEUEAT" f o r the keyword? I t makes sense given i t s f u n c t i o n . G. Helffrich/UM There i s a h i g h ly t h o u g ht of s c h e d u l e r used a t t h e U n i v e r s i t y of Cambridge, England which does many of t h e s e t h i n g s . . . Software P r a c t i c e & E x p e r i e n c e Vol5, No1 pp29-49 (1975) f o r d e t a i l s .
sounds ok, but vould l i k e max v a i t i n t e r v a l to be 1 week or so so t h a t you could run a weekly job a u t o m a t i c a l l y t h i s vay - i t vould resubmit i t s e l f each time i t r a n . (BAC/SFU) This sounds g r e a t ! -Mark Wei,ser I LIKE WAITUNTIL BETTER, ALSO ALLOW AT LEAST A WEEK. STEVE T. S e v e r a l u s e r s here have asked for such a f e a t u r e a l r e a d y . Prefer"WAIT" a s keyvord, a t l e a s t a veek t i m i n g (and p r a y for no c o l d s t a r t s of HASP!!!!) vould be n i c e . grd/rpi To t h e j o b A&B p e r s o n : If someone r e a l l y wanted t o do t h a t , he could have one b a t c h t a s k (A) do a l l of i t s p r o c e s s i n g , then i n i t i a t e the o t h e r (B) through *BATCH*. DanG/UM
17
ITEM 378 19:01 Aug21/79 39 LINES PRIME=371 HANSEN, JIM (UM) Temporary Kludge for HASP Queing In item 3 71, I suggested a change to the vay priorities are computed in HASP. The suggestion was prompted by numerous user complaints, both verbal and in writing Since that change requires a policy change (at UM) regarding what exactly the higher rate buys you, it vill probably take quite a vhile to approve. As a TEMPORARY measure, I vill make some other changes to ansver some of the user complaints. First, I vill put in a kludge to ensure that DEFER jobs are qued after all LOW jobs. DEFER and LOW execute jobs vill still be FIFO within the respective 'sub-ques'. This is not as desirable as a true priority queing, but does eliminate the glaring error in the current scheme. Second, HASP will compute a priority for LOW and DEFER batch jobs at the end of execution based on pages to print. The jobs vill be qued with that priority, hovever the printers vill print all possible normal priority jobs before starting a LOW or DEFER job. LOW and DEFER jobs vill be printed intermixed since the charge is the same for printed output in either class. This means that small batch print jobs can print on the PRIO printer based on size, regardless of job class, but only if there are no NORMAL class jobs of sufficiently lov priority. Of course, SYSTEMSTATUS (JOBS) vill have to be changed to take this into account vhen counting the jobs qued ahead of a given job. This scheme also leaves standing the preferential treatment for terminal users over batch users during LOW and DEFER hours. Third, HASP vill que all punch jobs at the same priority, regardless the job class. This is allowable, I believe, because punch output rates are the same for all classes. This vould make the punch que FIFO based on time of completion of the last job phase (execution, MNET reader, or *PUNCH*) rather than based on the submit time for LOW and DEFER class jobs. I must change the algorithm for punch queing anyway, since 'HASP vill be re-queing the job for printing in all classes. I do not feel this is a truly equitable solution and I vill continue to pursue the item 371 proposal. It is, hovever, an improvement. REF TO ITEMS 371 4 VOTES/FEELINGS Yes, much better than current behaviour. dvb. I agree vitb this except: LOW print jobs should perhaps be considered for printing before DEFER because it costs more to produce them, and punch does cost less for LOW and DEFER than for NORMAL. (CFE-UM) CFE is right about punch rates, but I totally disagree about print. Pending a proper policy decision by the UM CC, I will make no changes at all! JHH/um It's an improvement. Is there enough punching to make punch jobs worth much trouble? (ghl/UM)
18
THE UNIVERSITY OF NEWCASTLE UPON TYNE COMPUTING LABORATORY Director: Profraor of Computing and D i u Procruing:
Profeuor of Computing Science: B. RANDELL, B.Sc.. A.R.C.S.
Reference:
Tclcphtme Newraitlc (0632) 292^3
6/7
Executive Diiector N.U.M.A.C: Min _. It. BARRACLOUGH, JvLSc
29th August 1979.
Dear Bruce, Having read your paper for the Detroit MTS workshop, I thought it may be useful to publicise an accounting utility I have been developing at NUMAC, As you will see it is intended to take over the functions of most (if not all) of our current accounting utilities. Having one utility also makes the job of implementing multilevel projects a much simpler proposition. I shall send a copy of this to the MTS share Newsletter and invite comment from any other interested sites. Yours sincerely,
JxJ^oUfsl *-** MIKE DOUGLASS
Bruce McKenny, Rensselaer Polytechnic Insititute, Troy, New York, U.S.A.
1 2 1 81
MD/HGM
19
1 An Accounting Utility He are currently presented with quite a protlem when it coies to laintaining and using accourting utilities. The major frotlen seems to be that there are so lany of tbei often vith overlapping functions. I have partly implemented a Den utility vhich takes over the functions cf many of the current utilities. It is bopec that eventually any accounting (as distinct frcm tilling) furction vill be carried out using this new utility. A list of some of the utilities I would hepe to replace are flCCBAINT JCCEISFLAY BCCXEISPLAY IBJEAIliT EHJEISFLAI XCCCUNTING CIS GPDATE accounting initialisation routines • FIX •STATUS IIHEISFLAY This nev utility has a much tetter coBsard language than the accounting els. A description of this vill be found in appendix 1. levels c| access If ve visb this utility to replace at least those tenticned above, ve sust be able to allow different levels cf access to different users, e9 only ACC. should be able to do everything vhile the ordinary user should be able to alter nothing anc only look at certain fields in bis accountirg record. The levels cf access I have ispleiented are: c
«
Ordinary userA Can only look at his cvn accounting record.
"••
_.J_£J_s£t funds.. Can allocate funds between nembers cf th«a project for vfaich he is the authorised id.
2.
J_£__j__ct leader.. Can allocate funds, and create ard delete ids for the project for which he is the authorised id.
3.
ACC. himself.. Can do anything. What access a user has is indicated by using flags in the accounting record and the authorised id in the project
on
record. Multilevel projects Multi-level projects would be easy to iopleoent if the scheie I have outlined in appendii 2 is acceptable. facilities offered by this utility *»• *
The following available.
facilities
are
(or
seen
vill
be)
CHEAT! user or project records DESTROY user or project records DISPLAY user or project reccr^s or directory cntrjeMCElpi user or project records REBATE a user UEEATE a us e r An ordinary user will only be able to use the DISPLAY cosmand. By an appropriate choice of keywords *e can provide all the facilities of *STATUS in a vay that is invisible to the usejp. The rest of the conmands vill be available (to varying degrees) to certain privileged (it scne sense) users. Input to the utility is free-format, that is Hanks are ignored between keywords and delisiters. Cca-iands are optionally terminated by end-of-line and can alvays be terminated by a sesicclcn. The conmand fcrmat is given in detail but a brief description appears here.
in
appendix
1
A co.mand is split into four parts which appear in the following order: 1. 2. 3. 4.
Cosmand keyword Modifiers User spec. Keywords
the last three are optional. The modifiers are a list of keywords each preceded by •a» and optionally~,•-,. Eg 8HER3VIBa-iEEFPM. The user spec specifies what records we wish to deal with. This takes the fora cf a Coosa seperated list of project ids, user ids, userid blocks and one or two other constructs. A user id is specified simply by entering the id, by preceding it ty ,USER=» or by surrounding it by sii-gle quotes. p1
3 A project •PROJECT^.
id
is
specified
by
preceding
an id by
A userid block is two userids separated by '-*• 'AIL* nay be specified with obvious results and also All (), or IES<
facilites
The utility vill log all changes to accounting and project records. It vill do this ty putting CEESTAT records into the drop area. The full fcriat cf this record has not yet been decided but vill probatly contain an original field's contents and the change made. It vill be possible to turn this feature off if ACC. is using the facility and is doing the Weekly update. This vill prevent the drop area being flooded by records. Status cf the utility Much of the utility has already been iipleiented. It is currently vritten in the version of A1GCIR b^ing developed at HUBAC. I intend t 0 rewrite it in FLUE some tise in the future. It currently does all the things that ACCEISFLAY, FRJEISELAI, EIREISPIAS, ACCKAIN1, PBdEAINT and the accounting CIS do, though it is net yet fully tested. It vill not need much vork to replace such utilities as *FIX and the update. I use a }ii**fn interface to the accounting files vithin the utility and anticipate little trouble in revriting it to use the UEC MIS accounting routines.
Appendix _l l<.£fat of the coimands This is given in a BNE-like f e n . The foriat is: ::= [ ] [ ] [ ]
:= CREATE | EESTRQ1 | EISFLA1 | HOEIF1 | REEATE | UPEATE | MTS | SET | STCE | TlBE
ocdifier list>
:= | ,
:
= = 2 (initially) := EEFORE | KOJi I HER I VERIFY | IGTOT | EEFPS | ESFRJ
::= | , ::= All | | | ( _•¥*«*. ) ::= - ::= prcject= ::= AIL | IDS ::= | USER= | •« : := |
23
: := PROJECT = | FORMAT = | EREFIXCBAR = | ECHO • I VERIFY • | PABABETEB = | BODIPCHAE = | USTIBE • | *• TRACE = I IOG = | USER - | ACCESS = DEFAULT
"P6LQ/0OU)
Ot-lfl
* v S «
ACC. I •*
c_.j c±
ftU
^
lr»|T. +C
«*>••
<•***•*'
|trCU()«.
srt**.*A>A
W
-&-*_*..
24
«.
SYS>
U**_J-tr
«—J
6
Appendix 2 Bulti-leyel projects Here I describe a scheme vhich vill allow multi-level projects and hopefully satisfy everytodies needs. The scheme I outline should involve the miniou" of change to the project records and the project director?. ^ A given project record will have three fields cf interest: the directory pointer, the authorised id and a new field, the project to which it belongs. The directory pointer gives us the index of the entry in the directory which contains a list cf ids and, for each id, a flag. This flag indicates whether or not the given id is a project id. For exaiple assume project XCOO has in it's associated entry the ids X1C0, XAC1, and XA02. X1CC is a project. X1C0 has in it's entry X200, XB01, XE02. X2C0 is a project. X2C0 has as it's entry XCC1, XCC2.. This aeans that X1C0 is a sub-project of X00O and X20C is a sub-sub project of XCOC and a sub-project cf X1CC. Mote that by this scheme a project can have attached to it both user records and sub-prcjects. I'I net sure what use it is, it just seems sore general. I also see no need why the authorised id for say 1C00 actually be attached to the project.
i.eed
when allocating funds betveen a group cf users, the laxima that take affect are those in the sub-project tc which that group is attached. A given project leader vill only be able to allocate funds betveen those ids iamediately attached tc his project. I.e the funds for X100 can le given tc users XBC1 and XE02 and tc the project X2G0, but not to the users XC01, XC02. iJSple mentation Modification of the new utility tc use multi-level projects vill be fairly simple. Codification of the directory format and project records is again easy, in the case cf the project records it can be done with the EDITCB. DIRAEE, DIRREXT vill need to be extra paraseter the type of id.
25
icdified
to
take
as
an
UNTVFTJSTTY 0 F MICHIGAN Computing Center 22 September 1979 To: Programming and Counseling Staff rora: Jeff Cqden Re: The FP22Q version of MTS
w
nra today. Changes A nev version of MTS was installed at 6:30 are listed below. Tf vou run into problems please let me or version of the Georqe Helffrich know. This is a corrected system that was installed at f am Friday and taken out again at 10 am. 1)
fixed. It caused A buq in the SCANSTOtt subroutine was space to be allocated in the system segment and then never released.
2)
The EMPTY subroutine was changed to accept a logical T/0 unit number in GRO or a logica 1 .1/0 unit name in GRs 0 and 1 in addition to a Fmjn pointer in GEO.
3)
You ma- now $niSPli\Y SOIIRC to learn what FTnames are the current and previous *S0URCF*. You may also ^DISPLAY SINK ^DISPLAY to learn about the current and previous *SINK*s. •SOURCE* and *DTS"LAY *SINK* are synonyms for D I S P L A Y SOHRCF and ftDISPTAY SINK.
1)
the name of the You may nov SDTSPTA. SYSTFM to learn current Ramrod system, the date and time ( the Ramrod system It HM the Ramrod vas written and the MTS model number. system name and the MTS model number are both five characters long, ^ne first, two characters are taken from the second tvo characters of tho name of the month, the next tvo dirrits are + ho day of the month and the last digit is the last digit o^ the year. So ^P229 means 22 September 1979. $nrsPLAY MOHFL will give this same information. The Ramrod system is that part of the system that is maintained usinq the Pamrod utility. The ramrod system is loaded at TPT, time and the various components that make it up can normally only bo changed by re-IPIing.
5)
The SUISPT.AY *pdn* command where * T * is a magnetic tape has been changed to include the pdn in the first line of output. Trailing blanks are now removed from the ovner field as well.
6)
The ^DISPLAY command now uses the current device character ">" in commands of the form rather than alwavs using SDTSPIAY >T901.
6)
MTS now remembors more than 2t characters of an answerback. It doesn't, yet do anytfiing with the extra characters. This
26
2
is the first, step in being able to identify specific G7INF0 terminals attached to *ocs as express terminals. item #276; A^SRACKL, is a variable length item that will return all of the answerback. 7)
You may now say *SFT FNDFIIE= (ALWAYSl SOnRCEJ NEVFR) addition to «SFT Fvn^TTF^(CN|OFF|NEVER}.
9)
You may now r;av tSFT ERPCRDHMr= (LIBRARY INQLIBRARY \ OFF) in addition to •s7"" FPi>ORr>U"'!P= {FULL| CN|OFF) .
9)
In addition to PPINT-(PK|TN|ANY) you may also say PFTN^= (OClT.CIwr |^X IHPPPRCASEILOHERCASEI PTX?nCASE) on the SSTHNON, *s*"v and "^CONTPOI *PRINT* commands. nc and np?FRCASF are synonyms as are I.C, HC, PX, MIXEDCASE, and LOWFPCASE. Tnitiallv LC, ?!C, MX, MTXECCASE and LOWERCASE will all he taken to mean TN, while nC will be taken to mean ANY. EventualIv we want tc have them mean print this job on any printer that, can print uppercase or raixedcase. While it is the case that both the PN and TN printers can print uppercase and the TN printer can print raixedcase the reverse won't always be true. Someday we may have printers that can print mixedcase, hut not all of the characters in the TN character s<=>t. Tn fact, someday is today for certain remote printers where* we treate them as haveinq a TN At the present, printer when in fact thoy really don't. time HASP takes nc to mean FN rather than ANY, but that will chang° .
10)
The SSFT CAS*^ command war changed to allow MC, LOWFRCASF. t!P"FPCASF. and __TX_.CCASE as well as HC, IC, IX and MIXED.
11)
The FRIO=... Vevword on the "SsiGNON command and the RCPRINT=... keyword on the $SFT command were changed to allow initial substrings as keywords rather than a specific set of possible keywords that included a few, but not all possible initial substrings. HASP needs to be changed before this change will work correctly for the PRIO keyword on the fSTSNON command for hatch jobs.
12)
A number oF protection.
small
changes
were
in
made having to do with
1.1) The subroutine T 7 ^ which is used by system programs to allocate a device for direct use (use not through a OSR) was changed to just reserve an DMMPS logical device number (LDN) , but. not the device itself (no SVC GTUNIT) if GR1 contains the characters "NCNE" at the time of the call. FPFFH and G T V E B A C K were changed so that they could cope with this. The T n N can be released by calling FREED and will be released automatically when the program is unloaded. 14)
The raessaqo printed by MTS after a local time limit has been exceoded and SDSliSG is set off was fixed so it would AM get the PS:J riqhi-.
3 15)
Calls to ATTNTPP from hatch now give a return rather than the address of the MTS DSECT.
16)
The MTS tranfer vector was "cleaned up" a bit and unused entries were removed.
17)
The MTS common righthand table got too big so the dump, display and alter commands were given righthand tables of their own and the unused entries from the common table were removed.
18)
The job programs STGNCNM (signon message), SHUTDOWN and STARTUP were pulled out of the CMOS assembly. They still live in ramrod, STGNONM in the deck called SIGNONM and SHUTDOWN and STAPTHP in the deck called SHUTPOVN. In addition the STGNOflM job now prints any current signon message before reading a replacement From the operator's console. If you don't really want to replace the current message STOP or GCOSF the SIGNONM job.
19)
The code used to determine which projects can signon during system initilization was made less installation dependent by using a new global symbol, 5IPLPP0J, in COPY:GLOBALS. At UM this is set to VOPN, but more than one project or initial substring of . project could be specified.
20)
The code used t.o determine which projects belong to members of the "systems" staff was made less installation dependent by using a new global symbol, BSYSPROJ, in COPYtGLOBAI.S. AT UN this is set to W, but. more than one string or initial substrinq could he specifiod.
21)
In the previous system there were two commands SSIGNON and JSIGNOFF and each had one abbreviation $STG for SSIGNON and SSTGH for tSTGNOPF. This could get us into interesting situations when spelling correction was invoked and MTS would tell you that vou were already signed on for example when what vou were doing is trving to signoff. Now if CMDSCAN=UNAMBTG SSTGNON is taken as signon, SSIGNOFF and $SIGH as signoff and fsio as signon of you aren't signed on yet and signoff if vou are. If CMESCAN=AMBIG SSIGNON is taken as signon, tSTGNOFF, SSIGNOF and SIG CCID entered when vou are already signed on results in an error and if vou enter CANCFL or hit attention ycu won't get signed off.
22)
CUINFO item 59, SIGSKORT, may now be used to set the default type of signoff (LONG, SHORT or t). Before this value was onlv used if the signoff came as the result of something other than a signoff command. The LONG, SHORT and $ Keywords may he used on the signoff command to override the default.
23)
The data in COPY:ACC^OPMAT and COPY:STATOS^CT is
28
code
now
of U
also
4
available in the macros ACCFMT and STATFMT which are located in COPY:MTS.MACROS. This makes it possible to update tho accounting and statistics record formats using •CDUPDATF in a fashion that fits in well with that used for the rest of MTS. COPY:ACCFORMAT and COPY:STATESECT still exist, but programs that use them should be changed to use the macros so we can give the files the ax sometime in the future. 21)
All of tho switches at the start of the accounting record that are used bv M^S were qi ven FOUs and many of the references to these switches were changed to use them. T'll get to thorn all given enough time (and energy).
25)
The rules for who may specify public pkeys using the $SFT EXECPKFY=pkoy command and {PKFY1EXECPKEY}=pkey option on the "SPUN command and friends were changed. Before only "rich" users could use public pkeys. Now only users with the "can create pnhlic file" bit in their accounting record can do so. This seems reasonabl because these same users can create public files and given them public pkeys directly. Note that "rich'' users won't be able to specify a public ^^"EV unless they also have the can create public file hit on, even though the "rich" bit currently implies can create nub lie file. I'll ask the business office to turn the can create public file bit on fcr most rich users Mondav.
26)
M T S uses a little more care in getting the CCID from the *STHNCN command now. Before a command of the form *SIG CCIf>T=5 would have worked, but the T=5 keyword would have been ignored.
27)
«SKT RCPRTNT=NON?FPO is now allowed. It does just what it says, it causes the RC to be printed if it isn't, zero, unlike manv of the other RCPRINT options there is no check to make sure that the value is <255 or some such. Of course tho 'T* option must ask for the RC to be included in the termination message if you really want the RC to print.
29)
A return code of « Fr.m tho nsP entry point WAITPOR is now taken to mean no password is needed for this run. The PIT.? and OPFP ^SPs wore changed to use this feature. The ability to request no password processing using a special "notify" type return still exists and is used by the POPR and BNCH DS9s. ^he F T L * and CpFP DSRs were using the special notifv return, but this change makes things much simpler.
?Q)
A bug in th<=> oodp f or sionoff that would result in a SNARK i f a job attempted to signoff and statistics (STAT job) collection was going on was fixed.
10)
MTS now accepts and ignores tho VJAITUNTT.t= keyword on the siqnor command. This is necessary so Jim Hansen can go ahead and make the necessary changos to HASP to implement
29
5
BATTUNTIT.. 31)
The RCUTF- keywords on the $SIGN0N and ^CONTROL *...* commands may now be specified as ROHTE^'....' as well as simply P01TK... This is to allow blanks to be included in the host dependent portion of the route information for Merit network jobs. HASP changes are needed before this will work correctly for PC^TF keywords used on the SSIGNON command. .Tim also plans to allow this en the #NET card to make the ^SIGNON and *NFT command processing the same, although blanks can currently be used on the #NFT card even without quotes.
32
Several HSINGs and DPQPs were moved or added in a general attempt to clean things up a little.
33)
Calls to KWSCAN from the CMOS assembly were changed to use the common MTS righthand table explicitly rather than implicitly using a zero RHT address. Once again I'll get them all someday.
34)
All uses of the SPTPARM macro in the MTS assemblies were switched to SKTPARMH which is located in COPY:SFTPARM. The copy of SFTPARM in COPY:MTS.MACROS was deleted because it is no longer used and because it was verv much out of date.
35)
The macro SVCEon in COPY:MTS.MACROS was deleted in favor of a better macro with the same name in COPY:MISC.MACROS that Mike wrote.
36)
It A ROUTINE declaration for NULLRTN was added to MTSFQH. is a buddv O-F NULIRCT and keeps those assemblies that don't use NUI.LRCT from producing error messages.
37)
A GUINFO item number was reserved for use by UQV. were reserved for use by UBC a while ago.
38)
A check for reasonable LDNs was added to GTVFBACK.
39)
JCANCEL was changed to make PW= and PASSr40FD= the command. It was just patched before.
30
Several
illegal
on
SUPPORT
V~
«-
SOFTWARE
31
July 1979 New Features in AS_.iJ Mike Alexander July 30, 1979 This rae::o describes several changes made to ASMH since the last uodate to MTS Volume 14. The version of ASMH described here is in H?W:\S*H. It will be moved to *ASMH after user documentation has been prepared and it has been used by staff for a while. Please use this version and let me know of'any problems. Jjany of these changes were based on changes made by Gregory Uushial at SLAC. The underscore and macro library changes were aade by .Michael Hay ward at UBC.
Bugs Fixed and Minor Improvements The following minor changes are setting of the EXTEN parameter.
available
regardless of the
1.
?!N07S statements with more than 255 characters in the message work properly rather than giving unpredictable results.
2.
A macro parameter expression longer than 864 characters is message instead of giving truncated with an error unpredictable results.
3„
If a PRINT statement doesn't change anything and would otherwise not be printed, the assembler will not force it to be printed anyway. If it changes anything, it will beprinted always.
4.
The alignnent in the BSD records for a DXD with multiple operands will be the strongest alignment of any operand, rather than the alignment of the first operand. The length will be sufficient to include anv bytes added betveen operands for alignment purposes.
5.
A warning message will be issued if any AIF, LCLx, SBLx# or S"Tx statement ends with a comma. The most likely cause of this is a continuation card that starts beyond column 16. Previously this condition was accepted with no error message.
6.
An error message will be produced if any non-blank characters are found following the first blank in the parameters passed to the assembler.
7.
The header page includes assigned to files or *...*.
more
32 Mew features in ASMH 1
information
about
units
July 1979 8.
Some pass 2 error messages (primarily for undefined symbols) now contain some source program text to identify the error better. More are coming.
9.
A now error test and diagnostic message have been added: IBV056 - HSTHG RENDERED NULL BY A PRIOR ACTIVE USING Given the rules governing base-displacement resolution of implied addresses (choose the register giving the smallest displacement, and the highest-numbered such register), this message will be issued if it is found that a prior active USING's range overlaps and supersedes that of the USING being processed. The severity level of this error is 4.
New Parameters and, Logical I/O Unit Usage
(^
1.
Units 2 through 10 and 0 may be used for macro libraries in -that order.
2.
The RHL2 parameter causes the assembler to allow half word relocatable adcons with no error message (useful for assembling TABLES) . The default is N0REL2.
3.
There is a ?T?XTT=xxx parameter that can be used to specify that a user supplied subroutine is to be called for every line printed by the assembler. I am not very happy vith the way this is done and may want to change it. For this reason it will not be documented for users yet. The exit 'routine name is specified by •PEXITsIXXX1 in the assembler parameters. XXXX is the name of an KTS file containing the exit routine. The name must not be longer than 18 characters. The exit routine is called using standard OS linkage conventions. The parameter address list whose address is passed in R1 is: A(the line to be printed) A (the SPRINT parameter list) A (OCTL values)
A(line type flag byte) #
The first two are self-explanatory.. . The OCTL values', 4 successive halfwords, will be described below in the section "Changes to the Language." The line type flag is a single • byte whose bits are defined as: X»80» - This line each page.
is
part of the title field at the top of
, New Features in AS3H 2
33
.July 19^9 Y»40»
- T h i s l i n e i s a machine i n s t r u c t i o n l i n e , i . e . , output t e x t i s p r i n t e d a s t h r e e halfw^rd f i e l d s .
the
X ' 2 9 ' - T h i s l i n e i s a object program output l i n e in which t h e t e x t i s p r i n t e d as a double word. XM0» - This line is cross-reference.
part
of
the
symbol
table
X»09» - This l i n e i s p a r t of the post-assembly messages. X'04» - This l i n e i s p a r t of the pre-assembly l i n e s (EST) l i s t i n g , header page, and s u c h ) . X'02' -
(unused)
X'01' - This line is the first output line of this assembly. When the exit routine returns control to the Assembler, R1S must contain a return code. If an invalid return code is returned, the exit will be turned off (i.e., never called again for this assembly). The valid return codes are: 0 -
print the line in the buffer
a -
don't print the line in the buffer
8 -
print the line and return back to the exit with an empty buffer
12 - don't print the line and return with an empty buffer 16 - final 'return for this line (same as RC 4) 20 - kill the exit (i.e., don't call again for this assembly) 4. —*
The currently active usings will be printed at the top of each page if the UMAP parameter is active. If this will not fit on two lines, it will be truncated at two lines without warning. This can be suppressed by specifying NOUMAP in the parameters. UMAP is the default. The usings printed are the ones current as of the end of the assembly of the first instruction on the new page.
Changes to the Language The following changes to the assembly language are available if the EXTEM parameter is active. 1.
The expression on an ORG statement can contain symbols not yet defined in the program. This is supposed to work in the IBM version of ASHST, but doesn't.
34 New features in ASMR 3
July 1979 TnTNT statement has a new option: "MSOUpcE" or " 30X53*! PCS". This option is ignored if the G^N option is "NOG?:-:''. Otherwise, it controls whether the source text for macro generated statements is printed as well as the object cod=>. If "MSOUPCS" is active (the default) , the output is as it. alvays has been. If "N0MS0U3CE" is active, the output indoles the object code for macro generated statements, but not the source text, i.e., the right hand side of the listing will be blank for macro generated statements. There are ten new extended branch op codes (the corresponding old opcode is given in parentheses): BGT (BH), BGTF (BHR) , BGE (3*IL), BGTR (BNLR) , B£Q (BF) , BEQR (B^R) , BLE (BNH), BLER (BNHR) , BLT (3L) , BLTR (BLR) . The attributes of a symbol defined on a !)XD will be the same as if the symbol were defined on a T>S with the same operands. If -JOEXTEN is specified, the attributes will be as if the symbol were a section name. An attribute reference other than T' to a symbol with type "M" which is otherwise undefined will cause a forward scan for the symbol rather than an error message. A symbol will be type "M" and undefined if it has appeared in the label field of a macro instruction and has not been defined elsewhere. Underscore ("_") is a legal alphabetic character which can be used anywhere A-Z, it, 2>, or $ can be used. A new system global set symbol, CSYSNKST, is available in macros only. It contains the nesting level of the macro call. The top level macro is at level 1. The pseudo op OCTL provides a way of passing parameters to the print exit. There are 4 operands allowed on an OCTL statement, each of which must evaluate to a 16-bit absolute expression. These are evaluated and put into the corresponding halfwords of the OCTL values passed to the exit Note: The routine designated by the PEXIT parameter. Assembler places no meaning on the operand values; it simply evaluates thftin and passes them to the print exit. For a missing (null) operand, the value that was there before is left untouched. If the OCTL has no operands, the values will be reset to their initial states which are 0, 9, 15# and 70 respectively. Qualified . USINGS (or,' more properly, labeled UStHGS and gualified symbols), are a major new capability of ASRH, allowing much greater control over the resolution of symbolic expressions into base-displacement form with specific base registers.. The mechanics of this, facility are rather simple.
35
First, put
..In ly 1979 a label on a nsiNG statement. Then, to force the Assembler to resolve a symbol into base-displacement form through that "SIVG, qualify the symbol by preceding it with the label on An example of Labeled the USING, followed by a period. tJSJVGs and Qualified Symbols would be: PRIOR USI5G IHA!)Cr»,R10 NEXT USING IUADCB,R2 MVC PRIOR.DCBLRECL,NEXT.DCBLRECL without l a b e l e d USINGs, t h i s would have t o be w r i t t e n i n t h e awkward and i n e l e g a n t form: USING IHA1>CB,R10 HVC DCBLRECL, nCBLRECL-IHAOCB (R2) or MVC T)CBI.RECL-IHAnCB(,R10),DCBLRKCL-THAUCB(R2) The l a b e l on a USING may appear i n t h e name f i e l d o f a n o t h e r statement. The two u s e s o f t h e symbol a r e d i s t i n c t . If a l a b e l a p p e a r s on a USING, any o t h e r USING w i t h t h e same l a b e l i s dropped. If qualified s y m b o l s a r e used i n an e x p r e s s i o n , the qualifiers will cancel if possible. The r e s u l t a f t e r a l l cancellation must be an e x p r e s s i o n with e i t h e r no q u a l i f i e r o r one p o s i t i v e q u a l i f i e r . For e x a m p l e , THIS.SYM.'1 + NBXT.SYM2-N1.XT.DSECT
is legal and other hand,
is an expression qualified by "THIS."
On the
THIS.SYH1*NEXT.SYM2 is illegal since neither qualifier cancels. A qualifier may not be used with an absolute symbol and qualifiers may only be used in expressions that will be decoded into base-displacement address, i.e., in machine instructions or S-type constants. As is the case with non-labeled USING statements, a symbol (in the first operand) or a register (in any of the remaining operands) may appear in any number of USINGs. However, in the case of qualified USINGs, as long as all the USINGs have unique labels, all are considered active and are eligible to be used as qualifiers. There is a very basic concept about labeled and non-labeled USINGS that needs to be understood. In non-labeled USINGS, a register implies data, in the sense that a register may imply only one piece of data at a time (i.e., when a register that appeared in a USING appears in another USING, the prior USING is dropped). In labeled USINGs the reverse is true: the data
3C New F e a t u r e s i n ASMa 5
July 1979 implies a register. That is, a single register may appear in multiple USI'Ms, aj_l being active, so long as all the USIVJs havo unique labels. (dropping of labeled USINGs occurs only when the same labol appears ii. a USING or URO? statement, not whf-r. i reneat.ed register appears.) Labeled TSTNIs do rot interfere with non-labeled USINGs. '•her. the assembler resolves an implied address into basedisplacement form, either the expression to be resolvod was qualified or not. If it was, the specified labeled nsiSG will be used. If not, the active non-labeled nsiNGs will be scanned in the standard manner, looking for a resolution. A label on a USING defines an environment. As such, when you want to delete that environment, you must DROP the environment's name, the USIKG's label. An attempt to drop a labeled ^siNG by dropping its registers will result in those registers being dropped instead from the non-labeled USIXG pool. Yon would drop the Labeled nsiNGs in the example above by writing: TROP PPTOP,HFXT If a symbol in a DROP has been used both as a label on a HSING and as an ordinary symbol (so that it could be a register name), the labeled using will be dropped, not the register.
37 Features in ASMH 6
Au-qust. 27, 1979 Memo to: Programming and counseling staff From: Pat Sherry Re: Print exit for Assembler H This memo describes a subroutine which may be invoked as a exit (PEXIT) to the version of assembler H in the file NEW:ASKH. The ASMEDIT subroutine is used to make cosmetic alterations to the output generated by the assembler to provide a more readable listing, especially if the structured programming macros are used.1 The listing post processor is invoked by specifying print
PAR=PEXIT=W067sPEXIT on the $RUN NEH:ASMH command. as follows:
The print exit edits the listing
1.
The each this also the will
currently active usings will be printed at the top of page. The new version of the assembler already does if the UMAP parameter is active but the print exit must keep track of the active usings since it repaginates listing. The register indirection usings (see below) not be listed in the USING map.
2.
The current nesting level for the structured programming macros in inserted in the output for each statement.
3.
The cress-reference listing is pruned of all the internal labels generated by the structured programming macros (e.g., IFtnnn, DO.nnn, etc.) and also by the MSG macros.
4-
CASE macro invocations will have their respective case number printed in the right hand margin of the listing. If a CASE macro specifies a list of cases, only the first number is printed suffixed by the character "*", indicating more than cne case was given.
5.
FLAGS macro invocations vill have the flag mask, name, and address printed in the left hand margin of the listing for each flag declared. If more than one flag is specified on the same line of a FLAGS macro call, only the first will have this information listed.
6.
Macro invocations will have whatever object code is qenerated printed on the same line as the macro call. Only the first one or two instructions (up to eight bytes) will be listed by default. If PRINT GEN,NOMSOURCE is in effect, the output will include the object code for all macro qenerated statements, with the source text blanked.
*A similar post processor was available as a stand alone program in the file H067: SPASM. __
38
1
Items 1-3 do not Lcquir^ any special macro calls in the source file or macro libraries for the print exit subroutine. The additional features, however, require the macro library in the file W067:PBXIT.MAC to be specified on the $RUN NEW:ASMH command, and that the following statement be coded in the source file . before any USING or DROP statements: ASMEDIT fcsectir,INDCH=$1 where "csect" is optional and is the name of the initial CSECT if the macro is coded outside of a control section. The ASMEDIT macro initializes the print exit environment which redefines the following assembler instructions: USING DROP PUSH POP PRINT EJECT TITLE SPACE ASMEDIT also defines the symbolic register names R0-R15 and emits a USING for each of the reqisters with null dsects to allow an abbreviated form of address specification using the $ symbol. This permits instruction operands to be written as follows: LA MVC
R2,$R2+1 $R1 (4) ,=C»QQSV'
LA MVC
R2,1(,R2) 0 (4,R1) ,=C'QQSV
instead of
This notation may be used only for reqisters that do not have another unlabeled USING currently active. ' The reqister indirection character may be set to another character by specifyinq the keyword parameter "INDCH=char" on the ASMEDIT macro call. If "INDCr^NO" is specified, these USINGs will not be emitted and the register indirection notation will not be available. If the ASMEDIT macro is coded in the source file, the listing print status is controlled by the PRINT assembler instruction as follows: 1.
PRINT NOGEN is the default with generated printed on macro calls as detailed by 6) above.
2.
PRINT GEN causes all macro including the macro source PRINT MSOURCE option.
3.
PRINT
NOMSOURCE
object code
qenerated lines to be listed text corresponding to the
suppresses the text of the macro expansion
-
39 2
and iust prints those macro lines containing object code. The macro call line will contain up to eight bytes of the qenerated object code. This option will be ignored if the PRINT NOGEN option is in effect.
Example SPUN NEV.ASMH SCARDS=EDIT. S SPUNCH=-LOAD SPRINT=*PBINT* 2=W067:PEXIT.MAC PAR=TEST,PEXIT=W067sPEXIT
.0
THE UNIVERSITY OF NEWCASTLE UPON TYNE CO
t
COMPUTING LABORATORY Director: Professor of Computing and Data Processing:
Professor of Computing Science B. RANDELL. B.Sc., A.R.CS.
Executive Director N.U.M.A.C: Telephone Newcastle (0632) 29233
Miu fc. I J. tJARRACLOUGH, M,Sc.
17th August, 1979.
Ref: Dear Paul,
Thank you for your letter of 23rd July. Tour letter arrived just as John Law was about to send a tape (UNERD2) to Liz Sweet so I hurriedly arranged to have my SIMULA documentation appended as the penultimate file on this tape. This file contains the FMT source and a TN print of 'Programming Note 76 * SIMULA'. John's note to Liz explains the format of the file. PN76 is not as official NUMAC document (Programming Notes having been scrapped)but it is the up-to-date description of how SIMULA is run under MTS. PN76 is currently being converted into an official NUMAC document. SIMULA __as been in regular use here at UNE since more information on SIMULA and its use at UNE I'll refer of MTS Development Workshop IV (UNE 1978), paper 10L, in the session report, I 'presented a short sales pitch for
December 1975. For you to the Proceedings which, according to SIMULA'.
SIMULA was developed for IBM 360/370 computers by the Norwegian Computing Center (NCC) and all use of IBM SIMULA and derived implementations such as MTS SIMULA is licenced by NCC. Details of the cost of purchase or leasing can be obtained from: SIMULA Group, Norwegian Computing Center, Forskningsveien 1B, Oslo 3, Norway Telephone;(02) 46 69 30 Telex: 16 518 In 1975 when MTS SIMULA first became available, purchase of IBM SIMULA was fairly expensive but in 1977 NCC offered its SIMULA implementations to universities at substantial reductions. In the 1977 edition of the NCC publication 'SIMULA VITAE' the cost of purchase to universities was given as 50,000 Norwegian kroner while the cost to commercial companies was 125,000 Norwegian kroner. I have no information on current prices. Under an agreement with NCC, UNE has converted IBM SIMULA to run under MTS. In addition UNE acts as distributors for MTS SIMULA but only as directed by NCC. When suitable contracts have been exchanged between NCC and an MTS site wishing to run SIMULA, I will, on request from NCC, send a *FS tape containing the latest MTS version of the SIMULA compiler and Run Time System
A1
University of Newcastle upon Tyne COMPUTING LABORATORY
CONTINUATION SHEET..
•*"\
(RTS) along with an MTS installation guide and a user's guide (PN76 at present). Note that only the loadable programs will be distributed - no source listings of the SIMULA compiler and the RTS are ever disclosed by NCC. I beleive that as a result of our contract with NCC a reduction of 1C$ on the standard price of SIMULA is given to other MTS sites. If the MTS community wish to do a once and for all block purchase the price may be negotiable. Special arrangements would have to be made for any commercial use of MTS SIMULA.
„
Currently release 05oOO of IBM SIMULA is available in M T S . Due to pressure of other wo^K I have not had time to convert release 0 6 e 0 0 . Release 07*00 of the IBM SIMULA has just been (this month) distributee! by NCC and I hope to start work on converting this release at the beginning of October. Conversion could take anything from 4 to 6 months depending on the amount of work involved. Release 07o00 will have improved tracing and a symbolic dump facility* I am g. ad that at last there appears to be an interest in SIMULA developing within the MTS community. SIMULA is an advanced general purpose and discrete event simulation language and deserves wider use and publicity*
/
**\
Tours sincerely,
Ron Pringle. F. Pickelmann, The University of Michigan, Computing Center, 1075 Beal Avenue, Ann Arbor, M1 48109, Michigan, U.SJL.
«" , ,
RP/JW
42
<3
ITEM 372 10:18 Aug15/79 41 LINES TIFFANY, BERNARD (UM) STANDARDIZATION OF MACRO LIBRARIES. Do we really need the standardization of the macro libraries? Assembler, *FMT, *TEXTFORM, etc., all have a different format of macro libraries. I propose that the directory should be much like the assembler: first directory line starts at line 1. Each directory line should have the macro name and the starting line number in that order separated by a blank. *TEXTF0RM digresses from this by switching the order: starting line number and macro names. The directory should be terminated by either "00000000" or a blank at column 1 (like *FMT). The *TEXTFOBM says that "the directory will be terminated by the first non-numeric in column one (sigh). Currently *MACUTIL considers only the assembler-like macro directory line. It, also, allows fractions: i.e., 1.5. It is not a good idea to presume that each macro or copy section may have a name like the file names. Such names may contain illegal characters ":" shared file separator (i.e., COPY:PSA) , beginning "*» (i.e., *LLMPSEQU), and ", () " line number range (i.e., *LLMPSEQU (100)). All these "funny" macro names sounds to me just plain file names! For example, line number range specified doesn't really belong to a macro name unless we finally have "subfiles", where two subfiles in one file can start at line number 100. Presumably, regarding the requests from UEC, UQV, SFU, I may allow such "funny" names with a severe warning, and they may be considered as copy sections. Here I have received no such reguest from anyone at UM. Finally, every macro or copy section should start at specified line number or next available line, and terminate with "SENDFILE". Neither *FMT nor *TEXTF0RM conform with this manner. Any macro or copy section added to a macro library will automatically have SENDFILE added if not provided. Maybe the problem with macro libraries is due to the fact that the assembler is maintained by Mike Alexander at UM, *FMT by iebb at UEC, and *TEXTF0RM at UQV. My feeling is that we should decide on the standardization of macro libraries before things will go in undesirable way. Gail Lift tells me there are only a few *FMT macro libraries and no *TEXTFORM macro libraries yet. P.S.: *LLHPSEQU no longer exists at UM; it has been replaced by COPY:LLMPSEQU. 1U VOTES/FEELINGS Be should completely replace these old fashioned macro libraries with subfiles, where the macro names are subfile names. John Gourlay Yes John, but where are the subfiles? George? Hierarchical file systems are nice! DanG/UM The overhead in terms of space would to very high if you are thinking about putting one macro per file in a hierarchical system, Dan. Hhat other types of macro libraries (besides ASMH,FMT,TEXTFORM) are lurking out there? (ghl?UM) *11asr. I would like to have micro computer macros, but we don't have a cross-assembler that will handle them. RLH/Merit PLUS has yet another format. I think if we want a common format, it is essential to provide some kind of header for the members so that renumbered file can be recovered, (ab/ubc) I think it's more preferable to use "$ENDFILE" line with nothing or all blanks in a single line to signal the end of directory. That would be a lot better than all eight zeros or a single blank in column one. LB_.
43
I agree with most of your suggestions Bernard. If you want to propose a detailed format for a standard library, I will change ASMH to accept it. (NTA) Since TEXTFORH has no support for macro libraries, we could compromise. (D.Holberton/UQV) BATBOL has a library format that is a combination source and object library, (ab/ubc) I vould ask that directory entries contain both the starting and the terminating line numbers (you can keep the "$ENDFILE" too). Then these tvo numbers can be extracted and meaningfully used in MTS commands like $COPY ... Gav/UM Good idea, Gav. Would that be a compatible change? JHH/UM Bernard, the reason UQV allows copy section names to look like file names is to simplify the installation of new versions of the system (use one macro library for current and new mac lib for new version). G. Jackson/UQV I agree with article. Prefer directory simular to assembler withzeros as the terminator. Agree vith alan on header info line, also prefer ending line numbers. Also like idea of allowingnames for filenames as Jackson said, grd/rpi
44
ITEM 3 8 6 14:47 Aug28/79 HANSEN, JIM (UM)
52 LINES
An experimental Time and Date input toy. While writing a GLP to process statistics files, I needed a general time and date input routine. Because I was using the SPIBES parser, I decided to try an experiment making the input routine as general as possible. The test version of the routine is in W167:TIME.DATE and is SRtTNable. It is not a subroutine, but is designed to be used imbedded in the syntax of other commands parsed by the SPIRES parser. I will NOT make it a subroutine! I announce it here only because some folks might enjoy throwing times and dates at it to see how well it works and to be inSPlREd to do something better. The program reads from GUSER and prints on SERCOM. It recognizes a few simple commands, but if the input doesn't match a command, it tries to parse it as a time and date. If it succeeds in parsing the input as a time and/or date, it prints out, in a standard format, what it thought you typed in. Some of the commands recognized are STOP, MTS, and $. An endfile on GUSER implies STOP. The time and date is converted to an internal all digit form in a 16 character string, with a format IYYYMMDDHHMMSSHH where IYYY is the year, the first MM is months, ..., HH is hundredths of seconds. (This format allows two times to be compared with a CLC and is easy to generate.) Any fields may be defaulted, but all explicitly specified fields must be contiguous (e.g., the month and hour say be specified only if the day is specified). Also, to avoid ambiguity, hours may not be specified without minutes (except when AM or PM is specified) and the day may not be specified without a month. Two groups of commands specify defaulting of unspecified fields. One group controls the loss significant fields and the other controls the more significant fields. HAXTIME and MINTIME control the defaulting of the less significant fields, when MAXTIME is set, all defaulted fields less significant than the specified fields are set to the maximum legal values, given the specifications. MINTIME specifies that these fields are to be set to the minimum values allowed. For example, if HAXTIME were set, "12:20" would be the same as "12:20:59.99", while if MINTIME were set, it would be "12:20:00.00". Likewise, for "Jan 1980", the interpretation would be "Jan 31,1980" or "Jan 1, 1980". MIN and MAX are acceptable abbreviations. NEXTDATE, LASTDATE, and DEFAULTDATE (abbreviated NEXT, LAST, and DEF) control defaulting of the fields more significant than those specified. DEF causes the fields from a default time/date to be used. In the experimental program that time/date is the time and date the program started. NEXT causes the fields to be set so that the specified fields will be before the default time/date. LAST causes the fields to be set so that the specified fields refer to the most recent past occurrence of the field values. The program is experimental, and hence does not handle leap years properly. That would be easy to add, tho. The current time and date (the DEFAULT time/date) can be specified as "NOW". The error messages are cryptic, but could be improved easily enough. The file W167:TIME. DATE also includes the source, commands for compiling it, and the input to the SPIRES analyzer, all in the lines greater than 1000. 6 VOTES/FEELINGS Hhat time zone is this? EOT, EST, GMT, etc? Twilight zone The 0 Zone Newfoundland time. j»r
I oust say t h a t t h i s i s a timely contribution to MTS. John Gourlay If i t were a subroutine I would probably use i t in CONFER. (bob)
/ B
* «5\
^N
48
MTS-Spires Distribution 6\J)
August 12, 1979
1
Jim Sterken Computing Center University of Michigan Ann Arbor, Michigan 4A109 Dear Uick and Bill, Here is the MTS-Spires 6.0 distribution. Steve, Rick, Zvi, and I have worked long and hard to get this out. Now that we're done, we're quite happy with this version of Spires. He've run into only a small number of problems while installing your latest distribution and you've been quick to help us vith them even when we called you at home (sorry about t h a t . . . ) . Thank you! Thanks *lno for implementing so many of the things we've suggested over the past few years. As you can see, I've sent you two tapes: One tape, labelled "MTS-Spires 6.0", is the HTS-Spires distribution correijpondlng to your 4/11/79 Spires distribution with updates applied through 8/2/79. It is written at 6250 BPI with standard IBM Labelling. The volume name is EX0346. Please send make exact copies of trat tape as soon as possible and (along with a copy of this letter) one out to each of the UTS The data sites to whom you «»t only it understands so other than copying it, you w-»r.» . be able to do much with it. I've included a tape contents '!:r-r*cry produced by *FS which I would like you 128 HTSto forward to the o-\er MTS sites. The tape contains files, the firs'- .?- which, DISTNOTES, describes the contents of the rest of the t ».->-. The other tape, I t i l l e d "Spires Updates", contains the HTS *-?lie:3 to your system. It is written vith updates we've standard IBM labelling, 6250 BPI, volume name is EX0141. I've of the tape contents. The following files included a listina you have been include! (let me know if ycu'd like me to send anything e l s e ) : 1) HODS.BTS: This file contains all the updates we have made updates to your April 11, 1979 distribution tape with all your August 2, 1979. (That includes your "PRD"applied through 7/5/79 plus four "TES"-updates: 7/10/79, updates through 7/12/79, 7/13/79, *nd 7/13/79.) We have our own update program that takes this data as input and applies all the required HTS updates. 2) MOUS.STAN: This file was created from HCDS.MTS by a quickand-dirty SNCBOL program. The Format should match that of your regular CCMPARE-decks with the exception of the "//."-comment lines I've added. You should be able to apply these changes "TES/PRD" system all the changes are IFdirectly to your tested I've checked them quite thoroughly. Nevertheless, be _B I f
MTS-Spires Uistribution 6.0
August 12, 1979
2
careful, a mistake could have slipped in possibly. If any update looks strange, refer to file MODS.MTS for comparison. 3) FILEDEF.BI: definitions.
A
Bl-file
containing our current system file
4) UTSTNOTES: The distribution notes ve've included on our HTS-SPTRTS distribution tape. Just in case you're curious... I have a fev suggestions for upcoming Spires distributions: might as well stop including PL360.HTSPRO0S and A S M . M T S I N T F on your tape they are obsolete versions that ve aren't using anyway. HTS.IHTERFAC, the interface to PL360, is OK though it exactly matches vhat I an currently using. 2) We've made a l a n e number of changes to TRG, and to the system file definltiorn, formats, and macros. Yet there is now no vay for us to sonl back IP-tested code to you in these areas. We've discussed thin problem before vithout coming op vith a solution. But as tine passes, the non-BNF/PL360 parts of your system, especially the macros are groving so rapidly that it is imperative that we solve this problem. Merging in our HTS changes from scratch in these area each time you send out a distribution is beccsing more and more difficult. 1) You
3) Writing system* documentation is, I know time consuming, but if you ever qet * cv._nce to produce more I can point to a few areas where extra ^ T s s e n t a t i o n vould be a lifesaver. The first area that comes *• o mind is the system COPY sections R12USECT, R11DSFC-. etc. If sometime you could produce an expanded version a* these files with a line or two describing EACH variable, o-ir •,_sk would be made considerably easier. Many of the variables ir» already described in "Design of Spires I I " I realize, but 9437 more are not. Another area where lack of documentation is a problem is the system VGROUPS — especially in TRG. A comment nr tvo supplied with each variable vould help us immeasurably. ft) Nov that Zvi his the "HTS-side" of SPIDOC up and running, all HTS sites vill be maintaining the Spires manuals in the same data base style you are using. Thus for future distributions ve vill no longer be needing just the finished "printer-listings" but also the raw sPTDOC-output form of the manuals. The package of fdefs, protocols, and formats Zvi has Written, by the vay, is not too dependent on HTS. You sight consider merging those files into your standard system and then distributing your documentation that vay. You could, then, still use SPIDOC locally to produce your documentation], but then for the version of Spires you distribute Zvi's "back-end"-system could be used to handle on-line searching and publication of your SPIDOCgenerated data bases. In that common data base environment, problems having to do vith local changes to documentation for the various installations night be more easily attacked. If you are interested, we can send more details on the system Zvi has written. «n
HTS-Scires Oistribution 6__0
August 12, 1979
3
5) Since your monthly COMPARE-decks have been so helpful in keeping us abreast of coding changes, you might consider providing a parallel notification of documentation changes as they are made. I realize that this information can to some extent be obtained from SPIDOC on your system, but the process is still quite awkward. X think you might be interested in using a number of our updates for your own system: 1) I've re-written the SHOW STATIC VARIABLES code so that the output it produces is a more terse. Sections of arrays with identical, often unreferenced values are skipped. This change has been quite useful for debugging. 2) Quite a few of the changes involve little more than switching messages from "UPPER ONT.Y" to "Upper/Lower". You might consider going wholesale through all the processors and converting ALL your messages. We've also converted all the messages in System Messages (MSGDATA) to uplow for our system. 3) I've modified the command prefix echoing in Spires. You are always using "-?" for echoed protocol commands. I've included a Global FOR check there to print "-" or "«•". In addition, I've changed things so that for echoed protocol lines either a *•-?)" or a " * ? ) " prefix is echoed --- the " ) " is useful in looking back at old terminal sessions. It makes it easy to distinguish what came out "automatically" from the protocol from vhat vas actually typed in by the user. We don't distinguish between UPP3R and UPLOW with different prefixes. 4) I've modified the echoing for comments in protocols. In your system comments are always echoed whether they begin with "-" or "". I've modified thinqs so that ""-style comments are not echoed. This makes it possible to put in "invisible" comments in protocols, which won't clutter the listing up when the protocol is being XEQed. 5) Steve has gone through and made a number of consistency changes to the system files. He made "ID" either the key or a key-alias for ALL system files. He also added DEF-DATES and MOD-UATES/MOE-TIMSS to as many of the system files as possible. 6) We've changed A76 to produce uplow dates and weekday names. 7) We found a number of problems with the SET EXCEPTION command. Rick re-wrote that code. 8) I added a new command, "SET HEADER=(ADD | UPDATE | MERGE 1 REMOVE | * * * * } " to control what header UISPLAY puts before records that are being displayed to the active file. With UPDATE, MERGE, and REMOVE the record key is included too. 9) I've changed the BNFs so.that extra blanks are "squeezed" such that "SELECT SYS PROTO" works as well as "SELECT SYS PROTO".
49
HTS-Scires Uistribution 6__0
August 12, 1979
10) We allow abbreviating WHERE to WHB in the FOR command. 11) A number of more minor changes are scattered through our updates. I've tried to flag the ones I think you'll be interested in vith fairly conspicuous comments. Well, I guess that about wraps it up. Steve vill be dropping by for a visit in a few weeks. You can let him knov if you run into any problems. Having finished this distribution, I'll be switching back to some other projects. I'll keep in touch though. Rick Block vill be handling the "systems" work in Spires. Zvi is going to be moving back to Israel in • a few weeks.
So long,,*
Jim sterken
so
ITEM 387 17:21 Aug28/79 52 LINES PRIME=241 BALLARD, ALAN (UBC) New version of SPIRES Parser and Analyzer This item is a progress report on work done with the SPIRES parser since item 241. The whole package has now been completely rewritten in PLUS. The parser was rewritten as a preparatory step to installing system terminals and error correction. (I was planning on just making a few minor changes to the analyzer, but once I understood how it worked well enough to make them, I realized it was really a pretty simple program so rewrote it too. ) The new analyzer is quite a bit different from the Spires one. Its input language has been substantially changed. The new form not only provides support for new features, but is more convenient to write and read (I hope). The new analyzer allows semantic actions to be referred to by identifiers in the grammar, rather than numbers. It generates PLUS declarations or Assembler equates as auxiliary output, defining the values of the identifiers used. These declarations can then be included directly in the program written for semantics. The new package provides for "system terminals". (We used to call them "system semantics", but in fact they behave like terminal symbols of the grammar.) This has been done in a way that makes it easy to add new ones. Currently, I've implemented integers, MTS line numbers, quoted strings, Fdnames, and a few more. Others, including time and date input, will be added in future versions. A system terminal is referred to by name in the input to Analyzer. The new package also provides a first attempt at error-correction support. A grammar can specify points at which error recovery is to be attempted. On encountering one of these, the parser will attempt to spelling correct into a literal which is valid at that point, otherwise will ask the user for a replacement. I'm not entirely satisfied with the way this all works yet, and expect it vill need more work, but it is a reasonable start. The parser also supports the beginnings of a help facility. In response to a "replacement or cancel" or spelling correction prompt, the user can ask for a list of the valid keywords. The system terminals also contain support for looking things up in a "help file" , which can be invoked at an error prompt, or any point specified in the grammar. This will also need more work later. The initial pass at a rewrite supported exactly the same object deck format as is produced by the Spires analyzer; I've since made several incompatible changes, although the overall structure is still very similar. I've just finished a 45 page writeup describing the whole thing. If you'd like an advance copy, send me a message and I'll mail it out. I vill distribute this version at the same time as the next version of PLUS. This will probably be a couple of weeks at least. REF TO ITEMS 241 REF BY ITEMS 396 9 VOTES/FEELINGS Sounds like a great start! I'm ready and waiting to try it. JHH Alan, it looks good and I would like a copy of the writeup (I know that it's not a message, but...) Garry Jackson/UQV Wow! I wanna copy, too. DanG/UM Nice work, Alan ... I'd like to see the description too ... Gav/UM I'd like a copy. Why not send one clean one to UM and we'll xerox as many as we need. For misspellings, I would like to set minimum lengths. I'm tired of "NO" insstead of "ON" or "OFF", whachamacallit. LBT. Sounds great! I'm looking forward to trying it out. Looks like
51
you've made good progress glad you've progressed beyond PL360. Jim Sterken I ' v e j u s t mailed a couple of copies t o Jim Hansen for c i r c u l a t i o n or Xeroxing at UM (ab/ubc) item 387 * p r i n t *
52
•JoHM Sv/OSww&TTt (yw)1
A S o l u t i o n to Codeoff Problem 1 (done in PASCAL) Purpose To gain some familiarity with PASCAL. Description The program does what the problem description says it should do, with two minor exceptions: it does not survive trying to read more files than are on the statistics tape, and it does not ask the user if more files are desired after the first set are read. The first problem requires changing the way the program does input (i.e. it would have to call SCARES directly), and the second problem I just didn't feel like doing (it's trivial) . The program is about 630 lines of source, and requires about 85 pages of storage when running. It uses a dynamic array, via the record feature, to hold a list of job numbers and current commands. It uses static matrices for transition counts and probabilities. (T devised a method for dynamically building these matrices with records, but it didn't seem worth it.) This was the first PASCAL program I have written from scratch, so it is probably not a particularly clever use of the language. Time spent on it was about 30 hours. Comments This exercise does not address the system programming language controversy very much, but it was useful. For an SPL to compete with more standard languages to do GLPs like this one, it will have to at least have all their functionality — that means floating point operations, too! Of course, no one would consider writing a program like this in assembly language. PASCAL is a pleasant, enough language to use. Once I got over the initial hurdle of convincing the program to read a file on SCARDS, the implementation went fairly smoothly. 'or the most part, the language did what T expected. Note that T did not have a PASCAL reference manual— I used the UBC (and RPI) documentation. PASCAL I/O is not especially flexible. For instance, floating point. output insists on a digit to the left of the decimal point — pretty inconvenient when printing probabilities. It also proved difficult (if not impossible) to read more than one file on a tape without rewinding the tape before each one (and then forward spacing the tape to the right one via CONTROL) . T was also unsuccessful in recognizing an endof-tape return. This is not terribly important, though, since I could have called SCARDS directly instead of using standard PASCAL input. The compilers available
leave
something
53
to
be
desired,
2
hovever. I ended up using the UBC compiler, because it was the only one that would compile and run my skeleton program to read the file. The AAEC compiler wouldn't reset SCARDS to a file (not to mention that it insists on reading for INPfTT before the program starts). The stoneybrook compiler just gave program interrupts during compilation. All things considered, the UBC compiler was usable. It definitely needs an S^S interface, though. The program is in W034:CMDFREQ.S if anyone is interested. The problem has only one difficulty that T found — that in printing the most probable command sequence. Because SIGN is both SIGNON and SIGNOFF, the most probable following command will usually be ****. If it is not, the sequence will be circular. Without the signon-signoff distinction, this ends up being uninteresting.
54
ITEM 397 0 3 : 3 0 Sep10/79 128 LINES ?BIME=390 PICKELMANN, PAUL (UM) Pascal — New v e r s i o n s and s t a t u s I have j u s t i n s t a l l e d new v e r s i o n s of some o f t h e P a s c a l c o m p i l e r s under UNSP h e r e a t UM. T h i s i t e m v i l l d e s c r i b e t h e c h a n g e s ( t h o s e I f o u n d ) , some minor problems I f o u n d , and have some comments on a l l the c o m p i l e r s I know a b o u t , or a t l e a s t t h o s e someone t h i n k s might be good f o r MTS. Pascal 8000 • The new version is the Fall '79 version from Kaoal Abdali at RPI. He reguested that I send his tape back with the RD16 compilers (I guess everyone at Computing Services is busy moving). I'll send it back with some even more recent versions. The changes are: * A set of test programs has been included. * The writeup vas revised some and appears to have been converted to *format, but only the print file included on the tape. * LINENUMBER returns an array of characters instead of an integer. * In "A = RECORD E : a)A END", B refers to the current A rather than a more globally defined one. * Several bugs which caused the compiler to fail on incorrect programs have been eliminated * Sets may have up to 2048 members. * A cross reference has been added. * Lower case letters are accepted and treated as in the draft standard (same as the upper case equivalent). * The procedure DISPOSE is now perdefined, although it does nothing. * "bit-handling" functions have been added. Not$, and$, or$, xor$, shl$, and shr$ all work bitwise on integers. * The symbol table is now a hash table. The minor problems installing it were: * Only the one csect of the runtime support which vas changed vas sent. This is good in somevays, but since it had the same name I thought it was everything and lost somethings for a while. * *Linkedit has a bug and cann't cope vith the object for the compiler. Pascal/UBC + The version installed was the UBC RD16 version, not to be confussed with the UM RD16 version. It differs form the previous version in at least the following ways: * There is a new writeup, UNSP:PAS.BC.W, the 3 old ones seem to be obsolete now. * Identifers can be up to 32 characters long. * Register allocation has been changed. The "run out of accumulators" message should occur at most once per expression. * The format of the log file has been changed. It now has one line per error message which contains the number of programs which have encountered the error, the total number of times the error was given, and the total of the percentage the occurences of that error were of all errors in the programs. (I haven't quite figured out the signifance of the last one yet. Could someone at UBC explain it?) * Some internal displacements have changed. The minor problems in installing it were:
55
* Since the format of the log file changed, trying to run the new compiler with the left over file produced compiler errors because the lines were too long. The new file should have lines (0,127) in a format of (3110). See UNSP:PAS. BC. ERR for an example. * The print file for the manual, but not the *format source was included. (Although it probably uses a version of JON:MACLIB different than the one we have, so this may be a blessing) * If one tries to run the object version of the compiler THERE ARE 21 UNDEFINED SYMBOLS JULDAY DFAULT CHKPAR RANDE UNDEFINED SYQBOL(S): CALLER ISORT IPTR FRANDN DATEI RANDN DATE FSPACE RAND FEANDE NPAR FRAND CDATE FRANDL RANDL RTWAIT GSPACE Object for DATE, CDATE, and DFAULT can be found with the UM RD16 version. The others seem not to matter and can be ignored. * The object for the debuger, library, and compiler doesn't agree vith the source. The object installed here does and seems to vork fine. The Stony Brook Compiler + The version under UNSP differs from the RD16 version in that: * Use of the linker is optional * FORTRAN to Pascal interface routines are provided * Nonstandard files are supported. The tvo versions have a few bugs in common, the most notable of which is since I botched the two is it ok to continue checks, the compiler wilI interupt on some incorrect programs. I never seen to run it ti this, but due to popular demand I'll fix it in the next version (and hopefully the other bugs too). Stony Brook is sending an update which provides nonstandard files for the OS version and fixes some bugs. The changes should improve file support in MTS. Pie in the Sky • HDSI(Manufacturing Data Systems, a local company vhich made good) has a Pascal compiler vhich is supposed to be very machine independant, and have a good optimizer. The Computing Center is going to sign a nondisclosure aggreetnent so ve can look at the user documentation. After talking to the salesman-type one gets excited about this and thinks it is the vay to go. Pie in the basement • The Grenoble compiler is still around (there is even a version vith some improvements Dan Greening made or RD16). REF TO ITEMS 390 5 VOTES/FEELINGS What's the *linkedit bug Paul? Pat Sherry By any chance are the " + " strings underscores? He simply have to decide on one supportable PASCAL compiler. JWS/UM you bet. could you give us some idea of the use of each version at um? vhd/rpi
-
56
ITEM 402 12:01 Sep11/79 14 LINES ?RIME=150 EADIE, GAVIN (UM) Floppy D i s k s : p a r t i c i p a t i o n i n a t r i a l exchange ?? In a paper t h a t Brian Cashman and I produced f o r t h e D e t r o i t MTS Workshop we proposed a kind of *FS for f l o p p y d i s k s t o a l l o w HTS f i l e s t o be s e n t q u i c k l y from s i t e t o s i t e . UNE & UM have exchanqed d i s k s i n a very crude f o r m a t , and we a r e now ready t o u s e a more s o p h i s t i c a t e d mechanism. I have w r i t t e n a GLP v e r s i o n of t h e *F(LOPPY)S program v h i c h seems t o vork and t h e f i r s t f l o p p y encoded t h i s vay v i l l be s e n t t o UNE t h i s week. When UNE have r e t u r n e d a s i m i l a r f l o p p y I vant t o t r y t h e o t h e r s i t e s t o o . By t h a t time *F (LOPPY) S w i l l have l o s t the "G" from "GLP" (and probably t h e "L" t o o ) . I ' d l i k e t h e p e o p l e a t o t h e r s i t e s who a r e i n t e r e s t e d t o g e t i n touch v i t h me t o a r r a n g e a t r i a l e x c h a n g e . REF TO ITEMS 150 REF BY ITEMS 4 05 3 VOTES/FEELINGS To UM s t a f f : Let me know i f you want any f i l e s i n c l u d e d on t h e UNE f l o p p y ( t o be mailed F r i d a y 14th) : : : E a r l : George i s r i g h t (again) but t h e GLP a l s o i m p o s e s a f i l e s t r u c t u r e on the f l o p p y v h i c h a DSR vould n o t . . . Gav/UM Hhy t h e s p e c i a l GLP's? Won't MTS be made t o s u p p o r t t h i s d e v i c e l i k e t a p e d r i v e s ? $M0UNT * f l o p p y * . $COPY f i l e TO * f l o p p y * . $RUN *FS 0 = * f l o p p y * e t c . Earl Culham (UQV) The GLPs a r e r e q u i r e d u n t i l t h e d e s i r a b i l i t y and d e s i g n of a f l o p p y d i s k DSR are d e c i d e d upon and i a p l e m e n t e d . I t g i v e s you f l e x i b i l i t y during i n f a n c y b e f o r e the s t u f f i s wired i n t o t h e command l a n g u a g e . (Right?) G. Helffrich/UM
57
ITEH 405 18216 Sep 12/79 22 LINES PRIME=402 EADIE, GAVIN (UH) Floppy d i s k s : r a t i o n a l e for use as informal exchange media When I do t h e a r i t h m e t i c i t seems c l e a r that floppy disk exchange v i l l e a s e N e w c a s t l e ' s t r a n s - A t l a t i c telecommunication c o s t s substantially. This item i s addressed p a r t i c u l a r l y t o UNE s i n c e t h e i r Telene t c o s t s are high and r e a l , but i t holds a measure of truth f o r everyone. The floppy t h a t I got l a s t veek cost $2:25 t o a i r - m a i l and took a week to t r a v e l . As I r e c a l l , Telenet charges from the UK are $15.00/hour (absolute minimum : connect time o n l y ) . So, r e g a r d l e s s of t h e data q u a n t i t y , mailing a floppy i s a s expensive as 10 minutes on T e l e n e t . I can g e t about 75 pages (300kbytes) onto a floppy assuming a 20% compression ( t y p i c a l of program text) which r e p r e s e n t s a u s e f u l l y large amount of data. Maybe more FORUM ' i t e m s ' should be s e n t t h i s way, rather than on the magic v i r e s , s i n c e they are usually l e s s immediate than 'messages' and viewing v o t e s . Looking t o the future, even when we have h o s t - t o - h o s t networking over the o c e a n s , i t i s s t i l l going t o be very expensive t o maintain a vorking d i a l o g because although connect time w i l l drop, data c o s t s v i l l r i s e when data t r a n s f e r becomes e a s i e r . REF TO ITEMS 402 2 VOTES/FEELINGS This i s r e l e v a n t t o a l l of u s , s i n c e we agreed a t HSU t o s p l i t t h e communication c o s t s e q u a l l y . UNE v i l l not be paying more than anyone e l s e . (HTA) Yup - I guess I should have s a i d our TOTAL c o s t s v i l l be reduced most e f f e c t i v e l y by h i t t i n g the UNE b i l l . Also i t might get more than one UNE systems p e n an p a r t i c i p a t i n g in FORUM. Where are you Ian, P e t e , Lyn, E r i c , Bob ??? (Gav/UM)
58
ITEM 404 10:59 Sep12/79 HUNTER, ALAN (UNE)
87 LINES
PRIME=353
More on Default Listing and Object Files This is my long promised item on Algol W's use of scratch files. First, I have made a couple of changes to the action of the relevant parameters. I'll explain them, and then attempt to justify their action. I'm all in favour of Jim Bodwin's attempts to standardise compiler parameters, and it has occurred to me that our current use of SOURCE is ambiguous and could lead to confusion. This is especially so in view of *FTN's behaviour where SOURCE means "I want a source program listing" but: SOURCE= means "that's vhere the source INPUT is to be found". I think it is unreasonable to expect *FTN to change its ways at this stage in the game, so I have modified Algol W instead - these changes have been sent to Jim B. a UN. The following parameters change: SOURCE becomes SLIST (a la ALIST) LIST becomes FULLSLIST NOLIST becomes NOSLIST The following parameters are deleted DEFDECKFILE DECK now takes an optional RHS filename DEFSOURCEFILE SLIST and FULLSLIST now can take an optional RHS filename Now a few words of explanation. FULLSLIST means "ignore any /NOLIST cards found in the source". NOSLIST means "ignore any /LIST cards found in the source". Both SLIST and FULLSLIST mean "produce a compiler source listing". NOSLIST means "never produce a compiler listing". SLIST will allow the listing to be controlled via /LIST and /NOLIST cards in the source. The defaults are: Batch: SLIST , write listing on SPRINT Terminal NOSLIST , if SPRINT is not assigned; SLIST , if SPRINT has been explicitly assigned Only in the case where a terminal user gives the SLIST parameter, and leaves SPRINT to default, will a scratch file be used. The name of that file is -AWLIST . This filename can be specified by a user if he wishes by giving it as a RHS to SLIST (or FULLSLIST). e. g.: /COMPILE SLIST=-QQSVLIST I feel that this action gives sufficient options to the user; if students at a particular installation should not use the scratch file option, then they should be told to always assign SPRINT. No great harm will come to them if they do not. Next, object modules and scratch files. If SPUNCH is not explicitly assigned, Algol W will always use a scratch file if an object deck is requested. Since the last set of changes, the DECK parameter must be given to obtain an object deck; the default is for immediate execution of the program. Again I have extended the DECK parameter to take an optional RHS filename. If a user wishes to specify his own filename he may do so; otherwise the file will be called -AWLOAD . Scratch files used by Algol W in this way are always emptied before use. This fact is crucial to our argument in favour of their use. At UNE, systems and applications programming staff are in the front line for user advisory work — we see first hand the effect of user confusion. One of the commonest user errors goes as follows: a) b)
User c o m p i l e s program. User t e s t s program. >-
_rt 59
c)
User e d i t s s o u r c e t o remove an unwanted procedure o r WRITE s t a t e m e n t . d) User r e c o m p i l e s program, f o r g e t t i n g t o empty t h e object f i l e . e) He i s then p r e s e n t e d v i t h a ( t o him) v i e r d and unexpecte d e r r o r m e s s a g e , u s u a l l y about abnormal l o a d e r i n p u t ordering. Most u s e r s a t t h i s l e v e l d o n ' t know what a l o a d e r i s — i n d e e d , why s h o u l d t h e y ? We s h o u l d be p r o t e c t i n g them from the unexpected. Algol w does so. The v o t i n g o n i t e m 349 seems s p l i t both ways. I n v i e v of t h i s , and t h e f a c t t h a t most s t u d e n t s a t UM v i l l u s e t h e c o m p i l e r i n c o m p i l e , l o a d and go mode, UNE v i l l not change t h i s b e h a v i o u r . I t i s i n a c c o r d v i t h HTS N e v s l e t t e r 2 0 , p a g es 5 9 - 6 2 . I f o t h e r s do not l i k e t h e names ve have chosen a s d e f a u l t s f o r t h e s e f i l e s v e a r e q u i t e w i l l i n g to change them. I n d e e d , p e r h a ps t h e r e s h o u l d be a s t a n d a r d f o r t h e naming of s c r a t c h f i l e s used by l a n g u a g e p r o c e s s o r s ? How about i t , Jim? REF TO ITEMS 330 342 343 344 346 349 353 REF BY ITEMS 406 7 VOTES/FEELINGS The d a n g e r i s t h a t someone may have a f i l e w i t h t h e name -ANLOAD and you might empty i f when you s h o u l d n ' t . T h i s c o u l d be a v e r y b i g problem i f t h e name v a s -LOAD r a t h e r than -AWLOAD. I r a t h e r s t i c k v i t h SCARDS=... i n s t e a d of S0URCE=... A l s o , t h e nev v e r s i o n of *PL1 v i l l use no d e f a u l t f i l e s a t a l l u n l i k e *FTN (and ALGOLW). The s c r a t c h f i l e -SYSUT4, used by macro p h a s e s , v i l l be i n v i r t u a l memory. LBT. Hy P a s c a l p r o p o s a l v i l l be r e a d y s h o r t l y . SPUNCH=filename might imply d e c k , s i n c e l o a d , , g o u s e r s v o u l d put i t on the / e x e c u t e c a r d . Paul P I f someone i s s u e s t h e command: $R *ALG0LW . . . SPUNCH=-AHLOAD . . . v i l l -AWLOAD be e m p t i e d ? MFW/UM Other c o m p i l e r s s e t l i s t i n g d e f a u l t a s SLIST i f SPRINT i s e x p l i c i t l y a s s i g n e d o r h a s been d e f a u l t e d and i s not a t e r m i n a l , NOSLIST o n l y i f SPRINT h a s been d e f a u l t e d AND i s a s s i g n e d t o a t e r m i n a l . I prefer t h i s b e c a u s e $SINK v o r k s b e t t e r with i t . (MTA) She s t a n d a r d ( a t UM a t l e a s t ) f o r s c r a t c h f i l e s i s t h a t t h e y a r e t o be e m p t i e d ONLY i f t h e y a r e i m p l i c i t l y used. E x p l i c i t l y named s c r a t c h f i l e s a r e NEVER t o be emptied . I c a n ' t t e l l from t h i s i t e m i f t h i s f o l l o w s t h a t s t a n d a r d , dvb. I have a g r e e d t o go a l o n g v i t h t h e s e c h a n g e s v i t h one s m a l l c h a n g e ; t h e o l d parameter a r e s t i l l r e c o g n i z e d . I v i l l p u l l them o u t someday, b u t t h e y have a l r e a d y been documented. A long response to some o f t h e v o t e s i s i n i t e m 405.
60
ITEM 407 16:44 S e p 1 4 / 7 9 83 LINES HOWELL, DONALD C (UQV) UQV's c h a n g e s t o BASIC T h i s item i s i n r e s p o n s e t o a r e g u e s t from Ed Fronczak f o r more i n f o r m a t i o n about the work UQV has done on BASIC. H i s r e q u e s t was i n s p i r e d by t h e a r t i c l e on p. 4 of t h e UQV BULLETIN of 10 August 1979. The BASIC t h a t was mentioned i n t h e a r t i c l e was based on the l a t e s t d i s t r i b u t e d s o u r c e s , vhich come from D 4 . 0 , D4. 1 and D4. 2. Our l o c a l work was done i n two s t a g e s . A v h i l e a g o , Kathryn made the f o l l o w i n g c h a n g e s t o D3. 2 BASIC and s e n t them out on RD15, f i l e s 268 t o 2 7 4 . ( F i r s t read the doc. i n t h e d r i v e r f i l e f o r f i l e 26 7 ) . 1. The maximum no. of v a r i a b l e s v a s i n c r e a s e d t o 1024 from 512. 2. Maximum f i l e s i z e was i n c r e a s e d to 16 p a g e s from 8 p a g e s . T h i s a p p l i e s t o a l l t y p e s of f i l e s ( S , D and 0 ) . 3. The g e n e r a t e d o b j e c t code can be up t o 8 p a g e s ( r a t h e r tha n 3). 4. The capacity for string constants was increased by packing them in more tightly. 5. A PRINT statement terminating with a TAB field is printed, and the TAB is recognized. 6. IC is set off by BASIC, to force users to use %INCLUDE rather than JCONTINUE WITH. Two or three $CONTINUE HITH's got BASIC confused as to whether it was reading from the file or terminal. It looped reading from the file although EOF's were being returned. That version of BASIC was still quite "buggy". It vas getting "SYSTEM ERROR"'s at a rate of about 12 a veek. When I installed D4.2 BASIC, I incorporated the above changes and made the following extensions: 1. Changed the BASIC source so that ASMH can be used to compile it (Every CSECT that had a DXD in it had to have a Q-CON added that refered to the DXD s~ that it would be put in the ESD list) . 2. Removed the BASIC signon message from shared VM and had BASIC read it from the file ETC:BASICSIGNONM. There are several advantages to this method, one of which is that BASIC no longer needs the capability to turn protection off. 3. On reads of ETC:BASICSIGNONM and the help file, used the HAXLEN modifier to restrict the length of the input to the size of the buffers, which is 256 bytes. 4. Increased the amount of main memory available for programs, data and virtual files to 4 Mb from 1 Mb. These changes only involved GETP and FP.EEP. Because GETSPACE at UQV only gets a maximum of 1 Mb. per call, each routine is restricted to 1 Mb. of code and data space. 5. Checked the return code after all calls to GETP. The lack of this check was causing most of the "SYSTEM ERROR"s. 6. Installed the update sent out in MTS Change Form 4205. This update fixed the %RENUMBER command. All our updates to BASIC are in CDUPDATE form. The new BASIC is considerably more stable than the old one. The new BASIC at UQV is used 1000 times per month, versus 900 times per month for the previous version and there yet has only been 1 "SYSTEM ERROR" since 10 August 1979. There are still some bugs to be fixed: 1. If the active file is a data file, and a RUN command with no file name is issued, BASIC gives a "SYSTEM ERROR".
61
2.
There is a problem vith the vay strings are handled* For those who are interested, the file W422:BSC.STESTLIN contains a BASIC program that illustrates the problem. I vill send the updates out on a tape if anyone vants them. 6 VOTES/FEELINGS If you vant to send updates, they can be put oh a redistribution. Redistribution is the vay to go. It vill be on the next UQV tape for redistribution. (DCH/UQV) GREAT!! (SJG/WSU) Perhaps UQV should take over BASIC from UM. the vork that has been done vas long overdue. Very good. (Clark Lubbers/UM) I agree vith Clark. That vork was NOT easy! Perhaps you are more familiar vith the internals than UM is now. (Ed Fronczak/UM)
62
"""^
ITEM 408 11:53 Sep24/79 36 LINES PRIME=157 TIFFANY, BERN ARC (L BT) Version 5.5 PL/I-(F) Compiler. With the exception of MACRO and CHAR48 options, the last (^ free version 5.5 (OS release 21.8) of PL/I-F compiler is nov running. I plan to install this in NEW:PL 1 vhen the macro phases start to work. This new version is faster and cheaper than the current version of *PL1, primarily because a simple loader was written in order to reduce significant CPU time and the expense in loading some 254 modules during the compilation. Only tvo files (instead of four) will be used: NEW:PL1 and *PL1LINKLIB. •PL1LINKLIB is a DIP-type loader library line file. The maintenance is nov very easy with many thanks to *OBJUTIL. This involves an enormous vork, 2500 *CDUPDATE input lines to 32 modules plus an extra module 1EMTM, vhich produces SYM * records. This doesn't yet include some 400 *CDUPDATE input lines for 11 macro phases. Two modules from the OS version, IEHAF (which defaults options) and IEMAT (which patches and/or » traces), are deleted. With the old computer 360/67 now gone, I do not have to change various modules that generally would produce addressing interrupts on a 360/67 but not on 370's* A good example of this is to try to execute a TR instruction with a short translation table near the end of a page. Tvo new options are added: MTS|OS and NUM|H0NUH. If MTS, the PL/I-F compiler will produce decks that can run in HTS; if OS, in OS. The default is MTS. NUM and NONUM options control the printing of line numbers in the source listing. The default is NUM. Options are defaulted only at the start of the compilation /**N instead of every batch compilation. Options can be overridden if ^ they are specified. Here are some of default changes: —DIAG is default if SERCOM and SPRINT are different. — I f SPRINT is defaulted to a terminal, then NOOPLIST, NOSOURCE2, NOSOURCE, NOXREF, NOATR, NOEXTREF, NOLIST are assumed. The PL/I compiler will not default object and listing files. Too many users have been confused with default files. I will make an announcement in my vote when the PL/I compiler is ready. REF TO ITEMS 157 6 VOTES/FEELINGS Is this version totally different from our current PL/I, or is it a s set of updates which bring it up to level 5.5? G. Helffrich/UH Should *PL1LINKLIB really be ETC.:PL1LINKLIB? I'm not sure myself. (-Jeff Ogden/UM) Good Work! (and my sympathies...). I feel *PL1LINKLIB should be under ETC: ... (SJG/WSU) This looks good, but we still should get the PL/1 optimizer someday. (HTA) I agree that *PL1LIRKLIB should be under ETC: Yes, please get the optimizing compiler some day! We get MANY requests for it at the Merit office, and we have to refer them to HSU—which is not a bad thing, but they only have it on HVS (yuck). The new version is available in NEW:PL1. LBT.
63
JTEH 413 18:38 Sep27/79 14 LINES BALLARD, ALAN (UBC) Second PLUS d i s t r i b u t i o n a v a i l a b l e I am about to mail a tape to Jim Hansen with the second d i s t r i b u t i o n o f PLUS, and the rewritten "Spires" Parser and Analyzer. This vill eventually make its vay to the other installations via the distribution mechanism. Hovever, if you'd like an advance copy, please let me knov via a message or a vote. This nev distribution contains the folloving changes: — some bug fixes — some SDS SYM card support — fully reentrant code (and R12/R13 reversed for nev coding conventions) — various Other, mostly minor extensions 3 VOTES/FEELINGS • • • •
(Did B. McKenney request an advance copy for RPI? If not,.*. tapes are on the vay to RPI and SFU. (ab/ubc)
64
JSFi
SIMON FRASFR U N I V E R S I T Y . B U H N A B Y . H.C., C A N A L ' - . COMPUTING CI N l Rl
September
Grant Crawford TEXTFORM Support Group Computing Center University of Alberta Edmonton, Alta T6G 2H1
V'
1979
•
Grant,
.
First of all I have included a list of my current 'TEXTFORM BUGS' list. I have marked the problems I consider most serious with an asterisk. In addition, I have a few questions and a few problems to report. Question #1 I wanted to use the facility. My idea was to tell TEXTFORM everywhere you see the word 'thing', do something This could be useful for automatically indexing some pre-specifled set of words. So I began playing around with the command. I understood that the form of the command was: where &test is a string to be looked for and &np was a command to b e executed• I tried various things but never got anything better than what my listing shows. It seems that the wrecked my definition of the variable fittest, but note that the action (&np) got executed OK. What have I done wrong? Question #2 How about making the space between adjacent footnotes into variable? As far as theses are concerned, our library expects adjacent footnotes to be double-spaced so all the theses writers here (and there are many)have to add their own command like • Question £3 How come the TEXTFORM course notes that I got from you guys say that you shouldn't let SCARDS default. The only thing I can see is that maybe TEXTFORM isn't restartable when this is allowed.
Problem #1 I'm sure you've probably seen this problem before. Guess it's caused by . The spacing between the footnote number and the footnote text is not constant. Problem if2 End-of-page problem Similar to another problem I reported, I think.... The underlining got carried over into the footnote area. Problem _#3 Run-time problem Don't know if you've seen this before. One of the system guys (using a Memorex 1377 terminal) typed the first run command and stacked the second run command and then went away.... He came back to this strange sequence of events and then issued the third run command which caused a program interrupt and then the fourth that worked! Got any idea what happened here? Guess that's about all for now. Except that I still haven't been able to successfully move NEW:TEXTFORM into *TEXTFORM. People around here (particularly, the managers) are starting to get a little up-tight about that. So I'll be back to that for the rest of this week. You can be sure you'll be' hearing more from me soon.
66
University of Alberta
TEXTFOBM
Version: 1.0 (ct78)
Friday August
3,
OPTIONS: NOPROLOG /0)$$&\
internal Source Paqs Line Line *» # • # 1 1 5 1 1 5.1 1 1 5.2 1 1 5.5 1 1 6 2 1 6
!!!!GCI in control s !***Partial Use Flag !*—Input Use S !*-*Input Origin S !*-+ Input Line S this is a <5test>. $test<-
•naae' is not defined. Ignored. IN COLUMN 0 "tast<-" 2 1 6 * >. 2 1 6 * . 2 1 7 this is a <&test>. '$test<3 1 7 'name' is not defined. Ignored. 0 »test<-" IN COLUMN 3 1 7 * >. 3 1 7 * .
Commands Executed Macros Executed Functions Executed Expressions Evaluated
182 5 11 125
* of Controls * of Control Strings
264 92
Number of Words Number of Sentences Text Lines Printed Text Pages Printed
9 0 4 4
Number of Errors
67
vould the
be
the
palatal
transition
palatalized latter
i n i t i a l string of deqi 'day': / d i e / , / j / represents
and
from
/d/
to
/e/.
/d/
i s phonetically
/ e / i s phonetically prepalatal. An example of the
i s the final string of d_gnj.: / e n . / . Here / j / i s interpreted
as the feature of palatalization in [ n , J . / e / , vhich i s prepalatal, is
also postpalatal, vhich i s predictable because of the following
feature
palatality.
of
Postpalatality
in
Russian
is
alvays
predictable and i s never phonemic. Hovever, transition vord
despite
betveen
finally
or
the
claim
that
/ j / can
represent
the
a consonant and a vowel, i f a consonant occurs before another consonant, i t can be claimed that
the feature of p a l a t a l i ty can never be segmentalized, because i t i s alvays
concomitant
reasonable
vith
objection.
the I
consonantal
knov of
no
segment. This may be a
convincing
argument
for
considering / j / to be a part of such a consonant. I t i s possible to analyze
the palatal release of such consonants as the segment / j / .
I v i l l not attempt to ansver this question here. I v i l l assume that /j/
is
a
procedure another
separate to
segment
here,
noting
that
it
i s a simple
replace a l l sequences of a consonant plus / j / before
consonant
or vord-finally vith the palatalized consonant.
This vould have the e f f e c t of increasing the inventory of phonemes, but
i t i s not clear to me whether t h i s has any real conseguence to
the
system
»l
or vhether i t v i l l be just a notational variant, I
suspect the l a t t e r . * * (GJ^ee HcCavley (1968). J^Jperhaps the evidence v i l l only be found in speech errors fFromkia (op. c i t . ) ) or in childrens speech games. For example, if the sequence / C j / in word final position or before a nonpalatalized consonant could never become discontinuous, such that / j / wcull occur after a vowel, or an inherently hard consonant, e . g . , /mat 1/ — > Vnajt/j, e t c . , t h i s vould provide evidence that / C , / were the
!
68
FVatw^rt-e. P/'oMovw #2>
IV. British Fill Industry: Structures And Policies Before ve analyze vhy Canada has been dependent historically on American filas, it is necessary foe us to ask the question, vhy Canada, once* a colony in the British Eapire and having stronq political and economic ties vith Britain during early 1900s did not become dependent on British filas? To ansver that question, ve need to exaaine the structural ties that developed between British, American and Canadian filn industries going back to the early years of their development. i
The purpose of this section is to study those structural ties by applying the structural model proposed on p. ?? of this chapter betveen the British and American fila industries.
Production In early 1900s, several small production cenpanies Hepvorth, Gauaont, Ideal, welsh-Pearson and others aade filas in Britain. As noted earlier, British fila aakers were ahead of their American counterparts around 1912 in the sense that they vere already making five reeler pictures. * Hepvorth aade seven reelers in 1913 based on the novels of Charles Dickens.MPavid
/#^
» unless uLluu"viae; noted, data for this section are from Low. Rachel.. The History of the British Fila. 1918-1929. London: George Allen e Unvin Ltd, 1971. Perry, George., The Greqt British Picture Show. London: Hart-Davis,HacGibbon, 1974.
7
fe9
® Q?
•rr«»iit» r n m i - n i , » , * P « I N T * . ASSJ_GNEO-RECEIPX r NUMaER, Ads*a34._„.-. * R NEWJTEXTFGHH SCARDS=IMPGUipe SPUNCH=*P«INT*7 : . TEXTFORM: VERSION' 1 . 0 •*-*•«*•<•«*««•'• • •- •..- «.*«- —*,„-«_ -t6!-53r&0ft:-EXECUTION BEGINS REAO CALL. FROM 0 0 3 3 E A 4 0 * ^ S ^ r * _ L L £ G A t " P 4 R A M £ T E R S V R NEWSTEXTFORM SCARDS=DISTPROC SPUNOi*»PRINT*.__________L* TEXTFORM VERSlQ^.i.O THERE ARE • g UNDEFINED SYMBOLS T : • ENTER LQCN OF MORE LOADER iNPUTt »CANCEl_"_*,IGNa«E»«, • "USMSG"»"UXR£F»».UR "MAP": -—* 1 UXREF *—'•SfHe— ..-J"-.REFERENCED AT- llQEKTlON OQt"5ao~aY CSECT "wU~UCi-EUS " r i *»SORT —REFERENCED A T LOCATION 6 0 1 2 8 0 BY CSECT "NUCLEUS * •
@
®>
ENTER
LQCNOF
MORE L O A D E R " I N P U T , " C A N C E L " , " I G N O R E " .
• " U S M S G " * " U X R E F " . OR »MAP"S ? CANCEL —: • RUN-ONLY PROGRAM HAS BEEN UNLOADED. • OIS •PRINT* # __*J?RINT. v*as^^.*us_-A-j>AGes K-XZZ. LINES a R HCWSTCXfFORM 3 C A R 0 3 » 0 I S T P R 0 C SPU»
a.
Z*
T^V
<^K
<§7?
•'*
;
•—:
.,
jtoSER 'ERROR WO«tt»re*KttKifW^ oceuRRCQu-inrmN avafew '3UPROuTiNc;»'tResTnRr*iNApvisAaLeV r>NEW^*eiX^Oi^SXARD^=DlsTPR0C-SP w
_ TeXTFORW V_3TStOH~i'; 0 ' ^-=_^.-.-~r-.•.-.—„.._r- w ^ w . W « EXECUTION 0 E G I N 3 17:26:01 =—
UNIVERSITY __.— _ f _ — - . — I. — —
OF ALBERTA
—• . I,....., — , _——_. _..... _ ...
TEXTFORM
VERSIONS 1.0
:
ICT78)
MONDAY JULY 30
OPTIONS* NOPRQLQG S C I I N CONTROL • • • P A R T I A L USE FLAG * — I N P U T USE
INTERNAL SOURCE LINE LINE PAGE T» ff -0-
•-+INPUT
-*«-*—•—
1 TNPUT LINE >
GUNNING*S FOG INDEX =
17.91
FLESCH'S READABILITY. INDEX = STORAGE USED CPAGES)
UNIVERSITY
RUN TIME
l,,,,.l79,.ft,n3
AFTER
INIT AFTER PROLOG 113 113
CLEAN TIME 1.195
' AFTER RUN 157
TOTAL TIME (SECONDS CPU 80.919
SeUNCH=*PSlNT 17:33:33
OF ALBERTA
-OPTTONSS—NOPRetOG
104.16
BEFORE INIT 76
INIT TIME PROLOG TIME
S^TE.XTFORM VERSION I » EXECUTION B E G I N S
ORIGIN
TEXTFORM
VERSION: 1.0 ICT78)
MONDAY JULY 30
:
INTERNAL SOURCE PAGE LINE LINE U » * 1 1 * OUNNlNQ»S FOO INDEX F L E S C H ' S READABILITY
GCI IN CONTROL • ••PARTIAL use PL AG : •r-INPUT USE •-+INPUT ORIGIN *-+ INPUT LINE .AYOUT TECHNICAL!* NOINDEX*.)y
M
ta.TfrINDEX * 10 5 . 3 3
- ^
C. M*LSAJI?**
CSP^
jjppto'v
TEXTFORM BUGS - 13 AUGUST 1979 The following are known bugs in TEXTPOBM version 1.0. All of these have been reported to the University of Alberta. U of A will attempt to fix the more serious problems in the next version. The items documented at the end of the list are features available but not documented in the most recent documentation.
Footnotes / u
\" *
10 Auqust -1979 when a footnots is continued, the wordspace betveen the first and second words of the continued portion of the footnote is missing. 01 August 1979 Contrary to the TEXTFORM User's Guide, you cannot reset the attributes of the footnote counter variable (FOOTCTR).
%
i
24 July 1979 Long footnotes that have to be continued on the following paqts cause text immediately following the command to drop to a new line. 22 July 1979 When a command qenerates a footnote number that should appear as the last thing on the current line, TEXTFORM drops the number to a new line.
Tables, floats, etc.
/#fe\
03 Auqust 1979 If you attempt to define a table and then run TEXTFORM using the command, output is badly messed up. "/jC \ i
71 August, 1979
I
03 August 1979 The work.
and
variables
don't
03 August 1979 Contrary to ths documentation, you cannot put text into your table definition. 22 July 1979 The and commands do not work. 02 February 1979 If you attempt to DEFINE and USE a TABLE before actually putting any text on the page (i.e. at the start of your document), the text from one column may run into the next. To cure the problem insert
**%
02 February 1979 Contrary to Update 1 for the TEXTFORM Referance Manual, the and commands are not implemented. fU£, juov^jUo ***- - dt*
*AWJU1
«*.} t>r ko* Jau^T*.. <**J
C* £
So 5rv»riXl\*_. End-of-line problems 22 June 1979 If a command is attached to. the last word that vill fit on the formatted line, the command will be executed before TEXTFORM'S buffer is printed and may produce strange results. Avoid this problem by putting a blank between the word and the command.
<^*4
72
August, 1979
j0SS\
End-of-paqe problems
%
22 June 1979 S t r a n g e t h i n g s can happen vhen t h e l a s t vord ( f o l l o v e d by a command) on a l i n e c a u s e s t h e page t o o v e r f l o v . So f a r , I ' v e seen a f o o t n o t e badly garbled and I ' v e seen a page nuaber underlined.
Miscellaneous
y *
25 July 1979 We haven't had any luck making the command work. 03 J u l y 1979 The DISPLAY INPUT command d o e s n ' t vork p r o p e r l y .
02 February 1979 Horizontal space commands can cause a line overflov on either side of the command. This is regardless of vhether a vord space exists around the command or not. 02 February 1979 If a single logical vord is longer than the vidth of a line, (any combination of letters and commands not containing a word space) then the line following may be overstruck. 02 February 1979 Note that the parameter to the CHARACTERSET command oust nov 4*++*. be a 'string', not a name. (i.e. CHARACTERSET HATH must become CHARACTERSET 'MATH'). > ^^^
02 February 1979 % is not the logical backspace character. The command (or ) has been provided in it's place.
4-rvo. 02 February 1979 LINEREM vill return a negative value if the vord currently being processed will not fit on the current line.
August, 1979
73
FEATURES IMPLEMENTED BUT NOT DQCUHENTED Underlining 03 July 1979 Underlin: Underlining appears strange on d e v i c e s t h a t cannot support overprinting (datamedias, memorex t e r m i n a l s , c e r t a i n remote printers) s i n c e the underlines ( i . e . the overstruck l i n e s ) are eVcwN-yxJ printed above the a s s o c i a t e d t e x t . Don't panic, your ' ~ ---•_.-* -_ the .. -.. ....._.__ _ the output i i output vv ii ll ll look look O OK K vhen printed on TN p r i n t e r or Qualtera using *DITTO. / K*. I
Footnotes
•
02 February 1979 The v a r i a b l e FOOTCONTINUE has been added. I t i s printed at t h e beginning of f o o t n o t e s vhich are continued t o the next page. I t ' s d e f a u l t i s " ( c o n t ' d ) " .
lO-e 0 ^ -Ak silftvs ^ T*U, y*/ I*-* *^*l &• •*+" u ^ f ^ ftjds?\
T
August, 1979
Computing Services 352 General Services Bldg. The University of Alberta Edmonton, Canada T6G 2H1 (403) 432-2261
October 4, 1979
Coleen Melsness Simon Fraser University Burnaby, B.C. V5A 1S6 Coleen:
Thanks for the list of bugs. We found it very easy to work from. indicating which bugs will I have enclosed a copy pf your list, be fixed in the November release. Answer §1 You found a bug, which we will fix. If you need to use the facility in the meantime, test'> will do the trick. Answer #2 I made your request TXTFsFORUM item #32. We'll see what the others think. In any event the extension is not critical enough to warrant rushing it into the November release. Answer §3 The only intent here was to dissuade users from typing their input into the program, rather than a file. Another advantage to using SCARDS= is that the listing indicates what file was attached to SCARDS. Solution
#1
We had not seen it before, if you wish the size of the space to be fixed use texttext. We are unwilling to automatically place a fixed size space between the footnote counter and the text, because some users do not want one.
75
Solution
82
This looks like a 'for really' problem; however I was unable duplicate it. Please send me some data. Solution
to
#3
I can't think of a logical explanation for doubt (hope) that it cannot be duplicated.
this.
I
seriously
As for your moving problem. If you can't reach a solution soon, I'll sign on to your system from here, and give yovt a hand.
/
/
Grant Crawford Computing Services GRC/hmc
76
ITEM 30 19:29 Oct01/79 31 LINES CULHAH, EARL A. (UQV) A r o s e by any o t h e r name v o u l d s m e l l a s s v e e t . The TEXTFORM group i s c u r r e n t l y working on d o c u m e n t a t i o n . T h i s vould seem t o be an a p p r o p r i a t e t i m e t o g e t your t v o c e n t s v o r t h i n on some of t h e n a a e s used i n t h e l a n g u a g e . A c t u a l l y , i t s a l m o s t t o o l a t e for t h i s go around, s o a c o n c e n s u s must be formed PGQ. At t h e D e t r o i t v o r k s h o p , s e v e r a l i n s t a l l a t i o n s s a i d t h a t t h e y vould p r o v i d e a l i s t of names t h a t t h e y v o u l d v a n t t o s e e c h a n g e d . No l i s t s a r r i v e d , s o I assume t h a t e v e r y t h i n g i s a l r i g h t . I n l i g h t o f t h i s , my ovn l i s t of names of t h i n g s t o be changed a i g h t b e g o i n g a g a i n s t t h e a c c e p t a b l e s t a t u s guo. I f you have a s t r o n g f e e l i n g , t h i s i s your c h a n c e t o say s o , NOW and LOUD. I f v e can c o a e t o a common agreement q u i c k l y , t h e n t h e s e changes v i l l be i n the november r e a l e a s e . I f n o t , not. o l d name proposed name TIHRLIMIT TIHERLIMIT POSN ( i t i s a keyvord) POSITION OUTCHAR OUTDEV PROOFCHAR PROOFDEV ENG FRENCH ROM SPLITSTRG TEXTWID
ODCHARACTERSET ODNAHE PDCHARACTERSET PDNAHE ENGLISH FREN ROMAN SPLITSTRING TEXTWIDTH
Some others in the same vein have already been changed. LETTERSPACE DEPLETSPACE DEFHDSPACE HORDSPACE GBGESPACE GARBAGESPACE As only systems people are in this forum, maybe you could ask for opinions from the tecnical vriting staff at your installation as veil. 10 VOTES/FEELINGS A loud CHEER for all these suggestions. (ab/ubc) YES! xDCHARACTERSET is a might long, but I can't think of anything shorter unless you're already using a shorter form of "characterset". (ghl/UM) 1 aa NOT a Systems People! Hill consult vith others here for any other changes. Hov about HAXWORDSPACE rather than HAXHDSPACE. (Doug)
77
ITEM 28 20:20 Aug13/79 54 LINES ?RIME=25 LIFT, GAIL (UH) TEXTFORM and DITTO If ve expect t o make s i g n i f i c a n t use of •'DITTO v i t h output from TEXTFORM, ve v i l l need more f a c i l i t i e s than *DITTO c u r r e n t l y p r o v i d e s . Here are a fev thoughts on vhat f a c i l i t i e s ve do need. When p r i n t i n g output from TEXTFORM on a terminal on s i n g l e s h e e t s (and t o some e x t e n t on continuous forms) ve need t o be able t o do the f o l l o v i n g : 1) Stop on page boundaries t o v a i t for a nev s h e e t of paper 2) Repeat t h e j u s t - f i n i s h e d page i f t h e user r e q u e s t s (probably by typing something other than j u s t a CR vhen i n s e r t i n g a nev s h e e t ) 3) Take an a t t e n t i o n during printin g of a page and r e p r i n t the page 4) Have the user change type e l e a e n t s on a page Items 2) and 3) are necessary because many "nice output" t e r m i n a l s are soaevhat f l a k y , and don't alvays feed the paper s t r a i g h t , e t c . I don't think any output device (OD) c u r r e n t l y r e q a i r e s 4 ) , bat c e r t a i n l y soae v i l l as the output d e v i ce support i a p r o v e s . •DITTO has the a b i l i t y t o r e p r i n t an a r b i t r a r y page; t h i s vould be n i c e , but c e r t a i n l y not e s s e n t i a l (and • D I T T O ' S vay of i d e n t i f y i n g the page s e q u e n t i a l l y rather than by page nuaber i s not very c o n v e n i e n t ) . A l l t h i s could be done e i t h e r by the output d e v i c e (OD) or by a postprocessor (*DITT0). These t h i n g s are b e t t e r done by some c e n t r a l processor rather than s e p a r a t e l y i n each OD. This vould insure a uniform user i n t e r f a c e and e l i m i n a t e the need t o v r i t e the code i n t o each OD. The " c e n t r a l processor" could be something that s i t s betveen the 00 and the term, n a l , or *DITT0 (or perhaps b o t h ) . One argument for using *DITT0 i s c o s t . Running a document through *TEXTF0RH t v i c e i s an expensive vay t o get t v o c o p i e s o f s o a e t h i n g . I t i s a l s o convenient t o be a b le t o run TEXTFOfifl on a t e r a i n a l other than the one used for p r i n t i n g f i n a l c o p i e s . Bat i t voald be a nuisance to alvays be forced t o use *DITTO t o p r i n t t h e output on a t e r a i n a l . There are soae problems v i t h using *DITT0: 1) Type element changes must be coded for i t i n soae vay so t h a t *DITTO can t e l l the user vhat t o change t o and s t o p and v a i t at t h e r i g h t t i a e for t h e user t o do i t 2) I t has t o r e c o g n i ze page boundaries (but perhaps c c , mcc and c t r l - L are t h e only p o s s i b i l i t i e s ) 3) For s o ae d e v i c e s , i t may have to handle overprinting or v a r i o u s c a r r i a g e c o n t r o l operations The f i r s t problea i s l i k e l y t o be the vorst s i n c e i t i n v o l v e s p a t t i n g extra s t a f f i n t o the output t e x t vhich should not be p r i n t e d . To do t h i s c o r r e c t l y , the OD must knov whether •DITTO v i l l be ased t o print the document (so t h e user has t o have a vay t o t e l l i t ) . Once t h i s information i s included, •DITTO most a l v a y s be used t o print the document. I think ve should have an *DITT0 vhich v i l l at l e a s t vork f o r aost documents on most output d e v i c e s . Hovever, I think t h a t the user should not be obliged t o use •'DITTO to print a document (although i t i s not completely unreasonable t o require •DITTO'S use t o g e t s i n g l e s h e e t o p e r a t i o n ) . A r o u t i n e vhich a c t s a s as user i n t e r f a c e t o the OD might also be n i c e . Comments? 25 REF TO ITEHS 2 VOTES/FEELINGS This sounds s i m i l a r t o HTA's proposal for a u t i l i t y program t o copy
n
files to the Xerox 9700. At least both programs vould interpret control seguences imbedded in the text. John Gourlay I think that John is refering to item 370 in HTS:FORUM. It's not much of a "proposal," just a suggestion for one vay to approach support for the Xerox 9700. (HTA)
79
FROM THE UNIVERSITY OF BRITISH COLUMBIA COMPUTING CENTRE
John Coulthard
2076 WESBROOK MALL. VANCOUVER, B.C. V6T 1WB
A
DEPARTMENT:
TO
SOFT Committee
DATE: Sept. 11, 1979
S Newsletter
SUBJECT
t - W f c *
*
&
*
* * r i t m - J t
• J . * I * M » * . .
-
*
• . » « •
*IF .•<#» ; . ( . W l
. - » . » , * »
MESSAGE Attached find a copy of Tony Buckland's memo on possible improvements to the efficiency of the *IF interpreter. In view of the results we do not intend to proceed with this project in the forseeable future.
J «
SIGNED
REPLY
REPLY DATE:
Speedmemo TO OfttOtMATE — ••
SIGNED
for !_»„> t a n - i t . Bo.B or No. ta window liiwitftw:-••.
c
(_•
C
U
___3VBF
Writ, raply — retain »Wl» OflplMl M d t.tum pink copy.
v-^*w
C
80
(
L
c
BUMNUtS PORata LTD. (004|_NkV«111
1
To: John Coulthard From; Tony Buckland ,
July 25, 1979
POSSIBLE IMPROVEMENTS IN THE "IF" INTERPRETER'S EFFICIEHCY I investigated the distribution of CPU time during interpretation, using the TIHETALLZ facility of debug mode, for a number of different kinds of activity vhich I believe betveen them: -
are those on vhich FORTRAN programs tend to spend most of their time;
-
exercise most of the Interpreter's code (excepting command interpretation, statement function evaluation and calls on compiled routines by loaded routines)•
Where Interpreter code segments vere more heavily used, I looked for possible specific local improvements. In addition, I tested several more global improvements (tvo of the most fruitful of vhich vere suggested by Dennis O'Reilly). I had thought that a particular difficulty in this investigation vould be estimating hov much of its time an "average FORTRAN program" spends on each of the more common types of statement. Hovever, I found that, although certain kinds of improvement have more effect on certain statement types than on others, the sum of these improvements, for each of several types vhich should be most heavily used, vas very approximately the same.
I am therefore able to conclude that this investigation indicates the possibility of achieving, at the expense of a fev months* effort, a reduction in CPU time used during IF interpretation of approximately 10% to 20%.
I have doubtless overlooked many specific improvements, or have failed to imagine certain design changes that could increase these figures; but my "gut feeling" is that I could not add more than about half to them, yielding an overall improvement of no more than a guarter in Interpreter efficiency. Beyond this, a complete revrite could be attempted vith unpredictable results; this could take a couple of man-years, and at least the most heavily-used sections vould have to be done in a lov-level language to achieve the necessary efficiency.
81
2 Kinds, of Improvement Investigated Every time the Interpreter places an object on its vorking stack, it checks for stack overflov. By redesigning the stack, I coald take advantage of a system feature and ignore the possibility of overflov, letting program interrupt interception take care of the very rare actual overflovs. Stack underflov handling could also be simplified. This vould be moderately difficult due to the necessary redesign and the many stack operations in the Interpreter. Whenever a variable or array is referenced, the Interpreter tests it for allocation (assignment of memory locations). This could be coapletely avoided vith easy code deletions in the Interpreter, if all variables and arrays vere alvays allocated; but of course other IF modules must first be modified to make the necessary allocations. Soae specific code segments could be replaced by more efficient equivalents, vith. trivial effort except in some Example: cases vhere an unused register must be found. replace an HVC of 4 bytes with a load and store. Some conditional branches vhich nov nearly alvays occur could be aade to almost never occur by repositioning certain blocks of code, vith trivial effort. Certain sequential small-table searches vhich turn out to use disproportionate amounts of time could be replaced vith table lookups vith relatively little effort in recasting the relevant tables. Some small but heavily-used code segments could be eliminated if re-allocation of base registers could be done so that base changes and branches became unnecessary. In some cases, finding an extra base register or staying vithin the range of an existing one could require ingenuity and considerable care. A couple of branches could be avoided segments of code.
by
duplicating
short
In the particular case of array initialization, complete redesign of a relatively small part of the Interpreter could radically improve efficiency.. The present code behaves more or less as though an array vere a sequence of individual variables, vith considerable resulting vaste. In this case, hovever, there is some question as to whether there are many programs vhich spend a high proportion of their time on the once-only task of initialization.
82
3 Distribution of_gossible Percentage Improvements The following table gives percentage improvements in total CPU consumption vhich appear to be achievable, by each of the above categories of improvement and in total, for each of the kinds of FORTRAN program activity tested. Rounding effects cause some table columns not to total exactly.
83
u Internal/ external SUBBOUTINE invocation
writing
2.8
1.9
1.3
1.9
0.6
0.3
|
7.3
9.5
2.5
6.1
6.8
2.4
|
0.1
1.7
1.7
1.1
1.7
1.9
1.2
0.8
I
1.0
0.5
0.7
1.0
0.6
0.3
1.3
0.9
I
2.6
4.8
1.9
0.8
|
!•*
0.7
2.3
1.2
6.5
Logical operations (with constants)
Sinpler stack over/ underflow
0.1
0.4
4.7
Drop allocation testing
0.1
13.9
Use nore efficient code
9.8
1.1
Less frequent .ranching
0.7
0.1
Table lookup instead of searches Slininate soae base changes
4.4
Duplicate short code segaents
5.4
7.0
50.9 *
Totals (excluding
24.6
15.4
13.0
0.1
1.5
0.9
|
0.13
4.6
18.0
20.6
9.8
J
15.7
14.1
|
1.8
9.5
This improvement involves rewriting the entire section, and is therefore nit in addition to the other improvements above
J
2.9
0.1
1.6
aedesign array initialization
*
Arithmetic operations
13.9
0.1
Arithmetic IFs
Internal/ external FUNCTION invocation
DO looping
Inproveoent 1
PBINTing | GOIOs (format- | free) |
Subscripting
Array initialization
Activity ->
J
J
«_-
HARDWARE OR,
"J""*
^»ReA-r 77©o
t>£hfi7£
85
ITEM 361 0 0 : 5 2 Aug10/79 16 LINES PRINE=359 NEXT=362 HEBSTER, C. DABYL (UQV) XEROX 9700 D i s c u s s i o n : C a l l f o r FORUM-like c o n f e r e n c e ; Xerox 9700 page printer I n r e s p o n s e t o D o n ' s c a l l fo r d i s c u s s i o n s on Xerox 9700 s u p p o r t , UQV i s s u b m i t t i n g a s e r i e s o f FOfiOM i t e m s under t h e agenda t o p i c •Xerox 9700 page p r i n t e r 1 . Be a g r e e t h a t t h i s i s a r e a s o n a b l e s u b j e c t f o r a Task F o r c e s i n c e v e t h i n k e a c h i n s t a l l a t i o n may have a d i f f e r e n t i d e a of t h e use t o be made o f t h i s d e v i c e and ve had b e t t e r come up v i t h s u p p o r t a c c e p t a b l e to all installations. P r o b a b l y t h e b e s t vay f o r t h i s Task Forc e t o f u n c t i o n i s through a FORUM-like c o n f e r e n c e p l u s o c c a s i o n a l c o n f e r e n c e c a l l s . A p h y s i c a l meeting of p e o p l e i n v o l v e d may not be a b l e t o a c c o m p l i s h a l l t h a t i s n e c e s s a r y . Me have found t h a t each m e e t i n g ve have had v i t h t h e Xerox s a l e s and t e c h n i c a l p e o p l e h a s a ns ve r ed q u e s t i o n s from p r e v i o u s m e e t i n g s and r a i s e d nev o n e s . Don, can you o r g a n i z e such a c o n f e r e n c e ? I f s o , t h e f o l l o w i n g p e o p l e from UQV vould p a r t i c i p a t e : Kathryn Hard, Dave Evans, Garry J a c k s o n , John S t a s i u k , Henry Evasechko, Grant Crawford, and m y s e l f . REF TO ITEMS 359 REF BY ITEMS 362 363 36U 365 366 391 5 VOTES/FEELINGS Hov do o t h e r p e o p l e f e e l a b o u t such a CONFERence? Would you l i k e t h e d i s c u s s i o n i n MTS:F0RUM or someplace d i f f e r e n t ? ( - J e f f Ogden/UM) My i n i t i a l f e e l i n g i s t o keep i t i n FORUM j u s t t o keep t h e number of CONERences manageable (1 b e l o n g t o 7 n o w ! ) . Hovever, i f t h e volume of e x c h a n g e v i l l be t r u e l y huge, a nev CONFERence may be j u s t i f i e d . JHH/UM I t s h o u l d s t a y _n MTS:FORUM / RCF3SFU Keep i t i n MTS:FORUH. Fred S v a r t z I t h i n k i t s h o u l d s t a y i n MTS;FORUM.
\_ .
86
* £
/-
"\
ITEM 362 01:11 Aug10/79 55 LINES PRIME=361 NEXT=363 HEBSTER, C. DARYL (UQV) XEROX 9700 Discussion: What installations hope to accomplish; Xerox 9700 page printer In starting discussions about the implementation of the XEROX 9700 page printer, it vould be vise to understand vhat each of the installations would like to accomplish by installing a 9700 page printer. UQV vill begin by describing vhat ve vould like to accomplish. UQV has ordered a 9700 page printer for delivery on 1 October 1979. The printer is being ordered vith: -the online feature -an additional 64k of forms memory -an additional 768k of font memory -the Databuss svitch -the duplex feature (i.e. tvo sided printed) -no tape drive Unfortunately, even though XEROX accepted our purchase order, the duplex feature vill not be available initially. The present indication is that the duplex feature vill become available, in the U.S., during the early part of the 4th guarter of 1979. Our current local printing environment consists of: -three IBM 1403 line printers (purchased) -one IBM 3211 line printer (leased) -tvo Dataprinter line printers (purchased) one of which is used in the student area -four types of print trains PN, TN, APL, ALA (leased) which are used with the 1403 line printers. Eventually, after installing the 9700 page printer, our printing environment will consist of: -one XEROX 9700 page printer -three IBM 1403 line printers one used as a hard copy log for the operator*s console one used in the student area one used in the center for special forms not available on the 9700 and for braille -one type of print train (TN) mounted on the 1403 line printers The two Dataprinter line printers vill become local printers located remotely. The IBM 3211 line printer vill be returned to IBS. The APL, ALA, and PN print trains vill also be returned. Currently, our users have the ability to control several aspects of the printing environment. They can specify the print train, the type and quality of ribbon, and choose from a variety of forms.. Rith the 9700 page printer, we expect the user to also have the ability to control several aspects of the printing environment. The user should be able to specify, at a minimum, the font or fonts, the line orientation on the page, and still choose from a variety of forms. Basically, ve see the 9700 page printer operating in an on-line, large volume, minimum disruption mode. This poses some conflicts vith the goal of using some of the sophisticated features available on the 9700 (discussed in a subsequent item). REF TO ITEMS 361 REF BY ITEMS 363 364 365 366 2 VOTES/FEELINGS What is the databuss feature? (-Jeff Ogden/UM) Our Xerox rep says "The databuss svitch is necessary for the extra memory. It divides the memory into tvo halfs to allow concurrent printing and input etc." (Memory management?). Garry Jackson/UQV
87
ITEM 363 01:13 Aug10/79 137 LINES PRIME-359 NEXT=364 BEBSTER, C. DABY1 (UQV) XEROX 9700 Discussion: Some thorny questions; Xerox 9700 page printer 1. Hov can we give users access to the features of the 9700 page printer and still maintain adequate control over the 9700 so that the 9700 is not used in a disruptive mode? There are tvo vays to justify a 9700 page printer. You are either providing nev services or you are providing services currently available at a lover cost. While there are a number of features of the 9700 vhich can be invoked dynamically by imbedding in the data stream some 9 700 control information (called dynamic job descriptor entries or DJDEs), there are a nuaber of features that can not be invoked dynamically. For example, the design and use of user specified forms, the loading of nev fonts, the alteration of the libraries describing the printing environment on the 9700 (knovn as job descriptor libraries or JDLs) all require that the 9700 page printer be idle and that the operator must offline the 9700 page printer, invoke a 9700 utility, knovn as the HOSTLOAD utility, start a job on the host to ship the data across to the 9700, invoke the forms description language or FDL compiler to compile any user forms or invoke the print description language or PDL compiler to compile any job description entries or JDEs, and finally re-establish the 9700 as a printer. Besides being inefficient use of the 9 700 page printer, since you can't be printing during this time, the procedure is extremely avkvard. Hov is a user informed that errors exist in his FDL or PDL source? Hov long do you keep user-defined forms on the 9700 system disk? The operator has to manually delete any such form definitions. Hov do yon charge for user-defined forms? There is a conflict betveen keeping the costs of printing, on the page printer, reasonable and allowing users access to nev services vhich may be disruptive and increase the costs to an unreasonable level. 2. Hov does the system charge for printing done on the 9 700 page printer? An initial decision ve've reached is that ve vould eliminate the lines-printed charge as it becomes meaningless. Re also have surcharges for special print trains (like APL and ALA) and for special ribbons. These surcharges vould also be eliminated. This leaves us vith pages-printed charges and a surcharge for special forms. Nell then, hov do ve determine hov many pages have been printed? Keep in mind, that ve may be printing on one or two sides and our printing format may be such that tvo or more logical pages are actually being printed on one side of a physical page. While the 9700 page printer keeps numerous statistics about the jobs being printed, there is no vay to obtain this information from the 9700 in an on-line mode. The statistics can be printed on the 9700's console or dumped to the 9700's tape drive (except at UQV we won't have a tape drive). This means that soae level of the system, the DS8, HASP, or a DSP, has to figure out hov many physical pages are being printed and this implies that the host support has intimate knovledge of the job description libraries or JDLs residing in the 9700* This brings us to the next q nest ion. 3. Hov does one coordinate information required both in the 9 700 page printer and in MTS? For example, the basic printing environment for a page is described by a page descriptor entry or PDE. This PDE specifies the list of fonts available; the orientation of the lines on the page (landscape or parallel to the long side of the page, portrait or parallel to the short side of the page); the location of the starting logical line on
88
the physical page. It is possible to switch from one PDE to another using control information in the print data stream (via DJDEs). If ve allow the user to specify PDEs in some manner, then MTS and HASP must be able to validate the PDE specified by the user and provide some error indication if an incorrect PDE has been specified. This means that the host support must have a list of PDEs available on the 9700 page printer. The host support may also have to have knowledge of the contents of the PDE. For example, there may have to be a mapping of logical font names to font indices (see question 4). 4. How do we minimize or eliminate any 9700 specific data in users' print files? For example, font switching on the 9700 is done by including a byte in the data line which is an index into the font list specified in the page descriptor entry or PDE. This index can have values from 1 to 15. If the user were to have this font index imbedded in the data line in his print file, the font list in the PDE could never be changed without the user having to recreate his print file. It vould be more reasonable to have logical names for font names, probably the XEROX font names. 5. How do you provide backup in the event of corruption of the 9700 system disk? At UQV, without a tape drive attached to the 9 700, it vill not be possible to create a copy of the system disk. In the event of a failure, it would be necessary to transfer the source for the print description libraries or PDLs back to the system disk via the HOSTLOAD utility and then re-compile them as there is apparently no facility for transferring the object. This could take a few hours. It vill probably be necessary to have a second disk pack and make a copy of the system disk whenever it's contents change. 6. Hhat impact will the 9700 page printer have on operations? The limited capacities of feed trays and stacker bins vill keep an operator busy. How do you handle the output? Alternatives are stapling, binding, shrink wrapping, rubber bands, etc. What is a suitable environment for paper storage? 7. When do printing environment changes take effect? In the present system, the user can direct output to a PN printer, produce some output, and then after second thoughts, redirect the output to a TN printer. This change applies to the entire output, with the 9700 page printer, changes can be made on a page-to-page basis. For example, one page could be printed in landscape mode and the next page in portrait mode. Because this change is caused by control information placed in the data stream, the user could not have a change in printing mode apply for the entire output unless HASP can be changed to insert the appropriate control information in the output data stream. There is no problem if we allow the change to take effect only on the next and succeeding pages, but this is an incompatible change in the way the user sees the system behaving. 8. How do we handle error situations concerning user data lines? A user may specify an invalid font name (or in the future other invalid control information) or may have generated a Dynamic Job Descriptor Entry (DJDE). The DSB should give a non-zero return code and provide an error message, but should the errors be fatal or non-fatal? On the 9700 page printer side of things, certain requests are treated as fatal and the output is not printed and other requests are treated as non-fatal and the output may not be printed as intended. REF TO ITEMS 359 361 362 REF BY ITEMS 364 365 366 374 384 388
89
9 VOTES/FEELINGS Has anyone approached Xerox v i t h : Hov hard i s i t (and i s i t OK) for us (or them) t o modify the hardvare t o allow b e t t e r communication betveen t h e device and t h e mainframe? I s the FDL compiler a t l e a s t s l i g h t l y portable? Can ve have i t ? e t c . DanG/UM See item 366 f o r response to DanG. Daryl Webster (UQV) Many of t h e s e problems can be solved by using the second c o n s o l e i n t e r f a c e on the 9700 connected t o a port on MTS. Then HASP (or vhatever) can be a "console operator" for the 9700. (MTA) Mike i s probably r i g h t , but boy does that sound grungy. RLH/Merit A Xerox t e c h n i c a l rep. s a i d he though ve could use the 2nd i n t e r f a c e , bat i t l o o k s l i k e t h e UQV rep. thought o t h e r v i s e . ( - J e f f Ogden) As someone e l s e said somevhere no one wants t o t a l k about question 6. She pages are going to have to be bound somehow, which means that 9700 l i s t i n g s v i l l be harder t o WORK with than fan f o l d . Will anyone use the 9700 for program l i s t i n g s ? Paul P. I have used l i s t i n g s i n t h a t format o f f Gould p r i n t e r s and l i k e them b e t t e r than the b i g o n e s , generally . Takes g e t t i n g used t o tho. Binding i s an o p e r a t i o n s problem, not a programming one. JHH/um JHH, I s t h a t vhy you have a b o t t l e of binding glue on your desk? Fred Svartz Can t h e 9700 vork v i t h pre-punched paper (for a 3-ring binder)? MFH/um
--
90
0*\ \
ITEM 364 0 1 : 1 5 Aug10/79 21 LINES PRIME=359 NEXT=366 WEBSTER, C. DABYL (UQV) XEROX 9700 D i s c u s s i o n : A t e n t a t i v e p r o p o s a l ; Xerox 9700 page p r i n t e r For a v a r i e t y of r e a s o n s , we've d e c i d e d t h a t i m p l e m e n t a t i o n of s u p p o r t f o r t h e 9700 page p r i n t e r s h o u l d o c c u r i n t v o s t a g e s . The f i r s t s t a g e vould be t o support t h e 9700 page p r i n t e r i n a s i m p l e mode but t a k i n g a d v a n t a g e of a t l e a s t t v o f e a t u r e s o f t h e 9 7 0 0 ; c o n t r o l o f t h e l i n e o r i e n t a t i o n on t h e page ( l a n d s c a p e o r p o r t r a i t ) and t h e a b i l i t y t o change f o n t s v i t h i n l i n e s . A w r i t e u p c o n t a i n i n g more d e t a i l s i s c o n t a i n e d i n t h e f i l e W406:9700PROPOSA1. The w r i t e u p i s a m i x t u r e o f s p e c i f i c s and g e n e r a l i t i e s and i s i n t e n d e d t o s t i m u l a t e d i s c u s s i o n on s u p p o r t f o r t h e 9 7 0 0 . We h a v e found t h a t ve have had s o a e m i s c o n c e p t i o n s a b o u t vhat t h e 9700 can and c a n ' t do (and s t i l l may have s o a e ) and ve think t h a t o t h e r s may s h a r e t h e s e m i s c o n c e p t i o n s . We f u l l y e x p e c t t h a t t h e f i r s t i m p l e m e n t a t i o n v i l l be a "throw-away" v e r s i o n . I t seems t h e more v e l e a r n about t h e 9700 page p r i n t e r , t h e more q u e s t i o n s ve have about hov t o s u p p o r t i t i n an o n - l i n e mode. Many of our q u e s t i o n s v o n ' t be a n s v e r e d u n t i l ve have t h e 9700 i n s t a l l e d and g a i n some e x p e r i e n c e v i t h i t . One major c o n c e r n i n a d o p t i n g t h i s a t t i t u d e i s t h a t t h e d e f i n i t i o n of hov t h e u s e r s p e c i f i e s dynamic c h a n g e s through i n f o r m a t i o n imbedded i n t h e data stream s h o u l d not be t o o d i f f e r e n t from v h a t i s e v e n t u a l l y d e f i n e d . REF TO ITEMS 359 361 362 363 BEF BY ITEMS 365 366 367 368 370 374 4 VOTES/FEELINGS I read t h e p r o p o s a l . My i n i t i a l r e a c t i o n i s : Perhaps ve s h o u l d REPLACE the p r i n t o u t p u t i n t e r f a c e t o t a l l y and t h e p r i n t e r r o u t i n e s i n HASP v i t h s o m e t h i n g more u s e f u l t o t h e RM. O t h e r v i s e t h a t ' s an AWFUL l o t of work t o p i t c h when t h e RM comes a l o n g . JHH/UM I t h o u g h t UBC a l r e a d y had a DSP f o r t h e 1403. Perhaps t h a t i s a p l a c e to s t a r t . ( - J e f f Ogden/UM) Jim and J e f f : After a l o t of c o n s i d e r a t i o n , I d o n ' t t h i n k t h a t i t ' s t h a t b i g a change — of c o u r s e , I ' v e been wrong about t h i s t y p e of e s t i m a t e i n t h e p a s t ! Garry Jackson/UQV
91
XEROX 9700 Discussion: Proposed I n i t i a l Implementation C.D.wiH&>sf 6-* Co vill allow the user to direct his ontput to a specfic type of printer. This keyword can be used on the {CONTROL, $SET, and $SIGN0N commands and via the CONTROL subroutine. Again, initially, the user vill be restricted to specifying the DEVICE keyvord before any output is passed to HASP. 3. The nser vill still be able to specify PRINT=, RIBBON=, and FORM= keywords and vhether the output vill be directed to the page printer or line printer is described in the following decision table.
92
1 keyvord
DEVICE= |
| PRINT=pde-id | PRINT= | PRINT=TN | PRINT=PN | RIBBON=
valid valid calculate t o use | valid valid
| j PDE-id| | t |
error error
I i m p l i e s PAGE i m p l i e s PAGE
valid valid
i m p l i e s PAGE I depends on o t h e r I control options
| | |
|
valid
|
|
error i f not | CNTR
FORM=x; vhere X e r r o r i s n ' t available f o r t h e 97 00 FORM=y; where yi v a l i d isn' t available f o r t h e 14 03 F0RM=z; where z v a l i d i s available f o r both
i m p l i e s LINE
| 1
1 valid |
i m p l i e s LINE i f not CNTR, e l s e depends on o t h e r ! control options
\ | | |
j valid
I i m p l i e s LINE
1
i error
i m p l i e s PAGB
|
|
de pend s on o t h e r control options
| |
depends on o t h e r control options
| |
%
1 1 1 | | | | | |
|
j
error
| ROUTE=
ANY
LINE
PAGE
valid
| COPIES
g e n e r a t e DJDE t o | l e t HASP have 9700 do i t | do i t
| AUTOPGNUH
valid
|
error
1 i m p l i e s PAGE
|
4. Font changes will be indicated by data lines which contain control information at the beginning of the line. The control information will be preceeded and folloved by a user definable escape sequence. or
control-inforraation control-inforaationdata
I n i t i a l l y , t h e only c o n t r o l - i n f o r m a t i on t h a t v i l l be v a l i d v i l l be t h e keyword FONT=logical-font-name. I f a font name i s s p e c i f i e d t h a t i s not contained in the font l i s t of the c u r r e n t PDE, an e r r o r (?) message v i l l be p r i n t e d . Note t h a t multiple font changes in one p h y s i c a l l i n e a r e accomplished by o v e r p r i n t i n g and t h i s v i l l be the r e s p o n s i b i l i t y of the u s e r - l e v e l program. In subsequent implementations, o t h e r keyvords t h a t could appear as c o n t r o l - i n f o r m a t i o n a r e PDE= C0PIES=
( t o change t h e PDE on a p a g e - t o - p a g e b a s i s ) ( t o change t h e copy count on a p a g e - t o - p a g e b a s i s )
93
CHE= HARGIN=
(to allow predefined copy modification entries to be selected) (to allow left printing margin to be changed on a line-to-line basis)
It vould be more general to allow the control-information to appear anywhere in the line, but the overhead of scanning for the escape seguence and reformating the line seems excessive. 5. The user can define the escape seguence which signals that a line contains control information via a: new keyword ESCSEQ= which can be specified on the $C0NTROL, {SET, and {SIGNON commands and via the CONTROL subroutine. The right-hand side of the keyword is either an arbitrary number of characters or DEFAULT. If the user doesn't specify an escape sequence, it vill default to the single character (that we haven't decided upon yet). 6. The user vill be able to modify the action of the page numbering facility by using a nev keyvord AUTOPGNUM vhich can be specified on the {CONTROL, $SET, and {SIGNON commands and via the CONTROL subroutine. AUTOPGNUM=<(n,l,c,ON|N0NE|OFF> vhere
n is the starting number 1 is the line # on vhich it should appear c is the column # in vhich it should terminate ON is equivalent to (1,x,y) where x and y depend o \ the PDE in effect NONE or OFF are equivalent
that the systea looks like to the operator. 1. At HASP start-up time, the operator will start-up the 9700 page printer vith the 9700 START command and then SSTARTs and {DRAJNs the printer as he nov does. The 9700 page printer is operating on a single job basis, but vill recognize MTS header and trailer sheets as "banner" pages vhich separate "reports". 2. The header and trailer pages vill alvays be printed in landscape mode vith the default font. 3. When special forms are required, the page printer vill be started as a special forms printer with a specific form. This vill enable HASP to print all the output requiring the specified form vithout operator intervention. What parts of the system have to change? 1. There have to be changes at the MTS command level. Soae keywords have been extended and nev keyvords have been added. There aay have to be additional consistency checks made at this level. The commands involved are {CONTROL, {SET, and {SIGNON. There vill also have to be changes to the CONTROL subroutine. 2. The bulk of the changes vill go into the HASP printer DSR. The
94
DSR must be able to do the f o l l o v m g : - process all nev control information. For example, the DSR must be able to handle a request for a specific PDE. This implies the DSR must know which PDEs are available on the 9700 page printer and reject invalid PDE requests. - check that data lines do not contain any data that might be recognized by the 9700 as a dynamic job descriptor entry (DJDE) and reject the line as an error - check for escape seguences which signal control-inforaation and perform the control action - insert a font index value in the data line - on font change requests, determine the appropriate font index that must be inserted in the data line (this iaplies that the DSR must be aware of the font list in the PDE in effect) . - generate DJDE data lines to cause the 9700 page printer to select the correct PDE to provide the requested services. - before generating the trailer page, insert a DJDE that specifies the default PDE. - notify HASP of three situations (1) a job that must be run on a line printer because of a specific request (2) a job that must be run on a page printer because of a specific request (3) a job that was initially directed to the page printer but has been subsequently re-directed to a line printer (so that HASP can strip out DJDE lines) The format of the data lines being passed to HASP by the DSR will be changed to: 4-0 •2 +3 •4 +5
length of data (including font index byte) offset to font index carriage control data font index data
font index- it is necessary to included the font index vithin the data line as it is part of the data passed to the 9700 page printer. For those jobs printed on a line printer, the font index will be ignored by HASP. length of data- has been expanded from one byte to tvo bytes because some fonts on the page printer allov more than 254 characters in a line. offset to data- was added in case ve eventually find that additional control information has to be inserted HASP changes will include: - allow the new line format - remove the restriction of lengths to 254 bytes - add code to strip off DJDE lines when re-directing ontput to a line printer which was initially directed to a page printer. - add code to ignore the font index byte when the output is directed to a line printer. - add code to allow the operators to start the 9700 page printer either (1) as a non-special forms printer via
95
or
{STARTPAGEPTRn (2) a s a s p e c i a l forms p r i n t e r $STARTPAGEPTRn,FORM=aa
via
E. What h a s t o be done on t h e 9 700 page p r i n t e r ?
^
1. There v i l l be a s i m p l e Job D e s c r i p t o r Entry (JDE) as t h e d e f a u l t JDE. \" U i ^ t m * 1 1 1 b e a l i o i t e d s e t of Page D e s c r i p t o r E n t r i e s (PDEs). J. The HTS c a r r i a g e c o n t r o l t a p e c o n v e n t i o n s v i l l b e p r e s e r v e d . 4. o n l y s i n g l e - s i d e d p r i n t i n g a v a i l a b l e i n i t i a l l y . 5. Only one l o g i c a l page per p h y s i c a l page w i l l be s u p p o r t e d initially. 6. There v i l l be a l i m i t e d s e t of f o n t s .
ITEH 366 0 2 : 3 9 Aug10/79 31 LINES ?RIME=359 NEXT=367 WEBSTER, C. DABYL (UQV) XEROX 9700 D i s c u s s i o n : Hhat ve can e x p e c t from Xerox; Xerox 9700 page printerr I n d i s c u s s i o n s v i t h Xerox s a l e s and t e c h n i c a l p e o p l e , ve have received the following impressions. 1. Be w i l l n o t be a l l o w e d a c c e s s t o t h e 9700 o p e r a t i n g s y s t e m s o f t w a r e . We micht be a b l e t o s e e t h e l i s t i n g s t o s e e hov i t v o r k s , b u t ve won't be a b l e t o modify t h e s o f t w a r e . 2 . Changes ve might r e q u e s t i n t h e 9700 o p e r a t i n g system vould be c o n s i d e r e d , but would only be made i f t h e r e was a economic pay o u t f o r Xerox. Keep i n mind t h a t t h e i n i t i a l o n - l i n e i m p l e m e n t a t i o n has been d i r e c t e d toward i n t e r f a c i n g i n a v e r y s i m p l e minded way v i t h an IBM o p e r a t i n g s y s t e m v i t h t h e 9700 l o o k i n g l i k e a 3211 p r i n t e r . R e q u e s t i n g , f o r e x a m p l e , t h a t ve smarten up t h e communication b e t v e e n t h e 9700 and t h e h o s t s y s t e m ( i . e . a l l o w two way i n t e r c h a n g e d o e s n ' t buy much i n IBM o p e r a t i n g s y s t e m s environments. 3 . Be h a v e n ' t d i s c u s s e d t h e p o s s i b i l i t y o f a l t e r i n g t h e hardware, but X e r o x ' s a t t i t u d e would p r o b a b ly be the same a s t o w a r d s t h e hardware. We d i d d i s c u s s t h e p o s s i b i l i t y o f u s i n g t h e s e c o n d RS232 i n t e r f a c e , but t o t a k e a d v a n t a g e of i t vould mean c h a n g e s t o t h e 9 700 o p e r a t i n g system s o f t v a r e . 4. I t d o e s n ' t appear t h a t t h e Form D e s c r i p t i o n Language and P r i n t D e s c r i p t i o n Language c o m p i l e r s a r e p o r t a b l e or i f t h e y v e r e , t h a t Xerox vould g i v e us a c c e s s t o them. 5. X e r o x ' s e x p e r i e n c e v i t h o n - l i n e 9 7 0 0 s i s l i m i t e d . In f a c t , I don't b e l i e v e the o n - l i n e version i s o f f i c i a l l y a v a i l a b l e u n t i l September. Some o f t h e c u r r e n t d o c u m e n t a t i o n about t h e o n - l i n e use o f a 9700 i s m i s l e a d i n g and ve have been t o l d t h e d o c u m e n t a t i o n v i l l be c o r r e c t e d vhen o n - l i n e s y s t e m s a r e o f f i c i a l l y released. REF TO ITEMS 359 361 362 363 364 REF BY ITEMS 370 374
96
^
^ '
5 VOTES/FEELINGS Damn! DanG/UM On p o i n t 3 , Xerox t o l d us t h a t some i n s t a l l a t i o n s v e r e u s i g t h e s e c o n d i n t e r f a c e and t h e y c o u l d s e e no r e a s o n vhy ve c o u l d n ' t a l s o . (HTA) Xerox t o l d u s f i r s t o n l i n e i n s t a l l a t i o n s v e r e i n May/June. There i s dvb. one i n s o u t h - e a s t Michigan now. Xerox a l s o t o l d u s t h a t v i t h t h e o n l i n e i n t e r f a c e you c o u l d n ' t s v x t c h f o n t s v i t h i n a p a g e . ( - J e f f Ogden/UM) J e f f , t h a t v a s v h a t v e t h o u g h t ; h o v e v e r , when we l a s t t a l k e d t o Xerox (on 30 J u l y ) , t h e y a s s u r e d u s t h a t t h a t f e a t u r e w i l l be a v a i l a b l e vhen v e g e t o u r s y s t e m . They s a i d t h a t t h e o n - l i n e o f f i c a l r e l e a s e d a t e i s 1 S e p t . (GRJ/UQV)
^•brfHWtoJi
ITEM 367 1 1 : 3 7 Aug13/79 26 LINES PEIME=364 NEXT=368 OGDFN, JEFF (UM) Two q u e s t i o n s about UQV's 9700 p r o p o s a l I took a l o o k a t UQV's paper on t h e Xerox 9700 (W406:9700PROPOSAL) and i n g e n e r a l i t seems l i k e a good s t a r t . I've tvo s p e c i f i c q u e s t i o n s however: 1) Rather t h a n m i x i n g c o n t r o l i n f o r m a t i o n and d a t a throng h t h e u s e o f e s c a p e s e q u e n c e s ( s e c t i o n B,. item 4) v o u l d i t be b e t t e r t o i s s u e commands l i k e FONT=name by c a l l i n g t h e CONTROL s u b r o u t i n e a n d / o r u s i n g t h e ^CONTROL command? I n g e n e r a l I d o n ' t l i k e e s c a p e s e g u e n c e s and i f t h e approach s u g g e s t e d i n t h e UQV p a p e r i s t a k e n f e a t u r e s l i k e t h e FORTRAN Format t a b i t e m o r t h e PL/1 C01(n) keyword w o n ' t do what you might e x p e c t i f t h e l i n e happens t o i n c l u d e c o n t r o l i n f o r m a t i o n as w e l l . A l s o t h e CONTROL i n t e r f a c e makes i t much e a s i e r t o r e t u r n e r r o r i n f o r m a t i o n (an e r r o r nuaber & a message) t h e n t h e i n t e r f a c e provided by t h e WRITE I / O r o u t i n e and i t s friends. The o n l y problem v i t h t h i s t h a t I can s e e v o u l d b e commands t h a t t a k e e f f e c t mid l i n e and t h a t c o u l d be d e a l t w i t h u s i n g " o v e r p r i n t i n g " (I t h i n k t h e 9700 v o r k s t h a t v a y ) . 2) Soae f e a t u r e s l i k e AUTOPftGENUH ( s e c t i o n B, i t e m s 3 and 6) c o u l d be implemented f o r dumb p r i n t e r s ( 1 4 0 3 s , 3 2 8 4 s , . . . ) u s i n g c o d e i n thp HPTR (PTR) DSR or i t s r e p l a c e m e n t i n p l a c e o f o r i n a d d i t i o n t o h a v i n g t h e 9700 do t h e work. In those c a s e s vhere i t v o u l d n ' t be t o o hard i t seems l i k e a good i d e a and vould make t h e o p t i o n a l i t t l e l e s s d e v i c e dependent then i t c u r r e n t l y i s . Do o t h e r s agree? REF TO ITEMS 36'4 REF BY ITEMS 368 369 370 384
97
ITEM 368 13:34 Aug14/79 44 LINES PRIME=367 NEXT=369 JACKSON, GARRY R. (UQV) Response to Item 367: Control Subroutine and Fonts, etc. Taking Jeff's points (and MTA's request) in order: 1. We considered using only the CONTROL subroutine at an early stage of our planned 9700 proposal. First, we aren't exactly pleased vith the use of an escape seguence; hovever, after much discussion, ve felt that if one could only change fonts through use of the CONTROL subroutine then ve vould have introduced a very restrictive incompatibility vith current practices. Currently users can create their own print file (that creates "bold face" through overprinting) vith the editor, or may send their print output from a program to a file and then, after checking the output, copy it to •PRINT*. To allow the same flexibility with the 9700 page printer, ve felt that ve had to provide the ability to specify the control information in a data line. (To produce a line on the 9700 that contains characters from more than one font, the line must be sent to the 9 700 as two, or more, lines vith all but the first specifying that overprint should be performed.) The CONTROL subroutine could only be used vith *PRINT* since specifying a font for output to a file is meaningless. If it is decided that ve should allow a file to be COHTROLled to provide a specific font then we can see no way to avoid the use of an escape sequence. We are receptive to other methods of handling this problem. However, ve agree that changing fonts via the CONTROL subroutine (when the output is going directly to *PRINT*) is a useful addition and ve vill consider the inclusion of this facility. 2. Be agree that it vould be vise to provide the AUTOPGNUM option for all printed output. We'll add it iuto the HAS? printer DSR vhen we're modifying it. 3. Mike: ve also want to be able to do this; however, it vill have to vait until ve have settled Thorny Question #2 and have gained some experience vith the beast. But, because the Systems Group (specifically Daryi and Garry) wants it, we may offer it to the Computing Services staff as soon as we get the duplex feature. Imagine, a complete listing of HASP on less than 250 pages! This means that it should get done before anyone else gets a 9700. BEF TO ITEMS 364 367 BEF BY ITEMS 370 374 384 4 VOTES/FEELINGS Seeas to me that you're producing something similar to a plot file. Maybe ve need a device independent printer package and *PRINTSEE, *PHINTQUEUE, etc. Maybe ve need a general vay to save CONTROL information in a file for use vhen the file is read. A program that sets up tabs must now vrite directly to terminal not to a file to be copied. Paul P Is it really necessary or desirable to define an escape sequence if i is restricted to the front of a line? Why not just pick some new carriage character for this purpose? (Scott G./UM) I think Jim Bodvin has the right idea. For any usage as a standard printer, the special options could be disabled. Peter Bird/UM
98
ITEM 369 13:50 Aug14/79 26 LINES PRIME=367 NEXT=370 OGDEN, JEFF (UM) More on the Xerox 9700, data lines, and calls to CONTROL Being just a little stubborn and really not liking to mix control information with data I've got another suggestion. Rather than allowing control information and data to be placed in the same line would it wqrk to split this information up in a line by line fashion? Lines with control information could then be flagged using a special (and most likely user settable) logical carriage control character in the first position of the line. While deep in my heart I don't like this as well as using the CONTROL interface I agree that the problem of placing output in a file and then later moving it to the 9700 needs to be addressed. This scheme still has the problem of hov to return meaningful error messages and codes. It vould vork as expected vith the tab format items and the like and the "escape" character (if you vant to call it that) vould alvays be in a knovn place (col. 1) and of a knovn length (1). I also vonder if the macro facility that Don has been vorking on might be able to help us out here. As I understand it Don's facility will be able to be invoked for any "I/O stream" so it might allow the generation of "CONTROL" calls based on the data being processed and the macros selected, but I guess only Don knows for sure. Don? REF TO ITEMS 367 REF BY ITEMS 374 3 75 384 7 VOTES/FEELINGS votes * new pass Using the macro facility still implies an escape sequence, naaely the macro name. John Gourlay When can we count on the macro facility to be done? Have any goal dates been set? Don? DanG/UM Using a macro to process the output is analogous to *PRINTQUEUE. I'm puzzled— vhy is the special CC character more acceptable than the escape sequence? See Item 375 for vhat was meant to be said in point B.4 of our proposal. (Garry Jackson/UQV) I like the idea of using a fixed CC character for "escape sequences" since it would make it easier for other printing-type DSBs (like for terminals) to do something reasonable vhen they see this junk. (Scott G./UM) The something reasonable could even be done by DSRI if the vrite vas dCC and not 9MCC and the line started vith the special logical CC. I'd guess it vould just call CONTROL. (-Jeff Ogden/UM)
99
ITEM 370 1 6 : 5 9 Aug14/79 30 LINES PRIME=36 7 NEXT=374 ALEXANDER, MIKE (UM) More on t h e Xerox 9700 i m p l e m e n t a t i o n . I s t i l l t h i n k v e h a v e n ' t come up v i t h a good s o l u t i o n t o t h e problem of hov a u s e r i s t o s p e c i f y c o n t r o l i n f o r m a t i o n f or t h e 9 7 0 0 . I also t h i n k t h a t i t i s ver y d e s i r a b l e t o g e t t h i s r i g h t on t h e f i r s t i m p l e m e n t a t i o n , s i n c e t h e amount and c o m p l e x i t y of c o n t r o l i n f o r m a t i o n t h a t v i l l need t o b e p a s s e d from u s e r programs t o the DSR v i l l be much g r e a t e r i n t h e f i n a l i m p l e m e n t a t i o n , and ve c e r t a i n l y d o n ' t want t o have t o i n v e n t s t i l l a n o t h e r vay t o p a s s t h i s i n f o r m a t i o n l a t e r . I f e e l t h a t a t t h e DSR l e v e l c o n t r o l i n f o r m a t i o n s h o u l d be p a s s e d t o t h e CONTROL e n t r y o n l y . The i n t e r f a c e t o t h e CONTROL s u b r o u t i n e might be g e n e r a l i z e d some t o a l l o w a more e f f i c i e n t and f l e x i b l e d i a l o g e v i t h t h e c a l l i n g program, but t h i s c o u l d v a i t f o r t h e s e c o n d v e r s i o n o f 9700 s u p p o r t . I t i s a l s o true that there needs to be some vay f o r t e x t t o be prepared i n a f i l e and t h e n s e n t t o t h e 9700. A s o l u t i o n t o t h i s problem t h a t seems r e a s o n a b l e t o me i s t o keep t h e DSR i n t e r f a c e l i m i t e d t o CONTROL only and p r o v i d e a program t h a t v i l l t a k e t e x t i n a f i l e and p r o c e s s embedded c o n t r o l commands. The f o r m a t of the t e x t a c c e p t e d by t h i s program s h o u l d be d e s i g n e d s o t h a t i t can be r e p l a c e d by I/O stream macros vhen t h e y become available. T h i s probably means a t l e a s t p u t t i n g t h e c o n t r o l i n f o on s e p a r a t e l i n e s a s J e f f s u g g e s t e d i n item 3 6 8 . I l i k e t h i s s o l u t i o n b e c a u s e i t k e e p s t h e DSR l e v e l i n t e r f a c e r e a s o n a b l y c l e a n and s i m p l e , v h i l e g i v i n g t h e u s e r a s f a n c y an i n t e r f a c e a s someone i s w i l l i n g t o put i n t o t h i s u t i l i t y program. The program can be e x p e c t e d t o change and e v o l v e much more than t h e DSR i n t e r f a c e and t h e r e p r o b a b l y v i l l be s e v e r a l d i f f e r e n t such programs. Of c o u r s e , programs l i k e *TEXTFORM v i l l be a b l e t o r e c o g n i z e t h a t t h e i r o u t p u t i s L . i n g s e n t d i r e c t l y t o thje 9700 and w i l l use the c o n t r o l commands d i r e c t l y . BEF TO ITEMS 364 365 366 367 368 REF BY ITEMS 374 375 384 6 VOTES/FEELINGS Looks much c l e a n e r t h i s vay t o me. (DAC/WSU) I agree. (ghl/UH) C l e a n e r f o r s y s t e m s programmers, but n o t f or u s e r s . John Gourlay Note t h a t t h e u t i l i t y program proposed i n t h i s i t e m d o e s n o t have to be used i f a l l t h a t i s vanted i s o r d i n a r y p r i n t e d o u t p u t with no s p e c i a l embedded p r o c e s s i n g r e q u e s t s . You can s t i l l copy a f i l e d i r e c t l y t o t h e 9700. (MTA) I LIKE THIS APPROACH. STEVE T Seems r e a s o n a b l e t o me. ( S c o t t G./UM)
100
ITEM 374 16:15 Aug 15/79 26 LINES PRIME=370 NEXT=375 GOURLAY, JOHN (UM) Xerox 9 700 imbedded control commands supported. I think that the objections to imbedded control commands (or escape sequences) are overdone. One observation is that we cannot escape(?) using them. The most omnipresent example is printer carriage control characters. Every line sent to a printer in MTS has imbedded control information. Another example is Tektrinics terminals and many other semi-intelligent terminals. All of the carriage control and plotting done by such terminals is initiated by control information iabedded in the text sent to the terminal. Even our ovn data concentrators respond to imbedded commands if one prefixes the coamands vith the correct number of CTRL-A's. I vould like to hazard a guess that the need to deal vith this kind of device control is going to become greater vith time, not less. This is because of the greater distribution of computing pover and the resulting complexity of control information that needs to be sent betveen components. It was possible vith tape drives to separate control from data because tape drives are hard vired and dumb. On the other hand, the only practical vay to connect fancy devices like the Xerox 9700 to MTS is by sending control information over the data lines — imbedded control commands. I suggest that ve design MTS around this inevitable trend, rather that encumber users with utility programs or macros that fake it. There certainly is room for argument over vhether or not to implement the full blown escape sequences, or just extend the existing carriage control somehow. I feel, however, that declaring that it is all really done with the SCONTROL command flies in the face of reality. REF TO ITEMS 363 364 366 368 369 370 REF BY ITEMS 375 8 VOTES/FEELINGS I find IMBEDDED escape sequences more objectionable than a special CC. What happens if a user copies his object deck to the printer by mistake? JHH/um Why not both, with a $CONTBOL command to turn processing of embedded escape sequences ON or OFF (with OFF the default) ? John, the 9 700 dosen't use escape sequences as suggested in the UQV paper, but alvays has the flag signal in a fixed location. {-Jeff Ogden/UM) hmmmm? i wonder why there is not a CONTROL packet in X25? I agree vith john. d. oreilly-ubc. X. 25 does have a "control" packet, the Q bit in the header. This is used to communicate "commands" to a CCITT PAD (terminal support) Usage in X.25 to x.25 connections is not defined, but then no other protocols are either. PLH/Merit I still think that we should avoid embedded excape seguences whenever possible. (MTA) Both escape sequences and carriage control are examples of "embedded control information". What is desired is a way to delineate control information which minimizes the probability of incorrectly recognizing data as control. (CEL) Prefer either "SCONTROL" or special CC codes, due to the spectorof an object deck being printed (they do it on purpose sometimesat RPI!!!). gary/RPI (formerly grd/rpi)
101
ITEM 375 17:53 Aug17/79 91 LINES PRIME=369 NEXT=376 JACKSON, GABBY B. (UQV) Escape Sequences vs CONTROL Re-visited After observing some of the comments/items that have recently appeared in MTS:FORUM concerning our 9700 page printer proposal, ve feel that our description contained in point B.4 may not be as clear as ve thought that it vas. Hence, please allow us aake another attempt to describe what we really meant. The main points, concerning the use of escape sequences, are: The control information must be enclosed in the escape sequence. - The control information MUST appear as the first information on the line. That means that the leading escape sequence begins in the first position of the line. The control information MUST be terminated by a repetition of the escape sequence. The terminating escape sequence can be, optionally, folloved by the CC character and data that is to be printed. (Hovever, after futher discussion, ve have decided that we vill only allow the control information to appear on a line by itself.) - The control information is specified with keywords — that is, FONT=1159AL, for example. There vere tvo reasons for specifying control information through the use of keyvords: a) There vill, eventually, be more that one piece of control information that can be specified; that is, ve plan to allov the users to, at least, specify PDEs, COPIES (on a page, not job, basis), CHEs and MABGIN. b) It is far less likely that a user could copy a file containing the required control-information that is invalid, to *PBINT* without it being detected as invalid. The DSR, on encountering invalid control information, could return an error code of 12, if that is acceptable. - The DSR vould evaluate the control information, say the font, and place the appropriate index, corresponding to the logical font name, in the next line that it sends to HASP. The use of a logical font name is necessary because the position of the font in the PDEs' font list vill likely vary from PDE to PDE. Guess that ve just assumed that this vas obvious, sorry. - When changing fonts within a print line, it is up to the user-level program to provide the line segments in separate calls to BRITE vith the overprinting CC supplied for all but the first segaent. The control information to set the required font must be on a line preceeding the line segment to be printed vith the font. After considerable discussion, among the Systems Prograaainq Group at UQV, ve have the following coaments a utility program approach: - The 9700 page printer is not going to be treated as only an exotic device; it is going to be our main printer. As such, all output to be printed at the centre, that does not require labels or braille, vill be produced on the 9700. - The fact that the user can {COPY the contents of a file, that vas created by the running of a program, directly to *PRINT*, aeans that he/she must knov that there is no embedded control information in the file being copied. If there is eabedded control information in the data being copied, if vill not be interpreted and some data following the control information aay not print. That is, information could be lost.
-
We t h i n k t h a t u s e r - p r o d u c e d programs a r e g o i n g t o make use of f o n t c h a n g e s . Being w r i t t e n by u s e r s , t h e s e programs v i l l n o t make a l l o w a n c e f o r u s i n g e i t h e r CONTROL vhen t h e o u t p u t i s d i r e c t e d t o *PRINT* or the e s c a p e s e q u e n c e vhen t h e o a t p a t i s d i r e c t e d t o a f i l e . Our f e e l i n g i s t h a t most ( i f not a l l ) u s e r s , who want t h e i r programs t o produce "fancy" o u t p u t , w i l l d e c i d e t h a t t h e p r o g r a m ' s o u t p u t v i l l a l v a y s be p l a c e d i n a f i l e and t h e n i n v o k e t h e u t i l i t y program t o produce t h e •PRINT* o u t p u t . B e s i d e s a n t a g o n i z i n g t h e u s e r s , t h i s v i l l i n c r e a s e t h e amount of I/O and CPU t i m e r e q u i r e d t o produce •PRINT* o u t p u t ( d i r e c t i n g output t o HASP i s c h e a p e r , i n CPU t i m e , t h an d i r e c t i n g t h e same o u t p u t t o a f i l e ) . He d o n ' t f e e l t h a t ve can a f f o r d t h e e x t r a I / O ' s t h a t v o u l d be r e q u i r e d w i t h t h i s approach. „ This means t h a t a proqram must t r e a t o u t p u t t o *PRINT* d i f f e r e n t l y than o u t p u t to a f i l e . In v h i c h c a s e , a r e n ' t ve b u i l d i n g some p s e u d o - d e p e n d e n c i e s i n t o f u t u r e p r o g r a a s ? By t h i s we mean that, i t would no l o n g e r be p o s s i b l e t o w r i t e programs t h a t t r e a t e d *PRINT* o u t p u t and f i l e o u t p u t t h e same. We c o n s i d e r t h i s t o be a backwards s t e p . REF TO ITEMS 369 370 374 REF BY ITEMS 384 388 9 VOIES/FEELINGS If t h e u s e r d i r e c t s t h e i r o u t p u t t o a f i l e and t h e n *PRINT* vho i s going t o {CONTROL *PRINI* t o t e l l i t v h a t t h e e s c a p e s e q u e n c e i s ? ( - J e f f Ogden/UM) I t h i n k t h e same p o i n t s apply t o programs t h a t v r i t e t o e i t h e r t e r m i n a l s or p r i n t e r s . I'm n o t s u r e of t h e i m p l i c a t i o n s of t h i s , but i t does seem t o be t h e same t h i n g . RLH/Merit I f ve a r e g o i n g t o do something l i k e t h i s (vhich I s t i l l d o n ' t r e a l l y l i k e ) , i t s h o u l d be done i n a d e v i c e i n d e p e n d e n t v a y . P e r h a p s have DSRI r e c o g n i z e t h e e s c a p e s e q u e n c e s . (MTA) Agree v i t h d e v i c e independency DESIREABILITY a l a MTA; a g r e e v i t h i c k i n e s s o f having t o use a prograir. (and h o w ! ) . (CEL) Don't q u o t e me a s a major brain on the s u b j e c t , but I now b e l i e v e t h e s e p e r a t e CC's as b e s t . . . gary/rpi Mike, I a g r e e t h a t t h e b e s t p l a c e t o put t h i s s t u f f i s i n DSRI; however, I ' l l have t o w a i t u n t i l the o t h e r s r e t u r n from v a c a t i o n b e f o r e I commit us t o doing i t i n DSRI. (Garry Jackson/UQV) If t h e e s c a p e s e q u e n c e MUST be f i r s t and no p r i n t a b l e d a t a i s on t h e l i n e , i t i s i s o m o r p h i c with a CC, why not j u s t make i t a CC and l e t HASP (or EM) f i l t e r out m e a n i n g l e s s s t u f f for 1 4 0 3 ' s , e t c . ? Of c o u r s e i t may be grim on a t e r m i n a l . JHH/um I a l s o t h i n k CC's a r e t h e way t o g o . Like how ' b o u t " ? " , a s i n ?ontrol. DanG/UM Agree w i t h CC's. Fred Swartz
103
HEM 376 2 0 : 4 4 Aug17/79 10 LINES PEIME=359 NEXT=384 BOETTNER, DONALD (UM) More on Xerox 9700 P r i n t e r D i s c u s s i o n I t v o u l d a p p e ar t h a t t h e o r i g i n a l item (359) v o n d e r i n g i f ve needed a t a s k f o r c e has s t a r t e d s u f f i c i e n t d i s c u s s i o n among i n t e r e s t e d p a r t i e s t h a t one i s n ' t needed a t t h i s time. That i s , I d o n ' t s e e v h a t a t a s k f o r c e vould do t h a t i s i s n ' t c u r r e n t l y b e i n g d o n e. Be can of c o u r s e r e e v a l u a t e t h i s p o s i t i o n at any t i m e . C o n v e r s a t i o n a t UM and a l l v o t e s on t h i s s u b j e c t from e l s e w h e r e has i n d i c a t e d t h a t ve s h o u l d not have a s e p a r a t e c o n f e r e n c e f o r t h i s t o p i c , but c o n t i n u e t h e d i s c u s s i o n s here i n FORUM. So keep goin g . . . REF TO ITEMS 359 TOO FEW VOTES/FEELINGS ON THIS ITEM AS YET
104
ITEM 384 1 6 : 1 9 Aug27/79 BODBIN, JIM (UM)
82 LINES
PRIME=375
NEXT=388
An Alternative to Escape Sequences for 9700 Control Information The following is a list of old and nev ideas and observations which I have biasedly selected to support my proposal: 1) A 1403 is *N0T* a 9700 and therefore CANNOT alvays look like one to users. There should, of course, be a vay to send output destined for either one to the other. 2) The 9700 is the first of a nev breed of printers. All of these nev printers should be treated in a similar way. 3) No one really knows what they are doing with the 9700 yet. Therefore, ve should make sure that ve are not locking ourselves into ANYTHING until ve have soae experience vith page printers. 4) The carriage control characters are a standard format for line printers. 5) Users or even whole installations may want to use the 9700 as the standard printer. The proposed method for meeting all of these requirements i s : 1) Develop a device independent print description file format that is analogous to and similar in structure to the device independent plot description files. 2) Include a version number in the header of the records of the print description files so that we can radically change the format and contents of those records a s nev devices become available and/or nev ideas evolve about hov things are done without introducing incompatibilities. 3) Introduce a nev pseudo-device (Jeff Ogden suggested •PAGE*) The DSB for •PAGE* vould accept print for the 9700. description records as input. Thus, the user could just {COPY a print description file to *PAGE* or BUN *TEXTF0RM vith SPHINT=*PAGE*. 4) Make the *PAGE* DSR smart enough to recognize everyday ordinary print records with carriage control in col 1. The chances of the two record types "colliding" can be aade small by selecting an appropriate header for the print description records. Thus, the user could copy anything to •PAGE* that she would normally copy to •PRINTS (although the converse vould not be true). 5) Write a program (•PAGESEE?) which is similar to •PLOTSEE in that it accepts print description records as input and displays the output on a non-page oriented device (terminal, 1403, etc.). *PAG£SEE would do reasonable things vith Users commands that are unreasonable for the given device. desiring 9700-type output on a line printer could get it by {RUNning *PBINTSEE S?RINT=*PRINT*. I do not envision the print description file as having any free standing text. Rather the text would be included in the print description records together with information about the text (e.g. length of text strinq, font type, etc). This means that normal print records with carriage control information in column 1 would be distinguishable from print description records. This is important since many users direct a concatenation of files to output devices. The DSR must somehow ensure that the second file in the concatenation is not at the mercy of the control By having tvo distinct record types information in the first file. it becomes more clear when the second file in a concatenation SHOULD be affected by the first files control information. Another advantage of imbedding the text in print description records is that it allows the control information to appear ANYWHERE
105
xn the t e x t s t r e a a . For i n s t a n c e , i f a user changes, f o n t s i n the middle of a l i n e of t e x t ( s a y , t o i t a l i c i z e a word) then t h e p r i n t d e s c r i p t i o n record d e s c r i b i n g the l i n e would contai n tvo s e c t i o n s of t e x t information each v i t h a header s t a t i n g the length of the t e x t and the f o n t t o be used f o r that t e x t . The proposed method of using escape sequences for such c o n t r ol i n f o r n a t i o n would require 3 l i n e s of information: a l i n e v i t h t h e t e x t t h a t vould appear before t h e i t a l i c i z e d vord, the control information t o change the font to i t a l i c s , and the remainder of the t e x t t o be overprinted on the f i r s t l i n e . REF TO ITEMS 363 367 368 369 370 3 75 7 VOTES/FEELINGS Minor problem: a l i n e v i t h o u t cc might look l i k e a print d e s c r i p t i o n record. Otherwise, I l i k e i t . John Gourlay I an not sure vhat t h i s says about the a b i l i t y to use the EDITOR on such f i l e s , but there are times vhen i t i s very convenient t o modify a f i l e v i t h p r i n t information via v i s u a l mode. (CFE-CC) I t should be easy to e d i t i f the c o n t r o l i n f o i s keyword o r i e n t ed and there i s no hex. The print d e s c r i p t o r header can be made t o look s u f f i c i e n t l y vierd so t h a t confusions betveen i t and regular t e x t v i t h o u t CC vould be rare. I don't l i k e t h i s a t a l l ! The d e f a u lt s i t u a t i o n for using the 9700 should aake i t look l i k e a p r i n t e r ! (CEL) There i s an a r t i c l e in DATAMATION, Aug ' 7 9 : "When i s a P r i n t e r Not a P r i n t e r ? " I t ' s about IBM's nev p r i n t e r , 6670 Information D i s t r i b u t o r . LBT Could have t h i s along v i t h *print* PRINT=XX F0BMS=(a p o s s i b l y f a i r l y complex thing i n d i c a t i n g ianscape or p r o t r a t e, font s e t , type s i z e and vhat e v e r . ) vhich vould apply to the e n t i r e job. A nev pseudo-device name i s probably reasonable. Point 4 i s important - one must be able to j u s t copy a normal f i l e t o the p r i n t e r . (JWS)
106
ITEM 388 13:01 Aug29/79 66 LINES PRIME=363 NEXT=391 WARD, KATHRYN (UQV) More on Xerox 9700 printer discussion I have just returned from vacation, having missed the major portion of the dialogue on the XEROX 9700. I intend to begin work immediately on the MTS and HASP printer DSR but vould like to readdress two issues that have been raised. 1. Thorny question #7 - When do printing enironment changes take effect? There has been r.o response to this issue, yet it requires some consideration. At this time a user is capable of changing the print environment, specifically the print train, at any time prior to releasing *PRINT* and having the the entire job printed in the most recently specified environment. With the 9 700, the printing environment is considerably more complex involving the orientation, page format, and more detailed font information. Specifically if a user requests a change in PDE, or even a change in print train, on a job bound for the 9700, either explicitly or by default, the only way for the change to take effect for the entire job is for HASP to have a thorough knowledge of the libraries on the 9700 and change 9700 commands vithin the data it has already received! It is bad enough that MTS must be thoroughly aware of the 9700 library without expecting it of HASP as well. Additionally a user may want different printing environments for different portions of his job so that it is unreasonable to assume that he wants it to take effect anywhere except the current position. If we were to allow users to respecify the printing environment for lines already sent to HASP, then they would have to, in fact, also supply a 'line' at which the change should take effect. For example he may only want to change the printing environment for the last 10 lines he has written. This whole mess is much to such to even consider. Therefore we will make an incompatible change. If a user specifies a new printing environment part way through job submission, the job will be directed to the 9 700 and the change will take effect with the next page to be printed, as PDE's can only be changed on a page basis. Because the 1403 will only have a TN print train there is no danger of a user changing the print environment, specifically the print train, on a job specifically directed to the 1403 without an error occurring. This decision means that in the original proposal in points B.1. and B.2., where it is specified that the user can only specifiy the PDE and the DEVICE before the job is released, is no longer true. 2. The discussion in the votes to item 3 75 regarding having DSRI recognize the escape sequences. I don't understand why we would want this. The esacape sequences have to be replaced vith device dependent information; hence, the DSR must have this function. The only other reason I can see for DSRI recognizing the escape sequences is for them to be stripped if data containing such sequences is to be directed to a different device. I don't feel they should be stripped — the user put them there, either manually or via a program such as TEXTFORM. In either case I think he should know they are there. Garry now also agrees with me, contrary to his initial vote. Is there
107
something we are missing? Is there another reason for DSRI to recognize then? REF TO ITEMS 363 375 4 VOTES/FBBLINGS If yon have decided hov yon WILL do it, there is no point in my vorrying forther about your code. If any one else is interrested in ay thoughts on how to avoid problem #1, let me knov. JHH/um By addressing this problem in FORUM ve are obviously interested in any coaments. These decisions are not yet cast in stone - but ve have to get on vith it quickly.. John Stasiuk(UQV) It is far too early to start coding on this yet. We aren't any vhere close to agreeaent on hov to do it. The proposal that I like best so far is the one Jia Bodvin aade in item 384. (MTA) If this is to be a throw away version then we must keep changes to MTS and HASP to a minimum. This is even more true because ve plan and hope to throv HASP avay someday also. (-Jeff Ogden/UM)
-«*»k
108
ITEM 391 14:05 Sep03/79 89 LINES PRIME=361 NEXT=392 OGDEN, JEFF (UM) Some private message on the Xerox 9700 question becoae iteas This and the next several items contain the sightly edited f3^ text of several messages that have been exchanged about the Xerox 9700 and its use under MTS and HASP. MESSAGE FROM: HANSEN, JIM (UM) 15:40 Aug30/79 W167:FORUH. HF To: Garry Jackson (UQV) , Regarding the 9700f I am for the moment retreating to ay HASP corner and proposing a less radical change to HASP to accommodate the beastie. Please, don't misunderstand; I aa not opposed to your suggestions in principle, only in practice. It seems to me that we should go slow on radical changes to HASP'S data storage format until we are sure of the best way to do it. Then we can either < make the radical change or wait for the RM, whichever is more appropriate. First, I don't think it is really necessary to change the foraat •« of HASP'S print record at this time. The only thing that vould buy us that we can't do otherwise is lines longer than 254 characters. 1 vould suggest that an initial implementation could forego the 254+ records and set the font index vith a control record using a special CC. I am not addressing hov it looks to the user nov, only hov it looks to HASP. The user could use escape seguences, control commands, or a special CC and still have MTS aap it into a special MCC for HASP. Since font changes MUST be made by passing a separate record to the 9 700 for the line with the nev font, a font chanqe could be accomplished by sending HASP a special HCC vith a command on it. HASP vould then, in PPR, interpret the MCC to change the font index being passed to the 9700. Of course, this same magic MCC would then be used also for other commands, such as landscape vs. portrait, etc. These other requests could be interpretted for non-9 700 devices (e.g. page numbering) or not (e.g. portrait mode) as is appropriate. I vould suggest using the CC X'3B' since this is already used by MTS and HASP to communicate information about what should and should not be sent to the MERIT network for print jobs. X'3B» vas chosen because it currently is an invalid CCW op-code for all IBM printers, it could be changed if needed. X'3B' vill also soon be used to signal the end of the headsheet and start of the tailsheet for use by PPR vhen a currently printing job is {CANCELled by the user or {DELETEd by an operator ^ so that the whole head and tail sheets vill print. I believe the extra lines generated for font changes vill not significantly affect performance since IN GENERAL font changes _, will be relatively infrequent until users get used to having them and even then infrequent if the 9700 is used as a primary printer in the system. Calls to HAS? will not be significantly increased and HASP I/O operations to disk likewise will not be greatly changed. I would like to avoid making radical changes to the record format until we are really sure of what we want because the changes vill have to be made all thru HASP, to EXEC, PPR, MXMTR, RDR and the MTS side of the interface. Remember, the same buffer packing and unpacking routines are used for execution, print, and punch jobs in each of those modules. This vould require the format of all types of records be changed or that the routines be taught the difference C ^ betveen print and other format records. The latter idea vould be so difficult to implement as to be unthinkable. In the long run, I really do prefer your suggestion. I feel this suggestion, however, would be MUCH easier and faster to implement, would be less prone to bugs, and could easily be converted to your
r
109
suggestxon, or some other similar one, vhen ve have more experience. The most attractive feature of your suggestion would be the ability to pass lines lonqer than 254 to the MERIT network. Even if you make all your changes to HASP, I will have to make many more to our HASP for the MERIT netvork stuff. I vould rather not make large changes to these routines until ve are really sure vhat ve are doing. Another advantage to the special CC vould be the 'extensible' nature of it. Be could add other commands for other printers, e.g. dynamic svitching betveen 8 lines/inch and 6 1/i if ve get one Of those printers. Finally, as far as HASP is concerned, the decision about vhich printer to put the output on could be postponed indefinitely until it actually prints. For general jobs not using the special 9700 features, no magic CC records vould be generated and defaults could be easily be used if such a job ends up on a 9700. A whole job could be *PRINT*ed and then a user could SCONTROL *PRINT* to specify 9700 in portrait mode vith italics. He could even que it for the 9700, then change his mind, or even change his mind back and forth several times. Have I not allowed for something here? My desire is only to make as few changes as possible until ve have some real experience. After ve have some experience, I vill be most happy to re-consider a better vay of doing it. In any case, it vill have to be redone for the RM. Of coarse, if this approach is unacceptable as an intermediate step, I am not philosophically opposed to the one you suggested. In fact, as you knov, I prefer to do things "right" the first time. I aa just not yet sure vhat is "right". ...Jia BEF TO ITEMS 361 BEF BY ITEMS 392 TOO FEB VOTES/FEELINGS ON THIS ITEM AS YET
110
ITEM 392 14:07 Sep03/79 60 LINES PRIME=391 NEXT=393 OGDEN, JEFF (UM) » • More on the xerox 9700 Question REPLY FROM: JACKSON, GAB2Y R. (UQV) 17:59 Aug30/79 W409:HF To: Jim Hansen (UM), We have the following comments concerning your suggested initial method of implementing Xerox 9700 page printer support in HASP. 1. All lines that are sent to the 9700, and are to be printed, must contain the font index byte. Thus the suggestion that MTS pass a font index to HASP on a separate line vith a special MCC means that PPR vould have to perform considerable data malipulation to insert the font index byte into the data line. We don't feel that this type of activity should be carried out in HASP. Furthermore, the font index must be generated from the logical font name (since different PDE's can have different fonts, and the same fonts specified in a different order). To have HASE perform the desired checking and generation of the appropriate index is way too late and adding to the complexity of the code that must go into HASP. 2. The switching between various PDE's is done by sending the 9700 a data line that begins with a certain (defined in the JDE) sequence of characters. To switch between, say, portait and landscape mode, one must change to a new PDE — which entails sending to the 9700 a data line that it recognizes as a DJDE to charge the PDE (vhich takes effect with the next page printed by the 9 700). To have HASP do this, means that any error detection will occur far too late. He will not allow the user to create his own DJDE; instead we vill create it from information passed in the escape seguence/special CC stuff. If a DJDE is encountered in the data being sent to •PRINTS, we want to reject it as invalid. Also, ve are sure that there will be initial users of the device that need to change the orientation for various parts of their output; not for the whole thing. If we were to have things work as they do now, it would mean that HASP would have to hold the last DJDE in, say, the JCT and provide it as the first output record (following the header sheet) to the 9700. We don't think that this is the vay to go. Generally, your proposal differs from the implememntation we have been considering, in that you expect HASP to perform the functions that we believe belong at the MTS/HASP ptr DSB level. These functions are directly related to 9700 device dependent support, not to the spooling facility, and as such support for them should not be put into HASP. It appears to us that your proposed implementation would entail far more, and greater, changes to HASP than vhat we have proposed. Except for the revamping of HASP'S data storage format, there are very few other changes required to HASP; whereas, if we take your approach, it is likely to entail far more overall work to obtain a suitable product— considering that there vill be a need for code to do duplicate tasks in both HASP and MTS. Garry Jackson and Kathryn Ward (UQV) REF TO ITEMS 391 REF BY ITEMS 393 3 VOTES/FEELINGS Have you considered what would happen if a RJE went down and ve had reroute to our 9700? (CEL)
111
If a l l l i n e s t o be printed need a font index b y t e , hov can Xerox claim the t h i n g i s c o a p a t a i l b l e ? Paul P. You can s e t t h i n q s up so no index byte i s present and a d e f a u l t i s used, bat then yon c a n ' t s v i t c h from one font to another. (-Jeff Oqden/UH)
112
ITEM 393 14:08 Sep03/79 61 LINES PRIME=392 NEXT=394 OGDEN, JEFF (UM) The Xerox 9700 discussions contiue MESSAGE FROM: OGDEN, JEFF (UM) 18:24 Aug30/79 W163:CHAIL To: the folks at UQV vith copies to some local people In general I agree that MTS vould be a better place for knowledge of the 9 700 and hov it vorks then HASP. I guess because this first attempt at the 9700 support is intended to be a throv avay version I would hope that ve could even keep the HTS changes to a minimum. Changes to allov the necessary records to control the 9700 to pass through MTS, the DSR and HASP, changes to pervent unwanted user data from controling the 9 700 and changes to reset the 9700 betveen jobs all seem necessary. Additions to the device coaaands accepted by the MTS PTB DSR to allov global options for a *PBINT* 9700 job vould probably be nice to have and pose no real change from the types of commands currently accepted. Changes that allov "dynamic" changes on a line by line, page by page or even character string by character string are a whole new question and need a lot of thought before we go too far. I hope we don't make any changes to the MTS DSR or HASP to support this last group until we have better agreement on what needs to be done and how to do it. For the present it would seem reasonable to provide these dynamic functions through the use of a program and after we have a better feel for what we want to do we can make changes to MTS or HASP or the RM as needed. By using a program we could keep the changes to HTS and HASP down to just those necessary to allov control information to be passed through unchanged and it vould be much simpler to make expermental changes to a program than to MTS and/or HASP. -Jeff REPLY FROM: JACKSON, GARRY R. (UQV) 10:53 Aug31/79 W409:MF To: Jeff Ogden (UM) , We are opposed to the use of a program for the simple reason that the 9700 is to be our primary printer as of the middle of October. By primary, 1 mean that ve intend to print all output, except braille and label output, on the 9700. In our opinion, forcing the users to use a special program vould antagonize them and cost too much in CPU time and I/O requirements; see Item 375 for our reasons for rejecting the utility program approach. Garry Jackson REPLY FROM: WARD, KATHRYN (UQV) 10:58 Aug31/79 B402:HF To: Jeff Ogden (DM) , Although the first implementation must be accepted as a throwaway version, the device is to be very much a production device, to be used by the most naive of users. As such I just don't feel we can expect the users to have to start running a program to use the printer. This actually sums up the whole problem, we are preparing an initial implementation, but having to go full production. This involves having to avoid incompatible changes at this time, as well as trying to forsee the final implementation, and avoid incompatible differences between this implementation and the final one. Kathryn REF TO ITEMS 392 REF BY ITEMS 394 6 VOTES/FEELINGS Can you really have it both ways? A throw avay version and a version that forsees the final version at the same time? Why bother vith the throv avay version if this is the case?
U3
I have been presuming that the i n i t i a l implementation vould make the 9700 look p r e t t y much the same as any other l i n e p r i n t e r . Apparently, ve are not a l l in agreement on t h i s point. (CEL) But i f the program vere used only for s p c i a l 9700 type t h i n g s , *print* and c o n t r o l could be used for naive u s e r s . Paul P. My s u g g e s t i o n vould to be implement NO s p e c i a l 9700 f e a t u r e s i n the October v e r s i o n , but only a l l o v p r i n t e r - l i k e t h i n g s . If people vant s p e c i a l f e a t u r e s , then i t should be no problem for those fev f o l k s to run a s p e c i a l program.Mark Weiser I don't think Garry or Kathryn understood vhat J e f f s a i d . ( S c o tt G./UM) " agree v i t h Mark Weiser. DanG/UM
114
ITEM 3 9 4 14:09 Sep03/79 OGDEN, JEFF (UM)
45 LINES
PRIME=393
NEXT=400
The last of the items on the Xerox 9700, at least for the moment REPLY FROM: OGDEN, JEFF (UM) 12:02 Auq31/79 W163:CMAIL To: Garry and Kathryn (UQV), Unless we are very careful when we throw out the first version and install the 2nd there will be incompatable changes in the user interface. Also it is important to note that most users won't need to run the program (if that is the vay ve go) to get their TN or PN print out on the 9700. It is only vhen they want to make use of the more advanced features like changes in a page by page, line by line or character by character way that they need to run the program. And the program is only temp., to be replaced when ve knov hov ve vant to do it. -Jeff REPLY FROM: JACKSON, GARRY B. (UQV) 13:26 Aug31/79 W409:MF To: Jeff Ogden (UM), I'm opposed to a program because it means that the user of the system MUST knov that there is no control info in his file before copying it to *PBINT*. I believe that this is asking too much of the users. Garry REPLY FROM: ALEXANDE5, MIKE (UM) Noboddy is suggesting that ALL use of the 9700 has to be through a utility program. MTA And here the matter sits for the moment. Don Boettner has organized a meeting for this Tues. at UM so that interested people can talk about this whole subject. I've also heard tell that Jeff Berrynam (UBC) said he would enter an item on this subject shortly. In the future I quess I'd like to see most of this discussion go on in items rather than messages, unless the subject of discussion is just too tentative. -Jeff Ogden (UM) REF TO ITEMS 393 REF BY ITEMS 400 6 VOTES/FEELINGS It's becoming increasingly clear to me that the best way to proceed is to first implement 1403 compatibility (no font changes or portrait mode, for example) and get some experience while this debate continues. (Scott G./UM) I agree with Scott. 1403 compatibility is the route that requires the least changes later. ACG I too think the safest route is 1403 compatibility first vith GLOBAL setting of font and forms and orientation. This will give us time to work on the user interface to effect dynamic changes. JHH/um I too now think that 1403 (or 3211) compatibility is the vay to go for the short run. (-Jeff Ogden/UM) The standard printout is usually 1403-like. (See compilers, programs, etc.). LBT. As said before, I agree. DanG/UM
115
ITEM 400 OGDEN, JEFF
21:22 Sep10/79
76 LINES
PEIME=394
NEXT=401
(UM)
A summary o f recent UM discussions about the 9 700 Bhat follovs i s my attempt at a summary of some of the discussions that have gone on at UM regarding the UQV Xerox 9700 proposal. After q u i t e a bit of discussion i t vas generally agreed that it vasn't necessary to implement a separate *PAGE* or print description records as long a s the output device in question vas line oriented and looked at least a bit like a printer (vhich the 9700 d o e s ) . If some nev, truly page oriented, device comes vlong in the future ve vill vant to reconsider this question. T h e major point of controversy seems to be over hov to get "control" information to the 9700. The traditional vay t o do this i n HTS h a s been through calls to the control DSR entry. Taking this approach for the 9700 causes problems f o r tvo reasons. First, because control calls can't be included in the data stream vithout running a program. Second, because up until nov all of the control commands for *PR± NT* take effect for the vhole j o b (global commands) , but many of the commands f o r the 9700 should effect only portions o f the job (immediate c o m m a n d s ) . It should be noted that vhile this i s true for *PHIHT* the opposite i s true for most terminal D S R s , and that ve have had many user requests for immediate printer commands like BIDTH=n, E J E C T , SPACE-2 (double space) , HEADING=, and TITLE= a« • •
One solution that has been suggested is to flag the control information using a nev logical carriage control character. The thing that ve have only slovly come to realize is that allowing control inf ornati*. n to be included in the data stream by flagqinq t h e information vith a new logical carriage control character i s a major change to the HTS I/O user interface. It seems that this type o f ability vould be very handy not just for the 9 7 0 0 , but for other devices as veil. The difficulty i s that the s c h e m e could turn out to be very device dependent. Be need to ask and ansver a number of questions before ve go t o o far. Specifically: 1) Is a nev logical carriage control character the best vay to i n c l u d e c o n t r o l information in the data s t r e a m ? 2) Should there be a way to include control information in the data streams directed to DSRs that do not normally process logical carriage control? Hov? 3) If 9700 control information flagged by a l o g i c al carriage control character is written to a non-9700 DSR should the information be ignored or result in an error? 4) If v e adopt the logical carriage control scheme f o r controlling the 9700 and then later vant to use a similar scheme f o r a different device vill ve need to pick another logical carriage control character or will o n e be enough? Bhat if the commands accepted by the tvo devices are different? Bith the above in mind ve vould like to suggest that everyone proceed very slovly in this area, being very careful to do nothing that vill close our options at an early stage before many of the issue s have been thought out. Specifically the initial version o f the 9700 support should be limited to providing "1403 compatible" services. By 1403 compatible, ve mean s e r v i c e s that a r e similar to those currently available through HASP using 1403 printers '(globally selecting different forms and character s e t s , for example). This vould allov points
116
A-1, A-2, A-4 and A-5 i n t h e o r i g i n a l UQV p r o p o s a l . P o i n t A - 3 , dynamically changing f o n t s during a s i n g l e j o b , c o a l d be implemented through c a l l s t o t h e DSR's c o n t r o l e n t r y d a r i n g the i n i t i a l implementation, but the a b i l i t y t o i n c l u d e c o n t r o l C^ information d i r e c t l y i n t h e d a t a stream should n o t . Soae scheae for i n c l u d i n g c o n t r o l i n f o r m a t i o n i n the d a t a s t r e am should be included in a l a t e r i m p l e m e n t a t i o n . The above covers the major p o i n t s of d i s c u s s i o n . The next item has soae s p e c i f i c comments, s u g g e s t i o n s , and q u e s t i o n s . REF TO ITEMS 394 REF BY ITEMS 401 VOTES/FEELINGS P r i n t d e s c r i p t i o n r e c o r d s were suggested by Jim Bodvin i n item 384.
jffcy
117
ITEM 403 02:06 Sep12/79 3 LINES PRIME=359 BERRYMAN, JEFF (UBC) Long- and Short-Term V i e v s o f t h e 9700 Problem My e n t r y i n t o t h e XEROX 9700 d e l i b e r a t i o n s has t u r n e d ou t t o be a b o u t f i v e pages l o n g . P l e a s e {COPY W306:9700 i f you're i n t e r e s t e d . BEF TO ITEMS 359 7 VOTES/FEELINGS For t h o s e a t UM t h e r e i s a copy of J e f f B ' s v i e v s p o s t e d n e a r t h e s t a f f m a i l b o x e s . ( - J e f f Ogden/UH) T h i s i n i t i a l l y seems t o me t o be a a o s t i n t e r e s t i n g a p r o a c h . I t seems t o ae a n o t h e r good a l t e r n a t i v e t o t h e o n e s ve h a v e a l r e a d y r e v i e w e d , and r e a f f i r m s ay b e l i e f ve s h o u l d hold o f f on t h e fancy s t u f f ' t i l ve can d i s c u s s i t more f u l l y . JHH/um I s t r o n g l y s u p p o r t t h i s approach. The problem i s not r e a l l y a 9700 p r o b l e m , i t i s a q e n e r a l d e v i c e s u p p o r t problem (MTA) The i d e a i s g r e a t . I t s g e n e r a l i t y i s VERY a p p e a l i n g . H o v e v e r , c a r e most be t a k e n a s t h i s method a l s o p r o v i d e s a l o t of r o p e . . , . Ear l Cnlhaa (UQV) Very n i c e . . . I may add t h a t something ver y VERY c l o s e t o t h i s v a s p r e s e n t e d i n a paper a t t h e UQV workshop by B e n e t , S t a s i u k , D a v i s , and Crawford e n t i t l e d "Line F i l e E x t e n s i o n s " (pp. 156-157 i n t h e p r o c e e d i n g s ) , chb I remember t h a t p a p e r . I t proposed s i m i l a r d a t a s t r u c t u r e s , b u t t h e s e m a n t i c i n t e n t was d i f f e r e n t . J e f f B. Sounds u s e f u l f o r improving t a p e and Merit s u p p o r t t o o ! D o n ' t f o r g e t t h a t p r e f i x c h a r a c t e r s a r e a t h i r d f i e l d ve a l r e a d y h a v e . ( S c o t t G./DH)
118
Advanced File and Device Support in MTS
i. ___________
'***«•*•*-_Vi*_-_
f
1
W_o_:?7.»
1.1. Introduction I'd like to take a general look at the question of supporting the XEROX 9700 and other advanced kinds of devices and pseudo devices. As I've already suggested (item 228), I believe that a proper solution to the 9700 problem vill only be had by considering the general problem of advanced (pseudo) device support in MTS. On the other hand, UQV has a real live 9700 about the burst into their living room, so I vould not like to get so far up in the clouds that I forget the iaaediate problem. 1.2. The Architectural Situation In operating systems architecture, one term that is currently gaining followers is "presentation image". A presentation image is the set of data structure(s) and action(s) vhich constitute the external appearance of a system function, as seen by the applications. In MIS, one of the most important set of presentation images is the set of presentation images of all the different types of files and devices in the system. One of the great things about MTS is all of these I/O presentation images have a lot in common. In effect, there is an idealized general I/O presentation image that all devices and files impleaent to some relatively large degree by virtue of the existence of the single generalized application I/O interface. READ, WRITE, and to a lesser degree, CONTROL, are subroutines vhich deal vith the MTS general I/O presentation image. As ve all know, the nice thing about having a single general presentation image is that file and device type dependencies in application code can be minimal — what works for line files generally works for printers, and so on. On the other hand, for the generalized I/O presentation image to succeed, it must be general enough to apply to the majority of situations. In particular, the MTS general I/O presentation image, with its simple record/line number/modifiers/etcetera features, must be general enough to be successfully applied in the majority of cases of MTS I/O. When it occurs that complex application-dependent protocols begin to appear frequently in addition to the existing general presentation features, it is a sure sign that the general features are not general enough. This, I believe, is our exact situation with respect to the 9700. It is also our position (and has been for some tiae) vith respect to 3270 "binary" I/O, which is an elaborate application-specific, device-dependent protocol if there ever was one. The 9700 and the 3270 are an interesting pair, because they are both printed-image-type devices. Ideally, one should be able to {COPY the same file to either a 9700 or a 32 70 device and get more or less the same output format from each. At the moment, ve are certainly rather distant from that ideal. 1.2. The Architectural Situation
119
Advanced File and Device Support in MTS
2
1.3. The Immediate Nee
1.3. The Immediate Need
120
Advanced F i l e and Device Support i n MTS
3
2« The S o l u t i o n s 2 . 1 . Long-Term A r c h i t e c t u r a l Changes As phrased i n I . B , a b o v e , t h e MTS g e n e r a l I/O p r e s e n t a t i o n image i s n o t g e n e r a l enough. From t h e 9700 »s s t a n d p o i n t , t h e main problem a p p e a r s t o be t h a t p r i n t e r c o n t r o l o p e r a t i o n s need t o be c a r r i e d along with p r i n t d a t a . The c u r r e n t l i n e - f i l e - l i k e c h a r a c t e r of MTS's g e n e r a l I/O p r e s e n t a t i o n image only a l l o v s l i n e numbers t o be a s s o c i a t e d with dat a l i n e s . As I s e e i t , vhat ve need a r e f i l e r e c o r d s v i t h more than j u s t t v o f i e l d s ( " l i n e number" and " d a t a " ) per r e c o r d . Of c o u r s e , i t i s a l v a y s p o s s i b l e f o r t h e d a t a f i e l d t o be a r b i t r a r i l y s u b d i v i d e d a t t h e a p p l i c a t i o n l e v e l - - t h i s i s what i s done i n p l o t f i l e s , f o r i n s t a n c e - - but what 1 am s u g g e s t i n g i s having m u l t i p l e f i e l d support b u i l t i n t o t h e o p e r a t i n g system. Having o n l y a p p l i c a t i o n - l e v e l m u l t i - f i e l d support r e q u i r e s t h a t a p p l i c a t i o n programs (*PLOTSEE, f o r i n s t a n c e ) be used f o r vhat vould o t h e r w i s e be normal {SLIST, e t c ) d a t a m a n i p u l a t i o n o p e r a t i o n s . More s p e c i f i c a l l y , v h a t 1 b e l i e v e ve should e v e n t u a l l y have i s a g e n e r a l I/O p r e s e n t a t i o n image t h a t a l l o v s each f i l e , p s e u d o - d e v i c e , o r r e a l device t o have r e c o r d s v i t h aore t h a n t v o f i e l d s . The i d e a vould be t o have a g e n e r a l p r e s e n t a t i o n i a a g e t h a t a l l o v s f o r an a r b i t r a r y number of f i e l d s i n a r e c o r d , v i t h each f i e l d having some a t t r i b u t e s , t h e a o s t i m p o r t a n t of which would be i t s name. Notice t h a t I am n o t a d v o c a t i n g t h a t ve c r e a t e some mechanism t h a t a l l o v s s u b d i v i s i o n of t h e r e c o r d ' s data s t r i n g — r a t h e r , I am s u g g e s t i n g , t h a t we allow more t h a n one d a t a s t r i n g p e r r e c o r d . Although i t i s n o t e s s e n t i a l , I am c u r r e n t l y assumirg t h a t t h e record format — i . e . , t h e names and a t t r i b u t e s of t h e r e c o r d f i e l d s — be c o n s t a n t over any given f i l e / p s e u d o f i l e / d e v i c e . Of c o u r s e , for v a r i a b l e - l e n g t h f i e l d s , n u l l v a l u e s would presumably be l e g a l , s o not a l l f i e l d s vould have to be s u b s t a n t i a l l y p r e s e n t i n a i l r e c o r d s . To s e e how t h i s would work for t h e 9700, imagine t h a t t h e 9700 DSR were s e t up t o have t h r e e f i e l d s p e r r e c o r d , a s f o l l o w : Name Attributes Function DATA length 0-32767 The data to be printed CARRIAGE-CONTROL l e n g t h 0-1 optional carriage control character LOCAL-CONTECL-COMMAND l e n g t h 0-255 DJDE-type c o n t r o l command Now, assume further that the f i l e system has been enhanced to the point where users may define the field structure of f i l e records, with a few reserved field names ("LINE-NUMBER" and 2. 1. Long-Term Architectural Changes
121
Advanced File and Device Support in MTS
4
"DATA") havinq p a r t i c u l a r s i g n i f i c a n c e . Also, assume t h a t the vay {COPY vorks (at l e a s t by default) i s t o copy f i e l d - n a m e - v i s e , s o that I f ve s e t up a f i l e whose record s t r u c t u r e i s the same as the 9 7 0 0 ' s , then {COPYing t h a t f i l e t o the 9 700 v i l l , for each record copied, copy f i l e f i e l d "DATA" to 9700 f i e l d "DATA", f i l e f i e l d "CARRIAGE-CONTROL" t o 9700 f i e l d "CARRIAGE-CCNTROL", and f i l e f i e l d "LOCAL-CONTROL-COMMAND" t o 9700 f i e l d "LOCAL-CONTROL-COMMAND". Null value s of "LOCAL-CONTHOL-COMMAND" vould, of course, have no e f f e c t . F i l e s so defined vould be true 9 700 print f i l e s , but no program vould be needed t o copy them. This shovs the general idea of the approach I am s u g g e s t i n g . Of c o u r s e , once a general mechanism l i k e t h i s vas s e t up, t h e r e vould s t i l l be a l o t of remaining vork required to choose the s p e c i f i c record s t r u c t u r e s for the various MTS d e v i c e s and pseudodevices i n a vay that allowed maximum u t i l i t y . For i n s t a n c e , a 9700 p r i n t f i l e such as I have described should be p r i n t a b l e on other output d e v i c e s , t o o , although with a r e s u l t not n e c e s s a r i l y i d e n t i c a l t o the 9 700's output. Thus, i n designing the record format for the 9700, one should approach the problem in a s p e c i f i c - d e v i c e - i n d e p e n d e n t way. In other words, ve should not desiqn a 9700 print f i l e format — ve should design a general format for representation of printed information, so t h a t t e r m i n a l s , p l o t t e r s , and non-9 700 p r i n t e r s can a l l support the saae format. Supporting advanced d e v i c es i s not the only reason f o r having m u l t i - f i e l d f i l e s . Although i t i s somevhat o u t s i d e the scope of t h i s n o t e , I should point out that i f one i s to support r e l a t i o n a l databases one day, vhat i s required i s a vay t o represent a r e l a t i o n , vhich i s a vector of n - t u p l e s , a l l structured i d e n t i c a l l y , v i t h each coordinate of each n - t u p l e being a data f i e l d value. M u l t i - f i e l d f i l e s are i d e a l f o r r e p r e s e n t i n g r e l a t i o n s — a l l ve need do i s make each n-tuple be a m u l t i - f i e l d record, and have each coordinate be one record f i e l d . By implementing m u l t i - f i e l d f i l e s , ve vould be moving c l o s e r to supporting r e l a t i o n a l databases by providing a p r e s e n t a t i o n image t h a t i s v e i l s u i t e d t o r e l a t i o n a l database use. Hovever, a s t r a i g h t f o r v a r d m u l t i - f i e l d f i l e implementation vould not encounter any of the avesome combinatorical problems of r e l a t i o n a l data transformations, because no such transformations vould be implemented. When the time came t o expand the m u l t i - f i e l d f i l e f a c i l i t y i n t o a f u l l r e l a t i o n a l database f a c i l i t y , the design e f f o r t could concentrate on the i n t e r n a l c o s b i n a t o r i c a l problems, s i n c e the e x t e r n a l p r e s e n t a t i o n would already e x i s t . Thus, as v e i l a s s o l v i n g n e a r - f u t u r e advanced-device implementation problems, m u l t i - f i e l d f i l e s would a l s o provide a useful separation of the r e l a t i o n a l database problem i n t o two smaller problems. 2 . 1 . Long-Term Architectural Changes
122
Advanced F i l e and Device Support i n MTS
5
2« 2 The, Shfirt-Terra__Subset S o l u t i o n As I read i t , UQV's proposed i n i t i a l 9700 implementation (W400:9700PBOPCSA1.) s a y s t h a t the following f u n c t i o n s a r e r e q u i r e d of t h e i n i t i a l implementation: 1. p r i n t in 132X*6 landscape- mode ( l i k e old 11X15) I I . p r i n t in HSX^ p o r t r a i t .no.le ( l i k e old 8.5X11) I I I . dynamically change Cents within a l i n e . IV. e x p l i c i t l y choose t h e page p r i n t e r or t h e l i n e p r i n t e r V. a u t o m a t i c a l l y number pages Much of the d i s c u s s i o n coilowinq t h i s p r o p o s a l has r e v o l v e d around item ( I I I ) , which r e q u i r e s some kind of c o n t r o l i n f o r m a t i o n to L*. passed to the 9700 in t h e midst of t h e d a t a , which i s a problem when the data i s coming from a p r e v i o u s l y written f i l e . Since t h e a b i l i t y t o change f o n t s dynamically i s r e l a t i v e l y r e v o l u t i o n a r y , I was c u r i o u s to see why UyV i s a n x i o u s to have i t in t h e i r i n i t i a l implementation. As far as I have been a b l e t o determine (item 3f.8, point. 1 ) , the only immediate need f o r dynamic f o n t changing a r i s e s as a r e s u l t of t h e i n a b i l i t y of the 9 700 to produce b o l d f a c e p r i n t from s u c c e s s i v e o v e r p r i n t s . If t h i s i s t he only r e a s o n , I sugqest t h a t i t would be f a r s i m p l e r t o implement boldface font changes by a u t o m a t i c checking i n t h e DSR, and l e a v e g e n e r a l i z e d dynamic font changing f o r t he f i n a l implementation. The DSR boldface implementation I have i n mind would b a s i c a l l y i n s e r t b o l d f a c e - f o n t c h a r a c t e r s where needed by doir.q a c h a r a c t e r - t y - c h a r a c t o r compare of a saved copy of t h e l i n e j u s t p r i n t e d and the l i n e about to be p r i n t e d whenever the nev l i n e was an o v e r p r i n t l i n e . While t h i s procedure would not be h l a z i n g l y f a s t , i t would only be invoked when an o v e r p r i n t l i n e was w r i t t e n . While what I'm s u g g e s t i n g may not be the most a_>propriate way to do boldface on the 9700, i t may make i t p o s s i b l e t o d e f e r f u l l y dynamic font changing u n t i l the f i n a l i m p l e m e n t a t i o n . Anyway, " a u t o i a t i c " boldface w i l l probably always be r e q u i r e d , for 1403 c o a s p a t i b i i i t y . In t a c t , t h e 9730 r e a l l y should do t h i s i t s e l f — o p t i o n a l l y , or c o u r s e .
/.. 2 Tho Short-Term Subset S o l u t i o n
123
;j ';
\t;.
i
<*}
t*\ I Kt .
DOGUMENTATION
125
ITEM 360 13:29 Aug09/79 15 LINES EVANS, DAVE (UC.V) System C o n t r o l B l o c k s D o c u m e n t a t i o n P r o g r a m . A p a r t - t i m e p e r s o n a t UQV h a s j u s t f i n i s h e d w o r k i n q on a s y s t e m t h a t a l l o v s t h e d e s c r i p t i o n of s y s t e m c o n t r o l b l o c k s ( d s e c t s , e t c ) i n much t h e same way a s t h e IBM System C o n t r o l B l o c k s m a n u a l . We h a v e s t a r t e d u s i n q t h i s t o o l t o document t h e v a r i o u s d s e c t s and t h i n q s i n MTS.MACROS i n t h e hope t h a t i t w i l l be of some u s e t o u s and a n y new p e o p l e who j o i n u s . The w r i t e - u p f o r t h i s s y s t e m and an e x a m p l e i s i n W403:SCB.DOC and a n y o n e i n t e r e s t e d s h o u l d c o p y t h i s t o a TN p r i n t e r . The s y s t e m i s s p e c i f i c a l l y d e s i g n e d a r o u n d 32 70 t y p e t e r m i n a l s . I f a n y o n e h a s a n y comments on t h i s program I would b e ' g r a t e f u l t o r e c e i v e them. I hop e t h a t e v e n t u a l l y a l i b r a r y of a l l t h e d s e c t s and c o n t r o l b l o c k s i n t h e s y s t e m w i l l be a v a i l a b l e - h o p e f u l l y m a i n t a i n e d by t h o s e r e s p o n s i b l e f o r t h e v a r i o u s d s e c t s and d i s t r i b u t e d a s part, of t h e n o r m a l MTS d i s t r i b u t i o n . I s u p p o s e t h e q u e s t i o n s t h a t I want a n s w e r e d a t t h e moment a r e - i s anyone i n t e r e s t e d ? - d o e s anyone want any c h a n g e s made? - h a s e v e r y o n e f a l l e n a s l e e p ? 11 VOTES/FEELINGS yes, i n t e r e s t e d . BAC/Sfu. I t would be n i c e i f i t c o u l d r e a d A s s e m b l e r and g e t you s t a r t e d u s i n g t h e a c t u a l c o d e Sounds very u s e f u l . (MTA) We t h o u g h t a b o u t g e t t i n q i t t o p r o c e s s DSECTS d i r e c t l y b u t d e c i d e d i t v a s t o o c o m p l i c a t e d i (DGE/UQV) SOUNDS GREAT, WAS IT ON RD16? . . . I T ' S ABIT HARD FOR ME TO SET A LISTING TC OUR TN PRINTER OTHERWISE... GRD/RPI I c o p i e d t h i s t o a p r i n t e r , b u t t h e funny TN g r a p h i c s ( h o r i z o n t a l b a r , s u p e r s c r i p t s , e t c . ) came o u t a s " ? " . I s your v e r s i o n l i k e t h i s , o r d i d t h e n e t v o r l s i n v o l v e d do s o m e t h i n q funny t o i t ? G. H e l f f r i c h / U M We c o u l d r e a l l y a s e i t h e r e a t Wayne, ( r g / w s u ) Y e s , by d e f a u l t M e r i t ' s Hermes s u p p o r t o u t p u t s a ? f o r non p r i n t i n g c h a r a c t e r s . T h i s f e a t u r e c a n be o v e r r i d d e n by t h e Hermes command XNPC=0FF. b u t t h e ? a r e a p p e a r i n g on INPUT t o UM, no "NPC" p r o c e s s i n g i s done i n t h a t d i r e c t i o n (by M e r i t ) i t must be UQV's o u t p u t t o DATAPAC. Not s u r p r i z i n g t h o , a s t h e r e a r e no ASCII e q u i v a l a n t s . RLH/Merit Would UQV c a r e t o comment? S o r r y a b o u t t h a t - - RLH i s c o r r e c t . Our n e t w o r k DSR c h a n g e s non-ASCII c h a r a c t e r s t o " ? " on o u t p u t . Bob E n q l e y s a y s t h a t we can g e t a r o u n d t h a t b y t r a n s m i t t i n q SBIN. ( I d o n ' t t h i n k t h e n e t w o r k s w i l l t a k e i t . Garry Jackson/UQV)
126
Computing Centre UNIVERSITY OF BRITISH COLUMBIA 2075 Wesbrook Place Vancouver, B.C. V6T 1W5 August 31, 1S79 Kathy Young Computing Center 1075 Eeal Avenue Ann Arbor Michiqan 48105 Dear Kathy: Enclosed is a list of UHC documents produced since January cf this year. We are abo it to republish UBC DOCUMENTATION and when we do I'll circulate it as well. However, this list gives just the most recent documents and is probably of more interest. I have not foryotten my promise to produce a proposal for merqinq documentation distributions into regular ones, I've just been very busy. It is forthcoming. One of the things I proposed at the Workshop was that we each include in the text-processor source for documents a standard COMMENT block indicating the status of the document. I've enclosed with this letter a copy of those thinqs I think should qo into it. \ny suggestions for things I've missed? Yours truly,
Jon Niqhtinqalc Cc. MTS Newsletter
127
<2>
UBC DOCUMENTATION - September 1, 1979
New Documents produced since January 1979 /^
UBC ASSEMBLER 360/370 ASSEMBLERS IN MTS Paqes - 72
Apr 1979
UBC MTS INTRODUCTION AN INTRODUCTION TO MTS Pages - 54
Aug 1979
UBC NTSYS Apr 1S79 NUMERICAL TAXONOMY SYSTEM OF MULTIVARIATE STATISTICAL PROGRAMS Pages - 1 UBC OETHO GRAM-SCHMIDT OSTHOGONALIZATION Pages - 4
Apr 1979
&
UBC SPSLTR May 1979 SOLUTION 01 NONSYMMETRIC SPARSE MATRICES USING TEAR VARIABLES Pages - 7 UBC STAT GfllDF. STATISTICAL PROGRAM REC0MMENDA7 IO'IS Pages - 20
Apr 1979
UBC VSS OS/VS SIMULATOR Pages - 49
Aug 1979
___
Document-s revised since January 1979 UBC ALGOLW
Oct 1971 Revised - Jan 1979
ALGOL W REFERENCE MANUAL Paqes - 120 UBC BATCH
dec 197 3 Revised - Mar 1S7y
THE MTS BATCH USSR'S GUIDE 53 Pages
* v
UBC BMD09S
Feb 1970 Revised - Feb 1979
TRANSGENE RATION Pages - 7 UBC CHARACTER CHARACTEP MANIPULATION IN FORTRAN Pages - 56
128
Jul 1970 Revised - Jul 1979 -^%
y.3C__.OCaMEHTAn_.N_Z«_liE_._.Sher^_._J979 Mar 1978 Revised - May 1979
UBC COMBINE A FECOPD CPKBTWTW-. PPOGHAM Eages - 12
nnc conMAtns THE MTS COh.flKttf Paqes 141
Dec 1970 Revised - May 1979 MANUAL m
Feb 1970 Revised • Jun 1979 THE CRITICAL "ATI! METHOD FOR PRECEDENCE NETWORKS Pages - 23
UBC CPPN
Feb 1S72 Revised - Mar 1979
UBC DEBUG THE SYMBOLIC DEWIGGTNG SYSTEM Pages - 14U UBC ESP EDUCATION A I. STATISTICS PACKAGE Pages - 129 UBC FFT FASTER FOUTIEF TRANSFORMS FOR REAL DATA Paqes - 6 UBC FILES & DEVICES' THE MTS FIIFS AMD DEVICFS MANUAL Paqes - 171 UBC FBTBASIC A BASIC USERS' GUIDE TO FMT Paqes - Bo UBC FORT BAN
Feb 1977 Revised - May 1979
Mar 1978 Revised - May 1979
Jun 197 2 Revised - Jun 1979
Sep 1976 Revised - Jan 1979
May 1977 Revised - Auq 1979
FORTRAN US~n«S G'JIDE Paqes 137
Jul 1972 Revised - Mar 1979
UBC FTN
FORTRAN IV COMPILERS Panes - 2(> UBC FUNCTION MATHEMATICAL (OR 3?ECIAL) FUNCTIONS Pages - 46
129
Hov 197 3 Revised - Jun 1979
U_.C__)QCjUMENTA__IQN_-^gp_:emb_jr^i
UBC GPSSV GENERAL PURPOSE SIMULATION SYSTEM V Pages - 4 UBC IF THE INTERACTIVE FORTRAN MANUAL Pages - 132 UBC MAIL
Oct 197 1 Revised - Feb 1S79
Apr 197 3 Revised - Aug 1979
Jun 1973 Revised - Apr 1979
THE MTS MAILBOX FACILITY Paqes - 7 UBC PLC EL/C: THE CORNELL COMPILER FOR PL/1 Paqes - 90 UBC PROFILE EXECUTING COMMANDS FROM SIGFILES Pages - 10
Jun 1971 Revised - Jan 1979
Jan 1975 Revised - Feb 1979
UBC QEXT
Mar 1977 Revised - Jan 1979 EXTENDED PRECISION FLOATING POINT SUBPROGRAMS Pages - 4
UBC RKC RUNGE-KUTTA WITH ERROR CONTROL Pages - 7
Apr 1971 Revised - May 1979
UBC SIMCORT
Jun 1969 Revised - Apr 1979 CALCULATION OF MEANS, STANDARD DEVIATIONS, SIMPLE CORRELATION COEFFICIENTS, AND T-TESTS FOR VARIABLES WITH SOME MISSING DATA VALUE Pages - 10
UBC SORT
Nov 1971 Revised - Feb 1979 SORTING AND MERGING ROUTINES, AND UTILITY PROGRAM Pages - 147
UBC SSP
Mar 1S72 Revised - Aug 1979 THE IBM SCIENTIFIC SUBROUTINE PACKAGE - SSP/360 Paqes - 2
130
fc
UBC DOCUMENTATION - September 1, 1979
UBC TRAP
Jun 1970 Revised - Feb 1979
PROGRAM INTERRUPT TRAP Paqes - 4 UBC WATFIV
Jul 1971 Revised - Mar 1979
THE WATFIV FORTRAN COMPILER Paqes - 59 Technical Notes produced .since..January 1979 TN119 BURAM (DBURAM) Status - To be incorporated into UBC CURVE. Paqes - 6
Jan 1979
TN121
Jan 1979
REVISED EPPOP RETURN FOI? SYM, DSYM, SYMI, AND DSYMI Status - To be incorporated into UBC SYMSOL Paqes - 1 TN123 ELSQ (DBLSQ)
May 1S79
Status - To be incorporated into UBC CURVE. Paqes - 7 TN124 NEW FEATURES IN 3270 DSR
May 1979
Status - To be incorporated into UBC TERMINALS Paqes - 11 TN125 DISTRIBUTION 4 CHANGES TO THE SIGNON COMMAND Status - To be incorporated into UBC COMMANDS Paqes - 2
Jun 1979
TN126 DCDBLE PRECISION VERSION OF NSPIV Status - To he incorporated into UBC NSPIV Paqes - 1
Jul 1979
Documents currently being revised UBC ASSIST THE ASSIST ASSEMBLER AND INTERPRETER Paqes - 64
131
Jul 1974
UBC DOCUMENTATION - September 1, 1979
UBC CORN PARAMETRIC AND NON-PARAMETRIC CORRELATIONS AND TESTS OF SIGNIFICANCE Paqes - 33
Jun 1S73
UBC CSHPIII CONTINUOUS SYSTEM MODELING PROGRAM III Eages - 6
Feb 1976
UBC DIFSY SOLUTION OF ORDINARY DIFFERENTIAL EQUATIONS WITH ERROR CONTROL Pages - 7
Jun 1974
UBC DOCUMENTATION A GUIDE TO DOCUMENTATION PRODUCED 3Y THE UBC COMPUTING CENTRE Pages - 76
Feb 1972
UBC FACILITIES INTRODUCTION TO THE COMPUTING CENTRE Pages - 45
Sep 1973
UBC FBAND Oct 1971 FAST CHOLESKI METHOD FOR THE SOLUTION OF BANDED SYSTEMS OF LINEA''. EQUATIONS Pages - 10 UBC FOURT DISCRETE FOUPTER TRANSFORMS WITH APPLICATIONS TO FOURIER 3EFIES AND CONVOLUTION INTEGRALS Pages - 19
Jan 1S70
UBC FP.BOB PROBABILITY III AN F OR T DISTRIBUTION Pages - 4
Nov 1969
UBC HELP A GENERAL PURPOSE HELP FACILITY Paqes - 13
May 1977
UBC LOGOP FUNCTIONS FOR LOGICAL BIT MANIPULATION IN FORTRAN G PROGRAMS Paqes - 5
May 1969
UBC MATRIX A GUIDE TO SOLVING MATRIX PROBLEMS Paqes - 16 1
Feb 197 2
UBC MCSCORE MULTIPLE CHOICE SCORING PROGRAM Pages - 13
Jul 1974
132
2BC^OCUMENTA^gN_-^e£t__mber^A_JL979
UBC PCHI PROBABILITY ON A CHI-SQUARED DISTRIBUTION Pages - 4
Nov 1969
UBC PFS PROJECT PLANNING SYSTEM Pages - 14
Jul 1569
, Dec 1974 UBC RJE OPERATOR'S GUIDE FOE THE REMOTE JOB ENTPY TERMINALS Paqes - 3 1 UBC SSA1 SMALLEST SPACE ANALYSIS Pages - 11
Apr 1574
UBC SSP THE IBM SCIENTIFIC SUBROUTINE PACKAGE - SSP/360 Pages - 2
Mar 1972
UBC ST?P SMALL T3IANGULAH DEGRESSION PACKAGE Pages - 21
Aug 1S74
UBC STUDENT AREA THE UBC STUDENT TERMINAL AREA Paqes - 17
Sep 1971
UBC SURFACE SURFACE VISUALIZATION ROUTINES Paqes - 4 2
Sep 1978
UBC TBAN THE TRANSPORTATION PROBLEM Paqes - 4
May 1969
Hew Documents currently in production UBC TSPLINE CURVE AND SURFACE FTTTTNG USING SPLINES UNDER TENSION UBC DIGITISE" USE OF THE DIGITIZER UBC MULTIWRITETv USE OF THE HULTIWRTTER ""SRMINAL UBC PASCAL PASCAL/U3C PROGRAMMER'S GUIDE
133
COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT COMMENT
************************************* ************************************* ** UBC COMPUTING CENTRE **
******************* *******************
** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
Docume
nt Source D e s c r i p t i o n (sample)
Name o f
Documen t
: UBC FMTBASIC
Date
: June 1979
C o n t a c t Person
: J.
Status
: Working D r a f t
Text P r o c e s s o r
: UBC FMT Ver 6 . 3 (Mar 24/76)
Niqhtingale
L i b r a r i e s Requi r e d : JON:MACLIB Comments
** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
: This i s a d r a f t copy of a r e p l a c e m e n t f o r the previous manual. He e x p e c t t o p u b l i s h ** t h i s manual in F a l l 1979. **
** ** ** ******; ************************************************* ******************* *************************************
134
INDEX
\ _ .. *
135
SCAHCEL, C h a n g e s ,
EP229 V e r s i o n , MTS,
SCANCEL, C h a n g e s , 55-30 SDISPIAY, C h a n q e s , 55-26 $SET, C h a n q e s , 5 5 - 2 7 , 5 5 - 2 9 SS1GNCFF, bug f i x e d , 55-29 SSIGNON, C h a n q e s , 5 5 - 2 7 , 5 5 - 2 9 Accounting U t i l i t y , Multi-level Projects, 55-19 A l e x a n d e r , ASMH, 55-32
MTS:FORUM,
55-100
Xerox 9 7 0 0 , 55-100 ANSBACKL, GUINFO, 55-27 answerback, Chanqes, 55-26 APL, P r o g r e s s R e p o r t , 55-11 ASMH, C h a n g e s , 55-32 print exit, 55-38 ASSIST, P r o g r e s s R e p o r t , 55-9 ATTNTBP, C h a n g e s , 55-28 B a l l a r d , MTS:FORUM, 55-51 SPIRES, 55-51 BASIC, C h a n g e s , 55-61 BATCH, P r o g r e s s R e p o r t , 55-1 0 B e r r y m a n , Change F o r m s , 55-7 HTS:FORUH, 5 5 - 7 , 5 5 - 1 1 8 Xerox 9 7 0 0 , 55-118 B o d v i n , MTS:FORUM, 55-105 Xerox 9 7 0 0 , 55-105 B o e t t n e r , MTS:FORUM, 55-104 Xerox 9 7 0 0 , 55-104 Buckland, I F , 55-81 bug f i x e d , SSIGNOFF, 55-29 SCANSTOB, 55-26 B u q s , TEXTFORM, 5 5 - 6 5 , 5 5 - 7 1 , 55-75 Change F o r m s , Distributions, 55-6, 55-7, 55-8 C h a n g e s , JCANCEL, 55-3 0 $DISPLAY, 55-26 JSET, 5 5 - 2 7 , 55-29
SSIGNON, 55-27, 55-29 answerback, 55-26 ASMH, 55-32
ATTNTRP, 55-28 BASIC, 55-61 CMDS, 55-30 CMDSCAN, 55-28 COPY:GLOBALS, 55-28 COPY:MTS. MACROS, 5 5 - 2 9 , 55-30 CUINFO, 55-28 EMPTY, 55-26 FREED, 55-27 GETE, 55-27 GIVEBACK, 5 5 - 2 7 , 5 5 - 3 0
GUINFO, 55-30 MTSEQU, 55-30 PRINT=, 55-27 ROUTE-, 5 5 - 3 0 SETPARM, 55-30 WAITFOR, 5 5 - 2 9 CMDS, C h a n g e s , 55-3 0 CMDSCAN, C h a n g e s , 55-28 COBOL, P r o g r e s s R e p o r t , 55-9 COBOL-VS, P r o g r e s s R e p o r t , 55-9 Codeoff Problem # 1 , PASCAL, 55-53 common r i g h t h a n d t a b l e , MTS, 5 5 - 2 8 COPY:ACCFORMAT, i n t e n d e d
removal, 55-29 COPY:GLOBALS, Changes, 55-28 COPY:MTS. MACROS, Changes,
5 5 - 2 9 , 55-30 COPY:STATDSECT, i n t e n d e d removal, 55-29 Coulthard, IF, 55-80 C r a w f o r d , TEXTFORM, 55-75 CUINFO, C h a n g e s , 55-28 Culham, TEXTFORM, 5 5 - 7 7 1XTF: FORUM, 55-77 D e f a u l t s , L i s t i n g and 55-59 Object F i l e s , Device s u p p o r t p r o b l e m s , Xerox 9 7 0 0 , 5 5 - 8 6 , 5 5 - 8 7 , 55-88, 55-91, 55-96, 55-97, 55-98, 55-99, 55-100, 55-101, 55-102, 55-104 , 5 5 - 1 0 5 , 55-107, 5 5 - 1 0 9 , 5 5 - 1 1 1 , 55-113, 5 5 - 1 1 5 , 5 5 - 1 1 6 , 55-118 D i s t r i b u t i o n 6 . 0 , SPIRES, 55-4 7 D i s t r i b u t i o n s , Change Forms, 5 5 - 6 , 5 5 - 7 , 55-8 55-7 8 DITTO, proposed- c h a n g e s , Documentation, P r o g r e s s Report, 5 5 - 9 , 55-11 Status Report, 55-127 Sysitem C o n t r o l B l o c k s , 55-126 Douglas, Accounting Utility, 55-19 E a d i e , Floppy D i s c s , 5 5 - 5 7, 55-58
MTS:FOBUM, 55-57, 55-58 EMPTY, Changes, 55-26 EP229 Version, MTS, 55-26
138
e r r o r message f i x e d ,
MTS,
HTS, EP229 V e r s i o n ,
e r r o r message f i x e d , MTS, 55-27 Evans, Documentation, 55-126 MTS:FCRUM, 55-12 6 E x c h a n g e , Floppy D i s c s , 5 5 - 5 7, 55-58 E x p e r i m e n t a l r o u t i n e . Time and D a t e , 55-45 Floppy D i s c s , Exchanqe, 55-5 7, 55-58 FORTRAN I / O , P r o q r e s s Report, 55-9 FREED, C h a n q e s , 55-27 FTN, P r o q r e s s R e p o r t , 55-11 G e r s t e n b e r q e r , Chanqe Forms, 55-8 MTS:FORUM, 55-8 GETD, C h a n a e s , 55-27 GIVEBACK, C h a n q e s , 55-27, 55-30 G o u r l a y , MTS: FORUM, 55-101 Xerox 9 7 0 0 , 55-101 Graphics, Proqress Report, 55-9, 55-11 GUINFC, ANSBACKL, 55-27 Chanqes, 55-30 H a n s e n , HASP, 5 5 - 1 4 , 55-1K, 55-18 MTS:FORUM, 5 5 - 1 4 , 5 5 - 1 6 , 55-18, 55-45 Time and D a t e , 55-45 HASP, P r i o r i t i e s , 55-14 Queueinq, 55-18 WAITUNTIL and HOLDUNTIL, 55-16 H o w e l l , BASIC, 55-61 MTS:FORUM, 55-61 Hunter, Defaults, 55-59 MTS:FORUM, 55-59 IF, p o s s i b l e improvements, 55-eO, 55-81 Proqress Report, 55-1 0 IG, P r o q r e s s R e p o r t , 55-9 intended removal, COPY:ACCFORMAT, 5 5 - 2 9 COPY:STATDSECT, 55-29 Item 2 8 , TXTF:FORUM, 55-78 I t e m 30, TXTF:FORUM, 55-77 I t e m 360, MTS:FORUM, 55-126 I t e m 3 6 1 , MTS:FORUM, 55-86 Item 3 6 2 , MTS:FORUM, 55-87 Item 36 3 , MTS:FORUH, 55-88 I t e m 3 6 4 , MTS:FORUM, 55-91 Item 366, MTS:FORUM, 55-96
I t e m 3 6 7 , , MTS.: FORUM, 5 5 - 9 7 I t e m 3 6 8 , , MTS:! FORUM, 5 5 - 9 8 I t e m 369 , NTS1: FORUM, 5 5 - 9 9 I t e m 370, , MTS::FORUM, 55-100 I t e m 3 7 1 , , MTS : FORUM, 5 5 - 1 4 55-43 I t e m 3 7 2 , r MTS: FORUM, 55-16 I t e m 3 7 3 , , HTS::FORUN, I t e m 3 7 4 , , MTS:: FORUM, 5 5 - 1 0 1 55-102 I t e m 375, r MTS::FORUM, 55-104 I t e m 376, , MTS::FORUM, 55-18 I t e m 378, , MTS : FORUM, I t e m 384, , MTS : FORUM, 5 5 - 1 0 5 55-45 I t e m 386 , MTS : FORUM, 55-51 I t e m 3 8 7 , , MIS SFORUM, 55-107 I t e m 388, , MTS.:FORUM, I t e m 391 , MTS : FORUM, 5 5 - 1 0 9 I t e m 392, , MTS.: FORUM, 5 5 - 1 1 1 55-113 I t e m 3 9 3 , MTS :FORUM, I t e m 3 9 4 , , MTS.: FORUM, 5 5 - 1 1 5 I t e m 397 , MTS :FORUM, 55-55 I t e m 400, , MTS.: FORUM, 5 5 - 1 1 6 55-57 I t e m 4 0 2 , , MTS :FORUM, I t e m 4 0 3 , MTS : FORUM, 5 5 - 1 1 8 I t e m 4 0 4 , MTS : FORUM, 5 5 - 5 9 55-58 I t e m 4 0 5 , MTS :FORUM, I t e m 407, , MTS : FORUM, 5 5 - 6 1 55-63 I t e m 4 0 8 , MTS :FORUM, I t e m 4 0 9 , , MTS:: FORUM, 5 5 - 6 55-7 I t e m 4 1 1 , MTS: FORUM, I t e m 4 1 2 , MTS : FORUM, 5 5 - 8 55-98, J a c k s o n , MTS: FORUM, 55--102 55-98, 55-102 Xerox '3 7 0 0 , 55-63 L e v e l F (C o m p i l e r , PL1 , 55-78 L i f t , DITTO, TXTF:FORUM, 55-78 LINKEDIT , P r o q r e s s R e p o r t , 55--10 LISTER, )P r o q r e s s R e p o r t , 55-- 1 0 , 5 5 - 1 2 L i s t i n q and O b j e c t F i l e s , Defaulit s , 55-59 Macro L i b r a r i e s , St and a r d i z a t i o n , 55-43 M e l s n e s s , TEXTFORM, 55-65, 55--71 MICROFICII E , P r o g r e s s 5 5 - 1 0 , 5 5 - 12 Report , moved, SHUTDOWN, 55- 28 SIGNONi1 , 55-28 55-28 STARTU]P, MTS, com i o n r i q h t h a n d table, 55-28 EP229 iV e r s i o n , 5 5 - 26
137
HTS, e r r o r message f i x e d .
P r o g r e s s R e p o r t , FTN,
e r r o r message f i x e d , 55-2 7 transfer vector, 55-28 MTS Commands, . . . s e e Scommand MTS:FORUM, I t e m 3 6 0 , 55-126 Item 361, 55-86 Item 362, 55-87 Item 363, 55-88 Item 364, 55-91 Item 366, 5 5 - 96 Item 367, 55-97 Item 368, 55-98 Item 369, 55-99 Item 370, 55-100 Iteir 371,
55-14
CMDS, 55-30 CMDSCAN, 55-28 COPY:ACCFORMAT, 5 5 - 2 9 COPY:GLOBALS, 55-28 COPY:MTS.MACROS, 55-29, 55-30 COPY:STATDSECT, , 5 5 - 2 9 CUINFO, 55-28 EMPTY, 55-26 FREED, 5'5-27 GETD, 55-27 GIVEBACK, 5 5 - 2 7 , 5 5 - 3 0 GUINFO, 5 5 - 2 7 , 5 5 - 3 0 MTS, 5 5 - 2 6 , 5 5 - 2 7 , 5 5 - 2 8 MTS:FOfiUM, 55-6, 55-97, 55-99, 55-109, 55-111. 55-113, 5 5 - 1 1 5 , 55-116
Item 372, 55-43 Item 373, 55-16 Item 374, 5 5 - 1 01 Iteir 375, 55-102 Item 376, 55-104 I t e s 378, 55-18 Item 384, 55-105 Item 386, 55-45 Item 387, 55-51 Item 388, 55-107 Item 391, 55-109 I t e o 392, 55-111 Item 393, 55-113 I t e m 394, 55-115 Item 397, 55-55 I t e m 4 0 0 , ' 55-^116 Item 402, 55-57 Item 403, 55-118 Iteir 404, 55-59 Item 405, 55-58 Item 407, 55-61 Item 408, 55-63 I t e u 409, 55-6 Item 411, 55-7 Item 412, 55-8 MTSEQU, C h a n g e s , 55-30 MuIti-level Projects, Accounting U t i l i t y , 55-19 Niqhtingale, Documentation, 55-12 7 OBJUTIL, P r o g r e s s R e p o r t , 55-10 Ogden, $CANCEL, 55-30 SDISPLAY, 55-26 $SET, 5 5 - 2 7 , 5 5 - 2 9 SSIGNOFF, 55-29 JSJGNON, 55-27, 55-29 answerback, 55-26 ATTNTRP, 55-28 Change Forms, 55-6
MTSEQU, PRINT=, R0UTE=,
55-30 55-27 55-3 0
SCANSTOR,
55-26
SETTARM, 5 5 - 3 0 SHUTDOWN, 55-28 SIGNONM, 5 5 - 2 8 STARTUP, 55-28 WAITFOR, 55-29 Xerox 9 7 0 0 , 55-97, 55-99, 55-109, 55-111, 55-113, 5 5 - 1 1 5 , 55-116 P a r s e r and A n a l y z e r , SPIRES, 55-51 PASCAL, Codeoff Problem 11,
55-53
Progress Report, 55-11 Status Report, 55-55 P i c k l e m a n n , MTS:FORUM, 55-55 PASCAL, 55-55 PLC, P r o g r e s s R e p o r t , 55-11 Plotting, . . . see Graphics PL1, L e v e l F C o m p i l e r , 55-63 p o s s i b l e improvements, IF, 5 5 - 8 0 , 55-81 P r i n g l e , SIMULA, 55-41 p r i n t e x i t , ASMH, 5 5 - 3 8 PRINT=, C h a n g e s , 55-2 7 P r i o r i t i e s , HASP, 5 5 - 1 4 P r o g r e s s R e p o r t , APL, 55-11 ASSIST, 55-9 BATCH, 55-10 COBOL, 55-9 COBOL-VS, 55-9 Documentation, 5 5 - 9 , 55-11 FORTRAN I / O , 55-9 FTN,
138
55-11
DM, PASCAL.
Progress Report, Graphics,
Graphics, 55-9, 55-11 IF, 55-10 IG, 55-9
LINKEDIT, 55-10 IISTER, 5 5 - 1 0 , 5 5 - 1 2 MICROFICHE, 5 5 - 1 0 , 55-12 OBJUTIL, 55-10 PASCAL, 55-11 PLC, 55-11 SOR1, 5 5 - 1 0 , 5 5 - 1 2 SPITBOL, 5 5 - 1 0 , 5 5 - 1 1 Student System, 55-10 TAPECOPY, 55-10 p r o p o s e d c h a n g e s , DITTO, 55-78 p r o p o s e d n a m e s , TEXTFORM, 55-77 Q u e u e i n g , HASP, 55-18 Redistribution, . . . see Distribution R0UTE=, C h a n q e s , 55-30 S a n q u i n e t t i , PASCAL, 55-53 SCANSTOR, buq f i x e d , 5 5 - 26 SETPARM, C h a n q e s , 55-30 SFU, TEXTFORM, 5 5 - 6 5 , 55-71 S h e r r y , ASMH, 5 5 - 3 8 SHUTDOWN, moved, 55-28 SIGNONM, moved, 55-28 SIMULA, S t a t u s R e p o r t , 55-41 SORT, P r o q r e s s R e p o r t , 55-10, 55-12 SPIRES, D i s t r i b u t i o n 6 . 0 , 55-4 7 P a r s e r and A n a l y z e r , 55-51 SPITBOL, P r o q r e s s R e p o r t , 55-10, 55-11 S t a n d a r d i z a t i o n , Macro Libraries, 55-43 STARTUP, moved, 55-28 Status Report, Documentation, 55-12 7 PASCAL, 55-55 SIMULA, 55-41 S t e r k e n , SPIRES, 55-47 Stevens, Proqress Report, 5 5 - 9 , 5 5 - 1 0 , 5 5 - 1 1 , 55-12 Student System, P r o q r e s s Report, 55-10 System C o n t r o l B l o c k s , Documentation, 55-126 TAPECOPY, P r o q r e s s R e p o r t , 55-10 TEXTFORM, B u q s , 55-65, 55-71, 55-75 proposed names, 55-77
T i f f a n y , Macro L i b r a r i e s , 55-43 MTS:FORUM, 5 5 - 4 3 , 5 5 - 6 3 PL1, 55-63 Time and D a t e , Experimental r o u t i n e , 55-45 t r a n s f e r v e c t o r , MTS, 55-28 TXTF:FORUM, I t e m 2 8 , 55-78 Item 30, 55-77 UBC, Change F o r m s , 55-7 Documentation, 55-127 IF, 55-80, 55-81
MTS:F0RUM, 55-118
55-7, 55-51,
Progress Report, 55-9, 5 5 - 1 0 , 5 5 - 1 1 , 55-12 SPIRES, 55-51 Xerox 9 7 0 0 , 55-118 UM, SCANCEL, 5 5 - 3 0 SDISPLAY, 55-26 $SET, 5 5 - 2 7 , 5 5 - 2 9 $SIGNOFF, 55-29 SSIGNON, 5 5 - 2 7 , 5 5 - 2 9 answerback, 55-26 ASMH, 5 5 - 3 2 , 5 5 - 3 8 ATTNTRP, 55-28 Change Forms, 55-6, 55-8 CMDS, 55-30
139
CMDSCAN, 55-28 C0PY:ACCFORMAT, 55-29 COPY:GLOBALS, 55-28 CO?Y:MTS.MACROS, 55-29, 55-30
C0PY:STA1DSECT, 55-29 CUINFO, 55-28 DITTO, 55-7 8 EMPTY, 5 5 - 26 Floppy D i s c s , 5 5 - 5 7 , 55-58 FREED, 5 5 - 2 7 GETD, 55-27 GIVEBACK, 5 5 - 2 7 , 5 5 - 3 0 GUINFO, 5 5 - 2 7 , 5 5 - 3 0 HASP, 5 5 - 1 4 , 5 5 - 1 6 , 5 5 - 1 8 Macro L i b r a r i e s , 55-43 MTS, 5 5 - 2 6 , 5 5 - 2 7 , 5 5 - 2 8 MTS:FORUM, 5 5 - 6 , 5 5 - 8 , 55-14, 55-16, 55-18, 55-43, 55-45, 5 5 - 5 5 , 5 5 - 5 7 , 55-58. 55-63, 55-97, 55-99, 55-100, 5 5 - 1 0 1 , 5 5 - 1 0 4 , 55-105, 5 5 - 1 0 9 , 5 5 - 1 1 1 , 55-113, 5 5 - 1 1 5 , 55-116 MTSEQU, 5 5 - 3 0 PASCAL, 5 5 - 5 3 , 5 5 - 5 5
OH, PL1 #
Xerox 9700
PL1, 55-63 PRINT=, 55-27 F0UTE=, 55-30 SCANSTCR, 55-26 SETPARM, 55-30 SHUTDOWN, 55-28 SIGNONM, 55-28 SPIRES, 55-47 STARTUP, 55-28 Time and D a t e , 55-45 TXTF:FORUM, 55-78 WAITFOR, 55-29 55-97* 55-99, Xerox 9 7 0 0 , 55-100, 55-101, 55-104, 55-105, 55-109, 55-111, 5 5 - 1 1 3 , 5 5 - 1 1 5 , 55-116 UNE, A c c o u n t i n g U t i l i t y , 55-19 Defaults, 55-59 MTSrFORUM, 55-59 SIMULA, 55-41 UQV, EASIC, 55-61 Documentation, 55-126 MTS:FORUM, 55-61, 55-86, 55-87, 55-88, 55-91, 55-96, 55-98, 55-102, 55-107, 55-126 TEXTFORM, 5 5 - 7 5 , 5 5 - 7 7 TXTF:FORUM, 5 5 - 7 7 Xerox 9 7 0 0 , 55-86, 55-87, 55-88, 55-91, 55-96, 55-98, 55-102, 55-107 WAITFOR, C h a n g e s , 55-29 WAITUNTIL and HOLDUNTIL, HASP, 55-16 55-107 Ward, MTS:FOEUM, Xerox 9 7 0 0 , 55-107 W e b s t e r , MTSrFORUM, 55-86, 5 5 - 8 7 , 5 5 - 8 8 , 5 5 - 9 1 , 55-96 Xerox 9 7 0 0 , 55-86, 55-87, 5 5 - 8 8 , 5 5 - 9 1 , 55-9 6 Xerox 9 7 0 0 , D e v i c e s u p p o r t. problems, 55-86, 55-87, 55-88, 55-91, 55-96, 55-97, 55-98, 55-99, 55-100, 55-101, 55-102, 55-104, 55-105, 55-107, 5 5 - 1 0 9 , 5 5 - 1 1 1 , 55-113, 55-115, 55-116, 55-118
140
