Migration to APL2
Vector 2:4, page 123
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 123
The National Westminster Bank has one of the largest data-processing facilities in Europe and runs MVS/XA with TSO for end user computing requirements. Two centres, one in London and the other in the Midlands, are utilised with the majority of end user computing carried out at the Midlands Centre. Use of these facilities by non-DP staff is made using high level languages such as PL/1, SAS, GIS and APL to produce management information. Many of these APL users are business analysts with very limited knowledge of the TSO system as a whole, but have found VSAPL fits their requirements for a programming language in that it is easy to use, interactive and allows a level of flexibility not available with other languages. The decision to upgrade operating systems from MVS/370 to MVS/XA would impact all TSO users, but especially those using APL
The decision to install APL2 followed directly from the decision to install MVS/XA. APL2 would not only exploit the advantages of XA but would also offer access to SQL/DB2 ( a database management facility) and ISPF ( a panel driven development system used widely throughout the Bank) via two new auxiliary processors. It also promised a full Nested Arrays implementation along with workspaces up to 128Mb! The installation of APL2 on the first of the Bank’s two TSO systems which support APL users was carried out as soon as all prerequisite products (GDDM, ISPF2, etc) had been installed.
It was decided that APL2 would completely replace VSAPL when the switch from MVS/370 to MVS/XA was made. This entailed the migration of all VSAPL workspaces already written and those under development to APL2. Due to the urgency placed on the implementation of MVS/XA, the short-term migration procedure would entail making only the changes essential to allow the workspaces to run under APL2. The migration procedure was further complicated by widespread use of AP124, an auxiliary processor unavailable under APL2 which was used in all VSAPL applications which access full screen panels. Any such workspaces would have to go through a further migration step in which all references to AP124 would be replaced with corresponding calls to AP126 (the Graphical Data Display Manager auxiliary processor). Although AP126 was available under VSAPL, GDDM had not been installed due to the fact that AP124 offered a viable alternative and GDDM was not a prerequisite of VSAPL. However GDDM is now required to allow use of the new fullscreen APL2 function/variable editor.
Under VSAPL, users were allocated a partitioned dataset (PDS), named as ‘userid.A.APL’ where ‘userid’ is the users unique logon identifier. In this PDS, users were able to permanently save private VSAPL workspaces by copying them from their loadable form (‘userid.APL.wsid’) as created by VSAPL to a partition in the A.APL library. The reason for the use of a PDS for permanent workspace storage is based upon system limitations. All TSO users are able to write datasets (including APL workspaces) to several of the many 3380s allocated as TSO workpacks. These workpacks are cleaned up daily by housekeeping compress jobs which delete any datasets on these packs which have not been placed into the housekeeping exceptions listing. Such housekeeping is essential to free required storage available for use by other TSO users. By copying APL workspaces from the TSO workpacks to the users own PDS on a permanent pack, space is freed on the overloaded workpacks. The use of project libraries create a dataset ‘userid.APLnnnn.wsid’ where nnnn specifies the library number. A dummy entry is also placed into the master catalog ‘A.APLnnnn.userid’ to allow VSAPL to cross-reference library number ‘nnnn’ to the correct ‘userid’.
For APL2 implementation, it was decided that all APL users would be allocated an A.APL2 PDS in which the user could store APL2 workspaces. This would allow users to have two copies of each APL workspace (one VSAPL and the other APL2) for the duration of the migration, when both an MVS/370 system with VSAPL and an MVS/XA system with APL2 would be available. The APL2 options module was modified for our installation so that the APL2 workspaces would be )SAVEd as ‘userid.APL2.wsid’. When the VSAPL option module was attached to APL2, )MCOPY was able to reference workspace datasets set up by VSAPL directly. The next step along the migration path was to decide upon the method for APL2 invocation (CLIST, ISPF, etc). Over the past ten years since VSAPL was first installed, each user section has developed its own standards for entering VSAPL, and copying workspaces to and from the aforementioned PDSs. To attempt to force users into using any new centralised methods would only have caused further confusion within these departments. Upon making the decision to allow users to continue to access APL2 in the same way as VSAPL, the details regarding APL2 invocation were dispersed to users in a series of meetings and technical demonstrations.
Once user migration had started, the migration of project/public libraries began. At this stage, a major change to previous VSAPL strategy was made. Under VSAPL users were allowed to create new project libraries virtually at will. This led to libraries being allocated which in some cases were never used, or only used for a limited period. Just prior to APL2 installation, a study showed that of over eighty project libraries allocated, only seven were in use. Control of APL2 project libraries would now fall under the direct responsibility of an APL2 ‘system administrator’ who would allocate the required datasets for project libraries. The use of VSAM datasets to store project libraries was selected. This would remove the requirements for separate datasets for each workspace in a library and the dummy entry in the catalog. The only drawback to this method is that users have to allocate required libraries as follows:
This method was also applied to the public libraries. Once all the required public libraries had been built, users were able to begin migration in earnest.
APL2 )MCOPY used in conjunction with the TRANSFER workspace became the standard migration tools. Users would initially copy the required workspace from their APL PDS to a VSAPL loadable dataset (‘userid.APL.wsid’) which could then be )MCOPYd directly into APL2. When the required amendments to code had been made, issuing a )SAVE wsid would set up a ‘userid.APL2.wsid’ dataset which could then be copied back into the user’s A.APL2 PDS.
By the time migration was completed on the first of the Bank’s two TSO systems supporting APL,it was noticed that time required for workspace migration varied greatly upon the style of VSAPL code. Workspaces which had been well designed and written using a modular approach were found to be very easy to migrate. However workspaces which had direct access to APL124 contained in user written functions instead of using the standard FSM routines took considerably longer to migrate. At this stage, a difference between VSAPL and APL2 was noticed which was not mentioned in any of the IBM manuals. Under VSAPL, if a variable offered for sharing with an auxiliary processor did not contain a valid initial value, the default was assumed. Under APL2, if a variable shared with an AP contains an invalid value the variable is not shared successfully and will return a code of 1 whenever accessed. This problem was heightened by the shared variable offer returning a successful completion code so the error could only be spotted by detecting incorrect results being returned when using the AP.
Usage of APL2 during this initial migration period proved that APL2 was a relatively bug-free product. However the APL2/ISPF interface (one of the major enhancements) failed to work. At this stage it was pointed out that although a new ISPF release (2.1.1) had been installed for MVS/XA, the APL2/ISPF interface required ISPF release 2.1.2 which was not made clear in any documentation received from IBM. After receiving and installing ISPF 2.1.2 in record time, it was then discovered that no documentation regarding the interface could be found in either the ISPF or APL2 IBM manuals. Nor could IBM find any of the required manuals in their libraries, but IBM did find a solution. Along with the new release of ISPF, a load module was included on the ISPF load library (ISPAPAUX) which contained the missing auxiliary processor AP317. Also included with ISPF 2.1.2 was an APL2 Transfer Format of a new workspace ISPFWS. This workspace contains a single function which allows access to ISPF from within APL2 by just passing an ISPF service string to the function. In addition to this, a new parameter had been added to ISPF with this new release which is required on the APL2 invocation step. Once this solution had been found, the migration of the second TSO system could begin.
The majority of APL users are based at this second centre. For many APL users who used a financial modelling function, the migration involved a straight )MCOPY of their existing workspace followed by a )COPY of the new version of the modelling workspace. For other more experienced APL users, the same problems that had occurred on the first system recurred. It was at this stage questions began to be raised regarding EDITOR 2, the new fullscreen editor. Although the new editor offers some interesting new facilities (most noticeably the ability to split the screen while editing functions) the removal of the command line seemed to confuse many users. Also the new editor places a large number of entries into the SYMBOLS table and can even be crashed with an index error if deleting and concatenating lines at the same time.
Some deterioration of performance was noted under MVS/XA. However due to environmental constraints it was not possible immediately to go single image at this stage. However after some further investigation one of the sources of the poor performance was found to be APL2 itself. When users began to use large APL2 workspaces which could not be self contained within their logon region size, storage ‘above the line’ was accessed as designed. However, this produced a large amount of paging and a single APL2 user was able to take over 60% of the systems paging capacity. In an effort to reduce this ‘above the line’ access, users were requested to limit their workspace sizes to be within their logon region size. The facility for accessing larger workspaces is still available, but if it is used the user will experience longer response times than other APL2 users. The request for the limiting of workspace size has had the desired effect by improving APL2 performance to a level comparable with VSAPL.
At the time of writing this article, migration has been completed on both centres. The migration has highlighted not only the advantages of well written modular code but has also allowed users to review their use of APL. The next step of the conversion to APL2 is for APL users to become aware of the new facilities offered by APL2 and use them to rewrite migrated workspaces which would benefit from use of ISPF, Nested Arrays, SQL/DB2, etc. These new facilities have also created interest in APL2 from users of other languages. In particular the simplicity of the APL2/ISPF interface has attracted attention from non-DP users using PL/1 who have shown that panel driven systems are much easier to write using APL2. The migration from VSAPL to APL2 took over five months to complete, but the process of learning to exploit APL2 to its full potential will take longer with significantly more emphasis placed on design.