replace a programatical compare

Ronny John · New User Joined: 30 Mar 2010 Posts: 33 Location: USA

I have two files Fie1 and file2.
File1 is a PS file created using a program having the laYOUt as given below:

01 A PIC X(1).
01 B PIC X(6).
01 C PIC X(4).
01 D PIC X(1).
01 E PIC X(1).
01 F PIC X(1).

File2 is a VSAM file having the the layout as below: U and V forms the key.

01 U PIC X(6).
01 V PIC X(4).
01 W PIC X(1).
01 Z PIC X(1).
01 Y PIC X(1).

Can you plase give me a sort that will compare the record of file1 with file2 such that For records having B=U, C=V and W=0, the E should be equal to Y, else write the record to a new File3 having teh same layout a file1.

I need to replace a program with a sort to improve time of execution.

expat · Posted: Sun Jul 10, 2011 1:49 pm

1 What have you tried yourself
2 What research have you done
3 Which sort product and release level is installed
4 RECFM & LRECL of file1
5 RECSZ 0f file2
6 Please do not ask for a solution straight off of the bat without trying yourself

Bill Woodger · Posted: Sun Jul 10, 2011 2:58 pm

I don't understand your record layouts.

Each 01 in a Cobol program starts on a double-word boundary.

dick scherrer · Posted: Mon Jul 11, 2011 7:10 am

Hello,

Ronny John · New User Joined: 30 Mar 2010 Posts: 33 Location: USA

Bill,

You are right about the record layout thing. That was a typo from my side.
01 File1rec.
05 A PIC X(1).
05 B PIC X(6).
05 C PIC X(4).
05 D PIC X(1).
05 E PIC X(1).
05 F PIC X(1).
05 ---------
05 ---------

01 File2rec.
05 V PIC X(4).
05 W PIC X(1).
05 Z PIC X(1).
05 Y PIC X(1).
05 ---------
05 ---------

Expat,
The input to file is a GDG base having genrations created over a period of 1 Year. Manually searching the members is impossible using fileaid or file manager. So i wrote a program. I was suggested that rather than using a program its better to use a sort, but i am not that familiar in JCL.
File1 Record format is FB and LRECL is 15000.
Rec size of file 2 is 500 bytes.

dick scherrer · Posted: Mon Jul 11, 2011 9:29 am

Hello,

For whatever reason, you did not post some sample data. . .

From the bit you have posted, your performance issue/problem is the way you wrote the code.

You need to get the gdg collection into sorted order and then match this data against the other file. If you do the match inside a program or using the sort, both will run acceptably.

Nic Clouston · Posted: Mon Jul 11, 2011 10:03 am

I assume your program runs in batch? If so the JC you wrote to run it is very similar to the JCL you need to run a sort - job card, exec, input dd, output dd and sysin for the control cards which are NOT jcl but sort control cards.

Bill Woodger · Posted: Mon Jul 11, 2011 2:14 pm

So, you will certainly need to sort your 300+ generations (not members of a gdg). If sorting already, you'll certainly get a performance boost against the existing method.

Your VSAM file is in key order of the first 10 bytes? Is it a KSDS with that key, or, to put it another way, does it have duplicates of the 10-byte key you want.

Do you have headers/trailers on your flat file? If not you might (probably) not know which of the generations your extracted non-matches come from. If you do, hopefully you have a business date you can attach to the records so you know which generation it comes from.

If you don't have anything to tell you where it came from (reliably) then you might be looking at individual jobs for each generation of the dataset.
Then maybe you don't need the sort (depending on the order of the individual file) and you can look at using your original.

Of course, all of the answers should be in the spec. If you need more help, we need more answers.

SORT is not JCL. SORT is a program. All programs run in batch require JCL. What makes a piece of JCL a SORT is the program/procedure executed and the control cards supplied to it. The control cards are the most important thing you need to know, so check the forums and your sort manuals. For the JCL itself, get hold of something that works at your site, you won't have to change it much, probably.