GSVX346E (XSDS) and GSVX345E (XSDS) messages
Article ID: 4941
Updated On:
Products
Issue/Introduction
Should SYSVUSER be in the same WLM Service Class as the SYSVIEW task?
Is it normal to see CPU spikes of 13-14% for SYSVUSER? After lowering the priority from SYSSTC to STC for this reason below error message start apearing in STC output.
GSVX346E (XSDS) #CCI SEND failed, RECEIVER NOT FOUND GSVX345E (XSDS) #CCI SEND failed, rc 08 vrc 06110000 xrc 11000000
Cause
Research indicated that customer had a UserID in update mode and further investigation using the LISTLOG subcommand against that USERID from the USERs command showed:
2 REFRESH
2 REXX014I EXEC DASHBORD zosnocd
2 REXX020I IRXEXEC started
2 DASH011I Command=<LIBVIEW PARMLIB GSVXDASH PROCESS INCLUDE SUBCNTL NOCOMMENTS LJST IF NOUSER SITE SYSTEM ...
2 DASH012I RtnCode=16
2 DASH013I Message=GSV2312E GSVXDASH : 000020 : ERROR : <dataset > parameter is required
2 REXX021I IRXEXEC complete, elapsed 7.172647 cpu 0.021525
2 REXX006I DASHBORD completed successfully
Resolution
The DASHBOARD was corrected to eliminate the error:
DASH013I Message=GSVX067E Only 3 parameters are allowed on the SET command
Additionally, The messages:
GSVX346E (XSDS) #CCI SEND failed, RECEIVER NOT FOUND
GSVX345E (XSDS) #CCI SEND failed, rc 08 vrc 06110000 xrc 11000000
Could be caused by CCI/ENF not being active on the system. With that being said: When dealing with communications lines, errors such as these do occur from time to time and are not normally of concern. There is sometimes a "glitch" on the line, but as long as both sides of the communication recover, customers usually accept these errors. To eliminate the messages, customer increased the values in the XSYSTEM parmlib member by increments of 3, until they decreased or totally eliminated the messages.
The following are the timeout values which can be adjusted(increasing) in order to solve the above errors. Try increment by 3 seconds:
XscrCancelSessionTimeout 5
XscrGetCommandDataTimeout 5
XscrGetIdentTimeout 5
XscrGetStatusTimeout 5
XscrGetUserTimeout 5
XscrSendOsCommandTimeout 5
XscrStopSessionTimeout 5
XsdsSendTimeout 5
XsmsSendTimeout 5
XSPingTimeoutDefault 5
XssiReceiveInitialTimeout 5
XssiSendEndTimeout 5
XsssSendTimeout 5
XsxiReceiveInitialTimeout 5
XsxiSendEndTimeout 5
XsxsSendTimeout 5
At first, try increasing these values to, say, 15 seconds each. This would take care of most cases in which the response was not being received because something was preventing the receiver from getting CPU time. If necessary keep increasing these timeouts until all of the error messages disappeared. Please do NOT gor straing to the MAX value immediately. The reason for this is that, if there is ever a legitimate problem and timeout set to MAX means user will wait 5 minutes to be notified that the real problem exists. So the objective is to make these values only as large as they absolutely need to be to eliminate false error messages.
There are 4, additional, timeout values which need to be set at their
default settings unless there some specific reason to change them:
XscrConnectTimeout 15
XscrProcessCommandTimeout 180
XssiReceiveInputTimeout 1800
XsxiReceiveInputTimeout 1800
Feedback
