X-MVS-to:  ibm-main@ricevm1.bitnet
X-send-dataset: 'XMAILMSG.SEB1525.XA920412.T1605300.C000000'
Newsgroups: bit.listserv.ibm-main
Date:         Sun, 12 Apr 1992 16:05:00 EDT
Comments:     Warning -- original Sender: tag was NNMVS@MVS.DRAPER.COM
From:         "Stephen E. Bacher" <seb1525@MVS.DRAPER.COM>
Subject:      Re: User interface under TSO
Comments: To: ibm-main%ricevm1.bitnet@surname.draper.com

>I assume the phrase "bypass carriage return" means two characters,
>"bypass" and "carriage return," and that I can get the invisible input
>field to be on the same line with the prompt if I omit the carriage
>return.

Yes (i.e. X'2415') - except that I've noticed that it didn't always
quite work that way under some old releases of TSO/VTAM - or was it
TSO/TCAM?  Anyhow, this is true now, for whatever VTAM we've been at
lo these many years.

>   TPUT/TGET/TPG are direct interfaces to SVC 93.  They require no TSO
>   control blocks - in fact, you can issue them from a program that was
>   not invoked as a TSO command processor.  In batch they are no-ops.
>
>How are these things implemented?  Wait; I don't want to know that.  I
>want to know if they break the general rule that MVS I/O is via a
>DDname, one way or another.

Basically, there's no ddname for the terminal in your TSO address space
because the I/O isn't done in your TSO address space.  All the terminal
I/O is done by VTAM (or TCAM).  SVC 93 queues your requests to VTAM
(via VTIOC) or TCAM (via TIOC, using QTIP).  TCAM has ddnames for the
various lines and terminals and whatnot defined in the MCP, and VTAM
has ACB's and APPLID's defined for the logical units - which works out
to about the same thing, if you think about the fact that ACB's are to
VTAM and VSAM what DCB's are to the rest of us.  There's no TIOT entry
in the VTAM address space for your terminal, though.

Look at it this way.  Ddnames are just MVS's way to telling OPEN DCB
(and OPEN ACB for VSAM) where to find what to open.  You don't OPEN
VTAM ACB's - at least not in the "conventional" way - so what do you
need a ddname for?  What you DO need is a UCB for the device, and
that is definitely present for each terminal, disk and tape drive
on your system.

When you think about it, how could another address space send your
terminal a message if your address space "owned" your terminal in the
normal sense?  Since whoever owns your terminal cannot be the sole
I/O-er thereof, why not make the owner a huge centralized bureaucratic
entity like VTAM?  (A proven methodology in the real world? :-)

>On the serious side, and I think related to this, is there a
>documented way to detect whether a program is running in the
>foreground or background?

Assembler:  EXTRACT FIELDS=TSO returns a byte which has the high-order
bit set if your job is a TSO foreground job.

Also, if there's a TSB address (ASCBTSB is nonzero), it's a foreground
TSO job.  You can't look at the TSB, but you can look at the ASCB to
see if one exists. Code:

         USING PSA,0
         L     R15,PSAAOLD          GET ASCB ADDRESS
         USING ASCB,R15
         L     R15,ASCBTSB          GET TSB ADDRESS
         LTR   R15,R15              IF THERE'S NO TSB
         BZ    NOTFORE              THEN NOT A FOREGROUND JOB

CLIST:  &SYSENV is FORE for foreground, BACK for background.
REXX:   SYSVAR("SYSENV") likewise.

None of the above methods distinguish "TSO in batch" (EXEC PGM=IKJEFT01)
from vanilla batch - both are "background" jobs.  You can easily check
for TSOness, apart from 'ground, by seeing if there's a PSCB.  If the
active JSCB doesn't point to a PSCB, it's background.  Note that you
have to make sure you're checking the ACTIVE JSCB, in case it's a
multistep job.  Code:

         USING PSA,0
         L     R15,PSATOLD          GET TCB ADDRESS
         USING TCB,R15
         L     R15,TCBJSCB          GET JSCB ADDRESS
         USING IEZJSCB,R15
         L     R15,JSCBACT          GET ADDRESS OF ACTIVE JSCB
         L     R15,JSCBPSCB         GET ADDRESS OF PSCB
         LTR   R15,R15              IF THERE'S NO PSCB
         BZ    NOTTSO               THEN NOT A TSO ENVIRONMENT
         ...
         IEZJSCB
         IKJTCB
         IHAASCB
         IHAASXB
         IHAPSA
         CVT   DSECT=YES

But probably the only "programmer interfaces" are the EXTRACT macros
and the CLIST/REXX methods listed above.

Things are further complicated by TSO/E 2.3's new IKJTSOEV service,
which allows you to create a TSO environment dynamically in a batch
job.  I have never tried this, so I can't tell you whether it
creates a PSCB and plugs its address into the JSCB, but I would
guess that it does.   It won't create a TSB, though - or at least
it shouldn't.

  - SEB

P.S. Expect flame from Leonard on how the TSB shouldn't be fetch
protected because it was historically so only to hide TCAM passwords
which are no longer used, etc., etc.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)