| The following was taken from the APL VAXnotes file, and shows that Digital APL
has some significant advantages.
<<< TURRIS::NOTE$:[NOTES$LIBRARY]APL.NOTE;2 >>>
-< VAX APL Notes File >-
==============================================================================
==
Note 160.1 VAX APL VS STSC - COMPETITIVE ANALYSIS 1 of
2
SPGOPS::HARBOLD 1716 lines 10-MAY-1989
16:27
-< THE FULL ANALYSIS - 34 PAGES >-
------------------------------------------------------------------------------
--
________________________
May, 1989
The information in this document is subject to change without
notice and should not be construed as a commitment by Digital
Equipment Corporation. Digital Equipment Corporation assumes no
responsibility for any errors that may appear in this document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with the
terms of such license.
No responsibility is assumed for the use or reliability of soft-
ware on equipment that is not supplied by Digital Equipment
Corporation or its affiliated companies.
� 1989 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
The following are trademarks of Digital Equipment Corporation:
DEC MASSBUS VAX APL
DEC/CMS PDP VAXcluster
DEC/MMS PDT VMS
DECnet RSTS VT
DECSYSTEM-20 RSX VT320
DIBOL UNIBUS
IAS VAX DIGITAL
This document is an unpublished work which contains confidential
and proprietary information of Digital Equipment Corporation, and
is protected under the copyright laws. The existence of the copy-
right notice is not to be confused as an admission or presumption
of publication. Unauthorized copying is prohibited.
RMS is a trademark of American Management Systems, Inc.
Selectric is a trademark of International Business Machines
Corporation.
IBM is a registered trademark of International Business Machines
Corporation.
This document was prepared using VAX DOCUMENT, Version 1.1
Digital Equipment of Canada Limited
100 Regina St. South, Suite 370
Waterloo, Ontario
N2J 3A9
519-746-5427
March 31, 1989
DIGITAL
Sam Harbold
DIGITAL EQUIPMENT CORPORATION
Maynard, MA
Sam,
The APL evaluation at Prudential Assurance is proceeding as
planned and we have retained an APL consultant from the Kitchener
area who has some experience with VAX APL. He is helping the cus-
tomer convert programs from VS/APL on the IBM machine to VAX APL
on the VAX 6310. He has previously done a conversion at another
local insurance company from the APL product that ran on the
DECSYSTEM-20 to VAX APL and he understands the conversion issues
and where we may get into trouble during a conversion.
He is contracted to Digital and I am directing his work at
Prudential and helping him solve problems encountered during the
conversion. He has prepared the attached report for me that de-
tails some of the differences between our VAX APL and the STSC
version of APL. I intend to document the conversion issues so that
you will have an understanding of what's involved in converting
DIGITAL INTERNAL USE ONLY 1
from IBM VS/APL to VAX APL. This will be forwarded to you at the
completion of the project.
If I can help in any other way, please let me know.
Sincerely,
Brian Cochrane
PRUDENTIAL ACCOUNT CONSULTANT
BC:jb
2 DIGITAL INTERNAL USE ONLY
A Comparison of VAX APL and STSC APL
for the VAX/VMS Environment
As a result of a pilot project undertaken by Digital Equipment
Corporation at Prudential Assurance, an opportunity was found to
compare VAX APL and STSC APL*PLUS for the VMS environment. This
document was prepared for Digital Equipment Corporation and is to
be considered confidential in nature as outlined by our agreement.
The report consists of four major sections:
1. Executive Summary
2. Session Management Facilities
3. File Systems
4. Language Implementation
DIGITAL INTERNAL USE ONLY 3
Prepared by Merlin Consultants Ltd. - 89 March 30
4 DIGITAL INTERNAL USE ONLY
1. EXECUTIVE SUMMARY
The VAX APL and STSC APL implementations have some major differ-
ences with respect to:
A. Session Management Facilities
B. File Systems
C. Language Implementation
The Executive Summary conveys only a terse comparison of these
implementations with respect to these three areas of concern. If
you wish to develop an understanding of the differences, I highly
recommend that you review the detailed sections of the report.
A. Session Management Facilities
Session Management is subdivided into three categories of use.
i Interactive and Program Development Use
ii Productive Usage
iii Batch Processing Usage
i. Interactive and Program Development Use
In this part of the implementation STSC APL tends to shine. It has
a relatively sophisticated editor that allows you to edit charac-
ter data and functions simultaneously. By the way, the active APL
session log is considered to be character data. In the interac-
tive session, you are allowed to move the cursor to any line in
the session, modify the line, and execute it. This technique is
very important when you consider that software developers have a
need to create, test, and modify experimental statements as part
of their development task. The ability to collect the successful
DIGITAL INTERNAL USE ONLY 5
experimental statements from the session log and include them in
the definition of a program can only be viewed as an excellent
productivity tool. This can affect the product development effort
by as much as 10%. The only drawback is that the user must learn a
set of commands that can be applied only to this APL environment.
The character sets available for STSC APL do not recognize un-
derscored alphabetics. This means that they must be mapped into
lower case characters for conversion purposes. This is not a major
problem.
The keyboard layout provides for logical programmable func-
tion keys. In a VT320 environment, these are not well placed by
the implementors. They belong on the application keypad where
one keystroke can activate them rather than being activated by
pressing a function key and a standard keyboard letter. In addi-
tion, the backspace key does not appear to act as a destructive
backspace.
The VAX APL session manager is the same one that was used 15
years ago except for three significant upgrades. This means that
it requires upgrading that would involve between 3 and 4 man-
months of effort. This includes a month for documentation, a
month for design, and a month for implementation. The VAX APL
session manager allows the user to enter, edit, and execute an
experimental statement all on one line. You can also recall the
previous line that was entered using the up arrow key. It also
provides access to a full screen editor for editing character
and numeric data and functions. Fortunately, this is the same TPU
editor that is used in a system-wide sense. Thus the user only
needs to learn to use one editor.
Half of the keyboard layout is inaccessible. The entry of com-
posite characters is awkward but passable. Although underscored
alphabetics are accessible, the more important lower case alpha-
betics are not accessible through the keyboard. The function keys
on the application keypad are not supported.
ii. Productive Usage
6 DIGITAL INTERNAL USE ONLY
This is basically an environment where the user of the computer
system has no knowledge of APL and does not really care what
language was used to implement the application. It is perceived
that the user is comfortable with windowed data entry approaches.
STSC APL allows the software to examine each keystroke made by the
user and to take the appropriate action. The software may read or
write to a variety of windows on the screen. Character attributes
may also be assigned to characters in a window.
It is important that STSC APL for VMS not be confused with STSC
APL for the PC environment. There is absolutely no comparison and
the VMS product is sadly lacking most of the screen management
tools available for PCs.
VAX APL does not really provide any tools for a windowed envi-
ronment. DEC does however provide the Run-Time Library Routine
for Screen Management. For the tenacious software developer, this
routine provides a doorway to a very sophisticated and general-
ized system for controlling masks, windows, and scrolling images
that can match any conceivable windowing system. The routines
are accessible to APL and can be molded into a valuable screen
management system.
iii. Batch Processing Usage
Batch processing provides a way of utilizing the available pro-
cessing power to its fullest. Tasks that are executed in these
queues can be assigned to a lower service level than interac-
tive tasks. This effectively means that any processing time left
after interactive users have been serviced is used by the batch
tasks. Batch processing also allows tasks to be scheduled dur-
ing low usage time. It also creates a processing environment that
is independent of the terminal network and the associated human
element.
Batch processing is currently unavailable with the STSC APL prod-
uct. VAX APL conveniently and fully supports batch processing
tasks.
DIGITAL INTERNAL USE ONLY 7
B. File System
There are basically three types of files to be discussed in this
comparison.
i Stream Files
ii Keyed Files
iii Component Files
8 DIGITAL INTERNAL USE ONLY
i. Stream Files
These are typically ASCII sequential with <CR> or <LF> as record
separators. This kind of file is heavily used for Data Control
Language (DCL) procedures and for report files.
ii. Keyed Files
These files have primary and optional secondary keys that are
character or numeric and have data associated with the key. These
files are heavily used by database management software and other
high level languages. The maximum data length is 2048 bytes.
iii. Component Files
These files are really numerically keyed files that store APL
objects of any size and structure. The 2048 byte boundary is
effectively removed by the APL file accessing functions. APL also
adds information to record data type and size.
STSC APL supports Stream_LF files (ASCII sequential files with
<LF> as a record separator). This type of file is different from
the Stream_CR files that are more commonly used in the VMS en-
vironment. The system function that creates these files does not
recognize the version numbers of the RMS naming structure. In
other words, you cannot create version 2 of the file from within
STSC APL while version 1 still exists.
STSC APL supports a proprietary component file system that may
have very little dependence on RMS. The file system is more than
adequate for the data and security needs of APL users. The rel-
ative independence from RMS may present some performance issues
that have yet to be evaluated.
VAX APL has a totally integrated support of RMS. From within APL
you can access data found in any file organization supported by
RMS. This permits APL to be used as a modeling tool or in a formal
application system that coexists with other software systems.
You should note that the type of file categorization above is an
over simplification of the file types and organizations available
through RMS.
DIGITAL INTERNAL USE ONLY 9
VAX APL also allows the user to redirect input and output. The
redirection of output to a file rather than a terminal can save
significant amounts of development time and greatly simplify
application software. These files can be subsequently reviewed
through the TPU editor or submitted to print queues for producing
reports.
C. Language Implementation
Both implementations of APL support the strand notation. This
presents some conversion problems when systems are being converted
from earlier releases of APL.
VAX APL generally allows system commands to be executed under
program control. The system commands for listing object names
(variables, functions, and groups) have been extended to work with
inactive (stored) workspaces.
VAX APL will always load a stored workspace. STSC APL requires
that the user request the appropriate amount of memory before
a workspace is loaded. In addition, VAX APL allows software to
dynamically adjust the amount of available workspace. This is
another instance where VMS facilities have been integrated into
the VAX product.
Both systems support user define functions as arguments to lan-
guage operators. VAX APL allows these functions to have an axis
designation while the STSC product does not.
VAX APL has significantly extended the power of the language by
implementing user defined operators. This makes this implementa-
tion of APL one of the most "powerful" languages available in the
computing industry.
10 DIGITAL INTERNAL USE ONLY
2. SESSION MANAGEMENT FACILITIES
Session management facilities are defined as those facilities that
are used to process information during an APL session. For the
sake of this comparison, there are three distinct kinds of APL
sessions.
A. Interactive and Program Development
B. Productive Usage
C. Batch Processing Usage
The requirements for each of these types of session are somewhat
unique and place different emphasis on the APL interpreter.
A. Interactive and Program Development Use
During interactive and program development sessions, the user is
typically an individual who understands the process of developing
computer software. In simplistic terms, the user wishes to in-
teract with objects (data and programs) in a workspace by using
a screen and keyboard. The interactive tasks are those in which
the user enters one line statements that are immediately processed
by the APL interpreter. These interactive statements are typi-
cally small experiments that help the user develop ideas. They
may perform valid processing, produce informative error messages,
or allow the user to transfer objects to and from disk files.
Typically, these small experiments grow in complexity as the user
develops and solves a series of small but interrelated problems.
The combination of solutions eventually is developed into a system
that provides a convenient tool for a system user.
In this situation, these two products are best compared by re-
viewing the offerings of both products in a screen terminal
environment (typically VT320).
VAX APL-Interactive Session Management
DIGITAL INTERNAL USE ONLY 11
The user may enter experimental one line expressions on the screen
starting at the cursor location. Before pressing return, the user
has access to the line editing features provided by VMS. In other
words, the user may move the cursor back and forth on the line and
insert, replace, or delete characters to create an expression for
APL to process. When the user presses the return key, APL performs
the processing.
The user may also press the up arrow key at any time to recall the
previous entry that was given to APL for processing. At this point
it is important to note that if the user receives an informative
error message, this recall feature may be quite useful. However,
it is very limited. In most situations, the informative error mes-
sage tells the user that a command was missing that was required
for the experimental statement. Therefore, the user must enter
another command to fulfill the processing requirements before re-
turning to the experimental statement. At this point the user must
rekey the entire experimental statement because it is no longer
recallable.
The keyboard layout corresponds to the standard APL keyboard that
has been in the industry for decades. The user has convenient ac-
cess to upper case alphabetics, numerics, APL primitive function
characters, and a set of overstruck characters. Overstruck char-
acters were necessary because they form part of the group of APL
primitive functions. In addition, the standard for the language
allows the user to create alphabetics that are underscored. On the
VT320 terminals, underscored characters are created by entering
the keystrokes Ctrl D, A, Shift F to create an underscored A. The
number of keystrokes and methodology may vary with the type of
terminal being used.
The user CANNOT enter lower case alphabetics through the keyboard
with the VT320 keyboard. These characters are only available by
indirect reference to system-supplied objects (i.e., by indexing
vectors that already have lower case characters stored in them).
There is no facility by which the user may store phrases on func-
tion keys so that one keystroke can cause several characters to be
entered on a line.
12 DIGITAL INTERNAL USE ONLY
STSC APL-Interactive Session Management
As with VAX APL, the user may enter an experimental statement
and perform in-line editing of the statement before pressing
return. However, one significant feature that is available is the
ability to move the cursor to any position on the screen, modify
the expression, and press return. The statement on that line is
then executed by APL. This is significant to interactive tasks
because you can effectively recapture experimental statements that
have been used at any time during the interactive session. In fact
you can set the number of screens full or information that are to
be maintained in scrolling memory and then reexecute any of these
at will, without retyping the statements.
The keyboard layout shows some imagination. All of the standard
alphanumeric keys are where you would expect them. The shift
key provides access to the APL primitive function character set
and the AT key (marked Select) provides access to the standard
lower case character set and to the more commonly used over-
struck or composite characters used as APL primitive functions.
Unfortunately for those who touch type, the AT key is only effec-
tive when it is pressed before a regular keyboard key. In other
words, it is not a toggled switch key like the shift lock key on
the keyboard. A toggle switch facility is only found in the editor
or session manager.
The underscored alphabetic character set is always mapped into
lower case characters. Therefore, there is no need to recognize
underscored alphabetics that were inserted into the language to
enrich the ability to name objects. Underscoring shifted alpha-
betics was the only way of providing this extension with IBM 2741
(Selectric) technology that was prominent 15 years ago.
The function keys on the keyboard allow the user to enter and exit
from a full screen editor and to perform advanced line editing on
experimental statements (split a line, join two lines, delete a
character at the cursor, etc.).
DIGITAL INTERNAL USE ONLY 13
The keyboard organization does, however, lead to some different
keying patterns. For example, the untype or destructive backspace
key on the keyboard is documented as untype. When I press it, it
only beeps. The remove key is on a cluster of keys to the right of
the main keyboard and is not as conveniently located for removing
single characters.
Logical programable function keys can be defined by the program-
mer. However, to use these keys it is necessary to press a special
PF key followed by a keyboard character such as "D". The fea-
ture is an important one to have, but the implementation could
be improved upon in the VT320 kind of terminal environment. The
application keypad has several functions keys that could be used
for this purpose.
VAX APL-Program Development Session Manager
VAX APL provides access to the standard system-wide editor for use
in editing APL objects. Because the editor is accessible only
through a spawned process there is a small delay experienced
when switching from the APL session to the editor session. The
amount of delay may be controlled somewhat by the baud rate of
the terminal being used. The delay is not very significant when
you consider the very strong benefit of using one editor for all
processors. Once a user of the VAX system has been trained to use
the very powerful editor, the editor can be used throughout the
entire VAX environment.
The >EDIT command as seen from APL will take an object (character
or numeric variable or function) and place it in a file that can
be edited by the editor. Control is then given to the editor in
an environment that is independent of APL. When the user has
completed the editing session, the file is then handed back to
APL and the requested changes are automatically made to the active
workspace.
There are only a few outstanding criticisms:
14 DIGITAL INTERNAL USE ONLY
o The object being edited must be a global object. There are
times when it would be expedient to provide the knowledgable
end-user with access to a preformatted localized variable and
request that changes be made. Presently, this can be programmed
around with added effort.
o The object type cannot be changed while in the editor. When you
edit an object it is assumed to be a character vector. It would
be convenient if the user could communicate a name class change
to APL before ending the editing session.
o The programmer cannot control the screen (window) space taken
by the editor. It is always full screen. In many applications
it is useful to provide application related information on
part of the screen while providing access to the editor on the
remainder.
The strategy of utilizing a standardized system-wide editor is an
extremely significant factor in providing integrated software de-
velopment tools. This factor should bear some weight in selection
criteria for systems being used in the VAX/VMS environment.
DIGITAL INTERNAL USE ONLY 15
STSC APL-Program Development Session Manager
STSC provides a very sophisticated editor to the user. The editor
allows the user to edit several objects at a time including the
image of the active APL session log. Thus, STSC has recognized
that the program development task really does consist of solving a
set of small but related problems and they effectively allow the
user to selectively access the various parts of the solution. By
providing access to the APL session log through the editor, the
programmer can effectively return to those experimental statements
that were successful and combine them into a program that can be
inserted into the active workspace. Conventionally the programmer
would have to create written notes about successful statements and
later rekey them to create a program.
In order to use this editor productively, the user is forced to
learn a set of unique editor commands. In this editor the TAB
key introduces a command statement that has an optional counter
(number of times to perform the command followed by a one-letter
name and a set of options). In other words, the general form of
the command statement is:
TAB [count] name parameters
I suppose that this format of an editor command is useful where a
user community has a variety of terminals that may be unsophisti-
cated (not as flexible as the VT320).
Comparative Comments
In order to ensure that the usage of APL will grow, it is impor-
tant that Interactive and Development activities be made as conve-
nient as possible. In other words, make the environment attractive
to software developers.
The STSC product has made a significant step in that direction,
however, it would appear that its support of the VT320 terminal
environment still lacks some experience:
16 DIGITAL INTERNAL USE ONLY
o There appears to be no support for toggling between an applica-
tion keypad and numeric mode. The application keypad is where
STSC's programable function keys should be located on the VT320
terminals.
o It would be more convenient if the ALT key that provides access
to lower case characters acted as a toggle switch rather than a
single-entry switch.
o The introduction of a new editor requires an additional learn-
ing curve investment which STSC would undoubtedly maintain is
worth the time and effort. In some environments this may be
true.
VAX APL appears to be at the crossroads of wonderful opportuni-
ties. In the last five years this part of the system has received
three significant changes:
1. Access has been provided to the VMS line editor to provide
better integration with the VMS environment.
2. Some additional facilities have been added to the function
(del) editor (character string search, etc.)
3. Access has been provided to the TPU full-screen editor for
variables and functions.
Several approaches may be taken to improve the environment for the
APL system developer. The following suggestions identify some of
the topics that could create a significant impact on the VAX APL
user community.
DIGITAL INTERNAL USE ONLY 17
The first topic of discussion relates to character sets. As pre-
viously mentioned, the underscored alphabetics were introduced
to the language to enhance the availability of characters with
which to create object names. Underscored characters were chosen
because the type elements of IBM 2741 (Selectric) terminals did
not have sufficient physical space to provide lower case charac-
ters. Since that time, most terminals are now providing software
selectable character sets and most printers connected to computer
systems have improved in flexibility and ability to print a wide
variety of characters. In fact, present-day technology places
more emphasis on the ability to conveniently use upper and lower
case characters for report generation. Therefore, the APL require-
ment should emphasize the availability of upper case, lower case,
and APL characters. The greatest competitive edge will be won if
the APL implementation can support all four character sets in a
convenient way (upper case, lower case, APL, underscored alphabet-
ics). The most convenient method of implementation from the user's
perspective is to have the standard APL keyboard defined as the
default and then provide access to the other character sets via a
toggle switch setting (function key). The shift LOCK or CAPS key
on the keyboard is a toggle switch key. Most IBM APL systems treat
the character sets this way.
While on the topic of character sets, a word about the TAB char-
acter might be beneficial. The TAB character is generally used
inside of character text as a convenient way of encoding a group
of space characters. As a data compacting technique the TAB char-
acter has its place. However, from a system developer's perspec-
tive, the TAB key can cause unreliable results. Many terminals
and printers allow TAB stops to be set within the software that
drives the device. If the software developer does not have conve-
nient access to the TAB stop setting software then he/she cannot
control where the tabs are set. Rather than delve too deeply into
this issue, it appears that a wise choice is to always translate
the TAB character into the appropriate number of space characters
when it is used within APL. This is of particular importance to
the interactive and program development activities. This subject
is also relatively controversial and lengthy to discuss in this
18 DIGITAL INTERNAL USE ONLY
brief document. Therefore, the discussion about the TAB character
implementation is incomplete and only expresses an opinion about
its method of use.
The simple ability to move the cursor from its current row posi-
tion to a different row within the APL session, modify the line
of text at that location, and press return to execute the expres-
sion is very significant. I estimate that this ability alone can
reduce software development time by as much as 10%. The keys that
you would use to move the cursor around are identical to those
used by the full screen editor. This feature improves the user's
perspective on the convenience and power of the language because
the feature encourages the user to develop and test modular ex-
pressions of a solution to a problem. This is also a feature that
is important because APL is interactive and interpretive. Other
languages that are compiled or noninteractive would derive less
benefit from this kind of facility.
The accessibility of user definable programable functions keys has
an impact on interactive and development use. When properly used,
the user can press one function key and have several characters
inserted into a line of text. The developer finds this useful be-
cause commonly used phrases can be placed in the keys and recalled
conveniently. In the VT320 environment, these should be placed
in the application keypad definition. Of course, the application
developer needs:
o A way of inserting phrases on the keys
o A toggle switch that allows the keypad to be used as an appli-
cation keypad or a numeric keypad
This feature may have more significance to the application user
than to the application developer.
DIGITAL INTERNAL USE ONLY 19
In addition, it would be useful for the developer if he could
insert characters into an input buffer. Thus, a series of complex
commands may be efficiently entered by an application user with
one keystroke.
At present, VAX APL provides relatively poor support for access-
ing a variety of character sets through the keyboard. It has no
support at all for interactive control of cursor movement and no
support for programmable function keys. It may be informative to
note that the Run-Time Library Routines for the Screen Management
System, currently supplied with VMS (5.0), have almost all of the
tools required to support these strategically important features.
B. Productive Usage
Usually, one of the end results of software development is a
computer system that can be used without a software developer
sitting at the keyboard. The user of this final system is not
expected to be knowledgeable about software development. This user
typically understands the commands that are necessary to start
a process that requires data entry or produces reports based on
previously captured data. Since all of the factors required to
perform data entry and to produce reports have been defined and
logically embedded in the software and data organization, the
system is at a productively useful stage. Productive Usage of
these systems typically falls into two categories: Interactive
and Batch Processing. The discussion on Batch Processing has been
placed in Part C of this section.
20 DIGITAL INTERNAL USE ONLY
Interactive-Productive Usage
In this environment the user typically selects tasks to be per-
formed through menu selections. These tasks may activate immediate
or batch processes. The immediate process may create a report or
request that data be entered on a form that is displayed on the
screen. It is important from a system developer's viewpoint to
recognize that a menu and a data entry form are basically the same
tool. The only difference is that a menu accepts a different type
of data than a data entry form does. Thus, a menu is a special
case of a data entry form.
Two of the key elements in a data entry form are a mask and a set
of window specifications. The mask is a set of static characters
that make up the form. These characters may consist of special
graphic characters and brief field descriptions that communicate
what the user is expected to enter. Window specifications gener-
ally define the starting row and column and the number of rows and
columns that make up the length and depth of a data entry field.
Note that although the cursor may only exist on one row at a time
during data entry, a window specification can identify several
rows in its depth. Software can then automate the movement of the
cursor from one window to the next or from one row in a window to
the next. There is another set of numbers usually associated with
a window that controls the data type allowed for entry into the
window (alphanumeric, numeric) and that controls window attributes
such as color and/or intensity.
Once these elements have been defined, user-developed software is
then expected to be able to display the mask, assign attributes
to windows, and control the entry of data at each window. It is
important to note that the word CONTROL means that this software
must be able to recognize and act upon the entry of any key on the
keyboard. Otherwise the relatively naive user could cause unpre-
dictable events to happen during a data entry task. In addition,
when data entry at a window is completed the developer may wish,
at his option, to perform a variety of computing tasks (e.g.,
validation, set default values, etc.).
DIGITAL INTERNAL USE ONLY 21
Furthermore, once a group of relative entry is completed, it
is sometimes convenient for the developer to retrieve the data
from various windows that are still located on the screen. This
approach often clarifies the software and therefore improves the
ability to maintain the system.
STSC-Interactive Productive Usage
STSC provides some tools to facilitate the previous scenario.
o The cursor location is changed by assigning a vector of two
numbers to a system variable.
o STSC provides a way of displaying a table (character matrix) of
data with or without attribute specifications, within a window.
o STSC provides a way of retrieving data, with or without at-
tributes from windows on the screen.
o Each character entered may be read through []INKEY. The soft-
ware can then determine the type of action to be taken based on
the keystroke entered. This methodology can generally increase
CPU usage during data entry but does provide the ultimate in
data entry control.
Generally speaking, the STSC APL*PLUS/PC product provides a far
more extensive set of facilities for efficiently and effectively
controlling data entry or screen-driven applications. By compari-
son, the STSC APL*PLUS for VMS falls far short of expectations in
this area and should in no way be considered to be compatible with
the PC product.
VAX APL-Interactive Productive Usage
VAX APL does not provide any direct tools to facilitate the previ-
ous scenario.
22 DIGITAL INTERNAL USE ONLY
Facilities that are superior to the STSC implementation are avail-
able to users of the VAX APL environment through indirect sys-
tems. It is quite possible to fulfill these needs by incorporating
the use of the Run-Time Library Routines for Screen Management.
However, this requires that the developer of such systems has a
relatively extensive knowledge of computer systems in general and
is willing to investigate and learn about more detail than he re-
ally needs to know. This does not suit the characteristic profile
of the average APL system developer. Most developers of systems
written in APL are attracted to the language because it enables
them to create systems quickly and efficiently with a relatively
low learning curve. Even though their demands upon software sys-
tems have grown in sophistication, there is still a very strong
demand within the user community to use simplified tools that have
been integrated in the APL environment.
C. Batch Processing Usage
Batch processing is a means by which a set task may be performed
at any predetermined time. It has three advantages:
o It provides an ability to control the timing of processing to
be done. In other words, you can defer the execution of a task
to some time when system resources are only lightly utilized by
other activities.
o The task being run is independent of terminal networks and the
associated human element.
o By effectively managing the batch queues, the system resources
may be utilized to their fullest advantage. Processes run
in a batch queue typically receive lower service priorities
than their interactive counterparts. Since these tasks can
generally be run concurrently with interactive tasks, system
administrators can make full use of the resources available.
DIGITAL INTERNAL USE ONLY 23
To start a batch process, a user typically creates a standard
ASCII file that specifies the data control commands to be exe-
cuted. For APL processes, one of these commands invokes the APL
interpreter and is followed by a set of commands to be processed
by APL. This file of commands to VMS and APL is typically sub-
mitted to a batch queue with an appropriate set of parameters for
controlling the release time, CPU resources, and location of batch
logs.
STSC-Batch Processing Usage
At the time of writing this report, the STSC manuals do not de-
scribe such a facility. In earlier attempts to invoke the inter-
preter through the batch processor, the process failed to func-
tion. At this point in time, I would be best not to conjecture
about why the STSC product does not support batch processing.
24 DIGITAL INTERNAL USE ONLY
VAX APL-Batch Processing Usage
VAX APL is fully supported in a batch processing environment. As
described earlier, the user simply submits a command file to the
batch processing queue with the appropriate parameters. Normally
these command files are created using the ASCII character set and
so APL is entered in a TTY mode. This is acceptable because by
the time a process is well enough defined to be running in a batch
environment, the dependency on the APL character set is virtually
hidden. Furthermore, since the command file is conveniently cre-
ated by the system-wide TPU editor, the user is afforded with an
opportunity to provide some valuable documentation for the pro-
cess. Also, many users of VAX APL keep the most recent copy of
log files for process around as further documentation about the
anticipated resources required for processing.
DIGITAL INTERNAL USE ONLY 25
3. FILE SYSTEMS
The file systems used by STSC APL and VAX APL are quite different.
The STSC product provides access to two distinct kinds of files
while the VAX APL file system is totally integrated with the
VMS Record Management System (RMS). In order to simplify this
discussion, the types of files available will be divided into
three categories.
Stream Files
This type of file is typically one that contains a stream of ASCII
characters. The file is physically divided into records based on a
special character (carriage return <CR>, or line feed <LF>). The
record lengths may be fixed or variable with a maximum length of
2048 bytes.
Stream files that recognize <CR> as the end of a record are com-
monly used in the VMS environment as command procedures and report
files. These files are commonly referred to as ASCII sequential
files. Command procedures are typically created through the TPU
editor while report files are generated by user-defined appli-
cation software and passed to print queues where the appropriate
software controls the physical printing of reports. It is there-
fore clear that this type of stream file is fundamental to the
effective use of the VAX VMS environment.
Keyed Files
This type of file may be viewed as one that contains two types
of data. The first type of data consists of a key which may be
subdivided into primary and secondary portions. The second type
of data is the application data. Application software typically
retrieves the application data by referencing a unique file key.
26 DIGITAL INTERNAL USE ONLY
This type of file is more heavily used with inquiry systems that
are developed in COBOL or other compiled high-level languages.
It is rarely used directly in an APL environment because the
application data cannot exceed a size of 2048 bytes per key.
Component Files
In reality a component file is an indexed or keyed file in which
the keys are integers between 1 and 65535 and the data size may
exceed 2048 bytes in length. Component files are also relatively
unique to APL. Some other languages may refer to these files by
different names.
A file component can hold any variable that can be created in an
APL workspace. An APL variable may be homogeneous (all charac-
ter or all numeric) and may have zero or more dimensions (scalar,
vector, or n dimensional table). An APL variable may also be a
heterogeneous object (nested array) that contains sets of homo-
geneous variables including software. You may think of a nested
array as another name for an object that contains data and/or
software. The advantage that a component file structure has over
other file organizations is threefold:
1. The user identifies only the name of the object to be written
or read from a file and the component number to be used in the
I/O operation. No formatting is required by the user.
2. The object may span several records of the real file structure,
and the file system manages the organization automatically.
Thus the size restrictions of 2048 bytes is removed, and the
file system can be conveniently viewed as an extension of
workspace memory.
3. Data in a file component may be replaced without regard to the
length of the original data in that component. Therefore, the
system developer spends his time concentrating on the solution
to the problem at hand rather than concerning himself with some
DIGITAL INTERNAL USE ONLY 27
major issues related to file organizations and data handling
techniques.
STSC APL-File System
STSC APL effectively supports component files through a propri-
etary file subsystem that has been modified to work in the RMS
environment.
The indices of a component file must be a closed set of continu-
ously increasing integers. For example, if a file has ten compo-
nents, then the first data component may be 1 and the last is 10,
or the first component may be 21 and the last is 30. In order to
create a file that uses component 30, all components from 1 to 30
must have existed at some point in time. The system provides tools
to drop a set of file components from the top or bottom of the
file. This is different from the VAX APL component file system.
The file subsystem provides a level of data security beyond that
supplied by RMS. Each type of file operation supported in the
system has an associated access code. Users other than the owner
may perform permitted file operations based on a security access
number. In addition, the file system maintains time stamp user
identifier and type of operation performed on the latest access to
each file component. These security features are invaluable in a
commercial time-sharing environment.
An independent means of performing file sharing is provided. In
essence, a user may prevent others from accessing a file while
update operations are pending. At this time, it is not clear how
well this mechanism functions in conjunction with the automatic
interlocks provided by RMS.
STSC APL also provides a built-in facility for compressing data
files. Data files may grow in size without increasing the com-
ponent numbers. Suppose that you have a file of three components
and you wish to replace the second data component with a larger
variable than was initially stored in that component. The files
system must therefore put your new data in an alternate location
28 DIGITAL INTERNAL USE ONLY
and "remove" any reference to the original data. This process is
called a growing replace. The old data still occupies space on the
file until a new copy of the file is made. This copy must be cre-
ated by APL and not RMS directly. STSC provides a system function
that performs this file compression for the user.
STSC also provides access to a native file or stream file that
uses <LF> as the record separator. With this file type, the soft-
ware may read data starting at any byte in the file and ending at
any byte, based on a specified-length parameter. The native file
create system function does not recognize version numbers as used
by RMS.
The requirements to print reports from this kind of file may need
further investigation. If existing printers at an installation
will recognize the line feed character as a carriage-return line-
feed combination, then the file type can be used for holding re-
ports prior to printing. Otherwise, <CR>s will have to be supplied
by software before the data is placed in the file.
DIGITAL INTERNAL USE ONLY 29
VAX APL-File System
As mentioned earlier, the VAX APL implementation has been totally
integrated with RMS. It can access data found in any file organi-
zation supported by RMS. This permits APL to be used as a modeling
tool or in a formal application system that coexists with other
systems.
Component files have an integer key but the components themselves
do not require initialization. Therefore, the user may place data
in components 1, 3, and 5 without initializing components 2 and
4. The user is left to determine which components are active in
a file. Growing replacement of data in components still occurs
in VAX APL, but there is no built-in file compression system
function. A knowledgeable VAX APL programmer can construct a
utility to perform this task. VAX APL also allows you to delete
components from a file. This is not allowed with STSC APL.
In addition to the RMS file sharing features, the APL software can
release or hold file records for a specified time period of up to
four minutes.
In the VAX APL environment, file assignments (ties) are consid-
ered a property of the workspace. Thus, loading a workspace may
automatically cause file ties to occur.
VAX APL also provides two facilities that are useful and related
to the file system. Input may be redirected so that it comes from
a file rather than the terminal at any time during an APL session.
In this fashion, commonly used software may be automatically
loaded into a workspace whenever an application is started. This
facility can help in reducing software storage requirements and,
in effect, ensure that particular users are using the common
software.
The ability to direct output to a file at any time during an APL
session is extremely beneficial. The impact is felt most strongly
in two ways. The software developer may create reports that, by
default, are displayed on the screen. Once the user is satisfied
30 DIGITAL INTERNAL USE ONLY
with the results, he/she modifies the software by inserting a sim-
ple command that redirects the output to a file. The introduction
of this command does not affect any of the existing software that
has been previously tested. The second benefit is that the out-
put file can be a standard ASCII sequential file that is ready
for submitting to a print queue or for subsequent review through
the system-wide TPU editor. This methodology of creating report
files may actually reduce the amount of direct I/O operations re-
quired to produce a report. Hence, it can have an impact on system
performance.
Comparison Comments
The ability to create and read data from all file types supported
by RMS is of major significance in a VMS environment. Without
this ability, APL becomes a tool used by specialists in a confined
environment. With it, APL becomes an effective tool in formal
applications that may be designed using different languages and
file structures. APL also becomes an effective modeling tool that
can access any required data on the system without requiring a
specialized subprocess to reformat the data to the needs of the
language.
As discussed earlier, the ability to conveniently redirect output
to a file that is accessible by the TPU editor and print queues
can have an impact on software development time as well as on
overall system performance. Similar facilities may be developed in
the STSC APL environment to redirect output to a file, but this
requires additional modularity and user-defined documentation.
Such documentation typically rests in the hands of the few rather
than being made available on a system-wide facility.
The STSC APL file subsystem has yet to reach the maturity level
that other STSC APL products have reached in other operating sys-
tem environments. They obviously need encouragement and support to
bring their file subsystem into alignment with the RMS environ-
ment.
DIGITAL INTERNAL USE ONLY 31
VAX APL has been developed using tools that are an integral part
of RMS. This maximizes the ability of APL to become a corporate-
wide computing language for clients of DEC. The data used by,
and created by, APL need not be stored in an isolated environment
where it is inaccessible to the corporate user community.
32 DIGITAL INTERNAL USE ONLY
4. LANGUAGE IMPLEMENTATION
The language implementations of APL for STSC APL and VAX APL
are very similar. There are, however, a few items that should
be discussed.
Both APL systems recognize nested arrays and the strand notation
for creating vector arrays. For APL users who are involved in con-
verting from earlier implementations that do not recognize the
strand notation, this can potentially create conversion problems.
In earlier releases of APL, the expression 15 16 [1] would return
a result of 15. The equivalent expression using the strand no-
tation is (15 16) [1]. Typically, these situations would show up
only during user testing of the converted system.
VAX APL generally allows system commands to be executed under
program control, while STSC APL does not. In most instances, STSC
APL does provide an equivalent system function to perform the
task.
VAX APL has extended the commands that identify functions, vari-
ables, and groups found in an active workspace. The extension
also allows the user to view these lists in inactive or stored
workspaces. Thus, you do not need to destroy your active workspace
when you wish to search for a function in a stored workspace.
A VAX APL workspace can always be loaded into the active workspace
environment by using the )LOAD command. VAX APL automatically
adjusts the amount of available memory, when necessary, to accom-
modate the retrieved workspace. STSC APL requires that the user
first allocate sufficient memory to load the workspace. This may
encourage users to request more memory than they really need just
so they can be certain that the )LOAD command will work. On this
same topic, VAX APL allows software to dynamically allocate more
workspace when it is required. This is another situation where
the implementation of the language uses integral parts of VMS to
manage system resources.
DIGITAL INTERNAL USE ONLY 33
While both systems support user-defined functions as arguments to
language operators (reduction, inner and outer product, each), VAX
APL has extended the definition to allow you to specify the axis
over which the function is to be applied. In itself, this is a
powerful addition to the language.
VAX APL has significantly extended the power of the language
by implementing user-defined operators. To better understand
an operator, you should consider that a function uses data as
its arguments and controls the processing of data. An operator
uses functions as its arguments and controls the way in which
the functions are executed. Since both functions and operators
are user-definable, I doubt that you will find a more "powerful"
language anywhere in the computing industry.
34 DIGITAL INTERNAL USE ONLY
|