Mark, et al.

The web page does indeed describe the changes in the LE C sockets code
which were delivered in z/VM 4.4.0.  Actually, those C sockets changes were
made late in LE 1.8  and shipped with either z/VM 4.2.0 or 4.3.0 (I don't
remember exactly).   The major difference between the LE 1.8 and z/VM 4.4.0
implementations of the C sockets code was the DNS resolver used by each of
these sockets libraries.  The older LE 1.8 code contained its own internal
resolver functions.  In z/VM 4.4.0, the DNS resolver was moved out of the
LE C code to a separate set of callable services library (CSL) routines.
These CSL routines appear in the CMS VMMT library as the EZB1xxxx routines.
These routines use socket ids which are POSIX byte file system file
identifiers.  The latter is the cause of the increased virtual storage
requirement.

In z/VM 5.1.0, PING and TRACERTE were rewritten in C in order to pick up
the IPv6 support already included in the LE C sockets code.  This rewrite
made these two applications LE-based and this incurred the storage overhead
mentioned on my little LE FAQ page.  Additionally,  the DNS resolver used
by other, PASCAL-based clients was redone to use CMS CSL based resolver
functions (EZB1xxxx).   Thus, when any call is made to the resolver, you
incur the storage hit described on that web page.   I'm thinking I need to
add this to the list of reasons for increased storage use.

Hopefully this help explains why you are seeing differences when moving
from z/VM 4.4.0 to z/VM 5.x.0.   The LE C code changes shipped in z/VM
4.4.0, but the "exploiters" did not ship until z/VM 5.1.0. If you have any
other questions, please let me know.

Thanks!
     Mike  Donovan





                                                                       
             Mark Bodenstein                                           
             <[EMAIL PROTECTED]                                         
             >                                                          To
             Sent by: The IBM          IBMVM@LISTSERV.UARK.EDU         
             z/VM Operating                                             cc
             System                                                    
             <[EMAIL PROTECTED]                                     Subject
             ARK.EDU>                  Re: zVM 5.3 TCPIP memory problem
                                                                       
                                                                       
             09/17/2007 04:01                                          
             PM                                                        
                                                                       
                                                                       
             Please respond to                                         
               The IBM z/VM                                            
             Operating System                                          
             <[EMAIL PROTECTED]                                         
                 ARK.EDU>                                              
                                                                       
                                                                       




Mike,

Thanks for the information.  I work with Jim and am also trying to
understand the differences in memory use of the z/VM 5.3 TCP/IP clients
compared to the z/VM 4.4 ones.

The web page you reference talks about C sockets library changes, but says
these were already present in z/VM 4.4.  The difference we're seeing is
between 4.4 and 5.3.  So does this apply?  I also wonder because we're
seeing this with ftp and telnet, which aren't mentioned on your web page as
using the C socket library.  (Do they?)

I've done some more testing, and find that the 5MB or so additional memory
use that we're seeing only happens when there is a DNS lookup involved.  So
if I do "ftp cornellc.cit.cornell.edu" I see the additional memory use, but
if I do "ftp 132.236.98.12" I don't.  Similarly "ftp loopback" doesn't
cause the additional memory use.  I see the same thing for lpr: lpr profile
exec (p raw at cornellc.cit.cornell.edu causes the additional memory use,
while lpr profile exec (p raw at 132.236.98.12 does not.

So what is there about DNS lookup that causes this memory use, while
otherwise the clients don't suck up virtual storage?

Thanks,

Mark Bodenstein  ([EMAIL PROTECTED])
Cornell University



Reply via email to