Re: Cannot Start Subsystem QSYSWRK

On 19-Nov-2013 12:17 -0800, Jeremy Tipton wrote:

I have an as400 that is not used often anymore, but does have some
data/reports we still run from time to time. Currently I have no
network access to the AS400. If I use the STRTCP command from the
console, it tells me that subsystem QSYSWRK is not active. When I
issue STRSBS QSYSWRK, it says the subsystem is starting, but it never
does. If I look at the QSYSOPR message queue, it has two error
messages CPF0937 (Machine Check not recoverable. Error Code X'0000')
and CPF1102 (Function check occurred during start of subsystem).

Anybody have any suggestions? I am not really an as400 person. Any
help would be greatly appreciated.

I have seen the issue mostly when there have been prior disk failure(s). If the origin of the issue is related to the QSYSWRK *SBSD object itself, creating a new Subsystem Description object may be the only recovery required. The request to DSPSBSD QSYS/QSYSWRK /* output(*print) or opt-30 to display-all */ or DMPOBJ QSYS/QSYSWRK *SBSD might exhibit the same issue. And if so, that object is probably the issue. Or similarly, WRKJOBQ QSYS/QSYSWRK and DMPOBJ QSYS/QSYSWRK *JOBQ. Without reviewing the VLog to determine the actual issue, then as an /assumption/ that the *SBSD is origin for the problem, the create of a new version of the subsystem could be tested with RNMOBJ or MOVOBJ of the existing object, and then RSTOBJ from a backup [or since the object is in QSYS, re-creating from DSPSBSD output taken wherever the request functions, and with like-level of maintenance. Note that just like with the DSPSBSD or DMPOBJ, there is a chance that a rename or move request could potentially exhibit the same failure; e.g. if by chance the *SBSD object type has an object handler that requires /touching/ the composites in the same manner as does the failing Start Subsystem (STRSBS) request. By a test, it seems improbable that rename or move would exhibit any issue. If the *SBSD object is the problem, then the object is /damaged/ and so eventually, the DLTSBSD [of the renamed or moved object] would be required to effect final recovery [i.e. a /damaged/ object can be corrected only by deleting the object, after optional data recovery].