Re: savact consequences if job cancelled immed

On 11 Sep 2013 07:08, J Franz wrote:

What (if any) are the consequences of a SAV command canceled *immed-
it was canceled after running couple hours, are the locks cleaned up?

Message . . . . : 17427 - SAV DEV('QSYS.LIB/TAP06.DEVD')
OBJ(('/*' *INCLUDE) ('/ekdimage' *OMIT) ('/optmlb01' *OMIT)
('/qsys.lib' *OMIT) ('/qdls' *OMIT))
SAVACT(*YES) SAVACTOPT(*ALL) ENDOPT(*LEAVE)
SAVACTMSGQ('/QSYS.LIB/QUSRSYS.LIB/OPERATOR.MSGQ') UPDHST(*YES)

Any issues when run next time?

If /canceled/ implies /ended/ per ENDJOB [or SIGNOFF; e.g. SysReq-90] then the locks will be gone; i.e. locks scoped either to a thread within a job, or to a job itself, will disappear with the job. There is no "*immed" option for a /cancel/ if that term meant to imply the effect of an End Request (ENDRQS) [e.g. SysRqs-2] having been issued; i.e. there is no parameter accepting the special value *IMMED on the EndRqs command. I recall seeing several people typing "2 *IMMED" on the System Request input line, instead of just the "2" to effect a cancel, but [apparently they were unaware that] everything typed after the digit-two is ignored.

The SAV operation canceled with EndRqs [e.g. 2=Cancel from SysRqs] should cause the save request to activate its cancel handler(s) to cleanup the interrupted save. As an effective controlled-end of the request, the termination should have no ill effects within that job or another.

Saves interrupted with a user or system storage limit being reached [and I seem to recall, at least one other condition] purposefully will not run its cancel handlers because the cleanup requires the ability to create new objects [more storage], so the locks would remain, as well as any of its tracking objects. Saves interrupted instead by any other error conditions or terminating responses [e.g. C=Cancel, D=Dump] from an inquiry message, should cause the cancel handlers to perform cleanup, which should include dropping its locks.

No job should ever be ended directly with the immediate option [even though it is done often with few ill-effects], until after giving the job the chance to end with the controlled end feature that allows an active request the opportunity to perform cleanup. If the save request is ended immediately, then some cleanup may not be completed, even though some cancel handlers may be able to be invoked and perform some portion of the expected cleanup activity. The ill effects from a save terminated in a manner that does not allow for cleanup should be mostly innocuous because a save would not have changed the object. Thus I would not have concerns for my next save.

However a /logically/ incorrect condition may remain which could interfere with later actions. As an example [for SAVOBJ and similar vs SAV]: a database file that was being saved when that save request had been terminated without cleanup, would leave the file in a state referred to as a /logically damaged/ object; logically, the database file is pending a /database recovery/ action. But IIRC that logical condition is mostly just ignored, except when the only remaining pending action was to update the history if the /save/ had all-but-completed, for which the /damage/ condition is implicitly corrected in almost any other activity against [any member of] the file; e.g. in a terminated save [or restore] of database files, a request to DSPFD the_lib/*ALL would process any pending save\restore operations, by completing the pending activity and\or to remove the indication of pending work after if no action is required; see CPF3298 and cpf3245 OT22. A save after a prior save that was immediately ended could have some "recovery completed" messages; I did not see a message specific to /database save recovery/ however.