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
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 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
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 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:
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: