My experience with REXX stream I/O is that it is extremely slow compared to using a PIPE.
-----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: November 28, 2005 20:42 To: [email protected] Subject: SFS and open file [Was COPYFILE (REPLACE and SFS] 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. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
