Hello Folks @ 3000-L,

Re: sockets patches

I have watched a thread where concerns have been expressed about
sockets on 6.0 and I find the experiences being discussed are not
common among customers who are running sockets applications on
MPE/iX 6.0.  I know a lot of folks out here on 3000-L are very
successfully running their sockets applications on 6.0.

The specific SR being referred is 8606-125590 and is fixed in
NSTFDM2 6.0 Beta Test.  Since this patch is Beta Test it is not
being distributed unless you actually experience a problem
identified in the patch.  In this case the abort is a SA1047 out
of IP code i_inbnd_frag.where_to_merge+$14 and the solution to
the problem was to make a heap structure IP was working with
memory resident.

This abort has been seen multiple times at ONE customers site,
but has NOT been seen by any other customers site EVER before or
since it was seen at this site.  I would go as far to say that
it requires a unique environment to drive this abort and that
the risk of installing a Beta Test patch "in this case" far
outweighs the risk that you will ever see this abort before
you have a chance in the future to install a General Release patch
which will include this fix.

I have also seen references in this thread that 6.0 Sockets is
different than 5.5 Sockets... I wish I could say this was true
and that we have all kinds of new features, but I have to disappoint
you.  The 6.0 Sockets code and for that matter the entire 6.0
NS-TRANSPORT code is approximately equal to 5.5 NS-TRANSPORT with
patch NSTFD10 (A General Release patch built 1/23/98).

If we consider the current General Release patches for NS-TRANSPORT
for both 5.5 and 6.0 we can say:

  NS-TRANSPORT 5.5 with General Release patch NSTFDJ7
is approximately equivalent to
  NS-TRANSPORT 6.0 with General Release patch NSTFDJ5.
and this includes the sockets code.

If you plan to update to MPE/iX 6.0, I would highly recommend you
install the appropriate 6.0 General Release patches.

I have also herd concerns expressed about problems reaching the
limits of the inbound buffer pool... The buffer pool for our
purposes is a area where link drivers can perform Direct Memory
Access (DMA) writes and then pass the pointers to the Upper level
Protocols TCP, UDP and a few less known.  Once again sorry to
disappoint you, but NO changes in the Buffer Manger and Inbound
Buffer Pools from 5.5 to 6.0.  Actually I can not think of a bug
fix in years to this subsystem, but this sort of makes sense since
every link connected to the 3000 passes every frame received and
every frame sent through these buffer pools.

Buffer pools can be configured too small for increased traffic
levels between systems... and some of these pools can be increased
in size within NMMGR.  Most frequently reaching the limit of a
buffer pool is the result of 1) A network storm or 2) A rogue
application which is not performing RECV's in a timely manor to
free buffers received on a connection.  One way of troubleshooting
applications and their misuse of the buffer pool is to use nettool
"DI;RES" to monitor the buffer pool utilization and then start
aborting applications that use sockets.  When the utilization drops
way down, the application you just aborted is the "rogue" application.
One point to note is a buffer pool that is full or reached a
full condition is not necessarily a bad thing... A full buffer
pool is a throttle which protects the system from aborting and
depending on your Upper Level Protocol - TCP can handle this
condition on a intermittent basis, but of course UDP can not and
with UDP you get what you pay for..

I hope this helps ease concerns you have about the 6.0 NS-TRANSPORT.
Again I recommend the General Release NS-TRANSPORT patch be installed.


Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.