The Outside World

VECTOR Vol.3 No.4

Recent meetings

Our coverage of recent meetings in this issue is limited to the paper given by Dick Bowman, of C.E.G.B., last November, looking at APL’s links with the outside world. On Friday 20th February, the topic of the B.A.A. meeting at the Royal Overseas League was Are Your Systems Reliable’. The two speakers, Linda Kindred from the Wellcome Foundation and Chris Campen from the British Airports Authority, gave their views on good systems development practice through quality assurance. Their talks were followed by a panel discussion. A full report of this meeting will appear in the next issue of VECTOR. A riumber of people expressed an interest in the Quality Assurance Forum mentioned by Linda Kindred during her talk. Anyone interested in finding out more about it should contact: Gordon Irving, 17 St Catherine’s Road, Ruislip, Middlesex, HA4 7RX. Tel: 0895 635222

56

The Outside World by Dick Bowman

A feature becoming commonplace in newer APLs is the ability to use routines written in other languages. The object of this paper is to review some limited experience in using these features, suggest where the benefits to APL lie and Pose some questions about the applicability of this sort of link.

There is no pretence that this is an exhaustive survey ~ it is merely the collection of some recent experience. 1. APL*PLUS/PC Assembler Functions An expected corollary of the JCALL system function is that use of assembler routines in appropriate places should lead to some speedup in application processing. Certainly use of the <CSSMATML> routine described in the STSC documentation and incorporated in their distributed <INPUT> workspace had helped lead to this expectation.

Some experimentation with the ASMENS distributed workspace was inconclusive. There was a measurable performance increase with test data but in the context of an application (where function calls were frequent, but arguments were brief) the achieved improvement was judged unjustifiable in contrast to the effort which would have been required to implement the necessary changes. My problem seemed to centre around wanting to use routines subtly different from those provided in pre-written form; not having the patience or skills to write my own Assembler routines I burdened those that Tused down with APL prologues and epilogues converting data between what I had and what was wanted. Questions: " Does anyone have a good reliable way of measuring performance on the IBM PC  can we see quantification of the speed gains achievable? ® How much effort is required to learn enough Assembler to be able to cost-effectively integrate APL and Assembler if performance is the only criterion? 2. IBM ICU In their manuals IBM provide an example of a function which can invoke ICU to produce routine business  graphics diplays; it’s a little rudimentary, suffering lack of flexibility. Straightforward generalisation produces the <CHART> function (see Figure 1); a little more work results in <CHARTFREE> (Figure 2) which handles free data’ (to use the vernacular), A description and examples of use are shown in Figure 3; the most useful mode of operation, of course, is with pre-defined chart formats.

For all its faults  the main one being that there seems to be absolutely no scope to extend its capabilities  being able to link direct to a pre-written graphics package (and one used by lots of people in non-APL applications) carries obvious benefits.

One notes with interest that future plans for ICU appear to be along the lines of integrating more capability into it; in the context of the infamous line smoothness  enter a number from 1 to 99’, one wonders whether a more desirable evolution path would be as an appendage to programming systems with flexibility and rigour than for ICU to grow into yet another all-purpose  system with its own rules, idiosyncrasies and expertise.

57

VECTOR Vol.3 No.4

3. APL2 [JNA APL2 Release 2 introduced the facility to call programs written in other languages, Assembler and Fortran (with some restrictions) from both CMS and TSO, REXX from CMS only (my personal experience is limited to use within TSO). The potential is very attractive  by contrast to previous excursions by IBM APLs into the outside world, the implementation was surprisingly clean, The most awkward part of the process was to come to terms with the format of the NAMES file which provides the cross-relation between APL variables and Fortran/Assembler arguments and results  the best advice ] can offer is to work your way into it gradually with programs which you are familiar with and which are under your control.

Once you're over the hurdle of setting up properly-formed NAMES file entries (more plentiful examples in the documentation would help) usage is simplicity personified. For example, given a Fortran subroutine which we want to call <NELLY> all that’s necessary is to type: 3 12 O¥4 NELLY? You now effectively have a locked function named <NELLY> which (assuming that the Fortran routine has been properly link-edited library which you have allocated) you can treat just as if it had all along been written in APL. The left argument to [JNA is presently a little over-elaborate (the 3 means that you want to create a function; the 11 that your victim is a Fortran or Assembler routine); one awaits future extension with great anticipation. Having the function not only can you use it, you can move it around with JLOAD, )COPY and )PCOPY. Having got the feature, and knowing how to use it, what does it give in return? Essentially three things: a) Doing Things Faster

This is the obvious payoff - given a utility function you can avoid interpreter overhead. Equally obviously it should be possible to measure the performance gain; a place to start is the example provided in the IBM manuals. Compiling and linking were straightforward (we’re using MVS/XA and I found that it was only necessary to specify AMODEQG]1) at the link-edit stage, which is a slight departure from the official word, and may well be installation-sensitive. As an aside, the state of the Fortran art vis-a-vis Fortran66/Fortran77/VSFortran/XA is a veritable quagmire  I’ve (temporarily?) adopted the ultra-conservative line of compiling and link-editing what I need myself rather than rely on standard libraries, at least I have only myself to blame. Comparison with equivalent APL was that with vector arguments up to 10 elements there was a very slight advantage to the Fortran which steadily widened as the argument length increased until at 1000 elements the Fortran was about 2.5 times faster. Bear in mind that: i) You have to do a

little preparatory work in APL setting up arguments that the Fortra can swallow (this is universal and can lead to APL being a better performer tha compiled code in the right, and not uncommon, circumstances).

58

VECTOR Vol.3 No.4

ii) The Fortran routine (as written) has an upper bound on argument length which is not there for the APL (within reason). One could be contentious at this point and ponder the relative values of APL compilers against making wider use of facilities like this  but I don’t really think that doing it faster’ is in any way the major attraction of the feature. b) Doing Things Better This is what gets much closer to the point; there’s a vast legacy of pre-written code in other languages which performs well-defined tasks to a predictable standard. We don’t have to rewrite it all in APL and we can be confident of accuracy. Given the CEGB situation as a case in point  here’s a list of bought-in software which is available to anyone developing Fortran software on the system: NAG Library  Mathematical/Scientific Subroutines NAG Graphics  Graphical Supplement Harwell Library ~AERE main software library FACSIMILE  Ordinary Differential Equations EISPACK  Eigenvalue Analysis Solutions REDUCE Computer Algebra DASL  Data Approximation Subroutines MINITAB  Interactive Statistics IBMSSP ~IBM Scientific Subroutines GLIM  Statistical model building GENSTAT  Statistical model building It’s nothing like a complete list, libraries like NAG contain hundreds of routines themselves, and it’s all available now to the APL user as well. Why does this matter? Here’s an example: The Generating Board owns many cooling towers at power stations; they’re hundreds of feet high and have wails of reinforced concrete less than six inches thick. The problem is to deduce a complete wall profile from accurate measurement at a few select positions; we had a Fortran program which could do this and was of satisfactory accuracy, but it didn’t return the figures in a machine-readable format which we could use for further analysis; we needed a new program of comparable accuracy and for a variety of reasons APL was the preferred development route. The obvious technique to use was a spline-fit (which was also what our existing program used); immediate candidates were in IBM’s GRAPHPAK workspace and Gilman and Rose. But the problem was that neither of these got within an acceptable margin of our original program (which had had exhaustive checks for accuracy). Up to this point one had had a certain amount of faith in the accuracy of these routines.

NAG offered a pair of routines (EO1BAF and E02BBF) which seemed to fit the bill (they are intended for use as a pair); Figure 4 shows them in context of being used (most of the activity in the APL is to marshall the various arguments and set up space for results). It also points up the shortcoming of such

a lot of scalar programming; E02BBF is a one-

59

VECTOR Vol.3 No.4

C. a shot subroutine loop around (I guess each might be useable by the brave— but J was under time constraints to deliver). At the end of the day results agree well with our target performance.

Another example using NAG routines is the <POLYFIT> function shown in Figure 5 ~ what makes this relevant being that it provides the solution to the APL2 domino problem which I raised in an earlier issue. Whereas a naively-coded APL2 function failed to fit a curve after order 2, with VSAPL and APL*PLUS/PC carrying on to order 5  on the specific data in the previous discussion <POLYFIT> was willing to produce results all the way up to order 10. To save effort with pencil and graph paper, Figure 6 shows a calculated third-order fit to the data.

Again some oddities that you find when you use pre-written code: <E02ADF> is happy to provide an array result giving coefficients all the way up to your desired order, whereas the closely related <EOQZAEF> resolutely insists on taking single x-values only.

Note that the passing of time since writing <RCALC> has led to a slightly more confident coding style.

Question  How much APL code is good enough’ and how much fails if accuracy constraints are rigorous?

Doing Things You Couldn’t Otherwise Again an example:

We make extensive use of Tektronix (and other) graphics terminals, which operate in response to sequences of ASCII characters. Back in the old days of VSPC/VSAPL this was no problem; type: )WSPC PUNCH CONTROL and what you send arrives at the terminal untranslated, unadulterated and uncontaminated.

Migration to TSO/APL2 brought BIG TROUBLE (parenthetically, this is the only conversion problem which has ever worried us)  if it wasn’t printable it got mangled. We had an investment in graphics hardware and at the time (this is now changing dramatically) some reluctance to get involved with IBM graphics  terminals (because they really weren’t graphics terminals).

Some IBM conversion manuals told us where the problem came from (‘a TPUT with EDIT’) and led us off in the general direction of writing an AP which would bypass the problem. We never really got anywhere (our friendly SE offered to sell us a few 3277/ GAs) and APL2 Release 2 came along, accompanied by an unattributed verbal remark that [JNA made our problem trivial. We didn’t really see this, but there was also an offer of IBM sorting the problem out for us ata fee of £77 a manhour; we figured that if knowing this sort of thing let you earn £77 an hour we'd like some of the action for ourselves.

60

VECTOR Vol.3 No.4

Fortunately (?) we have a well-endowed Fortran system, and the Fortran graphics people had got round the problem themselves some years earlier; so what we did was to use their solution and [JNA to reach it. The outcome is shown in Figure 7; <DRAWABS> is a device-independent function which drawsa line toa specified point.

With device type specified in global <dev>, function <DRAWABST4107> constructs specific code for the Tektronix 4107 terminal; it gets translated to ASCII by the <ASCIIOUT> function before finally being chopped into 256-byte (maximum imposed by the assembler routine) chunks by <OUT> for transmission to the terminal by external function <VTADEO31I>. Apologies for the convoluted route, the bug(s) and the extraneous code, Note again the imposition of finite size limits and the consequent loop potential of the APL code (in practice this application very rarely wants to send a string of more than 256 characters in one go  ideally we should also do some blocking for transmission, but we don’t). The associated Assembler code is shown in Figures 8 and 9; there is some allegation that one or two of the translate table entries are incorrect. At the end day it really was wivial, but we didn’t ever get to see the £77 either.

4, APL2 EDITOR IBM Reference documents for APL2 contain sketchy comment about use of any operating system editor that you choose to use’ for function and operator editing; curiosity led to investigation of this feature. The IBM literature seems somewhat imprecise  what follows here is an attempt to provide a specific example of use of the feature in one specific installation; the environment is TSO with Release 1 of ISPF, the objective is to use the ISPF editor to edit an APL function. a) Augment standard CLISTs with a few of your own; Figure 10 shows the necessary TSO allocation and this is best done before invoking APL. There are two new CLISTs involved, called <ENT> and <CEDIT>, shown in Figures 1] and 12-the IBM manuals lead one to the impression that <CEDIT> would suffice, but this wasn’t the case; <ENT> is excessively complex and repeats some dataset allocation needlessly  what you see here is something which works rather than a honed-down version, b) Specify the name of the editor you want to use with the EDITOR command - in this instance the name is <ENT> c) Edit as required; a typical display is shown in Figure 13.

Having gone to all this trouble, the results are none too exciting; first intimation of trouble being the time elapsing between wanting to edit and being able to. Very ad-hoc timing comparisons for a simple editing exercise gave the following results: YEDITOR 1 YEDITOR 2 235 as YEDITOR ms

61

VECTOR Vol.3 No.4

An obvious candidate for speedup is the excessive amount of work in the <ENT> CLIST; some experimentation with chopping this about (and also taking the hint in the IBM manual) was none too conclusive; my personal resolution has been to avoid the facility until either someone shows me that it can be made to work satisfactorily or I can find a strong reason for needing to use the ISPF editor to edit APL objects.

Further reflection leads me to the opinion that my <MYALLOC> and <ENT> CLISTs are pretty awful, but ] remain dubious that refinement would lead to this route becoming my preferred editor  J feel that the overhead of creating and using data files must slow things up ultimately. But I stress that this is all based on very limited experience in one environment  Phil Last tells me that use of the CMS editor is preferable to EDITOR 2 in a CMS environment (again with a proviso or two); I suspect that if ] were invoking APL2 from within ISPF (rather than the other way about) there could be a different conclusion.

Question - Aside from the option of newcomers to APL using a familiar editor what is this feature for?

Acknowledgements:

My colleagues John Dedman and David Leal for their patience in the face of my ignorance of Fortran programming and ISPF; Gill Darbyshire for doing the spadework on <POLYFIT> as a first task in APL.

References:

. STSC APL*PLUSIPC System Reference Manual _ APL2 Programming: Language Reference; IBM Corporation; $H20-9227 APL2 Programming: System Services Reference; IBM Corporation; SH20-9218 . APL2 Programming: Using the Supplied Workspaces; IBM Corporation; $H20-9233 . APL  An Interactive Approach; Gilman and Rose; Wiley . NAG Fortran Library Manual; Numerical Algorithms Group . VECTOR Vol 3 No 1, Page 99; Technical correspondence.

Figure 1. The <CHART> function

i ¥ cuant Wi CHRICTL CTD 3 DAT ; PATACTL $ HEADING 3 KEYS; LABELS} RC; XY 30100 1 rel [2] *(2s.=R0¥126 DSVO 2 3 p’CTLDAT") /SHAREOK [3] APL26 Or SHARING’ Ty] 40 (5) SHAREOK:X+22" [6] Ye("24 pedo (7) CHRICTL+76p’ * (8) CHRICTLE4I1+% Zo 0 (9) cHRTCTLE 4+ 4I]+4 IO 2 (10) crarerelerwi+s ro 0 Cat] cHrrere[12+4)+4 0 0 (12) CHRICTEL16+18]+8+129¥ {13] cHaromi2si+'*" [183 CHRTCTLL32+14)+4 To 0 (15} CHRICTLL36+141¢4 IO 1tpY (16) CHATCTELHO+ 4 I+4 TOpX (17) CHRTCTLT B+ 4 ]4 JO T1tpSoW [18] CHRTCTL(48414]«4 IO 1tp62¥ C19] cHRTCTLLS2+141+4 IOpHEADINGHOW NAUSWHe

VERSION OF IcU ICU FUNCTION REQUIRED PFKEY INFORMATION DISPLAY SAVE/RESTORE PERMITTED NAME GP SAVED FORMAT WAME OF SAVED CHART DATA FREE DATA HUMBER OF COMPONENTS NUMBER OF X ELEMENTS LENGTH OP LENGTH LABEL LENGTH OF CHART HEADING eo panaesroea

62

VECTOR Vol.3 No.4

[20] cHRTETELS7J+t«! (21) cuRrerole4+1122+,4 ro 0 80 2 [22} DATACTE+0p0 (23) KBYs+, Son” [24] LABELS+ 620 C25) DAT+CHRICTE .KEYS, LABELS HEADING (261 ey (27) Cftw"10, (oCHRICTE) , (pDATACTL) DATACTE., (0X) .X, (oY) .¥, (KEYS) , (LABELS) ,pHEADING [28] Rcwore, v ® PRINTER OR GDP A PRINTER DEPTH, WIDTH, COPIES

Figure 2. The <CHARTF REE? function tay 7 GHARDPREE W:CHRTCTE :OTL DATs DATACTE ; HEADING s KEYS; LABELS: RCA 3 ¥ 010 2] Ord (2) +(2a,=R0+126 OsvO p'CTLDAT’)/SHAREOK [3] 'APL26 NOP SHARING! C4) 40 (5) SHAREOK:Xe22W (6) ¥e("2t 11 spy) pre3=¥ C7] CHRICTE*76p" * (8) cHRICTEL4}<4 To 0 VERSION OF ICU (9) cHATeTEL4+14]+4 TO 2 a ICU PUNCTION REQUIRED (10) cuarert(a+i4}e4 ro 0 @ PPKEY INFORMATION DISPLAY (11) CHRICTEL12+14]<4 TO 0 A SAVE/RESTORE PERMITTED (12) CHRTCTL(16+18]+8+12¥ ® NAME OF SAVED FORMAT £13) cHRTCTEC2SJ<"*! NAME OP SAVED CHART DATA 14] CHRTCTLE32+14)4 ZO 1 A TIED OR FREE DATA (18) CHRTCTEL36+14]+% TOpx a NUMBER OF COMPONENTS (16) cHRTCTEL4O+ 14 ]e4 Lopex © WUMBER OF X ELEMENTS (17) CHRICTEL AHH ]+4 10 1tpSoW ® LENGTH OF EACH KEY (18) CHRTCTLCUB+ S14 TO 14 6oW * LENGTH OF EACH LABEL (19) CHAICTELS2+14}+4 TOpREADINGHUOW a LENGTH OF CHART HEADING (20) currerils7}<"** a PRINTER OR GDF PILE WAME (C21) cHRTeTELe4+112]1+,4 fo 0 a0 2 6 PRINTER DEPTH, WIDTH, COPIES £22] DATACTL+ep x [23] KEYs¢,Sow (24) LABELS+ 62" £25) DAMCHRICTL .KEYS,LABELS HEADING (261 xXeex (272) Yeey (26) CPi*" 10, (oCHRTCTL) , (pDATACTL) ,DATACTL . (pX),X, (OY) .Y, (DKEYS) , (OLAPEES) sPHEADING (231 RcecTL v Figure 3. How to use <CHART>

The <CHART> function provides a link to the IBM CHART utility,

Prerequisite: If you wish to save or retrieve chart format definitions you must have a file

called _<tsoid‘CHART.ADMCFORM> allocated to the ddname <ADMCFORM>. This is done automatically if the workspace is used stand-

alone (see <LX > for specifics),

Note that terminology is CHART-terminology; fora full description of facilities consult the

relevant [BM manuals.

To draw a chart:

CHART name xvalues yvalues heading key labels

where:

63

VECTOR Voi.3 No.4

<name>  either *  (do not use a stored chart format) or name of stored chart format

<xvalues>  vector of xvalues (at present this link is restricted to tied  data)

<yvalues>  either vector of yvalues . or matrix with each row of the matrix a set of yvalues

Missing values are enterable as 1E72.

<heading>  Overall title for the chart. May be elided by entering as

<key> - Chart key (matrix with one row for each key). May be elided by entering as .

<labels> Chart labels (matrix with one row for each label). May be elided by entering as an

For example: NAME®**? Mea5 Y+59?100 HEADING*' FIVE RANDOM NUMBERS* KEY+1 6p’ RANDOM’ LABELS*5 1p’ABCDE’ CHART NAME X Y HEADING KEY LABELS

Function <CHARTFREE? provides an experimental equivalent for free data. Syntax of usage is the same, but both <xvalues> and <yvalues> are nested vectors; for example:

Xe(1 23) (4 5 6 7) ¥e(739100) (249200) CHARTFREE *s' Xe tt tt

Figure 4. <RCALC>  using E0IBAF and E02BBF sYaKsCsLCK 5 WRK LWA; IFATL 3 I5RES [1] # RF BORMAN - CALCULATE SPLINE-PIT RADIUS AT REQUIRED HEIGHTS (2) Me(ezacr) (3) xezacr (4) feRacr [5] Ke(4eM)p0.4 C6] oe se)0062 [7] bcKeues Ca} 9 WRK+ (16+6*4) 00.1 (9) ERRK+16+5*4 (10) FPAIZ*O [11] RES*EO1RAF MX YK C LCK WRK LWRK IFAIL [12] keaREst1] 13] croresl2] (14) Teo 115] #10 [46] MEXP: +( (L479) >pZREQ}+0 (17) +42REQUY]>(/ZACT) +ERR (1a) s0,1 (19) ZZ, 9(BO2BBF(HOM)K CCZREQLLI)S IFATLVCLI (20) +WEXT C2.) FRR(Z+2,0 (22) +NEXT ¥

Figure §. The <POLYFIT> fiction :

9 2eDEG POLYFIT XYsA3TpIPAIL:K<NEXTESP2SsW5W2 sW2 3X3 YsOT0 {1] aPOLYNOMIAL FIT (2) Oro+r [3] KeL+DEG tu) Of riexy (5) Be(px)pt a WEIGHTS

64

VECTOR Vol.3 No.4

C6] W1+(3,9X)p0 A REQUIRED [7] W2#{2,X)p0 fn REQUIRED WORK AREA [a] Ae(2pK)p0 A RESULTS AREA [1] (9) S+xp0 ® RESULTS AREA [2]  (10) rFAIz«o a RESULTS AREA [3} [11] (A 8 IRAIL)+EO2ADF(px)K WLW2A S IFAIL £12] ALAlsx? fl REQUIRED COLUMN ONLY (13) ret C14] Z(px)p0 [15] x+x xcaPipx 8 WAG "NORMALISATION! £16) NEXTL«{(pX)pNEXT) 0 (17) wees (P TRAIL }+0 C18] (P IFAIL)*B0245F K & XUI]P IPAIL (19) zfr}<P [20] +WEXTELI*1+1) C21) 

Vo (11 'WORMALISATION' ~ AS MANUAL C2) eC CXLEI-L/X)- C/O) XELD(T/2N-U/ 8 

Figure 6. The results of using <POLYFIT>

CURVE-FIT EXAMPLE

42

 THIRD ORDER

x ORIGINAL DATA

wt t T 1 1985 1988 1991 1992 1995

Figure 7. Achieving ASCII output to Tektronix 4107

¥ DRAWABS AsD [1] DRAW 70 POSITION <A> £2] oLpcpece [3] GPA [4] ACONNDC A [5] 2 'OUT ASCTIOUT (DRAWABS" DEV," A) ,DIYPE+NEWLINE' (6) DeDDE IDLESx0.1 meneeeenneel

65

VECTOR Vol.3 No.4

¥ ReDRAWABST4107 A (1] # T\107-SPECOIFIC <DRAWABS> [2] ReESC,*LG' ,TYL07CODE A 

V ZeASCIIOUT W [1] CONVERSION FOR ASCII OUTPUT [2] zelavlascrrcor(Qaviw]) v

¥ OUT STRING;L (4) ® SEND <STRING> TO TERMINAL 2 (3) STRING+ STRING (u] NEXT:+(O=pSTRING)*0 nm <VTADEO31> HAS INTERVAL 256-BYTE LIMIT [5] Le256L STRING (6] VTADEO31 E(L*S TRING) C7) STRING+LASTRING (8) +NEXT v

Figure 8. Assembler code to run VTADEO - part 1

Seaeeaeceeacsazeaecerseaszzasessse TOP OF DATA ASRASRECEATRESASARATE-CAPS ON- 88 Beo---+--CBECT VTADEO- causanseuseensessenesvarnassessasseasavanensgunsansgsgggesusteneenstts TILE UTADEO SET UP 11/4/65 FOR VTAM/NTO GRAPHICS * SIMILAR TO TCAM ADEOUT, EXCEPT OIFFERENT TRANSLATE ; TRELE! 5 a cusene eee asunnenrsuseseaneacansesatensonsanenenconsunsesnesaasis vTADEO §=6—- CSECT os OH s™ 14,12, 42(13) BAR 12,0 USING *,12 st 13, 8AV+4 LA 13,80 u 9, <V (VTRASR) t 5S, =A (BUFFER) 1M 7,8,0(1) R7 TS A(LEN), RB IS A(BUFFER) 4 7,.0(7) LR 0,7 LOOP MVC O(1,5).9(8) PACK THE OUTPUT ARRAY La S.1(5) INCREMENT tA 8.4(8) BcT 7,LOOP TEST !"m BUFFER (266) ,0(9) CONVERT FROM ASCII L 1,AQOR N O,STZE TPUT (1),(0).R REQUEST THE OUTPUT L 13, BAV64 LM 44, 42,12(13) BR 14 16F ROOR oc x'o2’ oc ALS (BUFFER > BUFFER os 2s6c SIZE oc X' OOOOFFFF ' ENO AAEAHAAEAESAAAEA ERI AEESSEREREES BOTTOM OF DATA e2ekeREREREEEEESERRS-CAPS ON-*E

66

VECTOR Vol.3 No.4

Figure 9. Assembler code to run VTADEO  part 2

RESESSERSSARESERARESRAEESEEERERESS TOP OF DATA SREERESERARAERARRAERE-CAPS ON- 08 VTRAGA CSECT SPACE 15 ® THIS FILE IS VTRASA, GRA 4/96 * TRANSLATE TABLE FOR TSO/VTAM/NTO GRAPHICS OUTPUT * OL234567B89ABCDEF oc X 000 10203372026 2F 160R250B0COD0EOF ' Oo oc X' £01112199C30322618199F 27 1C10161F* 1 oc X' 404F 7F 7E6BGEC507D40606C4E 68604561! 2 Dc X FOF LF EF SF

4F GE GF 7FOF 97AGESCTEGEGF' 3 oc X'7OCLC2COC 4CBCEC 7CBC-90 LOZD304D608 * 4 oc 5 oc 6 oc ? oc ODE 8 Dc X%'101112133C30322618193F 271C10LE iF! 9 oc X' 405A7F 7BBBSCEO7D40606C4E6R604B61' A oc LE2F OF 4F GF GF 7F SF S7AGESCTEGEGF' B oc X* PCC LC2CSC4CECEC7CEC9INLO203040606' C oc XD 706096 2E 3E 4EBEGE TEES 79CF 498060 O oc X BF O .182630486968 78089919253949696' ¬ oc X' S79IBISAZAIAAABGAGATAGRIBE4FIBEFO7’ F END SREARESSERARERSREES SNARES ASSEREX BOTTOM OF DATA FRRERARERRALEREREERE-CAPS ON-9%

Figure 10. TSO Allocation

SRENERESSEARRARSE SAAR RELARKAREEER TOP OF DATA SAERORRASAABARA ERE EL -COPS ON- OK PROC oO 00030000 FREE F(SYSPROC) 00360000 ALLOC F(SYSPROC) DA(‘HCCKO16.CLISTS', + 00460000 "HCCK. TSPF .LIBRN.CLIST', + 00460000 *SYBC. TSOER. CONTROL ' + 00470000 "SYSB . SPF .ULRIMO. cLIB, + 00471000 *SY88.ISR.VLRIMO, ISRCLIB‘) SHR 00480000 SORAERRESETREARELOERERSESSSERESS BOTTOM OF DATA Shancananceecnnsanes- CAPS ON-85

67

VECTOR Vol.3 No.4

Figure 1],

CRRGERSEAAARSARE RRS RESEAEESESEESES DATA CKERRERERRERECREEREER-CAPS ON-28 PROC 1 O5N 00030003 MAIN MBB NOPROMPT 00040000, EJECT 00060000 CONTROL NOMBS NOPROMPT 00060000 ERROR OFF 00070000 BET SDQNAME = ISPF.FULLTSO.PROFILE.&SYSUID 00080000 BET &DSV0L = TEMO6 00090000 SET SD8UNIT = 3960 00100000 FREE _F (ISPPROF ) 00110000 ALLOC FICTSPPROF) DAC 'EDSNAME.') OLD 00120000 FREE F(SPFK) 00300000 ALLOG F(SPFK) DAH) 00310000 90 TO IPOF 00320000 ALLOT: ERROR RETURN 00330000 ALLOC F(SPFK) DA(#) 90340000 FREE F(VK) 00360000 FREE F (SYSPROC) 00360000 FREE F(ISPLLIB) 00370000 FREE F(ISPPLIB) 00380000 FREE F(I9PMIB) 00390000 FREE F(T9Ps1B) 90400000 FREE F (ISPTLIB) 00410000 FREE F (TePPROF ) 00420000 FREE F (8YSABEND) 00430000 CONTROL MBS NOPROMPT 00440000 ALLOC F(BYBPROC) DA(*HCCKO16.CLISTS'. + 00460000 "HOCK. ISPF.LIBRN.CLIST", + 00460000 BYBC. TSOEA. CONTROL, + 00470000 *BYSE.BPF.VIRIMD.CLIB',  00471000

Figure 11. CLIST <ENT> (continued)

*BYBD.TOR.VIRIMO.ISRCLIB*) SHR 00480000 ALLOC F(ISPLLIB) DA( 'HCCKOLS.TSPF.LOAD’, . 00490000 "SY8O, TBR.VIRIMO.ISRLOAD’,  SYBB.TBP.U1R1MO,ISPL.0AD') SHR 00510000 ALLOC F(TSPPLIB) DA(‘HCCKOIG.RPANELE'. . 00520000 HOCK SPF. LIDBRN. PANEL '  00630000 'SYBO.ISR.VIRIMO.ISRPLIB’, * 00640000 "SYB8.ISP.VIRIMO.ISPPLIB') SHR 00650000 ALLOC F(ISPMLIB) DA('HCCKO1E.MESSAGES*, + 00860000 HOCK . DSPF . LIBRN. MESSAGE *, . 00670000 'SYSB. ISR.VIRIMO, TSRMLIB', + 00680000 "SYBB.ISP.VIRIMO.ISPMLIB') SHR 00590000 ALLOC F(TSPSLIB) DAC 'HCCKOLS. SKELETON’, + 00600000 HOCK. ISPF.IBRN. SKELETON’, + 00610000 SYOB.TSA.VIRIMO, TSRBLIB’, + 00620000 SYSO.IBP.VIRIMO,ISPSLIB') SHR 00630000 PLLOC F(TSPTLIB) DA('SYSE.ISR.VIRIMO,ISATLIB’, + 00640000 "SYSG.TEP.VIRIMO.ISPTLIB*) SHR 00650000 ALLOC FCTBPPROF) DA('SOSNAME.') OLD 00660000 ALLOC F(8YSABEND) DUMMY 00670000 POF: ATTN OFF 00680000 EJECT 00690000

68

VECTOR Vol.3 No.4

ZSPSTART CMD(CEDIT) 0700002 FREE F(TOPLLIA) 00710000 FREE F(ISPPLIB) 00720000 FREE F (Tee. IB) 00730000 FREE F (IeP9LIB) 00740000 FREE F(ISPTLIB) O0750000 FREE F (ISPPROF) 00760000 FREE F (SYSABENO) 00770000 CONTROL NOMBS NOPROMPT 00780000 FREE F(Syeros) 00790000 ALLOC F(SYSP0S) DA('TSOEASY.4SYSUID..OATA') SHR 00800000 L21ERROR RETURN 00810000 CONTROL NOMBE NOPROMPT 00820000 EXIT CODE (0) 00630000 ND 00840000 SORRARESEEAERSSEEEEEEESSLESEREEX BOTTOM OF DATA SSSSRERSERRSERELESER-COPG ON- 88

Figure 12. CLIST <CEDIT>

SHSPESAAEERERESSSSRAAERAREEEREESEE TOP OF DATA ROESERAERERESEEAERRA-CAPS ON- OK PROC oO 00010000 TOPEXEC EDIT OATASET( 'HCCKOL6 .APL2.E0IT') 00020001 SERERSREAERSAROSARSAEREAEERREREA BOTTOM OF DATA 82085889 KES EEERRERE-CAPS ON-2E

Figure 13. The final result  editing an APL object

erences xeeeeeeeeeeeseeeseneoreessese DATA eeeeeseeesesexeeecesceececesss

98061 zens POLYFIT XY3A; LS IFAIL;K;NEXTL;P3S;W;W1 3W2;X37;010 APOLYMOMIAL FIT 00002 066003 Kei +DEG 000004 (X Y)exy 800005 Wel pX)pt f VEIGHTS 080000 W1+¢(3, 5X) 0 8 REQUIRED WORK AREA 880007

= W2+(2,K)00 @ REQUIRED WORK AREA 600008 ft (2pk 98 fA RESULTS AREA [1] 060009 fA RESULTS AREA [2] 900010 ie te A AREA £3] 900011 (A'S IFAIL)+EO2ADF(ex)K K XY WWI W2 AS IFAIL 960012 AFAL;KI ® REQUIRED COLUMN ONLY 900013 I+1 000014 Z+(pX) 50 000015 X+X XCAP1 eX # NAG NORMALISATION  600016 NEXTL: TL ( (eK) NEXT), Q goo! NEXT: (P_TFAIL) +O 960018 (PIF oE02REF K A XCEIP TFAIL

@NEXTLU +141]

seeeeeeeeececceeceeecesesees

69

VECTOR Vol.3 No.4

APL86 Debate  8th July 1986 APL Enhancements Don’t Help the Spread of APL Reported by Anthony Camacho

Chairman (Mel Chapman): It is traditional, so far as the Olympics are concerned, that the host nation is entitled to nominate a new sport at each Olympiad. The APL86 Committee are therefore exercising that right and introducing into the conference proceedings DEBATES. I think itis the first time that such a concept has found its way into an APL conference.

The motion before this house is APL enhancements do not help the spread of APL”. Mr Richard Nabavi will speak first for the motion, and will be supported by Mrs. Valerie Lus- more. Speaking against the motion we have Mr Steve S. chiavo supported by Mr John Myrna. I therefore call upon Mr Richard Nabavi to speak for the motion. Richard Nabavi: Mr Chairman, ladies and gentlemen, J must confess it was with very considerable trepida- tion that I accepted the invitation to speak in this debate on this side of the house in this par- ticular venue. As J look around the people who are sitting in this room today, there are cer- tain very well known faces in the APL world and I

feel a bit like someone who has been in- vited to host a wine tasting at a meeting of the Temperance Society. What we are going to say on this side of the house may not be very popular with certain people here today, but 1 believe it is very important to the future of APL and indeed may determine whether APL has a long term future as a working computer language.

Now if we have a wonderful product, a really fantastic superb wonderful product, which no-one buys then there is something wrong. And the temptation at each successive APL conference over the last seven years has been to say well the reason that no-one buys our product is because they are all stupid.” You only have to look at some of the snide remarks that are made about other computing languages at successive APL talks (and I must confess I have made the same snide remarks) to see that our attitude to the outside world is one which can be characterised by the word arrogant ,

Let me just briefly say what we mean by to avoid any confusion. We are not talking about file systems. We are not talking about having a decent error trapping primi- tive. We are not talking about good formatting routines. We are not talking in fact about all those good things that were done in the 70’s by 1.P.Sharp, $.T.S.C. and others. What we are talking about is what happened next which is the enhancements such as nested arrays, user defined operators, all those good things. In brief we are talking about APLZ2 and simi- lar products from other vendors.

Now J want you just to imagine a brief scenario. We are going to talk about something dif- ferent from APL. We are going to talk about a man who wants to buy a car. (J mean au- tomobile for the American contingent!) So he goes into his local car showroom, speaks to the salesman and says he wants to buy acar. Now when that happens salesmen are normally very pleased because people often come in saying they don’t want to buy anything. Some-

70

VECTOR Vol.3 No.4

one who comes in saying they do want to buy something gets a really good reception. So the salesman says Yes sir. What kind of car would you like?” The man replies I want a nice practical runabout just to go round town with the kids and the wife, do the shopping. I don’t do many long distance trips. I want something with space so I can put luggage in it when we go on holiday; something cheap to run; something cheap to insure.” So the salesman says Well we've got this fantastic Italian sports car. [tis really amazing and very very powerful. It will do nought to sixty in 5.6 seconds and its top speed is 160 m.p.h. And it’s really nice, look at it, isn’t it beautiful, isn’t it elegant!” The customer says Yes it is really beautiful, really elegant, I would really like to drive one of those some day. But actually what I am looking for is a nice runabout about town to go shopping with the kids.”

So the salesman says Electric windows  it’s got the lot! It’s got everything you want. Two seater, you can put a beautiful blonde next door and drive her off, and she will be really stunned by that!”

And the customer says That s great, but how much petrol does it use? Can I afford sure it? Where do I put the luggage? Where do I put the kids? Where do I put the wife when I’ve got the blonde in the front seat?”

So, not surpringly, the customer goes elsewhere and buys a boring standard old car. Now this story gets repeated again and again in car showrooms all round the country. Eventually the people who are trying to sell this product get the message  the customer is stupid! But they have got to react in some way so they go back to the R & D Department of the manufac- turer and they explain the problem, saying No-one is buying this car”, so the R & D people say Well we'll look at it” and they have got some really bright people, some of them sitting in this room. And they go back and they spend two years doing intensive R & D. They come back two years later, get all the sales people together at a big conference, maybe in Man- chester, maybe in Seattle, maybe in Helsinki, and they say We ve got it now  this one is really going to go. This one is going to answer all the customers’ objections to our product. Top speed is 164 m.p.h. and it will do nought to sixty in 5.2 seconds. Isn’t it powerful!”

Now it may seem that no-one is that dumb, but I believe that the APL world has been that dumb. You can hear it, in fact we have heard it today, people are talking about APL, about how much more powerful the new APL is. But the old APLis notanold APL, it’s not old hat, it is the most fantastic, exciting, amazing concept that the computing world hasn’t seen. It’s a brand new concept for everyone out there. Itisn’tan old APL at all, it’s a totally new unknown product which we are not selling to the outside world.

Now some of those things they say about APL we know are not true. (The customer is stupid!) But some of those things undoubtedly are true, and some of them are facts which cannot be denied. And what has been the APL world’s response to those objections? They have made it even more powerful! But despite the fact that they have made it even more have not made it any more accessible to the outside world. Now there is a theory  and let me emphasise that it’s a theory which I don’t subscribe to ~ that IBM is a

71

VECTOR Vol.3 No.4

great conspiracy machine that produces conspiracies that are hatched in dark rooms some- where in the United States. And one might think at first glance that APL2 was a conspiracy to stop the spread of APL. Of course I don’t subscribe to that theory, but you have to admit that the timing is very very suspicious. I mean just look at it: just as the ISO standard for APL becomes fully developed and fully accepted, after years of work, IBM say Yes but we are now going to move people from VS APL to APL2” which although it in theory conforms more or less to the ISO standard is such a radical extension that in effect it’s a new language.

And look at the timing in terms of hardware. It may be coincidence, no doubt it is, but just as APL becomes available on small cheap micros that schools can afford, we change the ground rules so that APL2 and its lookalikes are not available on the small cheap micros that schools can afford. Because, make no mistake about it, the facts used to be that you could take an APL program, develop it on a small machine, a PC, even a Sinclair QL, and with very few exceptions that identical code would work on a mini computer, on a large super- micro, and on one of those big blue main-frames; and vice-versa. We have had customers in the company which I work for taking VS APL code and running it on a £150 micro compu- ter.

Now it’s not just an inconvenience that you can’t do that with an APL2 system that uses APL2 features, it’s an absolute disaster! The reason it’s an absolute disaster is that you can- not really go to someone and say, We have this wonderful product called APL. Here, try it on this cheap micro.” And when they have tried it and got to like it turn round and say, Well actually we didn’t really mean that. That’s old hat, that’s ISO APL. What you really need is this wonderful APL2 product that can only run on a big mainframe.”

All you have to do is to return to the terms of this motion and just think what is actually hap- pening in the real world. We, on this side of the house, are saying that the enhancements to APL, typified by APL2 butalso on the STSC and I.P.Sharp interpreters, are not spreading the word about APL. Now that’s a pretty gloomy statement. I think it’s true however, and if we want a ray of hope, let’s look and see what is spreading the word about APL. Well Pll tell you. APL*PLUS PC has probably done more to spread the word about APL than any- thing else which has been discussed in these conference sessions. QL APL on small machines, other PC APLs, other cheap inexpensive micro APLs that are coming out— they are the vehicles which are going to spread the word about APL ifanything is. But APL2 and the large mainframe systems  all that’s happening there is that customers are migrating from VS APL to APL2. We are not getting new customers from that process; we are merely confusing the old ones.

So Mr Chairman, I would submit that we need to look at the real world, see what actually happening out there, and address the needs of the market, not what we think they ought to want. Chairman: I now call upon Mr Steve Schiavo to oppose the motion. Steve Schiavo: T enjoyed my learned opponent’s point of view and took a number of interesting points from it. I believe it is important that we clearly define what we mean by enhancements and what

72

VECTOR Vol.3 No.4

is the base upon which we are building enhancements. I believe that’s made even more important, but if we can extend Richard’s analogy about the automobile (the car for those of you on this side of the ocean), the runabout he described that the chap was trying to find down at the local car dealer did exist in a number of cases and does exist in some cases today, in some of the terms that he described it. But the kind of enhancements we propose and Kind of things that his prospective auto manufacturer was installing are two different things. The kind of enhancements which we have installed in our line of business . are not simply the things to make his car go 170 m.p.h. They're to overcome certain inconveniences and offer additional conveniences beyond those described in the little runabout. For example some of the inconveniences in this little runabout are that its windows don’t open, the fact that it has a roomy back seat but there is no way to get in and out of it. More importantly the little runabout that is available now, and has been for a long long time, gets about two miles per gallon. Now one might presume to take it upon oneself to improve that and actually tinker with the engine a bit but when you attempt to do so you find that the hood is welded shut. All of which I believe leads us to clearly understand amongst ourselves, what do we mean by the enhancements. To start with, what is the base from which we are enhancing? I believe the base we talk about depends on what period of time we are talking about. It began some time ago with something called APL\360. For most of the 70s, and the 80s so far, it was a VS APL. In the 90s, possibly APL2, possibly APL PLUS, possibly a combination of one or the other or both. The enhancements that I’m describing I will limit to. .. modifications to the interpreter that add function for the APL user. I think the things we are talking about do include the file systems of various vendors, such things as CALL AP that extend also the environment and scope for APL users, SQL DS interface of APL2 and others, Sharp’s packages, various . . . tasks that include interfaces to the rest of the world  I consider those to be enhancements. For the purpose of this discussion what I will not consider to be enhancements (and you may argue but I wish you would defer it until I’ve left the country) I don’t consider ports to different computer hardware with no additional function to be enhancements  it’s just taking the same environment and moving it around. It’s certainly of value to the market place, Lord knows it’s been of value to us, but it’s not an enhancement to the language. I certainly don’t consider additional functions written in the language itself to be enhancements; those are merely conveniences which the customer could himself have written. And

finally what do we mean by the premise: have we spread the market, are more people using it. I think it’s important that we are able to take credit for a net improvement in the market over what it would have been if there had been no enhancements,

We see the world in four classes of people, if you would visualise a little two by two matrix: those who know APL and use it; those who know APL and don’t use it; those who don’t know APL and don’t use it; and a growing class of people who don’t know APL and do use it  the way I describe the premise sounds strange but I do seriously include in this class the vast number of people who use applications created in APL and neither know nor care that

73

VECTOR Vol.3 No.4

itis written in APL in the first place. And that number is definitely increasing. I think all we need to do to demonstrate our side of the case is to argue whether movement amongst that two by two array is in our favour or to our detriment.

For example are there more people who know and use APL than there would be without a share file system, without a formatter? There are certainly more than there would be without a compiler  several of us in this room know of projects where APL would not be used today were it not for the availability ofa dramatically less expensive more efficient user of CPU time.

Secondly are there more who use APL but don’t know it than there would have been otherwise? Those are those who are using the applications and did nothing to write them and don’t know what is inside them. Are naive users running APL applications today that would not have been written in APL withouta fully featured error handler; without a secure multi-user file system; or without PC specific graphics and screen handling enhancements? You'll remember, to be precise, I don’t consider simply moving the language to another piece of hardware an enhancement, but certainly a language that takes unique advantage of the additional features of that new hardware could be construed as an enhancement. Let’s talk about a net improvement to be gained by reducing the rate at which people exit APL: have fewer of those who know APL and not use it, have given up on using it. Fewer sites or applications have moved out of APL than would have done so without enhancements, I believe. I know of at least one firm which extended the life of its APL installation only because they were able to reduce the burden on the system by the use of certain important enhancements. And there are many sites who have fled the high cost of their APL timesharing applications, intending to re-write them in-house in some conventional language, only to re-write them on micro-computers in any of the wide number of enhanced APLs now available, with additional user-friendly features such as screens, graphics and so forth and all at a fraction of the original cost.

Finally, have fewer applications migrated away from APL because of the enhancements? Who could argue that enhancements have done nothing to persuade those using functional APL applications to avoid the costly conversion of their old systems? In fact their numbers are increasing even as we speak. STSC has many affiliated re-sellers, and 1 am sure a number of the other companies represented in this room have, who create and sell commercial applications as a business based on APLs that did not exist a few years ago. And their competitive advantage, those resellers, is based upon the speed and efficiency and user-friendliness provided not by the base APL systems but by an enhanced APL.

Meanwhile, more vulgar languages of the common people adapted to the day to day usage. They added an alspufen here and a tickety-boo there until they had enriched the language to an extent that they could make use of it everyday in everything that they did. It was no longer consigned to a small corner of their life for describing obscure species of plant life. It was no longer used way to set themselves apart in an esoteric conflab of like minded academics. It was used to conduct their daily work; to conduct their daily lives, and it expanded across what is now the whole industrial developed world. And that’s what we

74

VECTOR Vol.3 No.4

would like to see come of meetings of groups like this; that’s what we would like to see come of enhancements and continuing enhancements and continuing diversity and continuing arguments. Sometimes it’s useful to discuss how many angels can dance on the head of a pin, although I think we would be much better served if we were to gather our strength and begin to tell the rest of the world why we have committed so much of our own resources and attentions to this language. Mr Chairman thank you. That concludes my point. Chairman: Thank you. I now call upon Mrs. Valerie Lusmore to speak second for the motion.

Valerie Lusmore: I find it quite ironic in a way that | suppose if I was still working for my first employers in APL, I would probably be sitting on the other side of the house, because I worked for many years for Sharp’s in the stages when they were doing what I would call the original enhancements to APL. I came in at a base level where APL had what I would call the two basic and original enhancements, the formatter and the file system, which we would perhaps not consider enhancements but necessities. Without those I think APL would never have spread at all. Without those it would have been so difficult to do anything that nothing would ever have happened. Have I gone to the other side? No. ... I left Sharps. I went out in the real world. And, like many of us in this room, I thought APL was so marvellous that we wouldn’t really need to sell it. That’s a classic mistake we have all made. APL has spread despite the fact that most of us do not sell very well because we feel that something so obvious  yes, the customer is stupid! He must realise the advantages of this wonderful tool, after all if I find it a marvellous tool it’s quite obvious the customer should discover it’s a marvellous tool. I’m afraid the customer doesn’t understand that at all ~ he says Tough. I can buy this, that and the other, and I have a salesman dancing in attendance.” I think what would help is if we got our act together with the marketing; if we took things out there into the market place. In the times that we have sat here, all of us talking to ourselves, and we are still talking to ourselves, we haven’t brought in very many people from the outside world to this conference. After all this is our private time away from the rest of the world. In that time, if we had put as much effort into spreading the word outside as we have put into improving things inside for ourselves, we could probably have doubled what is going on, and ensured actual continuity. But the market place is outside and if we followed through (there's a very nice little phrase that I have heard in some of the literacy campaigns and I think we should adopt it for ourselves; and because it’s APL we could each do it twice a year.) If we went into this and said Each one, teach one” we’d be taking that out into the market place. We wouldn’t be staying in here. We wouldn’t be sitting here arguing about whether we can nest arrays or turn things upside down or whatever else. We would be going out and spreading it and I think that’s what will spread APL, not us all staying here. And I would ask you to look at that Mr Chairman and say because it’s APL Each one of us, teach one twice a year. Each. Two rho.” Thank you. Chairman: May I now call upon Mr John Myrna to speak second against the motion.

75