IBM Mainframe Forum

why all those stems, why not just

that' exactly what I was suggesting

and for the TS

to see by Yourself why "EXECIO * DISKW ..." is bad

use


and run three times
1) without statement 7
2) with statement 7
3) with statement 7 using 100 instead of the "*"

[/quote]

don't you think there's a mistake in



may be it's j instead of i ?

No. i is iterating over the input. j is keeping track of the output. Please read and understand the code given to you. I also suggest reading the Rexx language reference and the EXECIO documentation and understanding it.

OK, thanks to your advices, now my rexx is like as follow :

samb01 wrote:OK, thanks to your advices, now my rexx is like as follow :

Select all

/*REXX*/                                                                                                
DO FOREVER
  "EXECIO 1000 DISKR IN (FINIS STEM DTIN."  
  IF DTIN.0=0 THEN LEAVE                    
    DO J = 1 TO DTIN.0                                          
        IF SUBSTR(DTIN.J,22,9) = "PTL A" & SUBSTR(DT.J,34,2) > 10 THEN
      DO
          DTOUT.0 = DTOUT.0 + 1
          J = DTOUT.0
          DTOUT.J = SUBSTR(DTIN.J,1,80)
      END                                    
    END
END
"EXECIO" DTOUT.0 "DISKW OUT ( FINIS STEM DTOUT."

RETURN                                                
EXIT;            
 

This code must fall into endless loop.

Since each DISKR ends with FINIS option (e.g. the file is closed), then the next attempt should re-open it beginning from its first record again, and the whole bunch of records just read shall be re-processed again (and again, and again, and again...)

BTW, this “double buffering” by 1000 records at one single read doesn’t give any benefit except disadvantages. (First level of buffering is provided by zOS I/O system itself.) The code would be much more simple either (1) by reading 1 record at a time into the program stack, or (2) by reading all records (*) at once, into a stem, or into the program stack. The “performance improvement” after reading records by bunch of 1000 of them is an old myth, which has very little to do with the reality.

hello sergeyken,
i used willy jensen's method by reading by 1000.
Because, he said never used "*" in a EXECIO in Production...

So what is the right way to do ?

It seems nobody is agree by the right way...

samb01 wrote:hello sergeyken,
i used willy jensen's method by reading by 1000.
Because, he said never used "*" in a EXECIO in Production...

So what is the right way to do ?

It seems nobody is agree by the right way...

Using 1000-group is possible, but your code logic is wrong. It needs to be changed



Or, reading records one-by-one



Or, reading all records at once (in your example it may be either possible or not, depending on expected size of your input)

reading records by bunch of 1000 of them is an old myth, which has very little to do with the reality.

I beg to differ, I just did a quick test in a z/OS 2.4 system:
Program 1:

Program 2:

The results were:
count: 84000, time: 0.129330, cpu: 0.10
and
count: 84000, time: 0.376596, cpu: 0.34
So reading one record at a time is more expensive. And I found that the difference is much more in an older smaller system. Whether the added cost is significant of course depends.
But I give you that the I/O count were the same.

willy jensen wrote:

reading records by bunch of 1000 of them is an old myth, which has very little to do with the reality.

I beg to differ, I just did a quick test
The results were:
count: 84000, time: 0.129330, cpu: 0.10
and
count: 84000, time: 0.376596, cpu: 0.34
So reading one record at a time is more expensive. And I found that the difference is much more in an older smaller system. Whether the added cost is significant of course depends.
But I give you that the I/O count were the same.

1) I doubt that anybody would care about the difference in 0.2 sec for datasets below 100,000-500,000 records

2) I doubt that anyone dealing with datasets >100,000,000,000 would ask such question at the beginners forum

3) I doubt that the system dealing with 100,000,000,000 records would be based on REXX code

4) Any real system dealing with 100,000,000,000 records usually does some kind of record processing besides of stupid READ/WRITE; it usually takes much longer. If not (if the processing is simple), then instead of REXX any hi-performance standard utility can be used

Etc...

After all, in real life it makes no sense to complicate the logic in order to “save” 0.2 sec...

in real life it makes no sense to complicate the logic in order to “save” 0.2 sec

No argument there, but as I said for smaller systems it does make a difference and I like to program for the smallest common dominator. Ah well, each to her/his own.