|
View previous topic :: View next topic
|
| Author |
Message |
John Poulakos
Active User
Joined: 13 Jun 2012
Posts: 178
Location: United States
|
|
|
|
We get DFHSN1129 messages in the CICS log which means a userid is trying to sign in to CICS when they are already signed on at another terminal. It's a virtual terminal and the user has lost session, so there isn't any way to get it back.
When this happens, it means there is an outstanding MVS enqueue for this resource. I would like to know how to find and break this enqueue. All of the commands I know only work for datasets. The enqueue goes away if the CICS region is shutdown and restarted, which is not exactly a desirable fix. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
did You try with a set outservice
according to the manual
| Quote: |
OUTSERVICE
The terminal is not available for use. Setting a terminal OUTSERVICE means that the terminal can no longer be used by transactions. If PURGE or FORCEPURGE is also specified, any transaction using the terminal is terminated abnormally. If PURGE or FORCEPURGE is not specified, the transaction can terminate normally, but no further transactions can use the terminal. For z/OS Communications Server, setting a terminal OUTSERVICE also causes it to be released and the operator to be signed off, either immediately or when the current transaction has terminated.
|
|
|
| Back to top |
|
|
John Poulakos
Active User
Joined: 13 Jun 2012
Posts: 178
Location: United States
|
|
|
|
| I was going to try it in production, but everybody freaks out when I suggest it. Next time! |
|
| Back to top |
|
|
John Poulakos
Active User
Joined: 13 Jun 2012
Posts: 178
Location: United States
|
|
|
|
Here's an update:
Upon further investigation, the problem was not a CICS enqueue. It was faulty code in the CICS transaction that caused a TRU exit to hang because it was in the wrong storage key... it was never going to end. It's an old proprietary package, so I can't change it. I had to figure out how to deal with it. So I wrote a web service provider to handle it.
I coded:
EXEC CICS
INQUIRE TERMINAL(WS-TERM) USERID(WS-USER)
TASKID(WS-TASK) NEXT
To find the terminal the affected user was stuck on.
Then
EXEC CICS
SET TERMINAL (WS-TERM) OUTSERVICE PURGE
Here's where it gets weird:
Remember, these statements are in a web service provider, so CICS doesn't know the user is... the user is CICS.
I signed on to CICS and started a transaction I knew was conversational and doesn't end.
Then I invoked the web service giving it my User ID.
The web service provider abended with AEIP (INVREQ).
But, the transaction my ID was in was reset and I was returned to the sign on screen.
If it was an invalid request, why did it work? |
|
| Back to top |
|
|
|
|
