IBM Mainframe Forum

Why not let sort do the summation and the removal of duplicates? There are examples in the sort sections.

sjrcreation wrote:

Zio69 wrote:Unfortunately the array needs to be sorted by its key and no duplicates are allowed

hi Zio69 are you sure about the above..

with "older releases" (until 6.3-6.4) I'm 200% sure: if there's a duplicate or the tables aren't sorted you get a "A007 TABLE INPUT IS NOT IN SEQUENCE - file-name" error (see Reference Guide - Appendix B - Diagnostic). If you were talking about COBOL, then of course there's no SYSTEM error... but try a SEARCH ALL on an array that is not in sequence and tell me what happens!

sjrcreation wrote:so what will be the best approach for this ??

As BillyBoyo said, Synchronized processing... something like:



where VFILEn is a VIRTUAL file with the same layout as the corresponding "phisical" file. BTW, when 2 or more files have the same layout, you only need to code the fields int the FIRST file; afterwards you can code COPY. I.e.
FILE VFILE1 VIRTUAL F(xx)
COPY FILE1

Hey, Nic, I got busted in the Syncsort forum for suggesting using Easytrieve Plus...

Syncsort uses Keywords, Easytrieve uses something more readable and you can process headers/trailers readily, produce reports of what you've done to the data in the format you want them, stuff like that. And you can knock together the code pretty quickly.

I do wonder if anyone has time to do a "race" between Easytrieve and whatever-sort so we can get an answer to the performance thing as well.

Hi Billy

I do not know if he has DFSORT, CASORT or whateverSORT. Also I do not know if he HAS TO use Eazytrieve - he does not say. Certainly with DFSORT you can produce all sorts of reports with headers and trailers and, with appropriate comments, even I can read the stuff - but the only ones I have seen have been written by me!! trying out the various options. A lot of manual reading but if properly commented should be adaptable easily to similar requirements. I will have to get back to that exercise as I didn't go through all possibilities and Frank keeps on adding new ones - soon ICETOOL will be able to tie my shoelaces for me!

Yes, it does look they have added a lot of extra functionality to various SORTs. I found a bunch of old "reference cards" of mine the other day. I have a SYNCSORT pocket reference dated 1982. In those days, sorts did sorts and merges.

I can understand they want to extend them (not so many new sites to offer them to, so higher competition and having to encroach on other areas to make an extra buck or two) but why don't they admit it, and make it (all the keyword parameters) look a bit more like a "real" language? They could even support both, for backwards-compatability. Perhaps I should patent this idea before they can read it... And perhaps I should look at the DFSORT forum (I've never managed to use IBM's sort, always SYNCSORT or CA-SORT) to see if they've already done it...

ok.
little confused .
Thanks for your respond.

Hello,

I do wonder if anyone has time to do a "race" between Easytrieve and whatever-sort so we can get an answer to the performance thing as well.

Both DFSORT and Syncsort "outrun" Easytrieve for "big file" work. Easytrieve will also use more CPU.

In those days, sorts did sorts and merges.

In those days, Syncsort also had reporting capability.

little confused .
Thanks for your respond.

You're welcome. Unfortunately topics sometimes take a diversion . . .

What has you confused?