SYNCTOOL problem: S0C7 in the CTL3CNTL step

tarunbhardwajleo · Posted: Tue Mar 06, 2007 4:15 am

Hi,

Iam trying to sort an 84 byte fixed block file which has a few headers, a number of detail records and a few trailers.
1. The header record has its first two bytes as '10', followed by a timestamp when that header was created.
2. The detail record has its first two bytes as '20'.
3. The trailer record has its first two bytes as '30', followed by a number in the packed decimal format S9(9) Comp-3
4. The number of headers would always be equal to the number of trailers.

I want to build a file out of it that has just the first header present in the given file and just one trailer. In the trailer record that I finally get, the first two bytes, that is '30' should be followed by the sum of numbers present in all the trailer records in the packed decimal format. The detail records should be untouched and should be present in the file between the header and trailer without any editing.

The file looks something like this

dick scherrer · Posted: Tue Mar 06, 2007 4:23 am

Hello,

At a quick glance, it appears that your data is Zoned Decimal while your control statement refers to Packed Decimal. Try changing the PD to ZD in the SUM statement.

tarunbhardwajleo · Posted: Tue Mar 06, 2007 4:39 am

Still the same problem !

William Thompson · Posted: Tue Mar 06, 2007 4:44 am

I'm not real good at this, but from what your code looks like, why aren't just creating T1 as the header with sequence (include the first and 10 only), T2 as the data with sequence (include 20 only) and T3 as the trailer with sequence, summing on the packed field (include 30 only). sort on the 10/20/30 and the seq and drop the seq on output?

dick scherrer · Posted: Tue Mar 06, 2007 7:04 am

Hello,

What is in the 30 records starting in position 3? Whatever it is, it does not seem to be numeric for 5 bytes.

I copied your step onto my machine, changed the input to dd *, and got the 0c7. I then changed the value in the first 30 record to 11111 and the value in the second 30 record to 22222 and when the "summed" 30 record was created, i have 33333 (the sum). I also changed the SUM to use ZD for my test.

I'd copy/paste my results, but the remote emulator this site uses is fairly horrible - among other things, it doesn't do copy/paste.

When i go back onsite in the morning i'll send my output if you're interested.

Please look at the 5 bytes starting in position 3 of the 30 recs in hex and see if they even look like packed decimal numbers. Might they be comp rather than comp-3?

tarunbhardwajleo · Posted: Wed Mar 07, 2007 2:50 am

Hi Dick,

Its S9(9) COMP-3 and it starts from the 3rd byte in the record.... Iam still puzzled as to why am getting the S0C7 abend... its kinda getting on my nerves now...

dick scherrer · Posted: Wed Mar 07, 2007 3:44 am

Hello,

Please look at the data in hex (TSO/Browse) and post back what is in the first 10 bytes of the '30' records. Hopefully, a test of only a few can be run.

Once you post the hex for the 30 records, we will be able to determine why the 0c7. When you post them, please use the "code" tab at the top of the reply panel. "Code" uses a fixed font and lines up better.

Do you have access to the code that creates the records? A look at that may prove interesting also.

I'll keep an eye out for your reply

tarunbhardwajleo · Posted: Wed Mar 07, 2007 3:59 am

Hi Dick,

Here is the type '30' record in the hex format. You can see the 5 bytes in Hex starting from pos 3

dick scherrer · Posted: Wed Mar 07, 2007 5:26 am

You're welcome.

Well, that 30 record looks good. What's the chance of making a copy of the input file and only running 2 "groups of data - verifying that both 30's have a valid packed number?

Is it possible that deeper into the file is one or more corrupted 30?

I'm going to be on the road in a short while, but hope to get back online tonight and tweak my test file to include PD rather than the test i did w/ ZD.

dick scherrer · Posted: Wed Mar 07, 2007 7:48 am

Hello,

When i patched in some valid packed decimal numbers, the job works. The output has one 30 record with the correct sum in positioins 3-7.

I'm quite certain now that there is one or more corrupt records in the input file.

Good luck and let us know what you find

dick scherrer · Posted: Wed Mar 07, 2007 7:52 am

Ooops,

That should be "positions 3-7" instead of "positioins 3-7" and "fairly certain" rather than "quite certain"

Gotta leave a bit of room for "strange magic".

tarunbhardwajleo · Posted: Mon Mar 12, 2007 9:11 pm

Hi Dick,

Thanks for your reply. The problem exists with Type '20' records. When the type 20 records are included, I get a S0C7 abend but when I exclude them, the job runs fine and the sum is also calculated correctly for the type '30' records.

Although the my sort logic does not include type '20' records but Iam confused why Iam getting a S0C7 cos of it. Could you please figure out where the problem lies in my logic ?

dick scherrer · Posted: Mon Mar 12, 2007 10:00 pm

Hello,

How are you including/excluding the 20 records? Are you doing this in the sort or changing the file before it is processedin the sort?

How many records are in the entire file?

If you can post the "set" of records where the 0c7 occurs, we should be able to figure out why.

William Thompson · Posted: Tue Mar 13, 2007 1:54 am

I know it's a stupid question, but it looks like you are summing in cntl3 the type 30 trailers and it looks like you are expecting the type 30 trailers to be in the T2 file but it also looks like the T2 file has no type 30 trailers since the T2 dataset got created by the cntl2 which omits all 30's and includes everything else.....