Efficient Data Processing

Hello. I am trying to modify an existing COBOL program that reads in data (all 100K+records) then moves that data into a sort file for processing. I would like to only process (sort) those records that meet a certain criterion. My understanding is this will make my program execute faster therefore making it more efficient. Currently the program reads all records then eliminates those records which meet the criteria. I am new to COBOL programming and am not sure what information to include to get helpful feedback.

100k records not that much for COBOL program running on ZOS. There not much you can do, and generally not worth the effort. How long this program takes to run to run?

Approximately 30 seconds.

WTH, changing a batch program that runs 30 seconds is not worth your time. Reading record sequentially to selecting them for sort is what you would do in 90% of COBOL programs.

Thank you. I am new to “professional” programming. I guess with time I can get beyond just successful and include concise, efficient, and future friendly.

Efficiency and elegance, in a program, are beautiful to see; and they are very satisfying to create.

Not everyone understands what it is like, to smile with satisfaction, at the print-out of one’s own COBOL program, and think, to oneself, “I am a young, handsome knight from the Age of Chivalry, leaning back, against the base of a tree, some warm, midsummer day, playing my flute or my mandolin! And this gigantic, clunky mainframe that I am working on, is, in truth, a fair, lissome maiden, dressed in white, with flowers in her hair, dancing, barefoot, before me, to the rhythm of the music --the programs that I write-- that I play, on my instrument [my work-station]. And she is beautiful. And the music is good. And her dancing, to that music, gives it life! Truly, it is a delight to be here, with her; and a joy, to be alive, writing programs to earn my living!”

Programmers who try to do good work, however, do know that feeling.

In my own, personal opinion, the “point” of COBOL is, that it is understandable, and NOT just by programmers and other, arcane and esoteric types.

A COBOL programmer wants the program to be able to be read; a typical COBOL programmer wants the one who is reading the code, itself, to be able to understand what is happening, within that code.

“Mom and Dad? I had an amazing victory, at work, today! I solved a very difficult problem!”

And they reply, “Oh, really, my child? Tell me about it.”

And the COBOL programmer says, "Well, I had too many things to think about, all at once.

"I was evaluating a group of 30 different things, and each of those things could have had any of five shapes and any of 3 sizes.

"And, for each combination of shapes and sizes that those 30 items had, as they stood next to each other, I had to ask the computer to do some, specific, individual thing.

“And I was getting lost, in my logic. It was very frustrating. But, today, I figured out how to do it!”

The parents look at each other, with a smile of pride and congratulations that each offers to the other, with their eyes and a touch of their hands.

“That’s wonderful!” they exclaim, “How did you do it, my child? How did you solve the problem?”

“What I did was,” the COBOL programmer replies, "I put the 30 items all together, in a container, like a treasure-chest.

"And there was a different treasure chest, for each combination of those 30 items, in all their shape-and-size variety!

"And I put each of those ‘treasure-chests’ in its own ‘square’, on a giant ‘chessboard’.

"And there was a note, on each ‘square’ of that ‘chessboard’, saying, ‘IF you ever see a combination that is exactly like the one that’s in THIS PARTICULAR TREASURE-CHEST, THEN I want you to PERFORM a certain, specific action.’

"There was a different ‘certain, specific action’, for each of the ‘squares’ on that ‘chessboard’.

“So, whenever my program ‘saw’ something, it checked all of those ‘treasure chests’, to see if ANY of those ‘treasure chests’ looked EXACTLY like the thing that my program was ‘seeing’.”

“That sounds like a lot of work,” says Mom (or Dad).

“Yes,” agrees the COBOL programmer. “Yes, it was a LOT of work. BUT, I DIDN’T FORGET ANYTHING. I EVALUATED EVERY POSSIBLE COMBINATION, and figured out ‘the right thing’ to do, for EACH of those possibilities. In advance. NOTHING SLIPPED THROUGH MY NET!”

[NOTE: The COBOL programmer, in the above story, just explained the concept of a “Finite-State Automaton” (adapted into COBOL) to that programmer’s PARENTS!]

COBOL MUST be able to be understood by people who “know the business”, but do NOT know how to program a computer!

There are programs that take hours, to run; and each of them is but one piece of an integrated system of processes that happen at various times, under specific conditions, and at different intervals and various stages of the overall processing.

There are programs that do so much, with every record that they read, that the program has to include a “recovery” process in it, that will allow the system to “pick up from where it left off”, if there should be a computer crash or a power outage, an hour (or MULTIPLE hours) in!

Everything that’s happening, in that processing, is part of THE BUSINESS of the company that owns the computers and the data!

The BUSINESS people need to understand it.

That’s why COBOL was created, in the first place.

Otherwise, they would have just stuck with Fortran and Assembler.

Elegance and efficiency are beautiful. Being CLEAR is, also, worth-while.