COBOL Processing Logic for the below scenario

raveendra_ibm · New User Joined: 07 Jan 2006 Posts: 31

Hi All,

We have the following requirement :

We have a file with the following layout

Client Number 3 digit
Product ID 5 digit

Each Product can be owned by more than one Client and
each Client can have more than one Products.

Sample Data : (File A)

William Thompson · Posted: Sat Apr 07, 2007 12:07 am

Alot of the design would depend on sizes; The number of file B requests; The number of file A owner/product entries; The number of products a client might own; The number of times you might need to do this lookup.

Pete Eagleton · New User Joined: 14 Feb 2007 Posts: 11 Location: Chicago

read 'FILE A' and just load it into an internal table. Then you can read 'FILE B' and search the table several different ways. Find all the products the 'client'( from file b) owns and store the found products then re-search the table for all the clients that have those products.

raveendra_ibm · New User Joined: 07 Jan 2006 Posts: 31

Thank you William and Pete for your responses...

Here are a few more details of the scenario.

The fields are S9(9) COMP-3 and S9(11) COMP-3 respectively. We have around 50,000 entries in FILE A and the number of FILE B requests could be around 30,000, we need to do this lookup atleast twice for each entry in FILE B.

Given these statistics I dont think an internal table could be of any help to us.... Could you please let me know whether creating a VSAM file with the Client Number as key and Product ID as alternate key, the only appropriate solution for this.

Thanks,
Raveendra.

Pete Eagleton · New User Joined: 14 Feb 2007 Posts: 11 Location: Chicago

doing a KSDS is not the only solution (but maybe the better one). If you can afford the system overhead you could just read 'file a' sequenially for each lookup. it would be reading the entire file many times but is another way to do it. Best is, if available, is to put 'file a' into a DB2 structure. SQL can be a wonderful thing.

William Thompson · Posted: Sat Apr 07, 2007 2:16 am

dick scherrer · Posted: Sat Apr 07, 2007 2:16 am

Hello,

If your site uses DB2, you could create a temporary table and do what you want. This would be similar to your vsam approach but would done within the database environment.

If you want an alternative that does not use vsam or database, you can also do what you want using 2 passes of the orignal file. Make one pass with the fileA sorted by client and product matching against fileB selecting all of the records from fileA for the clients in fileB creating a new fileC containing the product numbers for all of the matching clients.

Sort fileC by product id discarding duplicates and fileA by product id; then match them giving you all of the clients who have each product id.

TG Murphy · Posted: Sat Apr 07, 2007 4:47 am

Here is another approach to consider.

1. Sort the file by Product ID.

56780 231
56780 232
56780 233 ( I added this record myself to better illustrate step 2.
56781 233
56782 233
56782 231 (I added this one too...
56783 234

2. Create a COBOL program that loads all records for a given product into a table. For the simple data shown above, it would first load these records...

56780 231
56780 232
56780 233

Note 1: In order to do this the program must use standard "control break" processing - sometimes called "set" processing.

Note 2: Assumption here that the data for the biggest product would fit into a table. If not, then this approach won't work.

The program would then use this table to write out the following records:

56780 231 232
56780 231 233
56780 232 231
56780 232 233
56780 233 231
56780 233 232

Alternatively, if volumetrics allow you could write the above records to a variable length file as follows...

56780 231 232 233
56780 232 231 233
56780 233 231 232

However, let's stick with the first suggestion.

You can see that we've cross-indexed the data.

Then the COBOL proceeds to do the same with the remaining records. When the COBOL program terminates, it would have written out the following records:

Prod Cus1 Cus2
56780 231 232
56780 231 233
56780 232 231
56780 232 233
56780 233 231
56780 233 232
56781 233
56782 231 233
56782 233 231
56783 234

3. Sort the new file by Cus1.

Prod Cus1 Cus2
56780 231 232
56780 231 233
56782 231 233
56780 232 231
56780 232 233
56780 233 231
56780 233 232
56781 233
56782 233
56783 234

Now you need another program to process this new file along with File B.

I would hazard a guess that this approach will out-perform the KSDS approach - perhaps significantly. However, the work involved is significantly more substantial as well. Under most scenarios - KSDS approach is best solution because it is far less costly to build and maintain than the beast that I just described. However if performance is your primary aim, then maybe....

raveendra_ibm · New User Joined: 07 Jan 2006 Posts: 31

Thank you Pete, William, Dick and Murphy for all your suggestions.

Pete, its not feasible for our shop to go for DB2, so we are zeroing in to KSDS approach.

Murphy, thanks indeed for the detailed explanation.

So finally going for KSDS with an AIX

Thank you all.

Regards,
Raveendra.

dick scherrer · Posted: Sun Apr 08, 2007 2:46 am

You're welcome - good luck