Re: BRMS save failed and ended with a MCH3601

On 08-Apr-2017 10:43 -0500, Steinmetz, Paul wrote:

BRMS save failed and ended with multiple MCH3601, followed by a
CPF3799.

Only details of one msg MCH3601 was given [edited inline below, rewritten as a kwd symptom string]; no mention if the context for everhy x2401 exceptions was the same, manifest as each MCH3601.

Third backup item of save, *ALLUSR, appears [to be] doing the
checkpoint processing for library QUSRSYS.
I've never seen this type of error.
Any thoughts from the group.
[ed.]
msgMCH3601 f/RmslUnlockSpaceLoc x/00D4 t/QSPSAVQ x/0612
msgCPF3799 f/QSPSAVQ x/08D1 t/QSRCLNUP x/02BB

Very likely, that the same issue would occur/persist for a non-BRMS save; i.e. unlikely the noted errors are specific to using BRMS.

The QSPSAVQ is the feature that does Save Spooled Output Queue entries; i.e. implements SPLFDTA(*ALL) for the save/restore feature. There are at least two old APARs noting issues for a pointer-not-set; APAR SE46480 notes origin as an invalid stored pointer in a spooled file that\thus does not properly address the OUTQ in which the spooled file is an entry for that queue, even noting Save While Active (SWA\SAVACT); APAR SE47427 for which there are a /large number/ [e.g. ¿9K?] of spooled files in the OUTQ for which the Spooled File Data (SPLFDTA) was not saved on the Save Library (SAVLIB) request. Neither APAR seems to be a match however, to the above symptoms.

Of note however, that for an incorrect\bad stored pointer in a spooled file, the APAR SE46480 suggested use of Start Spool[ed File] Reclaim (STRSPLRCL) feature for a "circumvention", specifying "either *ALL for the OUTQ parameter or the name and library of the output queue containing the failing spooled file." Of course if that resolves the issue, then that also further obscures what might be the origin; i.e. attempts at recovery before debug are likely to destroy information that would enable investigation of origin and which spooled file(s) [if any] were problematic.