Ron
Just going on the message sequence
IST663I INIT OTHER REQUEST FAILED , SENSE=083A0002
IST664I REAL OLU=AGFNET.AGFEI REAL DLU=AGFNET.N02TCE20
IST889I SID = EE93F7C97FD4F39D
IST264I REQUIRED RESOURCE N02TCE20 DISABLED
IST314I END
it is very clear that a link connection has been successfully established.
Then there has been a session initiation request - which can only happen
over an available session path - this isn't any of your flaky IP, folks! The
session initiation request has failed because the destination and secondary
LU is not in an enabled state. The LU has been activated but the ACTLU
response has a code which indicates disabled state.
One reasonable explanation might be that the program running the NJE
function in the AS/400 hasn't completed starting up.
-
The explanation of the sense code 083A0002 is as follows:
<quote>
Sense code 083A
LU not enabled: At the time an LU-LU session initiation request is received
at the SSCP, at least one of the two LUs, though having an active session
with its SSCP, is not ready to accept CINIT or BIND requests.
Bytes 2 and 3 following the sense code contain sense-code-specific
information.
...
0002 The SLU is not enabled.
</quote>
-
Just to be complete, I even checked the JES2 message. Here are the results -
it's the last of the 15 £HASP094 messages by the way and LookAt! just gives
you the first which is useless:
17 - it's an OPNDST request, in other words, a session setup is being
attempted
14 - means that JES2 is trying, in its words, not VTAM's, a "connection
sequence"
1002 - is the RTNCD-FDBK2 combination
short explanation: Logical unit inhibited for sessions
longer explanation: You attempted to initiate a session and one of the
logical units in the requested session is inhibited.
The remaining codes are of no particular interest, except the LU name at the
end, of course.
Now this discussion started by claiming that an LU name needed changing. How
might that relate to the disabled secondary LU?
Incidentally it would be quite incorrect to say there is nothing wrong with
the switched definition but it works so what is wrong with it[1] is
incidental to the reported problem.
Looking over a bit of confusion in previous posts - I hope I'll be excused
characterising them so - I can make the following comments:
1. Unless the NJE application on the AS/400 has consistently been caught in
the middle of being activated in some way - highly unlikely I would expect -
this is not a timing problem.
2. Since the connection is necessarily in place, there is no problem with
the connection - just in case a modem is involved - which, given a
"switched" definition is used, is not impossible, but unlikely.
3. I'm not sure what "online" might mean. The messages tell us that the
secondary LU is *active*, only it is not *enabled*.
4. Which side a connection is started affects the types of definitions used
for the connection, strictly the definition of the adjacent link station, in
the two platforms. However, since it is clear from the messages that a
connection has been established, this is a red herring.
5. The recollection of multiple LUs may have been RJE rather than NJE. For
example, if the AS/400 running RJE emulated a 3776 or 3777 MLU model,
multiple LUs would have been involved. An NJE connection between JES2 and
JES2, RSCS and RSCS and JES2 and RSCS required only one LU at either side.
Although I'm not familiar with the AS/400 implementation of NJE, I would not
expect the requirement to be different.
The possibility that there might be a suitable redbook was mentioned -
thanks, Mark.
Going to the redbook site and searching with "AS/400 and NJE" gets 3 hits.
The first AS/400 VM/MVS Bridge Configuration and Operations, GG24-4382-00,
is the best since it involves MVS although NJE does not actually appear in
the title. The second does have NJE in the title but involves POWER. Both
redbooks are quite small and download in a jiffy.
Given the extensive definitions present - a little bit woolly on the VTAM
side and involving antique configuration features such as NCP,
nevertheless - this should be adequate.
I happened to notice that the "Start QSNADS Subsystem" (STRSBS QSNADS)
command on the AS/400 side causes a NOTIFY request to flow from the
secondary LU to the SSCP with the information that the secondary LU has
entered the *enabled* state. Perhaps it is this command which needs to be
entered.
Incidentally, I see that "vary on" is an AS/400 "thing" in the context of
SNA entities so maybe Ed wasn't all that far off the mark - hum, no pun
intended. <g>
---
[1] C02TCED PU IDBLK=056,
IDNUM=ADAF0,
IRETRY=YES,
MAXDATA=4105,
MAXPATH=1,
ISTATUS=ACTIVE,
MAXOUT=7,
PASSLIM=7,
PUTYPE=2,
DISCNT=NO,
MODETAB=LOGMLU62,DLOGMOD=LOGMLU62,
USSTAB=USSSNAGF,
VPACING=1,
SSCPFM=USSSCS
N02TCE20 LU LOCADDR=20,MODETAB=LOGMNJE,DLOGMOD=JESNJE
I'm pretty sure that the AS/400 uses a format 3 XID so CPNAME is an
alternative to IDBLK/IDNUM for recognition. I find CPNAME is a bit neater
than IDBLK/IDNUM and not needing to dream up an IDNUM value is one
definition chore less.
IRETRY and PASSLIM do have a role in a switched PU statement but only when
used with a 3746 defining a multipoint line in the context of "external"
DLUR support. It is quite amazing that these operands were defined for a
switched PU statement back in the late '70s when they could start to have
any relevance only in the late '90s!
MAXDATA is ignored since the value is supplied by the AS/400 in the format 3
XID.
MAXPATH is obsolete - even if a PATH statement were present.
As I guess the connection runs over a LAN, you may want to set MAXOUT to a
larger value. Just in case NCP is involved, you can judge a better value by
using NTuneMON. You can reduce acknowledgements by using a higher value and
so improve performance.
You can also improve performance by increasing the PACING values. That's a
tricky topic and probably involves more than just the VPACING operand you
show here. You should use NetView Session Monitor trace data to examine how
much unnecessary extra traffic low pacing values impose.
I didn't see anything in the redbook about USS tables and I strongly suspect
that session setup relies purely on formatted requests. Thus I would expect
SSCPFM=FSS was more appropriate than SSCPFM=USSSCS as the way the operand
should be coded for the NJE LU. In fact the redbook authors for both
redbooks seem to be confused over this operand.
What appears to be the case is that SSCPFM=FSS just about literally means
nothing. If an human end-user is going to be entering text strings in order
to log onto or logoff from an application, VTAM needs to know what quirks
may be present in the text strings. On the other hand, if formatted requests
are used which need no translation by VTAM, this is evident from bits in the
request header. Thus there is no need to go looking for the code which
defined the type of character string - since there is no character string -
obvious really. Thus you can specify whatever you like for the SSCPFM
operand if there will never be any use of the "unformatted system services"
(USS).
It seems I have to thank the redbook residents who wrote these two redbooks
for this insight and to think I've been teaching this topic for so many
years without having appreciated what SSCPFM=FSS really means - nothing!
Chris Mason
----- Original Message -----
From: "Ron Wells" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Monday, September 10, 2007 11:15 PM
Subject: Re: JES-APPL
well...think there is a as400 problem/confusion ..?
the NJE on as400 comes from Comm Util's V5R4... anyone ever deal with that
before... our guy is trying to get info from IBM but??
guess I'll open ETR and see if IBM can tell us where we are going wrong
..so far as400 guy is batting zero with them ..
----------------------------------------------------------------------
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
