Combining Fields From Files Without COBOL Pgm?

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

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.

Is this one-time or ongoing?

When I encountered similar one-time problems, I moved the files to my PC,
described them with a flat-file schema, and joined them with SQL talking thr
ough
the Microsoft ODBC driver for flat files. It's fast, even on big files .. sa
y
500,000 records.

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

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.[/co
lor]

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

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:

[url]http://www.storage.ibm.com/software/sort/mvs/uq90053/online/srtmutol.html#spl[/url
]

//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)
/*

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

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/


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 r
un
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 dat
a to
join the two files. Is a change easier to promote than a new program?

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 da
ta 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

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:
>
>[url]http://www.storage.ibm.com/software/sort/mvs/uq90053/online/srtmutol.html#spl[/ur
l]
>
>//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

"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 (fo
r
example),

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


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