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

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].