| View previous topic :: View next topic |
| Author |
Message |
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
|
| Back to top |
|
 |
Frank Yaeger
Sort Forum Moderator
Joined: 02 Dec 2002
Posts: 1618
Topics: 31
Location: San Jose
|
 Posted: Wed Oct 06, 2004 10:32 am Post subject: |
 |
|
| Quote: | | With a COBOL exit, DFSORT does the I/O if COBOL sets FASTSRT in effect, or COBOL does the I/O if COBOL sets NOFASTSRT in effect. |
Now that I read this again, I see it's confusing.
There are two types of "COBOL exits".
The type of exit involving NOFASTSRT is "generated" by a COBOL program that calls SORT. You don't write this exit yourself - COBOL generates it for you as an interface to DFSORT in the case where the COBOL program needs to do the I/O itself for some reason. If the COBOL program can allow DFSORT to do the I/O directly, then the FASTSRT interface is used and an exit is NOT involved.
The other type of exit is a COBOL exit that you write yourself and tell DFSORT to use via the MODS statement. The samples in "DFSORT Application Programming Guide" that Kolusu referenced are for this second type of COBOL exit. A COBOL E15 exit can either have DFSORT read SORTIN, pass it records and then pass them back to DFSORT, or can just pass all of the records to DFSORT (no SORTIN)
A COBOL E35 exit receives records from DFSORT, and can either pass the records back to DFSORT, or can "delete" them all.
If you want to know more about DFSORT's E15 and E35 exits, see Chapter 4 of "DFSORT Application Programming Guide".
_________________
Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort |
|
| Back to top |
|
|
Phantom
Data Mgmt Moderator
Joined: 07 Jan 2003
Posts: 1056
Topics: 91
Location: The Blue Planet
|
| Posted: Thu Oct 07, 2004 7:56 am Post subject: |
|
|
Thanks Frank & Kolusu,
I have a very bad habit. I don't read the manuals from start to end. Whenever I encounter a problem, I search all the documents that I have. Somehow, I missed to see the examples provided in the DFSORT Application programming Guide pdf. I need to change myself somehow..... 
I'm reading the 4th Chapter of the App. Prog. Guide now. I will get back to you soon.
Thanks a lot for your help,
Phantom |
|
| Back to top |
|
|
William Collins
Supermod
Joined: 03 Jun 2012
Posts: 437
Topics: 0
|
| Posted: Wed Aug 19, 2015 12:34 pm Post subject: |
|
|
| The first Easytrieve Plus example uses a data-name for the subscript. If W-SUB had been defined as a binary field, the difference between that CPU usage and the index used for subscripting would not have been 100%. This has nothing to do with reference-modification (as a link to this topic thinks). |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Wed Aug 19, 2015 1:16 pm Post subject: |
|
|
| William Collins wrote: | | The first Easytrieve Plus example uses a data-name for the subscript. If W-SUB had been defined as a binary field, the difference between that CPU usage and the index used for subscripting would not have been 100%. This has nothing to do with reference-modification (as a link to this topic thinks). |
William,
I cannot test the code with binary variable but are you thinking that easytrieve behaves the same way as COBOL? What is the equivalent of TRUNC(BIN) compiler option for Easytrieve?
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
William Collins
Supermod
Joined: 03 Jun 2012
Posts: 437
Topics: 0
|
| Posted: Wed Aug 19, 2015 1:54 pm Post subject: |
|
|
Not so much that. The subscript is defined as 4 N, which is COBOL-equivalent PIC 9(4) USAGE DISPLAY.
To use that as a subscript, it will first be packed, then converted to binary, then the calculation.
To add one to it, it will first be packed, have one added, then unpacked.
The index is always binary, so there will be no conversion required.
The index over data-name when used as a subscript will be faster (for same reason as COBOL) but not 50%+ faster (other overhead in the program is masking the exact difference). About 30% faster, I'd expect.
The program is doing very little else, so the subscripting will have a big impact.
I can't test it at the moment either 
If someone can, the pseudo-assembler that Easytrieve Plus generates can be listed, to see exactly what is done extra between the two. |
|
| Back to top |
|
|
William Collins
Supermod
Joined: 03 Jun 2012
Posts: 437
Topics: 0
|
| Posted: Wed Aug 19, 2015 2:36 pm Post subject: |
|
|
Thinking further, in COBOL, for a one-byte OCCURS, a data-name as a subscript is faster than an index as a subscript. No clue if this is the case for Easytrieve Plus.
TRUNC(BIN) is the slowest of the TRUNC options for COBOL (generally, although there are specific cases where it is faster). |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
