IBM Mainframe Forum

Based on the Syncsort manual 1.4.2.0, the last parameter of WER036B message indicates to what extent the input file is sorted.

BIAS=zz where zz reflects the degree of prior sequencing in the input data. The number displayed ranges from 00 to 99 indicating random to highly sequenced input.

I wanted to know, if the WER036B message in spool shows the BIAS value as BIAS=99, is it safe to assume that the file is already sorted.

So far it was my understanding that 99 being the highest number, would indicate that the file is already sorted. I tested it by specifying SORTED option on the JOINKEYS statement and unfortunately job failed saying record out of sequence.

If anyone has more information, that would help.

Thanks.

"highly sequenced" isn't sequenced. Your test (good for trying) is showing this. Since there can't be anything greater than 99, I guess you're not going to find something there which says "in sequence".

For exactitude, you could only consult SyncSort support. I have no idea if they can tell you anything further.

What are you trying to do?

I was going to thru various job spools to analyze the amount of records being sorted and the CPU, Elapsed time these jobs take.

While taking a look, I saw that some jobs were showing WER036B message with BIAS value as 99 on one of the SORTJNF files. So I was just wondering if we could specify SORTED option on the JOINKEYS statements and thus avoid sort in JOINKEYS. I tried it and the job failed with record out of sequece message. I am happy that I didn't specify NOSEQCK option which would have caused the results unpredicatble.

My previous experience showed me that this worked and I always tested it with SORTED option before adding NOSEQCK to it). But it now appears that it worked in past becasue the file was already sorted on the key fields in some other jobs creating that file. I alwyas presumed that 99 would mean the file is sorted. Unfortunately manual is not very clear on this, though it does say highly sequenced input.

We have thousands of jobs and it can be a time consuming exercise to see which created this file and if it is already sorted on the key fields. Scanning libraries is not an option as there are lot of symbolic parameters. Though we do have some tools, but I was looking for a quick way and any information on this would provide everyone with more knowledge in this regard.

Is NOSEQCK documented for your SyncSort? I thought SyncSort didn't have it, but maybe they've added it.

Even if 99 told you it was in sequence, remember that would only be (for certain) on that run. It would be possible that another time the file was not in sequence with different input data. You have to know what it is sequenced on, bearing in mind that some "master" files will never be sorted, but will (should) always be in sequence. VSAM KSDS obviously have a natural sequence.

For your task, it may be helpful to talk to the people responsible for your Scheduler. If you give them a list of the JOBs where you find the 99, they may be/should be able to give you a report of the pre-dependencies and assist you in locating what created the input which gives the 99s. Explain to them what you are doing, and ask if there is anything they can do to help.

Hi Bill,

Thanks for kind advice.

NOSEQCK was made available with Syncsort 1.4.2.0 but it was also made available for Syncsort 1.4.0.1 with certain PTFs.

I verified around last 15 days of data and the SORTJNF file I am talking about has over 700 millions of records. And I am seeing that everyday, the WER036B message shows the BIAS value as 99.
Now it can not be just by chance that 700 million records are highly sequenced every day. When I manually browsed one of the files, I see that the records are out of sequence.

I am in the process of getting the job that creates this file.

But for now it appears that BIAS=99 does not mean that the file is already sorted. Syncsort should probably make it very clear in their manual in order not to cause any confusion.

Thanks.

Thanks for the update on NOSEQCK, very useful. Is it documented in the manual, or just as a change, if you have a moment to check.

Try to follow it up with SyncSort. They have a website with a User Community, and it is free to register (for Licensed Users). It may mean, for instance, that only a most minor part of the sort key is out of sequence, such that it may be possible to include that in a previous SORT without disturbing processing. Juest guessing, but with 700m records it is the type of thing you can look for. Even if some program needs to be changed, for a change in sequence, you may get substantial benefits from not having to sort in the JOINKEYS (exactly why you're looking at this).

Too many people use JOINKEYS wihtout being aware that it is sorting the files (they believe in Magic). One little trick that may help is, once you find who was responsible for the implementation in one such case, have a look at any other JOINKEYS steps that they have implemented...

Hi Bill,

The NOSEQCK is documented in the 1.4.2.0 manual. And yes as you have suggested, I will try to follow up with Syncsort.

And you are very much true that once I find out the person who coded it, that might throw some more possible tuning opportunities.

Thanks for the further update. Good luck with the work.