It turns out the creating job does an ERASE long before it does the COPYFILE (REPLACE -- so the REPLACE is irrelevant. Hence I am changing the title.
Simplifying, the code that is reading the file issues: parse value stream(ifn ift ifm ,'c','open READ') with ok2 handle2 say 'FILE SIZE: ' lines(ifn ift ifm ) FILE SIZE: 204430 <== Count from the OLD file do while lines(ifn ift ifm ) /= 0 X.1 = linein(ifn ift ifm) recsin = recsin + 1 if substr(X.1,1,4) = 'EOF ' then signal endofjb recsout = recsout + 1 end endofjb: parse value stream(ifn ift ifm ,'c','CLOSE') with ok2 say ' records read :' recsin say ' records written :' recsout records read : 15528 records written : 15528 <== These are equal, so no EOF record So the file was open to user B the whole time, yet it only processed 15528 records instead of 204430 records before it quit because lines(ifn ift ifm ) = 0. So much for it being consistent from OPEN to CLOSE. My suspicions are on "lines(ifn ift ifm )". Does it perhaps close and open the file under the covers? I've heard complaints that "lines" performs badly on other platforms -- but not on CMS. The file "ifn ift ifm" is RECFM V, which might make a difference. I don't have much experience with REXX level 2 I/O -- if I had written this, it would have been a Pipeline. You are right that the correct approach would be for the first job to kick off the second when it is done. In our case that would mean issuing VMSCHED RELEASE. So maybe I don't have to fix this -- but I am concerned about the use of level 2 I/O.
