Cobol - Combining Fields From Files Without COBOL Pgm?

Author

Combining Fields From Files Without COBOL Pgm?

docdwarf@panix.com

2004-07-14, 3:55 pm

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.

Writing a COBOL program to do this is none-too-difficult... but adding
another program to the jobstream (with associated move-to-Prod overhead)
is something I'd rather avoid.

Given the situation and tools outlined - no SAS, no REXX or CLIST
(knowledge of those tools on this site is minimal and their use is
actively discouraged) - might anyone have an idea how to go about this or
am I doomed to putting into Prod a program which consists, at its heart,
of something akin to

READ FILE1 INTO WK-FILE1-REC.
READ FILE2 INTO WK-FILE2-REC.
IF WK-FILE1-SSN = WK-FILE2-SSN
MOVE WK-FILE1-REC TO WK-FILE3-MAIN-CHUNK
MOVE WK-FILE2-POS-349 TO WK-FILE3-POS-241
WRITE FILE3-REC FROM WK-FILE3-REC
END-IF.

.... ?

Thanks much.

DD

Robert Wagner

2004-07-14, 3:55 pm

docdwarf@panix.com

2004-07-14, 3:55 pm

In article <40f55f44.246080484@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>Is this one-time or ongoing?

From the original posting:

--begin quoted text:

Writing a COBOL program to do this is none-too-difficult... but adding
another program to the jobstream (with associated move-to-Prod overhead)
is something I'd rather avoid.

--end quoted text

One-time situations, in my experience, rarely are moved to Production, Mr
Wagner; I thought that my mention of avoiding 'associated move-to-Prod
overhead' indicated that this would be an ongoing circumstance.

[snip]

>For ongoing, I'd load them into two DB2 tables and join them with scripted SQL.

From the original posting:

--begin quoted text:

Given the situation and tools outlined...

--end quoted text

The 'tools outlined', Mr Wagner, were 'an IBM mainframe, MVS (or whatever
it is called nowadays) and standard utilities (e.g., SUPERC); utilities
available are DFSORT and MAXBAT (no FileAid)'... and COBOL. No DB2 here,

ly.

Thanks much!

DD

Frank Yaeger

2004-07-14, 3:55 pm

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.
>
> Writing a COBOL program to do this is none-too-difficult... but adding
> another program to the jobstream (with associated move-to-Prod overhead)
> is something I'd rather avoid.
>
> Given the situation and tools outlined - no SAS, no REXX or CLIST
> (knowledge of those tools on this site is minimal and their use is
> actively discouraged) - might anyone have an idea how to go about this or
> am I doomed to putting into Prod a program which consists, at its heart,
> of something akin to
>
> READ FILE1 INTO WK-FILE1-REC.
> READ FILE2 INTO WK-FILE2-REC.
> IF WK-FILE1-SSN = WK-FILE2-SSN
> MOVE WK-FILE1-REC TO WK-FILE3-MAIN-CHUNK
> MOVE WK-FILE2-POS-349 TO WK-FILE3-POS-241
> WRITE FILE3-REC FROM WK-FILE3-REC
> END-IF.
>
> ... ?

DD,

You said you have DFSORT, so here's a DFSORT/ICETOOL job that will do
what you want using the SPLICE operator. For complete information on
SPLICE, see:

http://www.storage.ibm.com/software...tmutol.html#spl

//S1 EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN1 DD DSN=... FB/240 input file
//IN2 DD DSN=... FB/480 input file
//T1 DD DSN=&& T1,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,P
ASS)
//T2 DD DSN=&& T2,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,P
ASS)
//CON DD DSN=*.T1,VOL=REF=*.T1,DISP=(OLD,PASS)
// DD DSN=*.T2,VOL=REF=*.T2,DISP=(OLD,PASS)
//OUT DD DSN=... FB/241 output file
//TOOLIN DD *
* IN1->T1: copy records and add blank in position 241
COPY FROM(IN1) TO(T1) USING(CTL1)
* IN2->T2: copy key and add byte from 349 in position 241
COPY FROM(IN2) TO(T2) USING(CTL2)
* T1/T2->OUT: Splice on key to add byte from 349 at
* position 241
SPLICE FROM(CON) TO(OUT) ON(2,9,CH) WITH(241,1)
/*
//CTL1CNTL DD *
OUTREC FIELDS=(1,240,241:X)
/*
//CTL2CNTL DD *
OUTREC FIELDS=(2:2,9,241:349,1)
/*

JerryMouse

2004-07-14, 8:55 pm

Frank Yaeger wrote:
> You said you have DFSORT, so here's a DFSORT/ICETOOL job that will do
> what you want using the SPLICE operator. For complete information on
> SPLICE, see:
>
>
http://www.storage.ibm.com/software...tmutol.html#spl
>
> //S1 EXEC PGM=ICETOOL
> //TOOLMSG DD SYSOUT=*
> //DFSMSG DD SYSOUT=*
> //IN1 DD DSN=... FB/240 input file
> //IN2 DD DSN=... FB/480 input file
> //T1 DD DSN=&& T1,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,P
ASS)
> //T2 DD DSN=&& T2,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,P
ASS)
> //CON DD DSN=*.T1,VOL=REF=*.T1,DISP=(OLD,PASS)
> // DD DSN=*.T2,VOL=REF=*.T2,DISP=(OLD,PASS)
> //OUT DD DSN=... FB/241 output file
> //TOOLIN DD *
> * IN1->T1: copy records and add blank in position 241
> COPY FROM(IN1) TO(T1) USING(CTL1)
> * IN2->T2: copy key and add byte from 349 in position 241
> COPY FROM(IN2) TO(T2) USING(CTL2)
> * T1/T2->OUT: Splice on key to add byte from 349 at
> * position 241
> SPLICE FROM(CON) TO(OUT) ON(2,9,CH) WITH(241,1)
> /*
> //CTL1CNTL DD *
> OUTREC FIELDS=(1,240,241:X)
> /*
> //CTL2CNTL DD *
> OUTREC FIELDS=(2:2,9,241:349,1)
> /*

The JCL is longer than the dirt-simple program he's trying to avoid. Oh
well....

Arnold Trembley

2004-07-14, 8:55 pm

JerryMouse wrote:
> (snip)
>
>
> The JCL is longer than the dirt-simple program he's trying to avoid. Oh
> well....

But on the other hand, installing a COBOL program into production
would require installing JCL for the new jobstep.

If it were me, I would do the COBOL program, because it might be
easier to document the new record layout, perhaps give it its own
copybook. But that's not necessarily the best use of the programmer's
time. I just like writing easy COBOL programs.

Any IBM mainframe compatible SORT (DFSORT, Syncsort, etc) can do the
job. The only question is, how much trouble is it to install
additional JCL into production for the new SORT step?

Some shops may require more testing for a COBOL program that for a new
SORT JCL step.

--
http://arnold.trembley.home.att.net/

Robert Wagner

2004-07-14, 8:55 pm

docdwarf@panix.com wrote:

>In article <40f55f44.246080484@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:

>
>From the original posting:
>
>--begin quoted text:
>
>Writing a COBOL program to do this is none-too-difficult... but adding
>another program to the jobstream (with associated move-to-Prod overhead)
>is something I'd rather avoid.
>
>--end quoted text
>
>One-time situations, in my experience, rarely are moved to Production, Mr
>Wagner; I thought that my mention of avoiding 'associated move-to-Prod
>overhead' indicated that this would be an ongoing circumstance.

Some shops require any program/script that processes production data to be run
in Production, even if one-time.

>The 'tools outlined', Mr Wagner, were 'an IBM mainframe, MVS (or whatever
>it is called nowadays)

zOS.

>and standard utilities (e.g., SUPERC); utilities
>available are DFSORT and MAXBAT (no FileAid)'... and COBOL. No DB2 here,
>

ly.

I LOVE SuperC. It can run in batch (PGM=ISRSUPC) as well as ISPF. Second
attempt:

1. Convince SuperC to create the output file you want.

2. Forget temporary/intermediate files. Change the program the reads the data to
join the two files. Is a change easier to promote than a new program?

docdwarf@panix.com

2004-07-14, 8:55 pm

In article <40f5b950.269136318@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>
>Some shops require any program/script that processes production data to be run
>in Production, even if one-time.

I'll try to keep that in mind, Mr Wagner, when someone suggests I download
the data to a PC for slicing-and-dicing.

>
>
>zOS.

Thanks much.

>
>
>I LOVE SuperC. It can run in batch (PGM=ISRSUPC) as well as ISPF. Second
>attempt:
>
>1. Convince SuperC to create the output file you want.

I've tried flattery, wheedling and cajoleries, Mr Wagner, but SuperC does
not seem to respond well to any of those... oh, and it doesn't seem to
respond in the desired manner to any control statements I've been able to
code for it, either.

>
>2. Forget temporary/intermediate files. Change the program the reads the data to
>join the two files. Is a change easier to promote than a new program?

The program needs the data to be available in a VSAM KSDS for random reads
against SSN... and no, input data cannot be sorted in SSN order.

Thanks much!

DD

docdwarf@panix.com

2004-07-14, 8:55 pm

In article <40F58E3D.70309@us.ibm.com>,
Frank Yaeger <yaeger@us.ibm.com> wrote:
>docdwarf@panix.com wrote:

[snip]

>
>DD,
>
>You said you have DFSORT, so here's a DFSORT/ICETOOL job that will do
>what you want using the SPLICE operator. For complete information on
>SPLICE, see:
>
>http://www.storage.ibm.com/software...tmutol.html#spl
>
>//S1 EXEC PGM=ICETOOL
>//TOOLMSG DD SYSOUT=*
>//DFSMSG DD SYSOUT=*
>//IN1 DD DSN=... FB/240 input file
>//IN2 DD DSN=... FB/480 input file
>//T1 DD DSN=&& T1,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,P
ASS)
>//T2 DD DSN=&& T2,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,P
ASS)
>//CON DD DSN=*.T1,VOL=REF=*.T1,DISP=(OLD,PASS)
>// DD DSN=*.T2,VOL=REF=*.T2,DISP=(OLD,PASS)
>//OUT DD DSN=... FB/241 output file
>//TOOLIN DD *
>* IN1->T1: copy records and add blank in position 241
> COPY FROM(IN1) TO(T1) USING(CTL1)
>* IN2->T2: copy key and add byte from 349 in position 241
> COPY FROM(IN2) TO(T2) USING(CTL2)
>* T1/T2->OUT: Splice on key to add byte from 349 at
>* position 241
> SPLICE FROM(CON) TO(OUT) ON(2,9,CH) WITH(241,1)
>/*
>//CTL1CNTL DD *
> OUTREC FIELDS=(1,240,241:X)
>/*
>//CTL2CNTL DD *
> OUTREC FIELDS=(2:2,9,241:349,1)
>/*
>

Reproduced in its entirety, Mr Yaeger, because... well, because it
deserves to be. An exquisite and elegant solution for which I am both
thankful and grateful.

DD

William M. Klein

2004-07-14, 8:55 pm

"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40f5b950.269136318@news.optonline.net...
> docdwarf@panix.com wrote:
>
<snip>
>
> zOS.
>

Correction:

z/OS

As this is an IBM trademark, the punctuation is probably important. See (for
example),

http://publibz.boulder.ibm.com/cgi-...y3pg20/BACK_1.1

--
Bill Klein
wmklein <at> ix.netcom.com

docdwarf@panix.com

2004-07-15, 3:56 am

In article <BuudnUBfVKgVAWjd4p2dnA@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>Frank Yaeger wrote:

[snip]

[snip]
[color=darkred]
>The JCL is longer than the dirt-simple program he's trying to avoid.

Not when one reduces the JCL to the actual 'control' statements, much as I
reduced the COBOL down to the guts of the PROCEDURE DIVISION... but even
if it were the JCL would be part of a larger stream which has to be
submitted to Prod so there'd be no overall change, as opposed to making
another program and having to go through the documentation necessary to
include and maintain it.

DD

docdwarf@panix.com

2004-07-15, 3:56 am

In article <ElhJc.94745$OB3.12990@bgtnsc05-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
>
>JerryMouse wrote:
>
>But on the other hand, installing a COBOL program into production
>would require installing JCL for the new jobstep.

Well... in this situation what I've had to do is take an existing program
that's the 'guts' of a system that's about to be replaced... and at the
Last Possible Moment in the code, after everything's been edited,
compared, looked-up and updated...

.... and add a whole other skinkty-zillion lines of code to take the
perfectly-formatted and balanced result of the Old System... and reformat
it for the New System, in essence maintaining all the functionality of the
Old while making way for the New.

There is, of course, a Very Good Reason for all this... 'The users are
accustomed to the reports which come out of the old system and we'd like
to keep those running.'

(My opinion is... all the Old System jockies are hoping to High Heaven
that the New System blows up big-time; were that to happen there'd be
more-or-less current updates to all the old files so a swap-over would be
easier.)

Anyhow... so what I have is some thirty-odd steps of JCL in which one
program name has been changed (//STEP020 EXEC PGM=OLDCRAP has become
//STEP020 EXEC PGM=NEWCRAP) and in its step a few files have been added
(like the lookup one I'm trying to make which initiated this thread).

>
>If it were me, I would do the COBOL program, because it might be
>easier to document the new record layout, perhaps give it its own
>copybook. But that's not necessarily the best use of the programmer's
>time. I just like writing easy COBOL programs.

Hmmmmm... I wonder, Mr Trembley. Do you mean to say that if you have a
program that writes a report to a dataset you'd write an easy COBOL to
read-n-print instead of using IEBGENER? How about... a jobstream that
needs a new sort step; would you write a COBOL program with an internal
sort or a JCL step or would you just cobble together an external sort?

I was taught, e'er-so-long ago, to avoid program proliferation and that
whenever it Made Sense one should use a system utility instead of writing
a program. (What 'Makes Sense' can be decided, of course, about as
readily as what constitutes 'A Logical Unit of Work')

>
>Any IBM mainframe compatible SORT (DFSORT, Syncsort, etc) can do the
>job.

I wasn't quite sure that it could, Mr Trembley, hence my asking here...
and I learned from Mr Yaeger the arcana necessary to pull it off. It is
one thing to wave one's hands and say 'Oh, no prob, a SORT of some kind
will do it'... and a similar thing to say 'Hey, I'm sure it's in the
manual somewhere'... and a different thing, entire, to have the man who
leads the folks who write the manuals say 'Here it is.'

>The only question is, how much trouble is it to install
>additional JCL into production for the new SORT step?

Ahhhhh, there's the beauty of it... what's another sort-step? Nothing at
all, a mere bagatelle... at least that's the feeling on my present site.

>
>Some shops may require more testing for a COBOL program that for a new
>SORT JCL step.

Exactly, Mr Trembley... programs, no matter how simple, are Deep,
Mysterious, Complex things to be approached with Awe, Respect and Version
Control. In JCL... hey, what's another sort-step?

DD

LX-i

2004-07-15, 3:56 am

William M. Klein wrote:
> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> news:40f5b950.269136318@news.optonline.net...
>
>
> <snip>
>
>
>
> Correction:
>
> z/OS
>
> As this is an IBM trademark, [snip]

Maybe he wasn't wanting to infringe on the trademark... ;)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

JerryMouse

2004-07-15, 3:55 pm

Arnold Trembley wrote:
> JerryMouse wrote:
>
> But on the other hand, installing a COBOL program into production
> would require installing JCL for the new jobstep.

Nah, he could add ten lines to an existing program.

docdwarf@panix.com

2004-07-15, 3:55 pm

In article <GcGdna7lLq4iMGvd4p2dnA@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>Arnold Trembley wrote:
>
>Nah, he could add ten lines to an existing program.

.... and suffer the move-to-Prod overhead associated with moving a program
into Prod that I was hoping to avoid... and have to modify the JCL for
that existing program's step to address the files in question, as well.

DD

Colin Campbell

2004-07-15, 8:55 pm

docdwarf@panix.com

2004-07-16, 3:55 am

In article <Vs-dnT_cl_9MmGrdRVn-uw@adelphia.com>,
Colin Campbell <cmcampb_at_adelphia.net> wrote:
>docdwarf@panix.com wrote:
>
>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

JerryMouse

2004-07-16, 3:55 am

docdwarf@panix.com wrote:
>
> ... and suffer the move-to-Prod overhead associated with moving a
> program into Prod that I was hoping to avoid... and have to modify
> the JCL for that existing program's step to address the files in
> question, as well.

1. Shhh! Don't tell.
2. If you have to tell, that's okay if you're paid by the hour.

Colin Campbell

2004-07-16, 3:55 am

docdwarf@panix.com wrote:

>In article <Vs-dnT_cl_9MmGrdRVn-uw@adelphia.com>,
>Colin Campbell <cmcampb_at_adelphia.net> wrote:
>
>
>
>'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 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]
>
>
>
>
>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.
>
>
>
>
>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?

docdwarf@panix.com

2004-07-16, 8:55 am

In article <4pmdnWdgKqKdo2rd4p2dnA@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>docdwarf@panix.com wrote:
>
>1. Shhh! Don't tell.

If I don't tell someone that a program has been modified then it usually
doesn't get moved to Prod; moving to Prod, in this case, is the goal of
the entire exercise.

>2. If you have to tell, that's okay if you're paid by the hour.

I tend to do better work when I say 'I'm having Fun!' than not... and
suffering the move-to-prod overhead associated with moving a program into
Prod does not make me say 'I'm having Fun!'; avoiding this is merely a way
of avoiding giving my client the best bang for their buck for my time.

(sounds almost Noble, don't it?)

DD

docdwarf@panix.com

2004-07-16, 3:55 pm

In article <gaqdndmX6eGQxmrd4p2dnA@adelphia.com>,
Colin Campbell <cmcampb_at_adelphia.net> wrote:
>docdwarf@panix.com wrote:
>
>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.

With all due respect, Mr Campbell, I answered that question with words
from the original posting. If one is labelled as having 'just about
everything that I need' and the other is labelled as having 'all that I
need is one byte' then a guess might be that one has just about everything
I need and the other has one byte that I need.

>
>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.

Quite right... and utilities have a tendency to pass data more quickly and
cheaply than programs, as well. In my experience an external sort using

OPTIONS=COPY
INCLUDE COND=(382,2,CH,EQ,C'AZ')

.... will create an output file faster and less expensively than a COBOL
program which uses

READ INFILE.
IF IN-STATE-CODE = 'AZ'
WRITE OUTREC FROM INREC.

.... which, under readily-conceived conditions, might be the same thing.

>
>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.

Ahhhhh, the Eternal Balances... maintainability versus functionality (one
large program versus many smaller ones), maintainability versus efficiency
(MOVE CORR is efficient but a maintenance nightmare, GO TO DEPENDING ON is
blindingly fast but but also a maintenance nightmare), human time versus
machine time... and lo, to dwell upon such matters at Great Length is,
indeed, praiseworthy.

>
>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).

If reading the 480-byte record alone were enough to accomplish the entire
process then using the 240-byte file would be unnecessary... but, as per
the original description, the 240-byte contains 'everything I need but'
and the 480 contains an 'all that I need is'. To ask if the 480-byte
record contains ' everything I need but (and) all that I need is' reminded
me of that Ancient Joke:

'When does the train to Pittsburgh leave?'

'Every w

day at 11:am.'

'Tuesdays, too?'

.... and such things, while instructive as jokes, tend to weary me in
technical discussions... call it a flaw in my personality.

>
>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.

It appears that you are making an assumption in the absence of data here.
Later in this thread I stated that after I've created the 241-byte file I
will run it through an IDCAMS to create a VSAM KSDS for random reads
against SSN; my program will not have to read the 241-byte flat-file.

>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?

See above about Eternal Balances... when circumstances allow one might be
able to combine two steps into one but from a human-time standpoint and a
future-maintainability standpoint this might not always be desireable.

Thanks much!

DD

Clark F. Morris, Jr.

2004-07-26, 8:55 pm

docdwarf@panix.com wrote:

> In article <gaqdndmX6eGQxmrd4p2dnA@adelphia.com>,
> Colin Campbell <cmcampb_at_adelphia.net> wrote:
>
>
>
> With all due respect, Mr Campbell, I answered that question with words
> from the original posting. If one is labelled as having 'just about
> everything that I need' and the other is labelled as having 'all that I
> need is one byte' then a guess might be that one has just about everything
> I need and the other has one byte that I need.
>
>
>
>
> Quite right... and utilities have a tendency to pass data more quickly and
> cheaply than programs, as well. In my experience an external sort using
>
> OPTIONS=COPY
> INCLUDE COND=(382,2,CH,EQ,C'AZ')
>
> ... will create an output file faster and less expensively than a COBOL
> program which uses
>
> READ INFILE.
> IF IN-STATE-CODE = 'AZ'
> WRITE OUTREC FROM INREC.
>
> ... which, under readily-conceived conditions, might be the same thing.
>
>
>
>
> Ahhhhh, the Eternal Balances... maintainability versus functionality (one
> large program versus many smaller ones), maintainability versus efficiency
> (MOVE CORR is efficient but a maintenance nightmare, GO TO DEPENDING ON is
> blindingly fast but but also a maintenance nightmare), human time versus
> machine time... and lo, to dwell upon such matters at Great Length is,
> indeed, praiseworthy.
>
>
>
>
> If reading the 480-byte record alone were enough to accomplish the entire
> process then using the 240-byte file would be unnecessary... but, as per
> the original description, the 240-byte contains 'everything I need but'
> and the 480 contains an 'all that I need is'. To ask if the 480-byte
> record contains ' everything I need but (and) all that I need is' reminded
> me of that Ancient Joke:
>
> 'When does the train to Pittsburgh leave?'
>
> 'Every w

day at 11:am.'
>
> 'Tuesdays, too?'
>
> ... and such things, while instructive as jokes, tend to weary me in
> technical discussions... call it a flaw in my personality.
>
>
>
>
> It appears that you are making an assumption in the absence of data here.
> Later in this thread I stated that after I've created the 241-byte file I
> will run it through an IDCAMS to create a VSAM KSDS for random reads
> against SSN; my program will not have to read the 241-byte flat-file.
>
>
>
>
> See above about Eternal Balances... when circumstances allow one might be
> able to combine two steps into one but from a human-time standpoint and a
> future-maintainability standpoint this might not always be desireable.
>
> Thanks much!
>
> DD
>
Eliminate the IDCAMS copy step and use the sort to load the VSAM KSDS.
If necessary put the Delete/Define in a step that precedes the SORT.

docdwarf@panix.com

2004-07-27, 8:55 am

In article <ce3p24$gh7$1@news.eusc.inter.net>,
Clark F. Morris, Jr. <cfmtech@istar.ca> wrote:
>docdwarf@panix.com wrote:
>

[snip]
[color=darkred]
>Eliminate the IDCAMS copy step and use the sort to load the VSAM KSDS.
>If necessary put the Delete/Define in a step that precedes the SORT.

You know... I read this and thought 'Interesting idea... but IDCAMS is
more efficient at loading the KSDS than the SORT'... and then, immediately
following, came 'Really? How do I know this?'

I then began to construct arguments based on the nature and design of the
respective programs, that SORT, at heart, was built to address flat files
while IDCAMS was created for the various indexed ones...

.... and then I arrived at 'Hmmmm... too many assumptions, must have more
data!' so I built a couple of jobstreams which...

.... ultimately served to confirm my original prejudices and designs. The
first job was my original design, three steps of (Mr Yager's) SORT, a
DELETE/DEFINE and a Repro; given two input files of 64,159 records and an
output KSDS of 64,158 (header records dropped) the JESLOG showed:

I/O COUNT CPU TIME(SECONDS) ESTIMATED COST
316 1.45 $2.62
28 .07 $.13
1240 .73 $1.33

JOB I/O COUNT= 1584 JOB CPU TIME= 2.25 EST. COST= $4.08

.... and a second job, the first step being a DELETE/DEFINE, the second
being (Mr Yaeger's) SORT but OUT DD going to the KSDS defined in the first
step showed:

I/O COUNT CPU TIME(SECONDS) ESTIMATED COST
30 .07 $.13
1906 2.20 $4.00

JOB I/O COUNT= 1936 JOB CPU TIME= 2.27 EST. COST= $4.13

.... showing clearly and unambiguously that Less is, in fact, More.

DD

Sponsored Links