Thanks to all that responded! I appreciate the help!
On Thu, Nov 16, 2023 at 9:10 AM Jay Maynard wrote:
> A bit of Googling reveals that TAS is a component of BMC MainView. Under
> those circumstances, that OSA-ICC session might never talk to a VTAM
> application like TSO at all; if so, then
As other said, TAS use mean no VTAM definitions.
However ...it doesn't matter.
MVS console is also out of VTAM scope.
But the rules are still valid: VTAM or TAS or CONSOLxx does not use
LUNAME from OSA-ICC. All of them use devnum only to identify the
terminal/console.
How to define non-SNA
A bit of Googling reveals that TAS is a component of BMC MainView. Under
those circumstances, that OSA-ICC session might never talk to a VTAM
application like TSO at all; if so, then there's no need for an application
LU to pass the emulated terminal to VTAM. In either case, TAS handles all
Yes, TAS is doing something under the covers. Since you're giving it a
device number to talk to the OSA-ICC device, that means that device is not
owned by VTAM at all, at any time; instead, TAS is talking to it directly
using channel programming like it's a channel-attached, non-SNA 3270
terminal.
Perhaps it would be better if I explain what we have. We use the BMC
suite of products including the Terminal Address Space (an alternate
access method I think they call it). Within TAS, there is a LOGON
UCB(B400) parameter. The B400 corresponds to the OSA-ICC definition.
We have a Visara
W dniu 16.11.2023 o 01:47, Michael Babcock pisze:
We have an OSA-ICC connection set up as a 3270 session type. The LU Name
in that definition is TERM140. The CUA is B400.We have a 3270 session
defined with the proper IP and the same LU Name of TERM140.This all
works as expected. My
There is a relationship between an OSAICC definition and VTAM if you want to
use that OSAICC session as an non-sna terminal.
You then need a VTAM non-SNA definition in your VTAM list.
The relation between the OSAICC session and VTAM is based on the CUU address
you specify in your VTAM major
Correct. Tony supplied what you need. A VTAM APL is for applications, like
CICS and TSO, or for things that emulate terminals in software running
under VTAM, like NetView Access or TPX. The OSA-ICC is, as far as VTAM is
concerned, nothing more than a hardware 3270; all of the TCP/IP magic is in
You don't need an APPL. You need an LBUILD:
LOCAL080 LBUILD
*
ICU1L088 LOCAL TERM=3277,CUADDR=088,ISTATUS=ACTIVE,MODETAB=ISTINCLM, X
FEATUR2=(MODEL2),USSTAB=USSNSNA,DLOGMOD=D4B32XX3
On exception. If you are using the terminal as a console only, then VTAM
does not need to have
So you are saying I don’t need a VTAM APPL statement with an LU defined?
On Wed, Nov 15, 2023 at 7:47 PM Jay Maynard wrote:
> A VTAM APPL is used for a program. The OSA-ICC looks to VTAM like a plain
> old 3270 terminal. The LU definition that mentions the device number is the
> only LU
A VTAM APPL is used for a program. The OSA-ICC looks to VTAM like a plain
old 3270 terminal. The LU definition that mentions the device number is the
only LU definition you need, or can have.
On Wed, Nov 15, 2023 at 6:47 PM Michael Babcock
wrote:
> We have an OSA-ICC connection set up as a 3270
We have an OSA-ICC connection set up as a 3270 session type. The LU Name
in that definition is TERM140. The CUA is B400.We have a 3270 session
defined with the proper IP and the same LU Name of TERM140.This all
works as expected. My question is that I thought a VTAM APPL with an
LUNAME
12 matches
Mail list logo
