GSVX346E (XSDS) #CCI SEND failed, RECEIVER NOT FOUND GSVX345E (XSDS) #CCI SEND failed, rc 08 vrc 06110000 xrc 11000000

Products

• SYSVIEW Performance Management

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? We lowered the priority from SYSSTC to STC for this reason

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 you should look at increasing 
(by increments of 3): 

The timeout values which you should increase are as follows: 

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 

You could, 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 you could then keep increasing these times until 
(hopefully) all of the error messages disappeared. You should NOT just 
immediately increase all of these values to their maximum limits. The 
reason for this is that, if there is ever a legitimate problem, you would 
not want to have to wait, say 5 minutes to be notified that the 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 you should leave at their 
default settings unless you find some specific reason to change them: 

XscrConnectTimeout 15 
XscrProcessCommandTimeout 180 
XssiReceiveInputTimeout 1800 

XsxiReceiveInputTimeout 1800   

Additional Information

None.