Session O316/O317 - MVSE: How to Use the VTAM API

August 21-25, 1989

O316 - MVSE: How to use the VTAM API (part 1)
O317 - MVSE: How to use the VTAM API (part 2)

This was a two part presentation by two guys from Cray Research. Alex Hilleary did a wonderful presentation on IOS device drivers a couple of SHAREs ago, and I came to his VTAM presentation on the strength of that performance. I wasn't disappointed - leastways by Alex. In part 1 he talked about the VTAM API in general, and in part 2 Nic Catrambone talked about a specific VTAM application written at Cray. Around a hundred people were in attendance.

Alex talked about exits in VTAM applications (as it turns out, much of your interface with VTAM is through exits). In particular the three session termination exits (SCIP, NSEXIT and LOSTERM) are the most confusing. SCIP is the "Session Control Inbound Processing" exit; it sees some session termination events and all session binds. LOSTERM receives notification of more session disconnect events. NSEXIT sees other varieties of session disconnects. You must code each of these in your program, or there will be session outages that you will not find out about until your program starts getting RPL failures.

Many of the exits are "ACB" exits - they run asynchronously under an IRB of the same task that OPENed the VTAM ACB. You are free to OPEN an ACB in one task, then issue SEND and RECEIVE requests against the ACB in another task. The "ACB" type exits still execute under the ACB task, despite the fact that the bulk of your processing is under another TCB. If the ACB task terminates, the ACB is CLOSEd automatically.

LERAD and SYNAD are synchronous exits. They are not driven until you issue a CHECK macro against an outstanding RPL.

He talked about things like parallel sessions (more than one session between consenting programs), LMPEO (automatic splitting of large messages into small RUs), and how NCP's max RU size can hose you over (specifically, there is no way to find out what the max RU size is in an NCP until you blow the limit - I wish there was a way to get around this).

Nic Catrambone took over and talked about their VTAM application. They wanted to provide Cray access to a network of TSO/ISPF users, so they wrote a VTAM appli- cation that runs as an ISPF dialog. Each user's VTAM application in turn talks to a centralized VTAM application which acts as a message concentrator. This concentrator does I/O to the Cray directly using a proprietary protocol, and looks to the Cray as if it is really a bunch of terminals.

The concentrator address space has one TCB per session. But the ACB task is different from the session task; I don't see any particular advantage to this technique.

Nic recommended that you put all the control blocks relevant to a particular session adjacent in memory (ACB, RPL, NIB, etc.) While this is very convenient for dump viewing, I don't agree with this recommendation; handpicking the memory that you put control blocks in means you cannot use GENCB, and you are vulnerable to release changes in VTAM.

He made two recommendations that I can agree with - for a refreshing change. First, make all your NAMEs the same: ACB label, APPLID, NIBSYM, APPLNAME. VTAM allows these to all be different, but why? Also, you should use your VTAM exits to schedule work, not to perform it. This makes your code more extensible (he added "You'll live longer").

Back to session index
Back to index of SHARE meetings
Read the disclaimer