Thanks to all that responded! I appreciate the help! On Thu, Nov 16, 2023 at 9:10 AM Jay Maynard <[email protected]> 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 there's no need for an application > LU to pass the emulated terminal to VTAM. In either case, TAS handles all > communication with the device, and VTAM never gets involved. > > On Thu, Nov 16, 2023 at 9:02 AM Jay Maynard <[email protected]> wrote: > > > 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. Under those circumstances, there's no need tor an LBUILD/LU > > combination for that device, since VTAM's not talking to it. Instead, > > there's an LU definition in VTAM for TAS to pass the device through to > > VTAM, and that LU (which need not be the same one for every session) is > > what communicates with VTAM applications like TSO. > > > > On Thu, Nov 16, 2023 at 8:53 AM Michael Babcock <[email protected]> > > wrote: > > > >> 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 500LX box that contains a 3270 session with the same > >> LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a > >> LBUILD for B400 CUADDR anywhere in VTAM. I expected to see one however. > >> I assume then that the TAS is doing something under the covers and > >> as such VTAM doesn't need an LBUILD for B400. We do have LBUILDs for > >> other B4xx addresses (but they don't use TAS, they are for TSO). > >> > >> On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote: > >> > 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 question is that I thought a VTAM APPL with an > >> >> LUNAME of TERM140 was required but I do not see a TERM140 defined in > >> >> VTAM > >> >> at all. I’m not a network guy. Since this is working, I assume > >> >> it’s not > >> >> required. Can someone enlighten me? > >> > > >> > In simple words, LUNAME used in OSA-ICC session definition and > >> > emulator - it does NOT exist in any VTAM or TCPIP configuration. > >> > Instead, VTAM use device number (devnum), which is in turn not used in > >> > emulator session. However OSA-ICC session ties devnum with LUNAME. > >> > Note: the same devnum can be used by different LPARs and every LPAR > >> > has its own console/terminal. It is not shared, just "duplicate" > >> > devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely > >> > identify the device. > >> > > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to [email protected] with the message: INFO IBM-MAIN > >> > > > > > > -- > > Jay Maynard > > > > > > -- > Jay Maynard > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
