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
<[email protected]> wrote:
> ...
>On Wed, 12 Jan 2011 12:26:52 -0500, George Rodriguez
><[email protected]> 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
><[email protected]>wrote:
>> ...
>>> On Wed, 12 Jan 2011 09:19:46 -0600, Chris Mason
>>> <[email protected]> wrote:
>>> ...
>>> >On Wed, 12 Jan 2011 07:48:07 -0500, George Rodriguez
>>> ><[email protected]> 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 [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
