Hi Ed I'm always interested in the whys and wheres....
I'm on z/VM 5.2 and my stack is 32MB (I did have to up it from the earlier release). However, my "res=" from indicate user, shows 1,313 pages used. I do know about the 5 MB hit, due to LE. Which I thought was a hit to clients, and not the stack. I was wondering what your "res" usage was for your 64 MB machine? Now that we have vswitch, TCPIP does quite a bit less here. Very seldom does it pop up in the performance monitor <G>. I'm really the only CMS user (and using TN3270). But I have some 66 service machines, VSE guests and still some Linux guests (that haven't been migrated over to the IFL), with the guests using TCP/IP (but not the TCPIP stack). Not that virtual storage costs much (anything), but what caused you to go to 64 MB? Thanks Tom Duerbusch THD Consulting (trying to head off a rude awaking if 32 MB isn't sufficient) FELINE PHYSICS: Law of Cat Inertia A cat at rest will tend to remain at rest, unless acted upon by some outside force - such as the opening of cat food, or a nearby scurrying mouse. >>> "Edward M. Martin" <[EMAIL PROTECTED]> 9/17/2007 3:33 PM >>> Hello Mike, I am working on upgrading to z/VM5.3 from z/VM 4.3. In the process, I am reading lots of info. The program directory indicates that with Host/domain name resolution being performed by LE you need a minimum of 16m of virtual storage. And for 5.3 most server machines will need 32 meg and probably more. I have our z/VM 4.3 TCPIP at 64m already. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Bodenstein Sent: Monday, September 17, 2007 4:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zVM 5.3 TCPIP memory problem 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 At 01:08 PM 9/14/2007, you wrote: Jim, There are several reasons for the increased use of virtual storage when running the TCP/IP functions and utilities. You can read about some of these at http://www.vm.ibm.com/devpages/donovanm/zvmle.html and specifically look at http://www.vm.ibm.com/devpages/donovanm/zvmle.html#LEstor The 5M "feechur" you mention is an unfortunate artifact of sockets being defined as POSIX file descriptors in the Byte File System client code. "Fixing" this involves a significant rewrite of a BFS client storage management and will most likely not happen any time soon. Mike Donovan --- zVM 5.3 TCPIP memory problem I remember back in zVM 5.1 or 5.2 days seeing on the list that there were memory problems or memory size issues. I probably didn't follow it because I was using 4.4 and probably just thought it would be fixed. Now I see that it wasn't fixed. I've just been told by IBM it's a "feechur". I'm seeing it with the TCPIP clients, FTP and LPR. They grab about 5M and don't release it. I didn't see it in putting the release together because whoever runs the MAINT id in installation with a small machine size. Does anyone have any ideas or a solution or is that just the way it is? Jim -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]