APL+Win Application Migration
Vector 17:2, page 112
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 112
31 July 2000
This response is prompted by ZarkWin: Windows Programming without ⎕WI by Gary A Bergquist and Taking the Migraine out of Migration by Walter G Fil which appeared in Vector Volume 17 Number 1.
My point is that successful migration is not that simple.
Which applications do the authors have in mind?
Is it APL*PLUS/PC, or APL*PLUS/PC applications already migrated into APL*PLUS/386, or applications developed in APL*PLUS/386? In other words, is the screen interface for data entry based on ⎕INKEY as in earlier versions of APL*PLUS/PC or on ⎕WIN as in later versions of APL*PLUS/PC and APL*PLUS/386? Is the screen image based on a 24x80 character array or based on ⍞ or ⎕?
How do these applications store the data entered on the screen?
Typically, the popular approaches were either to use a segmented string for each screen where each segment occupies one variable/slot or to use double segmented strings where each screen occupies a first level segment and its content occupied the second level or to hold each entry on all screen in one huge character array where each screen had an absolute start and end row and each entry on each screen corresponded to a particular row.
That is, either as
or
or
Therefore, each screen and the content of each screen could only be established by a hardcoded system of dead reckoning. The insertion of a new screen or a new variable in any screen or the relocation of a variable on a screen involved not only the changing of all those dead references but also a major migration task to remap the existing arrangement to the new.
And, when an application required recurring data further dead references are needed. For example, if the application could track n service period defined in terms of m variables, say DateJoined, DateLeft etc., these variables would be referred to as (m-1)+row/segment 1 for DateJoined in service period 1, (in index origin 1) etc. All of this would be buried in the calculation engine of the application.
Do these applications have a menu system?
I dare say they do. There would be little point in migrating a one screen application.
Therefore, each screen would be displayed exclusively, requiring the user to go back and forth.
Each screen would also be self contained in the code that defines it: this includes lists, defaults, validation, error messages etc.
To what extent do the existing applications contain code to manage the inherent limitations of the interpreter and/or the operating system used?
Typically,
- application code always assumed the current directory or a directory referred to by a library number
- file input/output was necessitated by the size of the workspace
- printing was highly customised within APL, not least because of APL characters.
The application development cycle.
Consider the application development cycle. It is Program, Test, Debug, Document in the first phase and Maintain, and Evolve in the second phase. Migration is subject to the same development cycle except that it necessitates another cycle, namely, Integrate.
It is well established that phase 2 is the most expensive in the application life cycle.
The articles seem to suggest that phase 1 is all that is required and all other things are constants. Not so. At least not so without serious loss of credibility.
An application using the features of APL+Win version 3.5 makes a comparable one written in version 3.0 look dated. What of an application that looks and feels like a DOS APL application?
The migration route suggested still incurs all the overhead of phase 1 with the possible exception of the Document cycle (typical APL approach) but fails to realise any of the potential benefits and does not consider phase 2 at all.
Consider the missed opportunities:
Moving the screen input variables outside the application, say to a spreadsheet where all the properties/characteristics are defined, thereby allowing easy maintenance (in terms of tracking duplicate names, ensuring consistent validation, error reporting etc) of the ‘Input’ segment of the application.
Usage of the selector interface, housing each screen on a separate tab thereby allowing open access to any screen at the click of a mouse.
Holding the values entered in named variables which retain their inherent type, such as numeric, date or character.
Usage of third party ActiveX controls such grid objects to provide a intuitive interface to the user, particularly for recurring items such as the one for service period described above. Usage of nested arrays is an inherent part of this.
Usage of the operating system in two critical ways, namely resources and API calls. For instance, using the Windows printing facility allows the selection of printers on a network (including their particular facilities such as duplex printing) can be available without any programming overhead other than the call. The call to the CharUpper API is far more efficient that any equivalent in APL.
Usage of other resources on the computer, such as COM objects for sending/receiving data to/from standard applications. Something like WORD and EXCEL print and present data far better than APL.
Usage of control structures to make program flow more visible and self documenting.
Usage of a more modern idiom library such as IBM’s is far more programmer efficient and powerful than, say, the original FINN APL idiom library. Refer to the algorithms for formatting without leading or trailing blanks, for instance.
Conclusion
In my view, a legacy system is neither the specification nor the boundary of a Windows application, it is simply the test bed.
The key to a successful application is integration with the platform it runs on and with the applications it co-exists with. The efficiency of that application is in using the features of the tool it is written with, and not in maintaining the quirks of previous incarnations of that tool.