Coding Approach

Purni · New User Joined: 04 Nov 2009 Posts: 7 Location: USA

I need a feedback from you all.
We have designed software where you used following flow:
SAS program(input I1, I2 and output A) – did one merge to find out common records between I1 and I2 a criteria.
Sort step(input A, output B) – Remove duplicate
PL1 program(input B, out C) – read a database with key as record B and produce field C = B + field
SAS program(input A ,C, I3 output B) –
did one merge to find out common records between A and C based on a criteria.
did another merge to find out common records between output of previous merged and I3 on a criteria.

Please let me know if it was better to use one SAS program for all these step or our approach was better. Is there any other better approach?
I need to know which one is better approach - Divide the functionality in multiple programs or use one program for everything.

Bill Woodger · Posted: Fri Jun 10, 2011 4:35 am

You'll be keeping superk busy. Your original is now in Other Mainframe Topics.

Divide. Keep it simple. Let the data do as much of the work as it can. Appropriate tool for each element. Everything easier. Simpler JCL. Re-runs a doddle. Usually faster to run. Spread workload around team if necessary. Win, win, win.

dick scherrer · Posted: Fri Jun 10, 2011 6:10 am

Hello,

Both of your topics are now in the Other Mainframe Topics part of the forum.

Please review both and decide which one you would like to keep. Also, decide if there is anything in the "other" thread that you would like to have in the "keeper".

Purni · New User Joined: 04 Nov 2009 Posts: 7 Location: USA

I want to keep this one.

dick scherrer · Posted: Fri Jun 10, 2011 6:36 am

Hello,

enrico-sorichetti · Posted: Fri Jun 10, 2011 11:39 am

well seven passes over data seem really a bit too much
better review the requirement to see if they were properly understood!

and .... three languages seem also overkill
from the description nothing thad could not be done thru sort
and using sort steps 1 an2 could be unified

and als I wonder why after the DB read the need to process file A again
( after step1/2 file A has really nothing to do with file C )

PeterHolland · Posted: Fri Jun 10, 2011 2:35 pm

If it was up to me, i would go for 1 SAS job. Depending of course if the database could be accessed from SAS.

Bill Woodger · Posted: Sat Jun 11, 2011 4:52 am

Keyed file. Read to produce report.

Another department sees report, "that's what we need, but with this on".

Some nut gets the requirement. Adds a new keyed file, codes the lookup, amends the report to reflect the new control field. Shows user. They like it. He is 2nd-in-command of support group, so gets the thing added to the schedule with no further input from anyone (it was a "high priority" request).

It is a report using a batch-only file which is updated. Batch-only processing has to wait for online-file processing and back-ups. Reports have to wait for batch-only file updates and back-ups. Cloned original was already a dog, running over an hour. New report was running 2-3 hours. User getting data at 11am instead of 8am.

Muggins here picks up fault request. Clones new report program. Delete everything except processing of main fail. New flat file layout. Populate from main file, other fields waiting for look-up data. Sort and look-up static data files. Six times. Final read of the file to produce report. Whole lot runs in under 10 minutes, and ready well before 7am. Even added a CSV of the report data (the user was typing the report, daily, into Excel) and downloaded it.

Eight simple (seven really simple, one with a report) Cobol programs (instead of one real old boot), seven sorts (instead of none).

Of course, if the original program had "worked" then doing it that way would be perfectly fine as well. Worked as in result, timeliness, understandability, maintainability and all those nice sort of things.

As usual (always, I suppose) the most effective way to do it depends on the requirements and the data. Often, it won't matter much which way. If everything is thought through, usefulness or otherwise of potential implementation solutions becomes obvious. Mostly.

All this proves nothing.