Hi Chris,
I haven't responded to your previous post, because I'm waiting on a couple
of answers to questions that you asked. I didn't make the original changes
to the system in support of this change.
TN3270 server is a good description for the DAC unit. It's actually a switch
with the TN3270 software in the server (as you call it).
In my VTAMLST library, there's a TN3270A entry that looks like this:
TN3270A VBUILD TYPE=APPL
TN3270G GROUP AUTH=NVPACE, X
DLOGMOD=MTQRYPC, X
MODETAB=PBSBMODE, X
EAS=1, X
PARSESS=NO, X
USSTAB=VTMUSS0N
TELNI*** APPL USSTAB=VTMUSS5N
TELNE*** APPL USSTAB=VTMUSS0N
That was one of your questions or assumptions that you made. Yes we are
using z/OS Communication Server IP system for TN3270 support. The z10 that
we have uses the OSA-ICC only for the terminals and consoles used by
Operations in the Computer Room.
When I said that we switched from the DAC unit to the OSA, this is what was
coded it the profile used by TCP/IP:
ARPAGE 20
GLOBALCONFIG TCPIPSTATISTICS
IPCONFIG NODATAGRAMFWD SOURCEVIPA
SOMAXCONN 100
TCPCONFIG RESTRICTLOWPORTS INTERVAL 120
UDPCONFIG RESTRICTLOWPORTS
DEVICE VIPA01D VIRTUAL 0 VIPA
LINK VIPA01L VIRTUAL 0 VIPA01D VIPA
DEVICE OSA0402 MPCIPA NONROUTER AUTORESTART
LINK OSA0402LNK IPAQGNET OSA0402 VLANID 25 VIPA
DEVICE OSA0602 MPCIPA NONROUTER AUTORESTART
LINK OSA0602LNK IPAQGNET OSA0602 VLANID 25 VIPA
TRANSLATE
HOME
10.254.76.30 VIPA01L VIPA
10.254.76.31 OSA0402LNK
10.254.76.32 OSA0602LNK
BEGINROUTES
route 10.00.00.00/08 10.254.76.01 OSA0402LNK MTU 1492
route 10.00.00.00/08 10.254.76.01 OSA0602LNK MTU 1492
route DEFAULT 10.254.76.01 OSA0402LNK MTU 1492
route DEFAULT 10.254.76.01 OSA0602LNK MTU 1492
ENDROUTES
.
.
.
START OSA0402
START OSA0602
When you talk about TN3270 and TN3270E you mention that there's a comma
missing in front of the mode table which makes it a TN3270 without the E. As
I'm not sure of what I'm using, let me paste the TN3270E STC job:
//TN3270E PROC PARMS='CTRACE(CTIEZBTN)'
//TN3270 EXEC PGM=EZBTNINI,REGION=0M,PARM='&PARMS'
//STEPLIB DD DISP=SHR,DSN=SYS2.LOCAL.VTAMLIB
// DD DISP=SHR,DSN=SYS2.VTAMLIB
// DD DISP=SHR,DSN=SYS1.VTAMLIB
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//PROFILE DD DSN=OMVS.PROD.TCPIP.PARMLIB(TN32&SYSNAME),
// DISP=SHR,FREE=CLOSE
If I add the entry that you gave me (TELNETDEVICE IBM-DYNAMIC ,D4C32XX3) do
I leave the other entries the way they are or should I add the missing
comma?
Chris you've been very patient with me and I truly appreciate it...
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-332*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Six Consecutive Years*
On Thu, Jan 13, 2011 at 12:32 PM, Chris Mason <chrisma...@belgacom.net>wrote:
> George
>
> While you are preparing the descriptions of your problem for which I asked,
> I
> have a couple of topics to raise.
>
> I'll cover the first topic by reviewing the three ways one can set up a
> TN3270
> server[1] so that a TN3270 TCP connection can be concatenated to an SNA
> session supporting the 3270 data stream.
>
> 1. A TN3270 server in a logically external "unit" with a logical SNA
> connection -
> which can include a form of channel connection - to the SNA "boundary
> function" supported by the z operating system immediately or ultimately
> connecting to the z operating system supporting the primary LU in the SNA,
> necessarily LU type 2, 3270 session.[2]
>
> With this implementation of a TN3270 server, the TN3270 TCP connection is
> represented within the SNA environment[3] as an LU which is the secondary
> LU when in session with the primary LU application and is defined in VTAM
> as
> an SSCP-dependent LU statement subordinate to a PU statement. The LU
> statement may be generated dynamically if the "unit" has the necessary
> support.
>
> This is the type of TN3270 server I assume your "DAC unit" provides.
>
> 2. The z/OS Communications Server (CS) IP component TN3270 server and
> the very similar TN3270 server integrated as an "internal client" with
> "TCP/IP
> for VM".[4]
>
> With this implementation of a TN3270 server, the TN3270 TCP connection is
> represented within the SNA environment[3] as an LU which is the secondary
> LU when in session with the primary LU application and is defined in VTAM
> as
> an APPL statement, possibly and ideally, a model APPL statement.
>
> The types of session which can be supported here for "displays" can be LU
> type 2 or the particular implementation of LU type 0 for the support of
> 3270
> data streams, to be abreviated to "3270 LU 0".
>
> Based on the following:
>
> >...> TN3270E as a STC on z/OS using a VIPA address
> >...> TelnetGlobals
> >...> ...
> >...> EndTelnetGlobals
>
> I assumed that you had "switched" to this type of TN3270 server.
>
> 3. The OSA-ICC and similar "units" implement a TN3270 server where the
> TN3270 TCP connection has *no* representation within the SNA environment.
> It is however represented as a pre-SNA (the less clear "official" term is
> "non-
> SNA") channel connection from a 3270 device as was originally implemented
> by
> the 3272 control unit. As well as being used as a "console" device for the
> operating system, this channel connection can be defined to VTAM using a
> LOCAL statement and VTAM undertakes to perform "protocol conversion" such
> that the pre-SNA channel-atteched device takes on the appearance of an LU
> supporting "3270 LU 0".
>
> Worrying about whether I realy understood what your "switch" was all about
> and noting the following from your "Subject":
>
> >...> Switching a DAC unit with OSA
>
> I realised there was a possibility for massive confusion and your "OSA"
> just
> might be an "Integrated Console Controller" (ICC) use of an OSA feature -
> which has nothing whatsoever to do with z/OS CS IP component.
>
> Of course it still could make sense to mention the OSA feature as
> characterising the "switch" since it could be providing the interface from
> the
> IP node to the IP-supporting media all in support of the TN3270 server.
>
> -
>
> A quick test to be sure we are all on the same wavelength is to ask whether
> the named "session partner" for the CICS "session" is defined in VTAM as an
> APPL statement, a LOCAL statement or something else.
>
> - If it's an APPL statement, your TN3270 server is indeed the z/OS CS
> TN3270E server.
>
> - If it's a LOCAL statement, your TN3270 server must be an OSA feature
> configured as an OSA-ICC (channel type OSC).
>
> - If it's something else. that will be interesting!
>
> As a way of confirming that the configuration from which you were
> "switching"
> was the "outboard" TN3270 server I described as 1 above, it would be
> interesting to be assured that the named "session partner" was defined in
> VTAM as an LU statement.
>
> Precisely which of the TN3270 servers you were using is the first topic
> covered.
>
> -
>
> The second topic relates to your TELNETDEVICE statements.
>
> I need to rely upon one assumption and one intention for this discussion.
>
> - I need to assume that the "DAC unit" was an "outboard" TN3270 server and
> necessarily supported LU type 2.
>
> - I can see from the TELNETGLOBALS block you posted that you are intent on
> using the mode table entries in support of your SNA sessions which
> support "3270 LU 0" - although you have specified the default values.
>
> There are three points to make about this:
>
> 1. The first point concens the LU type.
>
> Note that this isn't an academic point; it affects the "feel" of the use of
> the
> 3270-based communication.
>
> LU type 2 operates in an half duplex manner whereas "3270 LU 0" operates in
> a full duplex manner. The users of the PCs running the TN3270 client will
> be
> sensible to the different behaviour. According to my assumption, they will
> be
> used to half duplex operation and may become confused by full duplex
> operation.
>
> System programmers tend to be quite happy to run their 3270 display
> conversations in full duplex mode. They expect to be able to jump in at any
> time and "do stuff" and are happy to compensate for any mess they create.
> Developers, close cousins to system programmers, expect the same from their
> 3270 display conversations and have tended to impose this preference in
> their
> defaults. I know about this because I have discussed precisely this point
> with
> the culprits! Typically customer-facing users expect to have a much more
> regulated conversation with their "server computer" and absolutely do not
> want to "screw up" because they "jumped in" at a time when the program was
> not ready for them. Where the regulated half duplex LU type 2 protocol is
> used, canny users might know about the "Attn" key - or its PC keyboard-
> mapping equivalent - as a way of "jumping in" - but "jumping in" in a
> controlled
> manner that both parties agree about. That is the benefit of "business-
> oriented" half duplex behaviour as opposed to "geek-oriented" full duplex
> behaviour.
>
> 2. TN3270/TN3270E
>
> Ahem, you claim - almost certainly quite correctly - that you will be using
> RFC
> 2355 TN3270E. Unfortunately, the mode table entry names you have specified
> in your TELNETGLOBALS block
>
> >...> TELNETDEVICE 3278-2-E NSX32702
> >...> ...
> >...> TELNETDEVICE 3279-5-E NSX32705
>
> are all in the first positional parameter position and not in the second
> positional parameter position which means that they will apply when TN3270
> -
> without the "E" - protocols are agreed between the TN3270 server and the
> TN3270 client. It is the name specified in the second positional parameter
> position which applies when TN3270E protocols are agreed between the
> TN3270 server and the TN3270 client.
>
> The code specified between the TELNETDEVICE statement and the pair of
> mode table entry names corresponds to the code used during TN3270 or
> TN3270E negotiation. It is a code created by the TN3270 client logic. I
> tried
> finding out how this was specified in the Attachmate product website but,
> although I think I found a likely prompt, the text was just too coy!
>
> Somehow what you specify is converted into one of the "device-type" codes
> mandated by RFC 2355 for TN3270E negotiation. I assume you have some
> deployment process which supplies the products installed on the PCs used by
> the TN3270 clients and how these products are customised. You should be
> able to determine from this standard customisation which of these codes is
> generated by the TN3270E negotiation. You need then only specify the
> TELNETDEVICE statement for that code.
>
> If your standard customisation causes the "IBM-3278-3-E" code to be
> generated, you need specify only the following:
>
> TELNETDEVICE IBM-3278-3-E ,SNX32703
>
> Notes:
>
> a. That vital comma
>
> b. I have used a mode table entry from the IBM-supplied table.
>
> c. I have actually used the mode table entry name which is used by default
> without your needing to specify anything. However, as always, it helps to
> specify relevant statements and parameters even if they are the default
> values.
>
> d. For some reason or another, the TELNETDEVICE statement seems to be
> able to assume that the code is preceeded by "IBM-" without there being any
> need to include those characters in the code as specified. You will see
> that
> the codes in the famous "Table 33. Device type and logmode table" in the CS
> Configuration Reference manual does include the "IBM-".[5]
>
> Incidentally, there never were nor never will be models of the 3279 other
> than
> 2 and 3. In any case codes including "3279" no longer feature as codes used
> by implementations of TN3270E according to RFC 2355. It's a bit tricky
> trying
> to pin down where the ficticious 3279 codes came from since the original
> RFC
> addressing the topic, 884, eschews them!
>
> IBM-DYNAMIC (no pre-defined display size)
>
> 3. What I would like you to consider since it is likely that the Attachmate
> emulator supports it, is so to set up the emulator that it uses the IBM-
> DYNAMIC code. That way you need never worry about how the users set up
> the presentation space dimensions in those cases where the users are
> sufficiently savvy to experiment with this potential capability. For other
> users
> there will be no perceived difference.
>
> The TELNETDEVICE statement would appear as follows:
>
> TELNETDEVICE IBM-DYNAMIC ,D4C32XX3
>
> Again I have specified a suitable mode table entry from the IBM-supplied
> table
> which is also the default.
>
> -
>
> Chris Mason
>
> -
>
> [1] I describe always a TN3270 server - and a TN3270 client. These days
> TN3270 servers and clients will (should) always be able to support RFC 2355
> TN3270E as well as TN3270 protocols prior to the TN3270E "tidy-
> up"/enhancements.
>
> [2] If the session is for a "printer" rather than a "display", the LU type
> can be
> type 1 (without the use of function management headers) or LU type 3.
>
> [3] Some would say "network" but it may be so rudimentary a "network" as
> hardly to justify the use of such a term!
>
> [4] I believe there are approximately similar products supported by the
> implementations of an IP node and related programming supported in a VSE
> environment.
>
> [5] Checking my lecture notes last updated for "TCP/IP for MVS" Version 3
> in
> November 1995, I see that this is in support of "migration" from earlier
> implementations of TN3270 support.
>
> On Wed, 12 Jan 2011 14:09:07 -0600, Chris Mason
> <chrisma...@belgacom.net> wrote:
> > ...
> >On Wed, 12 Jan 2011 12:26:52 -0500, George Rodriguez
> ><george.rodrig...@palmbeachschools.org> wrote:
> >
> >>Hi Chris,
> >>
> >>Now I'm 100% confused... It's probably the way I'm describing the
> problem.
> >>Let me show you examples of messages that CICS provides when things
> >happen:
> >>
> >>This is for user TARANTI:
> >>
> >>CICPTOR is the CICS that owns the terminals.
> >>
> >>06:28:42 TELNE870 Signon this is the initial startup
> >>06:35:53 TELNE875 Signon 7 minutes later the user is signing in again
> >>06:35:59 TELNE875 Signon a few seconds later signing on again
> >>06:36:16 TELNE875 Signon
> >>07:08:38 TELNE875 Signoff
> >>07:32:50 TELNE870 Signoff
> >>07:59:58 TELNE1B0 Signon
> >>08:00:02 TELNE1B0 Signon
> >>09:21:44 TELNE1B0 Signoff
> >>09:51:38 TELNE933 Signon
> >>11:57:24 TELNE51A Signon
> >>11:57:27 TELNE51A Signon
> >>12:01:04 TELNE933 Signoff
> >>
> >>CICPTM is the CICS where the application is.
> >>
> >>07:06:20 TELNE875 timed out if the initial start up is at 6:28 and
> >>inactivity happens 30 min. later, this is ok
> >>07:30:09 TELNE870 timed out
> >>09:18:27 TELNE1B0 timed out
> >>11:57:51 TELNE933 timed out
> >>12:42:42 TELNE51A timed out
> >>
> >>I appreciate your help...
> >>*
> >>*
> >>*George Rodriguez*
> >>
> >>On Wed, Jan 12, 2011 at 11:19 AM, Chris Mason
> ><chrisma...@belgacom.net>wrote:
> >> ...
> >>> On Wed, 12 Jan 2011 09:19:46 -0600, Chris Mason
> >>> <chrisma...@belgacom.net> wrote:
> >>> ...
> >>> >On Wed, 12 Jan 2011 07:48:07 -0500, George Rodriguez
> >>> ><george.rodrig...@palmbeachschools.org> wrote:
> >>> >
> >>> >>Before the Christmas break, we moved the TN3270 configuration that
> >was in
> >>> >a
> >>> >>DAC unit to z/OS and started using TN3270E as a STC on z/OS using a
> >VIPA
> >>> >>address. The environment is as follows:
> >>> >>
> >>> >>CICS/TS v3.10 with a TOR and an AOR
> >>> >>TCP/IP v1.9
> >>> >>z/OS v1.9
> >>> >>Attachmate EXTRA! Enterprise 2000
> >>> >>
> >>> >>The problem is that a user is timed out after a 2-3 minutes and it
> takes
> >>> the
> >>> >>user all the way back to the USSTAB. In CICS I have coded
> >USRDELAY=30
> >>> >and in
> >>> >>the TCP/IP profile parm we coded interval 120 on the TCPCONFIG card.
> >>> >>
> >>> >>Any and all help is greatly appreciated.
> >>> >>
> >>> >>*George Rodriguez*
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
Home of Florida's first LEED Gold Certified School
Under Florida law, e-mail addresses are public records. If you do not want your
e-mail address
released in response to a public records request, do not send electronic mail
to this entity.
Instead, contact this office by phone or in writing.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
