Re: Combining Fields From Files Without COBOL Pgm?

From: Colin Campbell (cmcampb_at_adelphia.net)
Date: 07/16/04 

Date: Thu, 15 Jul 2004 21:35:23 -0700

docdwarf@panix.com wrote:

>In article <Vs-dnT_cl_9MmGrdRVn-uw@adelphia.com>,
>Colin Campbell <cmcampb_at_adelphia.net> wrote:
>
>
>>docdwarf@panix.com wrote:
>>
>>
>>
>>>All right... platform's an IBM mainframe, MVS (or whatever it is called
>>>nowadays) and standard utilities (e.g., SUPERC); utilities available are
>>>DFSORT and MAXBAT (no FileAid).
>>>
>>>I have two versions of a file (key = startpos 2, len 9, character
>>>ascending (actually SNN in display-numeric format), both containing the
>>>same number of records and the same keys. One is 240 characters long
>>>and contains just about everything I need, the other is 480 characters
>>>long and all I need from it is a single character (for each matched
>>>record) from pos 349 to make a new file consisting of the what-I-need
>>>records with this character added at pos 241.
>>>
>>><snip>
>>>
>>>
>>>
>>>
>>>
>>You didn't exactly say whether the longer file contains the same data as
>>the shorter file.
>>
>>
>
>'One contains just about everything I need... all I need from it (the
>other) is a single character... make a new file consisting of the
>what-I-need records with this character added as pos 241.'
>
>
>
>>If the long records contain what's in the short
>>records, plus that one critical byte in position 349, why not change the
>>program that reads the short records to read the long ones?
>>
>>
>
>If the long record were to contain all that I need then it just might be
>possible that I might not have referred to the short record as containing
>'all that I need'.
>
>[snip]
>
>
>
>>As I see it, you have a production program change and a production JCL
>>change to make anyway, so why not make the change the most efficient it
>>can be?
>>
>>
>
>I am not sure what you intend by 'efficient' here; I was taught, long ago,
>that utilities are quite frequently the most efficient ways to deal with
>data.
>
>
>
>>Of course, if the long records do not contain everything that is in the
>>short records, ignore my suggestion.
>>
>>
>
>I will give your suggestion as much attention as the reading which gave
>rise to it appears to have given my posting.
>
>Thanks much!
>
>DD
>
>
>
I only meant to ask whether the long record contained all of the data in
the short record, not to insult you, or to discourage the use of of a
utility, or anything else along those lines. I quite understood that
the 240 byte record contained all the data you needed, except for the 1
byte you want to add. However, I don't believe you said whether the
long record has the same data as the short record, plus more. That is
what I was asking, and guessing that the long records might contain
everything you needed, I made a suggestion.

Where I used the word "efficient", I was referring to the fact (and it
has been a fact for 40+ years in data processing) that passing less data
through the computer / operating system leads to shorter elapsed times,
and almost always, to reduced CPU time.

In my experience, programmers too often look "locally" at a problem, and
miss a chance to accomplish more in a program with less load on the system.

In the case we're discussing here, you have to read the 480 byte records
at least once, because the 1 byte you don't have elsewhere is there. If
that is enough to accomplish the entire process, that is better than
reading the 480 byte record file, reading the 240 byte record file,
creating and writing the 241 byte record file, and then reading that 241
byte record file into the original program (which is going to be changed
anyway to handle the longer records, whether they are 241 or 480 bytes).

Even though DFSORT and SyncSort are quite good at doing I/O, the data
has to be transferred from and to the external storage. That takes
time. After you've created the 241 byte file, your COBOL program will
have to read that file, and do whatever else it was already doing.
Running two steps in a batch job makes the o.s. go through the overhead
of running a job step twice. (I don't know what this is these days,
but it used to be quantified as "several seconds".) If you can make
things faster, why not do so?

Relevant Pages

  • Re: Good Books
    ... I finally got it from the library and in the midst of work woes and holiday frazzle, sat down, read the book, and laughed aloud until the last chapter. ... So, all this time later, thanks for the suggestion, and it's worth a read for those who enjoy a good "fish out of water" tale. ... So I'm kind of glad to hear that it was probably just my reading the second time - I was starting to regret that I had recommended it. ...
    (rec.pets.dogs.behavior)
  • Re: A good C Programming book.
    ... Hello there, being a newbie to C and the forum, I've been reading these post ... and have another suggestion for you. ... The C programming vids are extremely useful, ... > a point with GNU/Linux. ...
    (comp.lang.c)
  • Word should open docs with the same formatting as they were saved
    ... Word 2003 has introduced the "reading view", which is the default format when ... formatting and pagination in reading view, in some cases looking worse than ... This post is a suggestion for Microsoft, ...
    (microsoft.public.word.pagelayout)
  • Re: inconsistent applet not inited error
    ... As per your suggestion, I switched ... over to the object tag after reading up on it. ... It has the safety net ...
    (comp.lang.java.help)