John
Glad to have been of assistance.
So, it looks like we forgot to configure NVAS to support modern emulators
(my default MODEENT is D4C32XX3, which NVAS apparently presents to VTAM
as DYNAMIC). When I override the MODEENT at CINIT time with EXT32782
(locally-defined clone of SNX32702 but with smaller RUSIZEs), the relay
mode logons within NVAS work but I'm stuck with a 24x80 screen size.
I think I finally worked out what you are saying here. You first post was about
a message which indicated total failure to start the relay session. Now you are
adding that you succeed in getting a relay session but only when you override
the LOGMODE parameter (the name of the MODEENT macro in the mode table)
with EXT32782 - rather than D4C32XX3, when you enter the equivalent of the
LOGON command (which goes on to create a request which eventually enters
NVAS as the SNA CINIT request). However your relay session does not have
the presentation space dimensions you want.
In other words I would have preferred it if you had said
When, in my USS (Unformatted System Services) LOGON command, I specify
EXT32782 in order to override the default LOGMODE parameter ... in place
of When I override the MODEENT at CINIT time with EXT32782 ... That way
people reading the archives for elucidation stand a chance of following what is
going on without having to puzzle themselves too much!
Anyhow, looking at the codes you mentioned from the message in the NVAS
log, we can determine the following:
RPLREQ = X29 means that the VTAM request was a REQSESS, the call used to
request that the local SSCP, VTAM, initiates a session where the current
program will be the *secondary* LU in the session.
Incidentally, you have to know to go to an Appendix of the Communications
Server SNA Programming manual and then look up a control block code in order
to be able to translate this code to something that might start to mean
anything to you!
RTNCD = X14 translates to decimal 20 and, in the panoply of VTAM error
conditions, one which is assigned the generic code 20 officially means that the
program is still in development and that the programmer needs to go and sort
out a logic error!
FDBK2 = X4B is the more specific code within the generic return code. This is
described as the following:
quote INTRPRET sequence or LOGMODE not valid, or cryptographic
incompatibility /quote
which is still pretty general but at least mentions LOGMODE so, if you know
you are not using an INTRPRET sequence or cryptography, you may now be
focused on something to do with mode table entries.
The further explanation, stripped down to the LOGMODE angle, says the
following:
quote
You issued an INQUIRE, OPNDST, SIMLOGON, REQSESS, or CLSDST
OPTCD=PASS macroinstruction. Either the NIB for this request specified a
logon mode name that could not be found in the logon mode table for the
logical unit named in that NIB or something involving cryptography.
/quote
SENSE = X08210002 means the following:
quote
Sense code 0821
Session parameters not valid: Session parameters included on a BIND were not
valid or not supported by the half-session whose activation was requested.
The session parameters are usually obtained from the logmode table entry.
Bytes 2 and 3 following the sense code contain sense-code-specific
information.
0002
Mode name at CP not valid: The specified mode name was not recognized by
the CP.
/quote
which actually tells us no more that the RTNCD=X14/FDBK2=X4B did.
There are a number of those usually very helpful VTAM hints in the
Communications Server IP and SNA Codes manual. However, they do not
address what I guess NVAS has done which is to try to specify a particular
mode name for the session for whatever reason.
It seems you are aware of whatever these internal machinations on the part
of NVAS are and know what needed fixing - once you had appreciated that
NVAS was feeding VTAM an invalid mode table entry name for the ongoing
relay session to CICSTECH.
(my default MODEENT is D4C32XX3, which NVAS apparently presents to
VTAM as DYNAMIC).
Presumably the explanation is somewhere in there. I don't know where
DYNAMIC comes from here. It is not a mode table entry name in ISTINCLM
although there could be such an entry in a private mode table which would
need to be available to the NVAS APPL statement used for the relay session
to CICSTECH.
The name DYNAMIC may be related somehow to the TN3270 device code
DYNAMIC or IBM-DYNAMIC which maps to mode table entry name D4C32XX3
by default.
Chris Mason
On Fri, 17 Jul 2009 09:08:50 -0500, Chase, John jch...@ussco.com
wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Chris Mason
John
I'm not familiar with NVAS but this messages looks like the sort that
is
presented to a feeble end user who could not cope with complicated
technical
explanations and so the ridiculous words network constraints are
used which
could
