Re: OSA-ICC Connection Question
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 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 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 > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > > > > -- > > Jay Maynard > > > > > > -- > Jay Maynard > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 terminal or console in z/OS? It is well documented IMHO and ICC does not change anything. Just do it as for 3174-xxL attached terminals. -- Radoslaw Skorupka Lodz, Poland W dniu 16.11.2023 o 15:53, Michael Babcock pisze: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 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 > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > -- > Jay Maynard > > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 node. Example: * * NON-SNA VTAM TERMINALS VIA OSA-ICC KAART * LBUILD LOCAL TERM=3277,CUADDR=03D0,FEATUR2=(MODEL2,SELPEN), X USSTAB=USSTSON, X DLOGMOD=NSX32704, X MODETAB=ISTINCLM CUADDR 3D0 must be known on the OSAICC card. There is no relation beween the VTAM LU and the OSAICC LU name, but it's wise to keep them the same :) br, Luc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 the firmware, below the level where VTAM sees or cares about it. On Wed, Nov 15, 2023 at 9:04 PM Michael Babcock wrote: > 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 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 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? > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > -- > > Jay Maynard > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 it defined. Tony Thigpen Michael Babcock wrote on 11/15/23 10:02 PM: 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 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 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 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 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? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Jay Maynard > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
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 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? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
