jra@bally.Bally.COM (John Anderson) (09/19/90)
okay, here we go... we are going to port all of our stuff to rs6000, don't flame me for asking about RT stuff: anybody successfully gotten conversations between an RT and AS/400? we (RT) can successfully send the AS/400 stuff, but not vice versa... we were successful with 2-way conversations with a system 38 but not as/400 - is there some trick to snaconfig or what? the rtfm approach is an easy answer, but most of us are too busy to read something the size of a phone book about something that we don't like. thanks. -- john anderson jra@grommet.bally.com Bally Mfg. Reno NV ///// Flygande tefat (tomat, ost, champinjoner...)
dukew@binky.sybase.com (Wayne Duquaine) (09/20/90)
John:
What types of error messages or error return codes are you seeing
between the RT and the AS/400. It sounds like a config error either on
the RT or on the AS/400, but without some kind of error message or error
sense code (or trace), it's tough to tell where the cause is.
If your RT can send to the AS/400, but the AS/400 cannot send to you,
I would lean toward the AS/400's gen (created LU or other objects) being out
sync with the RT's config. The AS/400 should be kicking out some sort
of error message to either the console or the program. It should also be
recording a message to its error log. Failing in that, you'll have to get
a copy of the trace between the two systems to try to divine what is
going wrong.
BTW: porting SNA code between the RT and RS/6000 is a good news/bad news
situation. The good news is, the port is extremely easy. It took about 1
day total for all our code. The bad news is that the RS/6000 SNA code
is buggy as all get-out. The original SNA Services code on the 9021 "golden"
release had a mean-time to failure of 90 seconds when we would stress test
it. (The same tests on the RT run 24+ hours without a problem.)
With the "3001 update", the MTTF is now up to about 1 hour. Allegedly, there
is another update supposed to be coming "real-soon-now". To make matters
worse, their level 2 tech support people are not very SNA savvy, and the
problem submission process is cumbersome (Level 2 has to try to recreate
the problem on their system before giving it over to development) so getting
quick resolution of SNA Services problems borders on being an oxymoron.
Apparently IBM's philosophy is: why let savvy SNA developers directly talk to
RS/6000 SNA developers, when it is so much more fun to put a naive (and not
fully trained) bureaucracy in between, and let everyone play "20 questions".
Hope this helps.
Wayne.
standard disclaimer applies. I speak for myself only ...