IBM GSE and APL Club Germany

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

As always, this was a well-organised and well-attended meeting (around 40 people were at most of the sessions). It was primarily an APL2 group, and it is also worth noting that Germany is a real stronghold for OS/2 so there is genuine interest in the progress of APL2 for OS/2.

I have detailed notes on two of the sessions: Timo Laurmaa demonstrated a number of TCP possibilities with APL and Netscape, and Dave Liebtag (IBM) showed a fully working APL2 interpreter under Windows 95.

Timo Laurmaa on TCP/IP and APL2¶

Timo began by showing how Netscape can be used as a front-end to an APL mainframe system. He made an early entry for the 1996 bad pun contest by demonstrating that the HTML construct <lieb> some text </lieb> has no effect — Netscape does not understand Liebtags (groan). He was very much focussed on the idea of an ‘IntraNet’ — an internal company network where there are no security problems and everyone has a high-bandwidth connection. Also corporate users are very happy to register for mass copies of Netscape which they see as virtually free. It gives them the possibility of standardising the user interface across a huge variety of applications.

He continued with some background on TCP/IP which he compared to shared variables except that anyone can talk to anyone once they understand the low level calls. Once you have established a connection to a TCP/IP node address, you find the HTTP ‘port’ is conventionally numbered ‘:80’ and the combination of address and port forms a ‘socket’ which the server opens and listens to. If it is an APL application (using AP119) it looks for a stream of characters like '|GET| ~~~~ |HTTP1.0|return' which is how Netscape begins a request. APL can now parse the remainder of the request which is essentially the string you see in the Netscape top line when you submit a query to a server such as Alta Vista. It can do whatever processing is required, format the results and write them to the socket wrapped in standard HTML.

Note that the server will close the socket after every request, which allows thousands of ‘simultaneous’ users, as sockets are occupied for a very short time — very different from an FTP connection where a user keeps the link active all the time. This ‘sign-in-sign-out’ model makes it impossible to ask for passwords as the server has no means of knowing that a following transaction has anything to do with a previous sign-up!

Timo ended with a demonstration of Netscape ‘evaluating’ APL expressions — simply type HTTP://.../aplserver/2 3⍴⍳6 into the top window (of course the APL characters present some problems) and see the result displayed in the browser window below. He handed out a couple of pages of quite simple APL code which implemented this facility on an APL2 mainframe.

Dave Liebtag on APL2 Future Directions¶

Dave began with a summary of the improvements made at service-level 7 of the OS/2 product. Some of the highlights were:

• some new ⎕ functions such as ⎕WSID, and also you can now fix functions with ‘illegal’ ⎕fns in the header line — a major migration aid!
• you get some warnings when closing, for example, the session manager.
• the editor now understands APL tokens.
• cross-system ⎕SVO is much easier to set up as you can now use the domain names and AP119 will translate these to addresses for you.
• some new GUI objects such as timers and DDE support.

In the afternoon, Dave approached the podium again, with a considerable show of reluctance .... "Well, I hate to say it ... this is my machine and it’s running Microsoft!"

• I think this is what you want — let’s see what happens if I click on it!

Dave gave us a quick tour of APL2 running under Windows 95, essentially he was able to show us a complete interpreter running in a very reasonable session window, with a function editor also fully operational. He then paused to ask the audience a series of questions, designed to find out how much more is needed to make this a marketable product, and whether there is sufficient market to justify the work.

1. I need to know about the Gui facilities. Providing AP124 all these years has been fairly expensive. Gui applications are not going to fly in AP124 anyway!
2. AP207 — the general graphics processor. This works now, but comes up as a separate window. We could do more — events and so on — but do you really need AP207 the old way?
3. Co-operative processing with ⎕svo. The vast majority of customers are not using it — do we need to do it?
4. What about AP127? DB2 is not there any more, so what do you want. Do we connect specifically to Oracle or do you need ‘everything’ via ODBC?
5. Communications inside the machine: DDE, OpenDoc, OLE. What do you need?
6. Language questions. Do you want true, blue APL2 or a system that would be easy to migrate to? Do we need namespaces, control structures, commute, rank, set-union and so on? What do you want in the interpreter?

So far the project has taken 7 weeks from ground-zero to what you see. Do you need a Gui interface at all? We can already call the interpreter as a DLL, so why not use another tool for the interface — I will never be able to catch up on Visual Basic and your finished application will never look ‘quite right!’

Currently this is headed for Windows 95 and Windows NT. If you only care about one of the above, let me know. Windows 3.x is not an alternative.

Dave got some quite clear answers, but of course this was a very stratified and self-selected survey! Yes, they want AP124 (people want to do off-line mainframe development) but no one needs AP207. Database access should be ODBC, but a reasonable minority wanted high-throughput Oracle access as well. True-blue APL2 is fine. Unfortunately for Dave, there was a solid vote for carrying on chasing after VB — virtually everyone wants to do their Gui programming in APL and no-one was willing to risk the alternative of programming in VB, Delphi or C++ and just calling APL to do the hard stuff. As you would expect, both 95 and NT are requirements.

I really hope this happens, but I have seen APL2 interpreters under Windows before (at least 5 years ago) and IBM politics always killed them at birth. If you need to downsize a mainframe system, what more APL2-compatible interpreter is there? Why should you have to struggle with all the gotchas listed by Rex Swain in the last Vector? Just )out, head for your Windows NT box and )in. There has to be a market out there, and it obviously isn’t on OS/2. It would be a terrible pity if APL2 died just as APL+Win and Dyalog finally approach full compatibility with it!