Michael
Sorry for rather a long post. The first part covers your original question
and the smaller second part covers your second question.
-
Here's the explanation of how a 3270 emulator and a 3270 application agree
to use presentation space dimensions dynamically:
1. The mode table entry specifies "unspecified screen size BIND", that is,
the 11th byte, the penultimate byte, of the PSERVIC operand specifies X'03'.
In addition, the 2nd byte of the PSERVIC operand must specify B'1' for the
first bit. This may be called the "query" bit and it permits step 4.
2. The 3270 application (primary logical unit - PLU) must be happy to use
the X'03' and the "query" bit in the BIND sent to the emulator (secondary
logical unit - SLU).
3. The 3270 emulator must be happy to accept X'03' and the "query" bit in
the BIND.
4. Following sending the BIND, the PLU sends a "query"[1] request to the SLU
and the SLU responds with configured presentation space dimensions (rows and
columns) - as well as other information.
[1] The full name is "Write Structured Field - Read Partition Query".
5. The application operates with the returned presentation space dimensions
as best it knows how.
For a little more information on exactly how the application operates, see
the last of the explanations of the fixed specifications below.
-
For comparison:
Here's the explanation of how it is/used to be when the only dimensions
available were 24 rows and 80 columns (mid-70's)[2]:
[2] There is/was another pair of dimensions (smaller), presumably provided
in order to be equivalent to the 2260 display device which the 3270 display
devices replaced, but it's generally been forgotten about. Since I checked
the 3174 Functional Description manual (GA23-0218-11) for this post, I see a
reluctance even to talk about the "model 1" 3270 display devices.
1. The mode table entry specifies "model 2", that is, the 11th byte of the
PSERVIC operand specifies X'02'.
2. The application (PLU) invariably is happy to use 24 rows and 80 columns
and X'02' is specified in the BIND sent to the 3270 controller microcode
(emulator) (SLU).
3. The 3270 controller microcode (emulator) is happy to accept X'02' in the
BIND when a "model 2" 3270 display device corresponds to the LU address - as
it almost invariably was in those early days.
4. There is no comparable step 4.
5. The application operates with the presentation space dimensions 24 rows
and 80 columns.
-
Here's the explanation of how it is/used to be when the dimensions other
than 24 rows and 80 columns were to be used and only those dimensions were
to be used (late-70's)[3]:
[3] This possibility was introduced when 3270 display devices with the
following dimensions appeared:
"model 3": 32 rows and 80 columns
"model 4": 43 rows and 80 columns
"model 5": 27 rows and 132 columns
Eventually other display devices appeared with other possibilities, an
significant one being the 3290 which, when used to the maximum for one
session, allowed 62 rows and 160 columns.[4]
[4] Shortly after the introduction of the 3290, I set up an exhibition stand
with 3290s configured for the old "model 2" dimensions. In spite of the fact
that the character font was no different than for a real "model 2" display
device, the greater separation made the 3290 presentation ideal for a small
audience of up to 10 observing a demonstration.
1. The mode table entry specifies specific presentation space dimensions,
the row size in the 7th byte of the PSERVIC operand and the column size in
the 8th byte of the PSERVIC operand, and the 11th byte of the PSERVIC
operand specifies X'7E'.
2. The 3270 application (PLU) must be happy to use presentation space
dimensions specified in the BIND image and that BIND image is sent to the
3270 controller microcode (emulator) (SLU). In case the application is not
happy to use the specified dimensions, it can change the BIND image
accordingly.[5] Alternatively, the application can just refuse to start the
session.
[5] It is perhaps important to mention at this point that the BIND image as
defined in the mode table entry associated with the definition of the SLU is
passed from the SSCP (VTAM) of the SLU to the SSCP (VTAM) of the PLU and the
SSCP of the PLU passes the BIND image to the PLU, the application, clearly
in the logic which is executed just before the PLU sends the BIND image to
the SLU, the 3270 controller microcode (emulator).
3. The 3270 controller microcode (emulator) must be happy to accept the
presentation space dimensions specified in the BIND. This originally
required that the "model" of the 3270 display device corresponding to the LU
address could "cope with" the specified dimensions. If the 3270 controller
microcode (emulator) is not happy to accept the presentation space
dimensions specified in the BIND, it returns a negative response to the
BIND.
4. There is no comparable step 4.
5. The application uses the presentation space dimensions as specified in
the BIND image.
-
Here's the explanation of how it is/used to be when one set of dimensions
were to be used for some subapplications (the second set below) and another
set of dimensions, typically, 24 rows and 80 columns, were to be used for
other subapplications, typically subapplications designed for the ubiquitous
original dimensions (the first set below) (also late-70's):
1. The mode table entry specifies one set of specific presentation space
dimensions, the row size in the 7th byte of the PSERVIC operand and the
column size in the 8th byte of the PSERVIC operand, another set of specific
presentation space dimensions, the row size in the 9th byte of the PSERVIC
operand and the column size in the 10th byte of the PSERVIC operand, and the
11th byte of the PSERVIC operand specifies X'7F'
2. The application (PLU) must be happy to use two sets of presentation space
dimensions specified in the BIND image and that BIND image is sent to the
3270 controller microcode (emulator) (SLU). In case the application is not
happy to use the specified dimensions, it can change the BIND image
accordingly. Alternatively, the application can just refuse to start the
session.
3. The 3270 controller microcode (emulator) must be happy to accept the two
sets of presentation space dimensions specified in the BIND. This originally
required that the "model" of the 3270 display device corresponding to the LU
address could "cope with" the specified dimensions. The "model" of the 3270
display device could always manage a first set of presentation space
dimensions which specified 24 rows and 80 columns.
4. There is no step 4 as described earlier.
5. The application uses the presentation space dimensions as specified in
the BIND image.
If the subapplication requires a presentation space corresponding to the
first set of dimensions, typically the older type of subapplication, the
presentation space is initialised with an "Erase/Write" code as the first
byte of the outbound request data. This has the effect of setting the 3270
controller microcode (emulator) to the dimensions as specified in the 7th
and 8th bytes of the PSERVIC operand.
If the subapplication requires a presentation space corresponding to the
second set of dimensions, typically the newer type of subapplication, the
presentation space is initialised with an "Erase/Write Alternate" code as
the first byte of the outbound request data. This has the effect of setting
the 3270 controller microcode (emulator) to the dimensions as specified in
the 9th and 10th bytes of the PSERVIC operand.
Note that where only one set of dimensions is specified (the X'7E' case
described above), whether the first byte of the outbound request data is an
"Erase/Write" code or and "Erase/Write Alternate" code, the 3270 controller
microcode (emulator) is set to the dimensions as specified in the 7th and
8th bytes of the PSERVIC operand.
Note that where the "query" function is used, step 4 in the very first
explanation, in effect two sets of presentation space dimensions are
returned and they are used as described here (the X'7F' case) except that
the values are returned from the 3270 controller microcode (emulator) rather
than having been specified in a PSERVIC operand.
In the case of 3270 controller microcode[6], the first set of dimensions is
24 rows and 80 columns and the second set of dimensions is whatever is
required (perhaps configured) for the device. Thus a 3174 on behalf of a
3278 model 5 would return a first set of dimensions 24 rows and 80 columns
and a second set of dimensions of 21 rows and 132 columns.
[6] Which microcode responds can be a little complicated and can depend on
whether the 3270 device connected to a 3270 controller is a "Control Unit
Terminal" (CUT) or a "Distributed Function Terminal" (DFT). There are also
some 3270 devices, such as the 8775, which incorporate the controller
function. Since the original post concerns only emulators, details of this
have not been covered.
In contrast to 3270 controller microcode, 3270 emulators can "do their own
thing". Exactly what and how it is specified should be found in the
documentation for the emulator. I tried looking up your emulator (EXTRA!
X-treme) but the online User's Guide was insufficiently detailed.
-
Full details on the above can be found in section 2.1.3.3, "Erase/Write
Alternate Command" in the 3174 Functional Description manual.
---
Comments on earlier posts:
1. Applications may have special affinity to particular dimensions because
they correspond to the relatively unintelligent display devices of the past.
Hence the mention of 62 rows and 160 columns which corresponds to the 3290
display device - first available around 1982 - when configured to use the
whole display surface for just one session. (The 3290 was popularly used to
support 4 simultaneous sessions presented concurrently where the dimensions
of all 4 were the traditional 24 rows and 80 columns.)
2. '"arbitrary and capricious" screensizes' are fine if the application
accepts them for what they are - that is, the person who wrote the
application doesn't consider the presentation space dimensions "arbitrary
and capricious". Peter Hankerer seems to be having problems with an
application which isn't quite as flexible as he would like and seems to be
making unwarranted assumptions when faced with "non-standard" column
dimensions.
3. D4C32XX3 is the IBM supplied mode table entry which includes the X'03'
specification in the penultimate byte of the PSERVIC operand. It does *not*
specify the "full screen" dimensions of the 3290 display device.
I'm mentioning this in order to be comprehensive. Tom Marchant and Shmuel
Metz have already pointed this out.
4. I assume "using the LOGON command interpreted" refers to possible
customization of Unformatted System Services (USS - the original USS not the
Johnny-come-lately UNIX System Services). It is *incorrect* to say that a
mode table entry cannot be specified when a customized USS table is offered
by the local VTAM system programmer. In the days before it became no longer
necessary to specify a mode table entry name which specified the
presentation space dimensions of the model of display that happened to be
plugged into a particular coax port on a 3274 or 3174 control unit, I used
to customize my USS tables so that the appropriate mode table entry name,
M2, M3, M4, M5 or M9 (for those 3290 dimensions) could be specified
immediately following the userid.
5. D4A32XX3 is equally as suitable as D4C32XX3 for this discussion since
both are for LU type 2. The only difference is in the RUSIZES operand since
the channel-attached SNA 3274 and 3174 controllers required a maximum
request unit size of 1536 which corresponds to the BIND code X'C7'. I could
never find a maximum specified for the non-channel attached 3274 and 3174
controllers and the responsible VTAM developer (Bruce Kohler I believe)
appears to have chosen 3840 (X'F8') arbitrarily.
Indeed however D4B32XX3 will probably not apply to this discussion since it
refers to an LU type 0 using 3270 data streams which corresponds to 3270
devices requiring translation between non-SNA channel programming and SNA
protocols within VTAM.
6. Peter Hunkeler mentions that there is a statement in his TELNET 3270
client which causes the "dynamic" mode table entry to be used. This is true
only if you have specified (or left to default) the appropriate association
to a suitable mode table entry when the TELNET 3270 server in Communications
Server IP receives the characters "IBM-DYNAMIC" during "device type"
negotiation with the TELNET 3270 client. By default this is D4C32XX3.
---
"How do I define a custom logmode?"
You can probably achieve everything you want using the IBM-supplied mode
table, specifically the D4C32XX3 mode table entry. However if you should
ever want/need to build your own mode table entry ("a custom logmode"), you
need to go to your VTAM systems programmer.
Ask him/her to do the job for you. He/she will need to code the mode table
entry as part of a mode table.
It may be that the definition of the LU which corresponds to your emulator
already has a MODETAB operand specified. If so, the new mode table entry
will be added to the specified mode table.
If the definition of the LU which corresponds to your emulator does not
already have a MODETAB operand specified, in other words, the mode table
entry currently used is taken from the IBM-supplied mode table, ISTINCLM,
your VTAM systems programmer will have to add the MODETAB operand to the
definition and create the mode table with your new mode table entry. The new
mode table is stored in the data set referenced by the VTAM procedure
VTAMLIB DD-statement.
In case your VTAM systems programmer has managed to rely completely until
now on the IBM-supplied mode table, I'm providing below an example based on
the D4C32XX3 entry in ISTINCLM. This also shows what I mean by the PSERVIC
operand which I refer to above.
myname MODEENT LOGMODE=myname, *
FMPROF=X'03', *
TSPROF=X'03', *
PRIPROT=X'B1', *
SECPROT=X'90', *
COMPROT=X'3080', *
RUSIZES=X'87F8', *
PSERVIC=X'028000000000000000000300', *
APPNCOS=#CONNECT
Of course, you replace myname with whatever name you would really like - in
upper case. Because MODEENT is an assembler macro you need to observe
assembler rules which means that the asterisks on all but the last line need
to be in column 72.
If this is the only mode table entry in the mode table, that is, your VTAM
systems programmer is creating the first mode table, you will need to frame
the MODEENT macro with a leading MODETAB macro (no operands) and a trailing
MODEEND macro (no operands) followed by the usual assembler END statement.
The following may be a little esoteric but it's worth covering:
If your VTAM installation is going to be investing in private mode tables,
you can benefit from the wisdom to be sure to have only one private mode
table for the whole installation, that is, all your VTAMs. When I first
started playing with mode tables, just about 30 years ago now, I created a
different mode table for each type of device and secondary application. In
very long hindsight, this was a mistake - although there was not the
slightest indication that this could have been a mistake in the late 70s.
While I was teaching the "Alias" function of SNI (SNA Network
Interconnection) in the late 80s, a clever student from France[7] noted that
only one private mode table per network, that is all VTAMs running under one
NetID, should be permitted. Otherwise the SNI "Alias" translation of mode
table entry names, mode names, doesn't make sense.
[7] Famed for their logic, the French!
When Low Entry Networking (LEN) and then APPN was introduced to VTAM in the
mid 90's, very many representations of logical units need to be created
dynamically. (These are dynamically created "boundary function" CDRSC
statements.) Where these representations of logical units are the secondary
logical units in sessions, they need to be associated with a MODETAB
operand. Only one dynamic MODETAB operand, as defined by the DYNMODTB start
option, may be specified. Thus there is again a need for a single private
mode table.
Chris Mason
----- Original Message -----
From: "Kuredjian, Michael" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Monday, 21 August, 2006 3:53 PM
Subject: Re: >27x132?
> How do I define a custom logmode?
----------------------------------------------------------------------
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
