File handling vs SQL query?

[Harhsaa_KK]

Assume there is a table having customer data which includes CUST_NUMBER,NUMBER_OF_BULBS(Millions of records).

Now to calculate the fee for each customer based on number of bulbs,I have two options in my mind
1. To take the unload of data to a file then by using COBOL file handing methods, read the file and Calculate the fee for each customer
2. In COBOL by using SQL query calculate the fee for each customer

Out of two given options which one is better and why?

[NicC]

If you are using files you are not on a mainframe so the question is irrelevant as mainframes use data sets not files.

If this is a course question then answer using the information that you have learned in your course. If you are simply curious then ask your teacher.

[enrico-sorichetti]

If you are using files you are not on a mainframe

does that imply the the cobol standards committee f***ed up things

when used the term

Code: Select all

FILE SECTION

instead of

Code: Select all

DATASET SECTION

so that' s the reason for the opinion that

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

[Akatsukami]

I respectfully disagree.

COBOL isn't a z/OS (or OS/360) proprietary language, it's a COmmon Business-Oriented Language. We'd justly mock ANSI if they'd defined it using jargon specific to Burroughs mainframes, PDP-11s, or Wintel boxes; there is equally no reason why that definition should be couched in IBM terminology.

Moreover, COBOL internal files map to JCL external files, which in turn map to z/OS data sets. The whole purpose of JCL is to avoid the tight coupling of a program to its environment that is seen on toy computers.

[enrico-sorichetti]

I had forgot to put the smiley,
and You took the thing too seriously John

edited my post to put a smile where it belongs.

[Akatsukami]

Poe's Law strikes again

[NicC]

I've been wanting to say this for ages:
it is

Code: Select all

DSN= (or DSNAME=)

not

Code: Select all

FN= (or FNAME=)

[steve-myers]

... The whole purpose of JCL is to avoid the tight coupling of a program to its environment that is seen on toy computers.

Absolutely. Not only that; to avoid programs from defining their environment. In other words, to use OS/360 as an example, discourage functional capabilities like the things IEHMOVE used to do.

Of course it can't be done, but wouldn't it be nice to go back 50 years in time and interview the senior designers about their motivation? I suspect most would argue they were trying to conserve storage, both core storage in the user programs and external storage both for the user programs and system data set storage required to implement the capability. Another issue is they were implementing a batch system rather than an interactive system.

I'd bet the designers of main device scheduling in ASP and JES3 are still grumbling about the loss of control caused by dynamic allocation!

Of course we're now in the realm of JCL rather than SQL and DB2!

[steve-myers]

To return to the topic; the whole point of SQL/DB2 is to not spin through all the data to pick out a few lines of the data.

[pranav283]

@Harhsaa_KK

Now to calculate the fee for each customer based on number of bulbs

That kind of tells that there must be a column that stores the usage of electricity, if yes, then please mention it.

Now, coming to your query on which method to use:
It depends on various factors:
-> which type of file you use in you COBOL code to bill the customers. Do the concerned fields from a part of some key if you are to use VSAM files ?
-> In case you are going to use DB2 (and not the unloaded file) - then is there an INDEX on the 2-3 columns in the picture? if yes, then It will speed up the processing. If you let DB2 do the work, then make sure you select only the required columns in your SQL to do the calculations as it will keep I/O costs to a minimum. Use a cursor to make sure you process each customer's record.