🚀 go-pugleaf

>                      I am converting an interactive program to run
>under TSO.  It displays data at the user's request.  Each clump of
>data has a header and footer.  On character-oriented systems, it keeps
>track of the screen so it can display the footer and stop at the
>bottom of the page to allow the user to see what's on the screen
>before continuing.  After the user says to continue, it again displays
>the header and resumes displaying the data.  On such systems, all
>prompts and responses are together on the same line.

If you're in a hurry, you can implement the same logic under plain TSO
as long as you know how to determine the current number of screen rows
and have code to clear the screen.  The GTSIZE macro will take care of
the former and there is code to do the latter via standard macros.

SM users can do their own screen scrolling, so you can get away without
even worrying about them if you're really under pressure.  (My opinion
is completely ungrounded in any factual basis, since SM isn't used
much around here.)

What language is this application written in, anyway?  If you're really
in a hurry, and this was on a completely different platform originally,
I doubt you want to rewrite this in 370 assembler...

>I don't have the manuals in front of me here at home, so I'll have to
>lookup the FULLSCREEN stuff Monday.  Correct me if I'm wrong: it
>doesn't matter how you got there, and it doesn't matter what else is
>running.  I believe it's the basis for the ISPF interface.  I had
>initially considered and then rejected it because I thought it would
>be too much work, but it's clear that a good interface a little bit
>late is better than a bad interface on time.  How does one interact
>with the user under ISPF?  I probably better order the ISPF Dialog
>manuals...

Despite occasional pejoratives hurled at ISPF, it's the best way to
develop a full-screen application for TSO users.  Not only is it
relatively easy to do, but it'll work compatibly with most other
full-screen applications - most people have more than one task to
perform at the same time.  On the other hand, if this is a one-time
effort, you may not have the time to dig into learning ISPF.

Coding non-ISPF fullscreen applications, though, is not a useful or
productive direction.  ISPF users will be upset, unless they have a
multisession manager package at their site.

>One more question about the TSO non-SM environment: how large is the
>buffer between the program and the screen?  I originally thought that
>when the screen is full, and TSO issues the famous "***" prompt at the
>bottom, the program stopped dead in its tracks hanging on the TPUT
>which is trying to write the line which will be the first line of the
>screen after TSO clears it when the user presses an action key such as
>Enter.  Something happened recently which now leads me to believe that
>the program continues executing, presumably filling a buffer.  I'd
>like to understand this better.  What is the impact of PA1?  I'd
>imagine it causes a flush of the buffer.

The buffer size is a function of whether the site uses TCAM or VTAM
and the various parameters specified by the system programmer.
In any case, your program shouldn't need to be concerned with this.
If it is retrieving data in real time as it spits it out, it should
do the pagination itself and not rely on the "***" prompt.  The "***"
prompt is the point at which both the user and the application have
the weakest control over what goes on.

>Speaking of PA1, I believe I need to have an ESTAE handler to catch
>it, but I'm not sure.  I probably also want to detect it uniquely so
>that other ABENDs continue as appropriate.$$

Not an ESTAE, but a STAX, to capture attentions.  This isn't as
flexible an interrupt handling mechanism as ESTAE/ESPIE, since your
application can't specify a retry address - it can only opt to
continue (ignoring the attention) or abort.  The typical attention
exit routine sets a flag in the mainline and returns - the mainline
checks for this flag at periodic intervals.  Not only does this slow
down the mainline code slightly, but it exposes the application to
segments of noninterruptability.  If you screw up the polling code,
you can let the user get into an unbreakable loop.

The alternative is to forget about trying to handle attentions and
let PA1 kill your program entirely.  You probably don't want that.
I imagine that you want PA1 to return the user to the main prompt.
That's not so hard to do if you watch that polling stuff.

I think that if you have any further questions, this discussion
should be continued offline, or moved to IBM-MAIN.

Hope this helps (and that Leonard doesn't violently disagree with
anything I've said here :-).

 - Steve "Batchman" Bacher
 - Draper Lab
 - Cambridge, MA

P.S. Sample code to clear screen (no allowance for ISPF or SM here):

         STFSMODE INITIAL=YES      SET FULL SCREEN MODE FOR VTAM
         LTR   15,15               IF NOT A VTAM TERMINAL
         BNZ   TCAMCLR             THEN DO A TCAM SCREEN CLEAR
*                                  ELSE DO A VTAM SCREEN CLEAR
         TPUT  CLR,L'CLR,FULLSCR,,HOLD
         STLINENO LINE=1           INSURE LINE MODE OUTPUT GOES TO TOP
         STFSMODE OFF              SET FULL SCREEN MODE OFF
         TCLEARQ INPUT             FLUSH PA2 AID QUEUED BY VTIOC
         B     DONE
TCAMCLR  DS    0H                  NOT VTAM - DO TCAM SCREEN CLEAR
         TPUT  FSON,L'FSON,FULLSCR,,HOLD
         TPUT  FSOFF,L'FSOFF,FULLSCR,,HOLD
DONE     DS    0H
         ...
CLR      DC    X'401140403C40400013'
FSON     DC    X'40115D7F1140403C40400013'
FSOFF    DC    X'40115D7E1140403C40400013'
         ...