Skip to content

IBM-based APL communications

Vector 1:1, page 62

system interfaces

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 62

The specific example Tim used was of an IBM factory with around 2000 employees, and 1300 terminals. A combination of APL and VM/CMS was expected to support a growth path like this:

                       1983      1984      1985
Mainframes       :       3         5         3
Versions of APL  :       3         4         1 (APL2)
Users            :     200       400       600
PCs              :       2        35        70
Cost/Unit        :     100        50        25
Units/hr         :     100       180       250

i.e. a four-fold reduction in the cost of a unit of computing, with a similar increase in the amount of useful computing achieved per logged-hour. The use of VM/CMS was seen as vital, in that it gave APL a consistent environment across the board from the PCs to the biggest mainframes, and thus facilitated communication between APL systems and also between APL users. If need be APL could use the power of CMS or CP to send messages worldwide, look up someone’s address in the global phone directory, or access a host of other useful software which Tim could only hint at (it being somewhat internal to IBM).

Tim dropped a number of interesting hints about the way you can put some go-faster stripes on your APL, for example by giving it a fixed chunk of memory to run in, which all users share. This has the beneficial side effect of making all 200 CMS commands available (not just the usual subset). He also emphasised the need to restrict the user base so that good response times were always guaranteed — programs like FRANGO need to be watched very carefully lest they slow everyone down.

Other simple things you can do include:

  • using the CMS stack to get at the output of CP commands (such as Query Time) for genuine information on resource usage.
  • making sure you use the best AP for the job in hand (generally AP110, but look for AP999 which is well hidden in the small print, and is 25 times faster than AP111).
  • using PGF or (even better if you can get it) Chart for your graphics. The new AP126 lets you call Chart (or the ICU to its friends) direct, and it also allows you to call back pictures off file and get a sensible result when the FSSHOW is terminated. This lets you build a very effective (and rather cheap) Prestel imitation complete with top-quality graphics.
  • going for big workspaces (1.5 to 15 Mbyte), but keeping the maximum object size below 64K.

All of which is helping to make APL increasingly useful as a communication tool for people. The use of online help and news means that any piece of useful software (be it good or awful) gets quickly spread around the system, while the availability of standard packages (ADRS/ADI) also helps users to swap data and ideas around.

In conclusion, if you are serious about the idea of management support via computers you need APL, VM/CMS (preferably plus classified bells and whistles), and someone to put quite a lot of effort into tweaking the system. Given these conditions, the resulting system can be very effective, and surprisingly efficient.