QZRCSRVS is the Remote Command/Distributed Program Call host server. Quite a mouthful to say. Try and say QSRCSRVS with a mouthful of frozen peas – you will spill a lot. #trustme. QZRWRVRSRCSRRCSRS is a web-service that basically receives authenticated requests (from other systems out there in cloud land) to run commands or to call programs on your system. I like to think of QSRCSRVS as a pre-run health-checker, or the front door to my system
I read somewhere that IBM recommends the QZRCSRVS prestart job config should be set to MAXUSE(1) which means that every individual request be serviced in a new job. This seems like a bit of a bottle neck, but it makes sense because IBM i will process these requests in super quick time and will prevent flooding if thousands of requests hit us at the same time. Use your own judgement here… tweak the setting and find that happy balancing point 🙂
A cleanup thread runs once an hour to determine whether a QZRCSRVS job is still being used by a Job Monitor. It determines if the job was used at least twice within the maximum job monitor interval length. If the job is not used during the previous two hours, it is ended. Java time stamps are used for this comparison, so it is imperative that the time zone value used by Java is correct (system value QTIMZON).
QZRCSRVS jobs are automatically removed two hours after the job it supports ends. Likewise QZRCSRVS jobs will end if the Job Monitor that created them stops, or if Management Central ends. Note: Since the Management Central Job Monitor monitors active jobs, you might see messages like “Internal job identifier no longer valid” in the QZRCSRVS job. This normally happens when a monitored job with Job Log Messages or the Job Status metric ends while the monitor is running.
Tracking which job caused the connection
What application initiated connections to host server jobs such as QZRCSRVS and QZDASOINIT?
The joblog will identify the user and client for the connection using message CPIAD02. For example, use WRKACTJOB JOB(QZRCSRVS) for remote command host server connections. If the user is QSECOFR over loopback, the QZRCSRVS joblog will show:
Message ID . . . . . . : CPIAD02 Message . . . . : User QSECOFR from client 127.0.0.1 connected to server. Cause . . . . . : User profile QSECOFR from client 127.0.0.1 is currently connected to this server job. The client name is either a TCP/IP remote system name, a dotted decimal IP address, the local host name, or an IPv6 address.
QHST will have a list of the connections using message CPIAD09. Use the following command to view:
DSPLOG JOB(QZRCSRVS) MSGID(CPIAD09)
Client is remote
In the case that CPIAD09 or CPIAD02 shows the client is a remote system, the initiating application could be virtually OEM product that sends a remote command to the iSeries using a number of available interfaces. The only additional clue we can find is what messages the joblog has after the CPIAD02. The messages will show what System i APIs or programs are called using the host server.
If the connections are coming from a remote IP, the active processes on the system with that IP will need to be investigated. Note: IBM Support does not assist with this.
Client is a local job
In the case, if the client identified by the CPIAD09 or CPIAD02 messages is a name or address local to the System i on which the host server job is running, we can identify what job initiated the connection.
To show the connections if the jobs are still active (WRKACTJOB JOB(QZRCSRVS) and the connections are TCP connections, enter the following at the CL command prompt:
Netstat shows you all kinds of info. Dive in there and have some fun with webservice nonsense….