Using VSAPL under TSO

By David Piper

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

In VECTOR 2.2 Adrian Smith raised some points about the difficulty of running VS APL under TSO rather than under VSPC. Whilst I agree that TSO leaves rather a lot to be desired in terms of user friendliness when running from the “READY” prompt, a lot can be done to improve things. TSO is a very flexible environment, in which just about anything can be achieved. The disappointing thing with TSO, is that the user-friendliness is left to the installation to create, and doesn’t exist in the product itself. The following describes some directions which might be investigated in order to implement a better TSO environment.

ISPF for Dialogue Management¶

One of the great benefits of using TSO is the availability of ISPF, with its flexible, and simple to use Dialogue Management Services. These facilities can be used to create very friendly dialogues running under TSO to conduct the user from the Broadcast Messages (where the READY prompt is normally first seen) into any other part of TSO. The dialogues can use a combination of full screen menus, data entry panels and tutorial panels. ISPF also allows an “expert mode” to allow very rapid navigation through menus for experienced users. ISPF can thus provide an environment suitable for use by both naive and experienced users.

VS APL Session Manager¶

A piece of advice that can be freely offered is: Don’t use the APL Session Manager. When this first became available, I was involved in performing some bench-marks on it. The initial figures derived were so appalling, that the bench-mark exercise was dropped, and the availability of SM withdrawn. The initial figures indicated that SM had the following impact:

A five-fold increase in CPU usage on screen bound activities
A doubling of CPU usage on CPU bound activities (no screen I/O involved except to invoke and terminate!)

Along with this impact on CPU, there was a considerable increase in Paging activity etc.

Since stopping the use of the SM, I have often wondered just how useful it is under TSO anyway, since any number of lines on the screen can be re-entered for execution simply by overtyping a single character. The lines entered in this way will be executed in the order they appear on the screen (this incidentally is a feature I miss under CMS, where it appears only INPUT lines can be retrieved for re-execution, and then only one at a time). The only benefit SM appears to offer is to “extend” the screen, so that data, already scrolled off the terminal can be recalled for execution. I think the overheads involved are hard to justify on this small benefit. If the APL SM is to be used, the colour of the output can be changed by using the HILIGHT operand of the VSAPL command. Since, by default, colour is linked to hilighting, specifying HILIGHT(OFF) when invoking APL will cause input from the user and output from the computer to be displayed in green.

Logging On¶

Assuming a logon through VTAM, this can be rather daunting! However, if the implementation has a reasonable service level applied to TSO, one bash on the attention key (or PA1 if locally attached) is sufficient to return to the LOGON prompt. The logon process can then start again by typing:

LOGON userid

The full screen logon provided with TSO/E is another matter however, and seems to be full of Bugs (eg prompting for the correct password to be entered, but protecting the password field at the same time!). Most users seem to find the variety of options on the Full Screen logon overwhelming, so turn it off. The typical user should be able to logon in at most 3 steps:

VTAM logon to TSO – LOGON APPLID(xxxx)
TSO will then prompt for USERID
Once the USERID is validated, a PASSWORD will be prompted for.

If RACF is installed, a fourth stage will occur when the password expires – prompting for a new password. Other information may be prompted for if insufficient data has been added to SYS1.UADS. It should be possible to cater for users’ needs simply by defining a logon procedure with a default region size, so no other information need be entered during LOGON. This process can be shortened further if a VTAM menu package is available e.g. NETMON or NET/MASTER. If correctly installed, these will allow the logon to be achieved in a single step; in fact NET/MASTER allows automatic logon to TSO to occur.

Screen Erasure Problems.¶

Messages such as:

SCREEN ERASURE CAUSED BY ERROR-RECOVERY PROCEDURE

will originate from incorrectly customised control units in 99% of cases, and can be solved quite happily with some effort at correcting this type of error. This sort of message normally results from GDDM, or other screen manager, thinking the terminal can do something when in fact it can’t.

There is absolutely no need for the use of PROJECT libraries under TSO. If it is necessary to share a workspace (eg to fix a bug), this can be achieved quite happily by simply copying it (using the NONUM operand of the copy command). Alternatively, other users’ workspaces can be accessed by changing the PROFILE PREFIX, and using )LOAD as though the WS were your own. If a security package such as RACF or ACF2 is installed, access must be granted before the )COPY or )LOAD is attempted.

The RACF GROUP concept can also be used to share a whole set of workspaces between a large number of userids without recourse to the project library facility. The RACF Group allows a common PROFILE PREFIX to be shared amongst many user ids. Any workspace with this profile prefix will appear in the )LIB listing of all users with the same prefix. Generic access rules can be used to provide the same facility under ACF2. Whether a user is able to )LOAD or )SAVE a workspace depends on the access level given under RACF. This concept is more flexible than that of the project library, since a given user will be able to )SAVE some workspaces, only )LOAD others, and may have no access at all to the remainder.

Clearing the Screen¶

One of the TSO manuals (I think its “OS/VS2 TSO Guide to Writing a Terminal Monitor Program or a Command Processor”, GC28-0648) gives a listing of a very short assembler program which will clear the screen. By placing this in one of the TSO load libraries, it can be invoked as a TSO command by using )TSO or AP100.

VSAM Record Locking¶

I am reliably informed that VSAM record locking works perfectly under TSO, for multiple region use. If multiple CPU access is envisioned, the Global Resource Serialisation feature is required.

Printing¶

Printing to local 328X type printers under TSO is something of a problem. This type of printing is supported by two installed user programs (IUP) – programs not actively supported by IBM:

DSPRINT – in use on many sites.
JES328X – less widely used but more reliable.

Neither of these products will support the use of APL characters without a considerable re-write. In addition, because these are IUPs, the command syntax may differ from site to site, although a common core syntax is normally implemented. GDDM also provides a print facility – ADMPRINT. This has been considerably enhanced in GDDM R4.0, to allow the use of printer control characters, thus with the use of two GDDM calls (FSLOG – AP126 code 603 and FSLOGC – AP126 code 606), all the standard printing facilities are available to APL, including the ability to print APL characters.

User Numbers¶

Under TSO, there is no way supplied with APL of sharing APL data with other users. In fact APL thinks all users are number 1001. However, an IUP is available which allows data to be shared between MVS regions – MVS Inter Region Access Method (IUP 5796-ATX). This IUP provides general auxiliary processor support for two MVS regions to communicate. It also allows communication with an IMS control region, allowing APL to generate DL/1 calls to IMS databases.

TSO Information¶

One advantage of VS APL under TSO is that a wide range of additional data about the operating environment is made available to APL through AP100. Extra pseudo-TSO commands have been provided to give the following types of information:

Current WSID, and save timestamp
Machine resource utilisation (CPU, DASD and other service units)
Current USERID, profile prefix
List of libraries available
List of workspaces in a given library
Releases of major pieces of software (MVS/TSO, APL, GDDM, HSM, RACF)
Terminal characteristics (Height, Depth)
Suppressing terminal output

These facilities are very useful to the APL programmer when interfacing to other systems, or when displaying information to a user on full screen panels.

Conclusions¶

I hope the above points have gone some way to answering the criticisms levelled against TSO by Adrian Smith in the last issue of VECTOR. It is a pity that IBM have not put a little more effort into making TSO friendly to start with. On the other hand, the TSO environment is very general purpose, and by using add-on products (thus cunningly generating more profits for IBM), can usually be made to perform at the desired level. Once implemented, a TSO environment can be very stable indeed.