On Thu, 15 May 2014 11:30:19 -0700, Skip Robinson wrote: >Clarification on REWORK. Besides documenting the APPLY date (which SMPE >shows anyway), it obviates the need to first RESTORE/REJECT the usermod >before re-RECEIVE/APPLY, a hassle I don't see the point of for a usermod >whose sysmod structure never changes. For re-RECEIVE to work, REWORK must >be 'higher' than the previous value. Current date in YYYYDDD format is >obviously higher each day. The final digit is for multiple retries in a >single day. ROT: if you've tried 10 times and still haven't got it right, >it's time to knock off for the day and try again tomorrow. ;-) > will changing the REWORK and re-RECEIVEing cause the SYSMOD to be selected on APPLY, absent REDO? Even if all the objects appear current in the target zone? Based on what entries in the target CSI?
Also (topic drift) The SMP/E manuals say that if the SYSMOD is absent from the SMPPTS, RECEIVE will re-RECEIVE it even if the REWORK is unchanged. But be careful: In our development we may make radical changes in the structure of a PTF (we never send two such versions to field). I have observed that merely deleting from the SMPPTS and re-RECEIVEing leaves tramp entries in the GLOBAL zone. I don't know whether changing REWORK causes such entries to be cleaned up. I rely on REJECT. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
