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

Reply via email to