|
View previous topic :: View next topic
|
| Author |
Message |
jerryte
Active User
Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada
|
|
|
|
I ran the below ICETOOL statement to copy the first 100 records of a large dataset:
| Code: |
SUBSET FROM(ICEIN) TO(ICEOUT) -
INPUT KEEP RRN(1,100) |
I assumed it would copy the first 100 records and then quit. Instead ICETOOL read the entire dataset which took a while since it was a large dataset:
| Code: |
ICE055I 0 INSERT 0, DELETE 62855791
ICE054I 0 RECORDS - IN: 62855891, OUT: 100 |
I could have done a SORT COPY with STOPAFT=100. Does anyone know why ICETOOL read the entire dataset? |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| You told it to. Or rather, you didn't tell it not to. FIRST(100) |
|
| Back to top |
|
|
jerryte
Active User
Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada
|
|
|
|
Thanks. The FIRST(100) does what I expected it to do.
When I code the RRN(1,100) then ICETOOL invokes an E15 user exit program. What puzzles me is why this program doesn't do some simple math and determine that once it has sent out 100 records that there is no need to read more records since nothing more will get written. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
Given the umpteen variations of the different operands which can be mixed and matched, it is NOT just "simple math"! I built in some short cuts for special operands such as FIRST(n), but to build in short cuts for every possible variation was prohibitive. Keep in mind that for a general purpose utility, what non-developers see as "simple" often isn't "simple" for the guy who has to actually develop it, and there are many tradeoffs.
Nothing stops you from using a simple DFSORT job with STOPAFT=n if you understand how that works. |
|
| Back to top |
|
|
|
|
