IBM Mainframe Forum

Now, with your original, the problem was this. The 45, which gives you the incompatible LRECL message, is the length of the longest output record. Your output is fixed-length, so all the output records are made the length of the longest record.

You then simply change those to 80-byte records. The records are "padded", but I'm not sure with exactly what. It should be spaces, most likely, but I don't have SyncSort and don't know what it does with a COPY that simple.

When you Edit the file does it look OK? No "unrecognisable characters"?

If, on one of your multiple output records in the first step you put ,80:X before one of the ,/,s then all your output should be 80 bytes long. No need for the second step.

BillyBoyo wrote:That's good. Some further things
...
With an appropriate INCLUDE, you can have INCLUDE, SORT, no INREC, no OUTREC, and more documentation than your comments provided

Wow BillyBoyo! Amazing tips!

It's because I needed OUTFIL to use ENDREC, then I remained with it …

About the INREC, if I don't use it, then I would need three comparisons instead of one. The amount of data may vary from 1 to 110,000.00. So, you prefer the three comparisons, right?

I do like SYMAMES. =)
First time I used it. Many things to learn yet.

If you are extracting a few records from a lot, then you'll save time, resources and money by using INCLUDE/OMIT rather than OUTFIL INCLUDE=/OMIT=.

Unfortunately, it is not possible to rearrange data before INCLUDE/OMIT, and your date is not in order for direct comparison (the full-stops/periods don't matter, as they are always in the same position). So you have to be careful. Year GT AND Month GT and Day GT is not the same as yyyymmdd GT otheryyyymmdd. (Year GT) or (Year EQ and Month GT) or (Year EQ and Month EQ and Day GT) is the same.

In your existing version, every record is extended by eight bytes, Every record is sorted. The INCLUDE= only prevents the records you don't want being output.

Without symbols and comments your original will be clearer to the next person along, but consume more resources. With symbols and comments you can make the INCLUDE clear and save on the resources.

If you change it around, post what you get so we can review it.

BillyBoyo wrote:You then simply change those to 80-byte records. The records are "padded", but I'm not sure with exactly what. It should be spaces, most likely, but I don't have SyncSort and don't know what it does with a COPY that simple.

The 45 dataset is filled with space on the right (40), and then the 80 dataset is filled with NULL character (00).

BillyBoyo wrote:When you Edit the file does it look OK? No "unrecognisable characters"?

It looks ok.

BillyBoyo wrote:If, on one of your multiple output records in the first step you put ,80:X before one of the ,/,s then all your output should be 80 bytes long. No need for the second step.

Really cool
with this it worked. the records are filled with spaces (40) till the 80 column. One step less and the correct result! Nice.

Well it looks like the "NULL" (binary zeros) are messing it up. Not too surprising, but what is surprising is that some of the Control Cards run, and others don't.

If you run it with some very simple cards and a very simple input file so that you can demonstrate/repeat the effect, then you can ask your boss if you can send it to SyncSort. It shouldn't be like that. It should flat not work, or it should all work, not some of them work and others not.

BillyBoyo wrote:If you change it around, post what you get so we can review it.

I did as you said, and it worked like a charm! hehe






Interesting that SYMNAMES works even if it's filled with NULL character on the right (I was also creating a temp and then copying to 80). And it also works with spaces on the right.

BillyBoyo, I learned a lot with you. Thank you very much.

Last questions xD

I didn't understand this. What do you mean by “actioned” and “line-numbers on”?

BillyBoyo wrote:Some of your Control Cards are actioned. Some are not. Perhaps those which are not have line-numbers on?

What's your approach when you need to compare the value in one dataset with the records in another dataset? Not to join the datasets, but to use in a condition like I used in this case.
Do you think what I'm doing is good?

What I meant was that the SORT was processed, but the INREC and OUTFIL were not.

I was wondering why the INREC and OUTREC were not processed. I thought maybe they had line-numbers in the dataset, and that the SORT did not. So, with my variable-length theory, they would be too long for 80 characters.

Theory turned out to be wrong.

However, it is still the case, with all the SYSIN records having 35 bytes of trailing binary zeros, the SORT Control Card was processed (you see the SORT in the sysout) but the INREC and the OUTFIL were not.

As I suggested, if you can make a really simple example which does the same thing (using DD * for SORTIN and SYSOUT for SORTOUT), where the SORT statement is processed and the INREC/OUTFIL are not (OUTREC is probably the same) then you can confidently package it up and send it to SyncSort as a bug.

SyncSort has been developed over many years. Originally INREC, OUTREC and OUTFIL did not exist. It looks like something with the "newer" code doesn't work in the same way as the "older" code for SORT itself.

The easiest way to associate data from two different datasets is with JOINKEYS. There are many ways JOINKEYS can be used, and you'll find good examples here and on the sister site (link at the bottom of the page).

ICETOOL's SPLICE (in your case, SyncTool's SPLICE) operator can get data from more than one dataset, but SPLICE is complex, and much can more easily be done with JOINKEYS. Plus there is no SyncSort documentation for SPLICE.

There are also ways to concatenate files on SORTIN, know which file the data came from using INREC, and then SORT the data together. These methods would use WHEN=GROUP in various ways.

SORT is a very powerful product. As it has no concept of program-storage, you have to think a little differently. The only place to store data is on a record*. The only way to get data from one record to another is with WHEN=GROUP and PUSH, or by JOINKEYS or SPLICE. Forget SPLIC, unless you really need it.

I think you are doing very well. Sticking with the symbols/SYMNAMES will help you a lot, and others who look at the SORT Decks that you produce. You can't understand everything at once. So build up your knowledge, piece by piece. Everytime you look for something particular, have a look at something else as well. Experiement until you understand.

There are many working examples you can find with a quick search. If you get stuck, there's usually someone here to help. Just show us what you've done, what happened, what you thought should happen. Try to tell in the fullest way. Like "from a dataset generated in another SORT step..."