🚀 go-pugleaf

In article <APPC-L%94011116201254@AMERICAN.EDU>, Steve Joyce
<sjoyce@VNET.IBM.COM> writes:
|> I sent your note to one of the key AIX SNA developers. Here is
|> his response.

Thanks for the followup, but I have been able to uncover the cause of
the error, EACCESS, which is in fact bogus/misleading, as permissions
are not at issue.

After searching in IIN/INFO I discovered a similar problem report which
pointed to misconfiguration (duplicate named local and remote LU names).
A little further digging into SNA Services/6000 problem determination
aids led me to the internal error log, and identification of the failure
apparently in CNOS processing.  This led me to look at the MODE/LIST
configurations, at which point I discovered I had included SNASVCMG and
CPSVCMG in the mode list for the connection, but had not explicitly
configured the modes (nor are they apparently needed) -- as a futher
point of note, "verifysna" did not catch the error.  Removing these
mode names from the list resolved the problem.

Your Raleigh contact suggested the following snaopen interface change:

|> If the output is empty, then he definitely does not have SNA installed
|> correctly.  If the /dev/sna file exists, then we should assume that his
|> SNAOPEN is not formed correctly.  Here is an example of a proper
|> SNAOPEN:
|>
|>    cid = snaopen("/dev/sna/conn_name");

Note that I had tried this specification previously; it fails with an
EEXIST error.  Apparently the full path designation is required for the
"open" interface, but "snaopen" accepts only the connection profile name.

Again, thanks for the followup.


--
-----------------------------------------------------------
Steve Jenisch                 SAS Institute Inc.
sassjj@unx.sas.com            SAS Campus Drive
919-677-8000 x7956            Cary, NC  27513
-----------------------------------------------------------