Rules:
- Selection of output is based on the date field, present in column 30 onwards.
- I need to select the records which are of "latest date", these dates come in the records itself.
- This latest date is not system date and not available by any other means (just present in inputs).

Can you explain about ur problem in bit more detail...Do you want a sort card which will pick up the records of latest dates every time or you have the luxury to change the sortcards everytime to sortout the records of your desired dates.

I suspect this will work for dates with a single-digit month and day but will fail for other dates (which is most dates). . .

Given that the data must be passed twice regardless, why not make two steps - one pass to select the latest date putting the data into a file and the second to select all records that match that date file?

if you have some good idea about a "dynamic" SORT card, would appreciate if you share it with us.

As i mentioned before, a way (the only way i can think of if the date is completely based on the data) to do this dynamically is to pass the data selecting the highest date.

When the data is passed a "sort control record" containing the highest date is written and used by the actual copy step.

I do not believe you can get what you want passing the data only 1 time.

I would also not try to sort the file by date descending to get the highest date first - this would just waste resources - the greater the volume, the greater the waste So far, this hasn't been suggested, but i imagine it could be. . .

I do not believe you can get what you want passing the data only 1 time.

I'm working on combinations, I try to use SYMNAMES but this is availbale in 1.3 release of SyncSort & my site is using 1.2.something version. But that would also need two passes.

And

Quote:

I would also not try to sort the file by date descending to get the highest date first - this would just waste resources - the greater the volume, the greater the waste So far, this hasn't been suggested, but i imagine it could be. . .

What difference would it make, as SORT would "process" all the records even if two passes..

P.S.: I kept this thread open for a longer time and didn't refresh, so couldn't check your replies that fast..

Yeah, this was one of the my questions when I was asked to write such a SORT, I'll again ask 'them' to provide me the dates in some standard formats.

The format shown may be the "standard format". If you're willing to write just a tiny bit of code, it is no problem to work with dates in that format. Assuming there is already code somewhere that already reads this file, it should not take 30 minutes to clone it, add an output file to hold the "date record", and pass the data selecting the most recent date. . .

Symnames will not remove a pass of the data - it would only let you use a "name" later in the code.

you are saying that we cant't get the desired o/p in a single step and also without descending order.

We might get the result in a single "step", but not in a single pass of the data. It will take one pass to determine the most recent date and a second pass to select all of the records with that date.

Quote:

could you please post the jcl how can we do this without descending sort .Just curious to know.

Once the date is known, simply passing the file selecting the records for the "date" will not require any sorting of the file. If the output (records matching the select date) need to be in some particulr order, they could be "sort"ed rather than "copy"ed while creating the output file.

Think about it:
2 fd's
2 opens/closes,
1 read
1 unstring
1 compare against the previous high date moving in "this" date if is is greater
1 write of the highest date after all records have been checked

That took less than 2 minutes - the code would not take much longer if entirely coded/typed by hand. And the program could mostly be cloned. . .
FWIW. . .

/SadnessOn
One thing i see today is what i call "the hammer syndrome". That is when one has a hammer and has learned to use it for more than simply pounding, there is a tendancy to want to use the hammer even when it is not appropriate (or indeed even wrong). I believe a requirement should be looked thru and some appropriate tool(s) be used - not just try to force the hammer to do the task.

Some solutions suggested (not this topic) take 3 or 5 passes of the data where 1 or at most 2 passes would be all that was needed. Worse, it might not be obvious to someone who had no clue and simply implemented something posted that successfully tested on a few records. If the total number of records is less than 100 it probably would never matter. When that process must handle 100million records, the "tuning" topics arrive. . . Or a new mainframe becomes necessary.

What makes it sad is that it is just not that difficult to deliver processes that run correctly and run well and are maintainable.
/SadnessOff

This work is not from my project I'm handling. They came to me with this requirement, they had quite a good constraint of time limits. My first thought about this prolem was to write a COBOL program but they asked if possible please work parally on SORT, because, today (July 07, IST) is their UAT (count the time since when I posted first). Well, I know this type of projects are not always there & this is not a nice example of a good management but when clinet needs one can't just deny (unless you want to loose your project).

That's all, and I try to help them, but I was facing lil problem in writing the SORT, so asked into the forum; so that if program is not possible at time some JCL could be handy; later it would be replaced with a program, hopefully this later would be pretty soon.

Tried to reply several hours ago, but was unable to post due to some kind of "technical difficulties" . . .

Quote:

when clinet needs one can't just deny

True, i would not recommend to "just deny". I do make sure the client gets what they require rather quickly. . . Given that they had a time constraint and given that the requirement was posted around 9 on Friday, using a bit of front-end cobol to detemine the selection date and doing the sort/copy with sort, the alternate process could have been running by noon on Friday.

True, i would not recommend to "just deny". I do make sure the client gets what they require rather quickly. . . Given that they had a time constraint and given that the requirement was posted around 9 on Friday, using a bit of front-end cobol to detemine the selection date and doing the sort/copy with sort, the alternate process could have been running by noon on Friday.