And then there's the issue of the user seeing a block of 10 records to delete but missing the deleted record in the middle of this block. So effectively, the user should delete a block of 11 records rather than 10. How will the command treat the already deleted records?

Of course a function like you propose cannot be handled to any user that is not aware of such things so maybe it is not an issue.

All and all I reckon a FROMRN and a TORN would be more suitable than the FROMRRN and NBROFRCDS proposal. Prior to executing the delete, the command would check if these records numbers actually exist and issue a warning if any does not.

Anyway, my 2 cents worth...

I'd retrieve the RRN from the INFDS of the file of the record just read. If it's in the range, delete it, and read another record by RRN. I/O blocking is not an issue with ILE RPG when it assigns the RRN (was an issue in RPG 3).

I'd also disable this option if the file is REUSEDLT(*YES) so a deleted record does not get filled in suddenly and then inadvertently deleted again.

Chris Ringer

While I've had to do this kind of thing before, my gut feeling is to not include the Relative Record Number option at all, and just go with the SQL-style WHERE and the *RCD position = "D" options.

So basically, you're gonna invent the SQL delete...   :o)

No, just enable it in CL. 

RUNSQL anyone?

I created RUNSQL in 1988 and have been selling it ever since. We had "words" with IBM about offering it in 2013, nearly 25 years after I first introduced it. But yes, if you are on V7R1 TR5 you can use IBM's RUNSQL command to do similar functions. But it does not include a search of the *RCD as a DLTRCD command would nor will it work on V5R4 an later (V7R1 is required). But both DLTRCD and RUNSQL are now "free" so who cares which one is used, really?

So what we need is this:

CHGSYSVAL SYSVAL(QALLOWSQLINCL) VALUE(*YES)

And then you would do your SQL thing as you would in RPG.

Serious now. I have not had any need of running SQL in a CL program in recent years, nor the urge to undelete rows nor delete blocks of rows by RRN.

The basic policy is: you deleted it, you fix it! And otherwise there's always the backup to resort to. You restore the table in another lib and copy the deleted block back from the restored table.

Guess I'm in Paulster's camp, except I was wondering why you're not using the journal, possibly RMVJRNCHG to do the un-delete (no programming required!).

Dale, did you reply the the wrong thread? The other one is talking about the UNDELETE function. I'm discussing a DLTRCD command in CL that provides both SQL or *RCD comparison to purge out records and as I said in my de!--script--ion, I have clients who have CL that was converted from S/36 OCL. That CL contains CPYF A to B INCCHAR(*RCD 1 NE 'D') and similar code, then they do a CPYF back to the orignal. Since they are not doing remote journalling, the journals are being shut off (because most of the time they also do a CPYF B to A after issuing a DLTF A. Its a nightmare end of month procedure.

The DLTRCD command allows us to go in an replace that 30 year old code with a single command that accomplishes the same task with a lot less overhead, and without interrupting the journalling procedures.

Remember, not every shop has a $10 billion IT budget--they get by, by asking "that won't cost anything, will it?"

Nah; I was triggered off Paulster's comment, "you deleted it, you fix it!" But, you're right, my comment might make more sense in the other thread.

Right Dale, I sorta mixed them up too. 

fwiw, DLTRCD with INCCHAR would be more like the original CPYF's (which probably originally were COPYDATA's), so replacing them would be more intuitive.

If you were to do anything with FROMRCD TORCD NBRRCDS, record selection should work the same way as CPYF.