Barbara
You asked so here's my best shot at the answer:
D - *D*efault because the mode table entry is in the "default" table ISTINCLM
and, since this is always present concatenated after any private mode tables
(MODETAB operand of the LU or LOCAL statement), it implies a mode table
entry name (mode name) naming standard - not that it was ever published as
such to my knowledge
4 - because the mode table entry is relevant to a 327*4* as opposed to a
327*6*, these being the two types of controller available at the time the vast
number of 3270 mode table entries were added to ISTINCLM
C - because the mode table entry is for a "C" model, as opposed to an "A", "B"
or "D" model
32 - because mode table entry applies to the range of devices are those
beginning with the number "32"
XX - because these particular mode table entries are of a general nature and
so don't belong to any particular model - a bit weak this one!
3 - a reference to the all-important X'03' in the penultimate byte of the
PSERVIC operand which gives the mode table entry it's flexibility with respect
to presentation space dimensions
Actually, I guess you're right, "intuitive" it ain't!
In fact, you'd have to ask one Bruce Kohler who dreamed up the mode table
entry names - or perhaps a successor who may have been responsible for
these one ending in "3" - what he had in mind when dreaming up the names.
Recall that they had to be valid in a "mode table entry" ("mode name") "name
space" with only 8 characters - typical IBM limitation - to play with. Although
you may feel that, with private mode tables, you have more flexibility, it
became clear to any who had to bother with it - and German customers had
to more than most incidentally - that, when using the "alias" function with
interconnected SNA networks, even with private mode tables, there is only
one "mode table entry" "name space".
All this to say that, in principle, you need to be careful not when dreaming up
names for your mode table entries.
Or - there's nothing so simple that "network guys" can't make it complicated!
On a serious note, you may like to ask your "network guys" to look into setting
up D4C32XX3 - or a private equivalent - as the mode table entry to be used
universally, thereby allowing the emulator user total control of the rows and
columns without reference to mode table entry names - or Unformatted
System Services (USS) commands such as your nvasxx7 with the mode table
entry name built into it.
It's important that both emulator and application program "understand" the
Read Partition-Query exchange but that's what I told my students up to 20
years or so ago now. I'd be amazed if there were still an application that
didn't
recognise Read Partition-Query and, as I said, any emulator you were tempted
to use these days should contain this support.
Getting back to the topic in hand, I've bee assisting a customer recently
using "Extra" and we couldn't get away from the rows and columns implied by
the standard 3278 model. If there's anyone still reading this who knows
different, perhaps they can jump in.
Chris Mason
On Wed, 25 Feb 2009 12:38:57 +0100, Barbara Nitz <[email protected]>
wrote:
>Chris,
>
>given that I have no clue when it comes to network things - I asked my
network guy. That's his answer:
>"Yes, he's right. I tried. It works with Logmode=D4C32XX3. Then one
wouldn't need a specially defined one."
>
>Having said that, I am now using 62x162 primarily because I don't have to
fiddle with the .ws file of pcomm anymore - version 5.9 allows it to define via
the definition panels (and will not overwrite when I have to change other
things).
>
>And, the logmode name d4c32xx3 isn't exactly intuitive, is it? while the name
of my logmode is: snx62162 (as in sna extended 62 by 162) <vbg> And my
network guy has this logmode name in the name of the netview access, so all
I need to remember is nvasxx7 - with the 7 standing for the logmode.
>
>Best regards, Barbara
>--
>Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
----------------------------------------------------------------------
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