Newsgroups: bit.listserv.ibm-main
Date:         Fri, 2 Oct 1992 08:58:48 EST
From:         Dan Fortriede <UCS521@BSUVM.UCS.BSU.EDU>
Subject:      Re: Problems with 7171 under MVS
Comments: To: IBM Mainframe Discussion list <IBM-MAIN@ricevm1.rice.edu>
              1 Oct 1992 13:30:17 EST from <TOM@PENNDRLS.UPENN.EDU>

On Thu, 1 Oct 1992 13:30:17 EST Thomas D. Denier said:
About problems with his 7171 via switched network.
>
>We see sequences of messages like the following on the system log
>several times per minute during busy periods:
>
>IST663I CINIT REQUEST FAILED, SENSE=08010000
>IST664I REAL  OLU=PENNLIBR.PA51       REAL  DLU=PENNLIBR.PRODUCTN
>IST889I SID = EB9B97C7FBAF61E1
>IST890I AUTOLOGON SESSION SETUP FAILED
>IST314I END
>IST663I INIT OTHER REQUEST FAILED, SENSE=0805000B 270
>IST664I REAL  OLU=PENNLIBR.PRODUCTN   REAL  DLU=PENNLIBR.PA51
>IST889I SID = EB9B97C7FBAF61E2
>IST314I END
>
>I have been able to induce similar behavior with real 3270 terminals by
>flipping the Test/Normal switch. This suggests that the messages occur
>when 7171 connections are dropped, since both events cause the host
>system to receive an unsolicited Device End interrupt. According to the
>VTAM messages manual, the problem is that the pair of endpoints involved
>does not support multiple concurrent sessions. I suspect that both VTAM
>and CICS are trying to reestablish sessions terminated by the
>unsolicited Device Ends, and that one of them succeeds and the other
>fails because it tries to establish a session between a pair of
>endpoints that are already in session. Is this suspicion correct? If so,
>how do I configure VTAM and CICS to ensure that exactly one piece of
>software tries to reestablish a session interrupted by a line drop?

Yes your suspicion is correct.  You can't have both VTAM and CICS automatically
re-establish the connections.  Our installation has the LOGAPPL in VTAM only
and has eliminated the AUTOCONNECT from CICS.  This has corrected this problem.

>Some of the message sequences appear to be associated with ATNI and ATND
>ABENDs reported in the CICS logs. The library software seems to recover
>cleanly, but the memory dumps from the ABENDs waste a lot of spool space
>and get in the way of diagnosing more serious problems. Is there any way
>of eliminating the ABENDs or at least preventing the memory dumps?

With the correction to CICS the ABENDs should disappear as well.

>We get several reports a day that ports that are supposed to be
>connected to CICS by the LOGAPPL specification in the VTAM definitions
>are not connected to CICS when people try to use them; the people
>involved have to do a VTAM LOGON to connect to CICS. At least one of
>these incidents involved a permanent virtual circuit between the 7171

(Is that Permanent Virtual Circuit (PVC) as in ISN AT&T world?)

>and a workstation whose owner only uses CICS (in particular, he does
>not have a TSO USERID). Does anyone know of a way to fix this? Failing
>that, does anyone have any suggestions for tracking down the source of
>the problem?

Does this occur the first time they try to use the device after CICS has been
re-cycled or later?  If the first time, we have seen similar problems and we
just need to force a disconnect on the 7171 line to have it automatically
recover.  We do this by dropping the PVC, resetting the switched network port
going into the 7171 which drops DTR and starts the appropriate recovery
mechanism, and then reconnecting the PVC.  The problem seems to be one of
timing between when VTAM is trying to give the port to CICS and when CICS is
up and ready to receive.  It happens infrequently, but we have set up
procedures to check for this state and correct before the library opens.

>
>We have seen at least one and possibly two occurences of a very strange
>problem. An applications programmer connected to a 7171 port assigned to
>CICS. He entered 'cssf logoff' to drop into VTAM and logged on to TSO.
>The connection between his workstation and the 7171 was later dropped
>for unknown reasons (we suspect a bug in the software that runs the
>switched network). He attempted to log on again. For the first few
>minutes he was told that his USERID was in use. After that he was able
>to log on and log off again. Even after he logged off the second time,
>there was a sort of anonymous TSO session running and consuming a
>significant fraction of the CPU. The SDSF DA display showed a task with
>blanks in the user name and job name fields, and the VTAM name of the
>terminal that got dropped in the job step name field. I finally managed
>to get rid of the anonymous session by shutting down and restarting TSO.
>TSO reported two session failures when I took it down. One was for the
>IBM Service Director, a PC with a 3270 card that logs on automatically.
>The other had a blank USERID and the address space ID of the anonymous
>TSO session. Is there any way of preventing this behavior? Failing that,
>is there a less disruptive way of getting rid of the anonymous TSO
>session.

We have seen a similar problem only twice.  We forced an unlikely device end
to simulate another problem we were having and caused the TSO session to start
running away with CPU time.  Our monitor immediately showed heavy (90%) usage
by that TSO job, eventhough the terminal was no longer connected.  We did not
try to logon to that same account.  The CANCEL U= command did not work and we
had to use the FORCE U= command.  This worked very well.  We haven't had the
problem occur enough to invoke enough necessity to track down the source, but
would be interested in whatever you find.


Just out of curiosity, have you run across a problem where people will on
occasion get a screen from someone else's 7171 CICS session?  We had a night-
mare trying to figure out this problem.  The problem manifested itself when
a user first connected to CICS through the 7171.  Instead of getting the CICS
welcome logo, they would receive a CICS screen left over from someone else's
session.  This was traced to temporary storage not being released when the
previous session was not terminated correctly by the user.  This left the temp
storage in place, which was then sent to the 7171 for processing once a
connection was re-established to CICS.  The same problem occurs on 3270s but
the screen is not re-displayed as with the 7171s so the user doesn't know it.
We had IBM write a new exit patch for CICS to handle this situation.  Let us
know if you are having the same type of problem.

Send reponses to Peg Simsic who brought this to my attention.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU