×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 26 Apr 2012 14:22, CRPence wrote:
On 26 Apr 2012 10:28, Jack Kingsley wrote:
retrieved the source code <ed: of the QMNSAVE>, it appears all the
options are *LEAVE
That is to suggest ENDOPT(*LEAVE) for all of the SAVxxx commands.?
But what about for any CHKTAP invocations or Tape Files being used?
Seems the following may be moot for the situation for the OP, per a
followup message [even before my above reply], which seems to confirm
that an ENDOPT(*UNLOAD) was found in the QMNSAVE source; presumably for
the SAV command, the last issued. Regardless, perhaps something of
value for the archives...
Because I can not find a copy of a somewhat recent source, I can not
confirm the ENDOPT(*LEAVE) for all of the SAVxxx commands, nor whether a
CHKTAP exists in the /shipped/ [unmodified] version of QMNSAVE. An old
copy of the QMNSAVE source from v5r1 however shows very clearly that the
CMDLBL(SAV) establishes the ENDOPT(*UNLOAD) for the last save command,
SAV being setup after the label "SAV:"; including prompting characters
on that parameter for when prompting had been requested [according to
the value of &PROMPT] for an attended save.
Irrespective of what information might be available in the "secured"
document from the IBM support site, there is a public document entitled
"Backing up your system" that suggests for Option-21 [and 23], that the
feature "will also perform a CHKTAP ENDOPT(*UNLOAD) command after the
last SAV command it processes." There is just no mention of where that
CHKTAP activity takes place. So it seems recompiling the program
QMNSAVE with that CHKTAP command request modified or removed, if it
exists there, should probably prevent an unwanted unload effect for the
GO SAVE Option-21.? Otherwise presumably just placing a CALL to the
program which does the work to "produce some listings off the tape",
somewhere after the backup activity in QMNSAVE completes [before the
unload either by a CHKTAP or a RETURN], should also suffice; of course
ensuring that the SAV command as the final part of the backup effects
the ENDOPT(*LEAVE) or ENDOPT(*REWIND) versus ENDOPT(*UNLOAD).
If the unload action is effected by an explicit request to CHKTAP
ENDOPT(*UNLOAD) [indirectly] from a program that calls the QMNSAVE, then
stopping that generally, might be different or more complicated;
something which the secured document apparently divulges.? That could
possibly be in the program QMNSRBND, but a v4r3 copy seems to have no
CHKTAP. I was also wondering if perhaps there could be something from
the QSRDFLTS *DTAARA instead, to modify the effect; if not something as
set via the GO SAVE Option-20, then an undocumented [except as noted in
that locked\secured document?] setting might exist to enable a change to
the final ENDOPT or the effects of a separate CHKTAP.? I can only
speculate what might be in that document; I have no access.
v7r1 IBM i: Backing up your system
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzaiu/rzaiu000.pdf
Same document pdf name, different titles\locations in whichever release
InfoCenter:
v6r1 System i: Backing up your system - IBM
v5r4 System i: Backing up your system - IBM
v5r3 iSeries: Systems Management Back up your server
v5r2 iSeries: Back up your server
Regards, Chuck
midrange.com
