Re: CL Processing File Members

The results received are presumably correct, due to the *NEXT giving the next alpha-ordered member instead of the next date-ordered member.
The RTVMBRD command is IMO, poorly designed. There should have been *FIRST, *LAST, *LASTMBR, *FIRSTMBR to locate a member [there are, but the latter are not single values for some reason], and then each of *PRV, *NEXT, *PRVMBR, *NEXTMBR for locate relative member; where 'MBR' implies hex-alphabetic ordering. Unfortunately the *PRVMBR and *NEXTMBR already exist in function, but in the *PRV and *NEXT by name. Yuck!

To effect [what I infer is] the desired result for the given scenario, each successive RTVMBRD should be performed against member *FIRST [with effective /relationship/ = *SAME; *FIRST is a single value, so *SAME is ignored] to ensure it does not match *LAST, before the RMVM request is performed. This is because after each RMVM &L/&F MBR(&N), what _was_ the next member in date order becomes the new *FIRST.

Presumably the logic in the scenario includes an early exit for a given date, but I will add.... My personal preference to effect a delete of all but the last member of a file in a non-concurrent maintenance program would be to perform the following:
OPNDBF &L/&F *ALL *LAST KEEPME OPNSCOPE(*JOB) /* named lib only */
RMVM &L/&F MBR(*ALL)
MONMSG CPF7301 EXEC(DO ... RCVMSG & optionally verify &5 = x'0001'
MONMSG CPF0000 EXEC(DO ... Oops! Not CPF7301
CLOF KEEPME

Additionally worth noting: The DSPFD TYPE(*MBR) generates a date ordered list. The DSPFD TYPE(*MBRLIST) generates an alpha ordered list. Using one of these output files from OUTPUT(*OUTFILE) is my preference, over RTVMBRD; typically using OPNQRYF to effect selection of which members to process.

Regards, Chuck