Re: IDCAMS Error Counts?

DD,

If your aim is to keep one record with the highest 115,8 key
for each 5,9 key, you might consider using a DFSORT/ICETOOL job like
this:


//S1    EXEC  PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN DD DSN=...  input file
//OUT DD DSN=...  output file
//TOOLIN DD *
SELECT FROM(IN) TO(OUT) ON(5,9,CH) FIRST USING(CTL1)
/*
//CTL1CNTL DD *
SORT FIELDS=(5,9,CH,A,115,8,CH,D)
/*

As an example, if your two keys in the IN records were:

AAAAAAAAA ... 00000001
BBBBBBBBB ... 00000001
AAAAAAAAA ... 00000003
CCCCCCCCC ... 00000001
BBBBBBBBB ... 00000002
AAAAAAAAA ... 00000004
AAAAAAAAA ... 00000002

The DFSORT/ICETOOL job would give you OUT records with the
following keys:

AAAAAAAAA ... 00000004
BBBBBBBBB ... 00000002
CCCCCCCCC ... 00000001

If I misunderstood what you wanted, then please explain further.

Frank Yaeger - DFSORT Team  (IBM) - yaeger@us.ibm.com
Specialties: ICETOOL, IFTHEN, OVERLAY, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/

In article <1126636547.091965.178430@z14g2000cwz.googlegroups.com>,
<yaeger@us.ibm.com> wrote:
>DD,
>
>If your aim is to keep one record with the highest 115,8 key
>for each 5,9 key, you might consider using a DFSORT/ICETOOL job like
>this:

I'd considered that, Mr Yaeger, and the solution I'd generated was not
nearly so elegant...

... but I'm not sure.  The job is in Production and my assumption is that
there would be less resistance to changing two control members (for the
current SORT and the IDCAMS) than there would be to introducing an ICETOOL
step, especially since folks on this site are not all that familiar with
manipulating ICETOOL.

On the other hand... what do I have to lose, worse comes to worst they'll
call me one who urinates.  Thanks much!

DD

<docdwarf@panix.com> wrote in message news:dg7k5q$1h$1@reader1.panix.com...
> In article <1126636547.091965.178430@z14g2000cwz.googlegroups.com>,
> <yaeger@us.ibm.com> wrote: 
>
> I'd considered that, Mr Yaeger, and the solution I'd generated was not
> nearly so elegant...
>
> ... but I'm not sure.  The job is in Production and my assumption is that
> there would be less resistance to changing two control members (for the
> current SORT and the IDCAMS) than there would be to introducing an ICETOOL
> step, especially since folks on this site are not all that familiar with
> manipulating ICETOOL.
>
> On the other hand... what do I have to lose, worse comes to worst they'll
> call me one who urinates.  Thanks much!
>
> DD

Resistance to changing two control members....sounds like that you must be
inside another sick shop!

JCE

In article <prJVe.70612$xl6.26911@tornado.tampabay.rr.com>,
jce <defaultuser@hotmail.com> wrote:
><docdwarf@panix.com> wrote in message news:dg7k5q$1h$1@reader1.panix.com...
 

[snip]
 

[snip]

>Resistance to changing two control members....sounds like that you must be
>inside another sick shop!

Matters of pathology aside... the physics I studied taught me that unless
the motion occurs in a zero-gravity perfect vacuum there will be friction.

DD

On Tue, 13 Sep 2005 22:34:34 +0000 (UTC), docdwarf@panix.com () wrote:

>... but I'm not sure.  The job is in Production and my assumption is that
>there would be less resistance to changing two control members (for the
>current SORT and the IDCAMS) than there would be to introducing an ICETOOL
>step, especially since folks on this site are not all that familiar with
>manipulating ICETOOL.

We don't have any ICETOOL either, but I needed to change a job to get
rid of everything except the last duplicate, so I was persuaded to
change the sort to the following:
//LLIA#3     EXEC  PGM=ICETOOL  **** SORT & ELIMINATE DUPLICATES
//TOOLMSG    DD SYSOUT=*
//DFSMSG     DD SYSOUT=*
//IN         DD DSN=&SYSTEM..LLIA.WORK.&CAMPUS,
//             DISP=(OLD,DELETE,KEEP)
//TOOLIN     DD DSN=UMS.PROD.DATA(LLIA3),DISP=SHR
//***    SORT ON 1-10 & 22 TO GET "DUP" RECORDS TOGETHER
//***     WITH INACTIVATE RECORDS BEFORE ACTIVATE RECORDS
//***     ELIMINATING DUPLICATES
//CTL1CNTL   DD DSN=UMS.PROD.DATA(LLIA3A),DISP=SHR
//***    SECOND SORT IS THE WAY LLIA WAS BEFORE.
//SYSOUT     DD SYSOUT=*
//OUT        DD DSN=&SYSTEM..SIS.STOP.TRANS.&CAMPUS,
//             DISP=(NEW,CATLG,DELETE),
//             UNIT=TAPE,
//             RECFM=FB,
//             LRECL=80,
//             BLKSIZE=8000

LLIA3 now contains:
SELECT FROM(IN) TO(OUT) ON(1,10,CH) ON(22,1,CH) LAST    -
USING(CTL1)

while LLIA3A has the old sort:
SORT FIELDS=(1,10,CH,A,22,1,CH,A,21,1,CH,A)

It seems clear enough that those who are unfamiliar with ICETOOL will
be able to maintain it.

In article <25bgi1heevsb73tn17ka3gdgnuduqv1mk2@4ax.com>,
Howard Brazee  <howard@brazee.net> wrote:
>On Tue, 13 Sep 2005 22:34:34 +0000 (UTC), docdwarf@panix.com () wrote:
> 

[snip]

>LLIA3 now contains:
>  SELECT FROM(IN) TO(OUT) ON(1,10,CH) ON(22,1,CH) LAST    -
>    USING(CTL1)
>
>while LLIA3A has the old sort:
>   SORT FIELDS=(1,10,CH,A,22,1,CH,A,21,1,CH,A)
>
>It seems clear enough that those who are unfamiliar with ICETOOL will
>be able to maintain it.

One can only hope... I've taken to providing profuse documentation (even
for simpler steps) not only in the job, eg:

// ****************************************
********************
//*** STEP010 - SORT
//***           SORT ON SSN (START POS 2, LEN 9)
//***           EXTRACT TYPE 3 (DTL) RECS FROM 240-BYTE FILE
// ****************************************
********************

... but also in the SYSIN members as well, using '*' in column 1 for
comments.  The SYSIN for this step is:

*
* BEGIN: SORT (EXTRACT & SORT)
*
*
* SORT ON SSN (STARTPOS 2, LEN 9)
* INCLUDE ONLY DETAIL RECS ('3' IN POS 1)
*
SORT FIELDS=(2,9,CH,A)
INCLUDE COND=(1,1,CH,EQ,C'3')
*

Belt and suspenders, as it were... the divantage, of course, is
maintaining comments in multiple places; in the job which caused me to
start this thread this causes a move to Prod not only of the two SYSIN
members but of the entire proc.

(Part of the move to Prod procedures involves running compares of new and
old; the Ops crew likes the fact that the only differences in the job are
lines that are commented... and if by some horrid mischance I accidentally
turn a comma into a space it shows up before it blows up.)

DD

<docdwarf@panix.com> wrote in message news:dg94qq$e7d$1@reader1.panix.com...
> Matters of pathology aside... the physics I studied taught me that unless
> the motion occurs in a zero-gravity perfect vacuum there will be friction.

Only the perfect vacuum part is nescessary, I think. You can have a
frictionless environment with gravity.

- Oliver

In article <EylWe.232492$9A2.45411@edtnps89>,
Oliver Wong <owong@castortech.com> wrote:
><docdwarf@panix.com> wrote in message news:dg94qq$e7d$1@reader1.panix.com..
. 
>
>    Only the perfect vacuum part is nescessary, I think. You can have a
>frictionless environment with gravity.

That might be so nowadays, aye... but the physics I studied might have
been codified before such things.

DD