---------------------------- Top of message ----------------------------
>>--> 03-11-97 10:42 S.SHEPPARD (SHS) Re: IDLETIMEOUT/COMM
>>--> 03-11-97 10:42 S.SHEPPARD (SHS) Re: IDLETIMEOUT/COMM
I ran into a fellow at SHARE last week who described the same problem.
Unfortunately, the APAR number he gave turned out to be incorrect and I
failed to get his name. Also, it turns out that level 10 of the MVS
server uses HPNS as the default when you go to TCPIP 3.2, but there is
an undocumented option you can put in the server option file, IUCVTCPIP,
which will cause ADSM to use the old method. This apparently allows you
to use TCPIP 3.2 and avoid the TIMEOUT problems. I am still working
with support on this.
Good luck
Sam Sheppard
shs AT sddpc.sannet DOT gov
San Diego Data Processing Corp.
(619)-581-9668
-----------------------------------------------------------------------`
---------------------------- Top of message ----------------------------
---------------------------- Top of message ----------------------------
>>--> 03-11-97 06:33 ..NETMAIL () Re: IDLETIMEOUT/COMM
>>--> 03-11-97 06:33 ..NETMAIL () Re: IDLETIMEOUT/COMM
-------------------------------------------------------------------------------
>
>
>Date: Tue, 11 Mar 1997 17:09:00 +0200
>Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>From: Eric van Loon <evanloon AT KLM DOT NL>
>Subject: Re: IDLETIMEOUT/COMMTIMEOUT
>To: ADSM-L AT VM.MARIST DOT EDU
>
>Hi ADSM-ers!
>We have plans for upgrading TCP for MVS to version 3.2 (now 3.1).
>Are there others having the same problem as Sam?
>Kindest regards,
>Eric van Loon
>
>----------
>From: Sam Sheppard
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: IDLETIMEOUT/COMMTIMEOUT
>Date: Monday, February 20, 1995 13:01
>
>I have a resolution (sort of) to the problems I posted here earlier in
>the week having to do with the unexpected onset of client sessions end-
>ing with IDLETIMEOUT and COMMTIMEOUT limits reached. Thanks to Jerry
>and Dwight for some interesting observations about this problem.
>
>However, as it turns out, the problem now has been resolved by removing
>MVS TCPIP Version 3.2 and returning to 3.1. The sometimes seemingly
>random nature of the failures (node backs up fine one day, fails the
>next; one fails consistently; one fails only during nightly incremental
>backup, etc.) along with some other network related problems earlier,
>caused us to overlook this new version of TCPIP as the culprit (after
>all, it had been running for 3-4 weeks and most of the 200 clients
>weren't having any problems).
>
>For anyone considering moving to TCPIP 3.2, I would advise caution at
>this time, as this is not the only problem we solved by backing out to
>3.1. This particular problem has been reported to level 2 ADSM support.
>
>Thanks
>Sam Sheppard
>shs AT sddpc.sannet DOT gov
>San Diego Data Processing Corp.
>(619)-581-9668
-------------------------------------------------------------------------------
-----------------------------------------------------------------------`
-----------------------------------------------------------------------`
=========================================================================
|
