Quick 'n Dirty Unpacking of COMP-3?

So... there's this file, see, that all-of-a-sudden someone Absolutely Must
Have ftp'd from the mainframe to a Unix box... not too often, only every
w or so.  LRECL=6000 and it contains COMP-3 fields... lots of COMP-3
fields... when I pull up the layout in ISPF editor and f COMP-3 all it
tells me there are 1,067 hits.

(Further research revealed no other type of non-DISPLAY numerics, no COMP
or COMP-n or BINARY or POINTERs)

First thing I do is look for FileAid jobs I have that do something
similar... and then I remember that there's no FileAid on the system.

Next thing I do is check the almost-FileAid they have, something called
MAX... it can reformat based on COBOL layouts.  I take a copy of the
file's layout, edit it to c 'COMP-3' '' all, put it into a program
skeleton and compile it to determine the new LRECL (9116), code up a
jobstream to let 'er rip... and it runs...

... and it runs...

... and it runs some more, after three hours of wall-time it blows up on a
B37 (space error)... whoopsie... didn't code SPACE= to be a bit more than
a third larger.  (The output I got - gotta love ,CATLG,CATLG - looked
pretty good for what got through.)  While it is running I figure, just for
laffs, to code some COBOL using the two layouts I already have...
something really complex, like:

OPEN INPUT INFILE OUTPUT OUTFILE.
PERFORM UNTIL NO-MORE-INPUT
READ INFILE INTO WK-INREC
AT END SET NO-MORE-INPUT TO TRUE
NOT AT END
ADD 1 TO INREC-CTR
MOVE CORR WK-INREC TO WK-OUTREC
WRITE OUTREC FROM WK-OUTREC
ADD 1 TO OUTREC-CTR
END-READ
END-PERFORM.
DISPLAY 'INRECS  READ ', INREC-CTR.
DISPLAY 'OUTRECS WRIT ', OUTREC-CTR.
CLOSE INFILE OUTFILE.
GOBACK.

(Notice the blithe use of MOVE CORR... kids, don't try this at home!)

... and I cobb together a jobstream, and wing it off...

... and Baby's not Happy, she blows up on record 1 with a S0C7
(non-numeric data exception)... so there's at least one record with
garbage data in it...

... and where there's one there's often a chance for more.

So... while the MAX job is running again, with a larger SPACE= for the
outfile I figured I'd ask if there is, once again, a Really Obvious
Solution that I'm missing... in this case one that would obviate the need
for me to code over a thousand IF FLD1 NOT NUMERIC MOVE +0 TO FLD1 (and
similar) statements.

Thanks for your time.

DD

Doc,
I know that I shouldn't speak without researching FIRST, but a MOVE CORR
getting a S0C7 seems "odd" to me.  I didn't think that simply MOVING a COMP-
3
field to a numeric display would get a S0C7 with bad data.  It may be "silly
"
but did you initialize
INREC-CTR

before you did
ADD 1 TO INREC-CTR

P.S.  Do make your Unix stuff work "better" did you also add SIGN is SEPARAT
E
for your numeric output fields?

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:c7ft8s$sis$1@panix5.panix.com...
>
> So... there's this file, see, that all-of-a-sudden someone Absolutely Must
> Have ftp'd from the mainframe to a Unix box... not too often, only every
> w or so.  LRECL=6000 and it contains COMP-3 fields... lots of COMP-3
> fields... when I pull up the layout in ISPF editor and f COMP-3 all it
> tells me there are 1,067 hits.
>
> (Further research revealed no other type of non-DISPLAY numerics, no COMP
> or COMP-n or BINARY or POINTERs)
>
> First thing I do is look for FileAid jobs I have that do something
> similar... and then I remember that there's no FileAid on the system.
>
> Next thing I do is check the almost-FileAid they have, something called
> MAX... it can reformat based on COBOL layouts.  I take a copy of the
> file's layout, edit it to c 'COMP-3' '' all, put it into a program
> skeleton and compile it to determine the new LRECL (9116), code up a
> jobstream to let 'er rip... and it runs...
>
> ... and it runs...
>
> ... and it runs some more, after three hours of wall-time it blows up on a
> B37 (space error)... whoopsie... didn't code SPACE= to be a bit more than
> a third larger.  (The output I got - gotta love ,CATLG,CATLG - looked
> pretty good for what got through.)  While it is running I figure, just for
> laffs, to code some COBOL using the two layouts I already have...
> something really complex, like:
>
> OPEN INPUT INFILE OUTPUT OUTFILE.
> PERFORM UNTIL NO-MORE-INPUT
>     READ INFILE INTO WK-INREC
>         AT END SET NO-MORE-INPUT TO TRUE
>         NOT AT END
>             ADD 1 TO INREC-CTR
>             MOVE CORR WK-INREC TO WK-OUTREC
>             WRITE OUTREC FROM WK-OUTREC
>             ADD 1 TO OUTREC-CTR
>     END-READ
> END-PERFORM.
> DISPLAY 'INRECS  READ ', INREC-CTR.
> DISPLAY 'OUTRECS WRIT ', OUTREC-CTR.
> CLOSE INFILE OUTFILE.
> GOBACK.
>
> (Notice the blithe use of MOVE CORR... kids, don't try this at home!)
>
> ... and I cobb together a jobstream, and wing it off...
>
> ... and Baby's not Happy, she blows up on record 1 with a S0C7
> (non-numeric data exception)... so there's at least one record with
> garbage data in it...
>
> ... and where there's one there's often a chance for more.
>
> So... while the MAX job is running again, with a larger SPACE= for the
> outfile I figured I'd ask if there is, once again, a Really Obvious
> Solution that I'm missing... in this case one that would obviate the need
> for me to code over a thousand IF FLD1 NOT NUMERIC MOVE +0 TO FLD1 (and
> similar) statements.
>
> Thanks for your time.
>
> DD
>

In article <fgMmc.11113$V97.2698@newsread1.news.pas.earthlink.net>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>Doc,
>  I know that I shouldn't speak without researching FIRST, but a MOVE CORR
>getting a S0C7 seems "odd" to me.  I didn't think that simply MOVING a COMP
-3
>field to a numeric display would get a S0C7 with bad data.  It may be "sill
y"
>but did you initialize
>    INREC-CTR
>
>before you did
> ADD 1 TO INREC-CTR

Hmmmmm... you mean coding something like:

01  INREC-CTR PIC 9(8) VALUE 0.
01  OUTREC-CTR PIC 9(8) VALUE 0.

... in WORKING-STORAGE?  Already done, aye... but for more laffs I
recompiled with a LIST and submitted another run...

CEE3207S The system detected a data exception (System Completion
Code=0C7).

Program Unit: SKELPRG2 Entry: SKELPRG2 Statement: 3077 Offset: +000005FA

Let's see...

003077      2  307900                 MOVE CORR WK-INREC TO WK-OUTREC

... looks familiar... and the dump shows:

3067 01 INREC-CTR        9(8) DISP        00000001
3068 01 OUTREC-CTR       9(8) DISP        00000000

... and upon entering the Temple of Truth provided by the PMAP... errrr,
LIST... 5FA shows:

0005FA  F822 D0F8 5F5E          ZAP   248(3,13),3934(3,5)     TS2=0
ANN-UNIF-ALLOW*

(line wrapped)

... hmmmmm... and when I put INITIALIZE WK-OUTREC and INITIALIZE WK-INREC
right before the PERFORM, recompile and resubmit... I get another S0C7,
still in the MOVE CORR but at displacement 3B5A... INREC-CTR still 1,
OUTREC-CTR still 0...pull up the listing, check for three baker five able
and find...

003B5A  F822 D108 4F5E          ZAP   264(3,13),3934(3,4)     TS2=0
ANN-UNIF-ALLOW*

... smells mighty familiar.

>
>P.S.  Do make your Unix stuff work "better" did you also add SIGN is SEPARA
TE
>for your numeric output fields?

I'll wait until I get some output before I present the Great Magic to
other folks and ask if they want leading or trailing signs...

... and that way they can stratch their heads, intone 'That's a goooood
question' and have a bunch o' meetings.

Greatly appreciate your time, Mr Klein.

DD

Bill Klein writes ...

>Doc,
>  I know that I shouldn't speak without researching FIRST, but a MOVE CORR
>getting a S0C7 seems "odd" to me.  I didn't think that simply MOVING a COMP
-3
>field to a numeric display would get a S0C7 with bad data.

It may depend on the compiler NUMPROC option. If the MOVE CORR generates UNP
Ks,
it will not S0C7, but if it generates EDs, ED instructions can S0C7 if bad d
ata
is found.

Kind regards,



-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA

In article <20040507102627.23382.00000989@mb-m14.aol.com>,
S Comstock <scomstock@aol.com> wrote:
>Bill Klein writes ...
> 
>
>It may depend on the compiler NUMPROC option. If the MOVE CORR generates UN
PKs,
>it will not S0C7, but if it generates EDs, ED instructions can S0C7 if bad 
data
>is found.

The standard compile JCL here sets NUMPROC(MIG)... as noted in my response
to Mr Klein the MOVE CORRis blowing up on a ZAP; browsing the LISTing
shows UNPKs, as well, and no EDs.

DD

docdwarf@panix.com wrote:
> In article <20040507102627.23382.00000989@mb-m14.aol.com>,
> S Comstock <scomstock@aol.com> wrote:
> 
>
>
> The standard compile JCL here sets NUMPROC(MIG)... as noted in my response
> to Mr Klein the MOVE CORRis blowing up on a ZAP; browsing the LISTing
> shows UNPKs, as well, and no EDs.
>
> DD
SIGN IS SEPARATE is almost guaranteed to generate either ZAP (zero add
packed) or CP (compare packed) for each field.  There may be another
option that also affects sign processing in addition to NUMPROC.  You
could try playing with the NUMPROC option but I think that COBOL
believes in forcing the sign nibble.  The more interesting question is
what is the data really like and do you have all of the record
descriptions related to this file.  This looks like an interesting
exercise because other things should be blowing up with the quality of
data so far.  Note the first and last records may be unique.

In article <c7gcfr$sm0$1@news.eusc.inter.net>,
Clark F. Morris, Jr. <cfmtech@istar.ca> wrote:
>docdwarf@panix.com wrote: 
>SIGN IS SEPARATE is almost guaranteed to generate either ZAP (zero add
>packed) or CP (compare packed) for each field.  There may be another
>option that also affects sign processing in addition to NUMPROC.  You
>could try playing with the NUMPROC option but I think that COBOL
>believes in forcing the sign nibble.

I believe that no matter what I do I'm going to get UNPKs and ZAPS
generated with COMP-3 fields... but my beliefs have been trampled in the
past.

>The more interesting question is
>what is the data really like and do you have all of the record
>descriptions related to this file.

The data are really full of trash and I have the only record description
related to the file... ain't Life grand?

>This looks like an interesting
>exercise because other things should be blowing up with the quality of
>data so far.  Note the first and last records may be unique.

Thanks much for your time.

DD

Doc,
I would be curious if compiling with NUMPROC(PFD) produced any ZAP's in the
LIST output.  Although I wouldn't recommend that option to my "worst enemy" 
for
most applications, it MIGHT do what you want for this one.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:c7gkd2$81l$1@panix5.panix.com...
> In article <c7gcfr$sm0$1@news.eusc.inter.net>,
> Clark F. Morris, Jr. <cfmtech@istar.ca> wrote: 
COMP-3 
UNPKs, 
data 
>
> I believe that no matter what I do I'm going to get UNPKs and ZAPS
> generated with COMP-3 fields... but my beliefs have been trampled in the
> past.
> 
>
> The data are really full of trash and I have the only record description
> related to the file... ain't Life grand?
> 
>
> Thanks much for your time.
>
> DD
>

In article <uLQmc.11441$V97.8410@newsread1.news.pas.earthlink.net>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>Doc,
>  I would be curious if compiling with NUMPROC(PFD) produced any ZAP's in t
he
>LIST output.  Although I wouldn't recommend that option to my "worst enemy"
 for
>most applications, it MIGHT do what you want for this one.

Well, another belief half-trampeled... the LISTing shows UNPKs by the
score but nary a ZAP.  The job runs to completion and shows final DISPLAYs
of:

INRECS  READ 00068353
OUTRECS WRIT 00068353

... and (including a SORT to copy a VSAM to a &&TEMP for flatfile
processing) runs in 2min 24sec wall-time, with a total CPU time of 8.52.

The other job - the MAXBAT - was timed out after about 4.5 hrs on the wall
and burning 9999.21 in CPU...  someone's gonna be really happy about that.

Greatly appreciate the intelligence, Mr Klein... come Monday and I'll
diddle a bit with SIGN SEPARATE clauses.

DD

docdwarf@panix.com wrote:

> In article <uLQmc.11441$V97.8410@newsread1.news.pas.earthlink.net>,
> William M. Klein <wmklein@nospam.netcom.com> wrote:
> 
>
>
> Well, another belief half-trampeled... the LISTing shows UNPKs by the
> score but nary a ZAP.  The job runs to completion and shows final DISPLAYs
> of:

For those of you not familiar with the idiosyncrasies of NUMPROC on IBM
mainframes, NUMPROC(PFD) which I THINK corresponds to the COBOL standard
assumes C or D for the sign nibble on signed field and F in the sign
nibble for unsigned fields.  This is interpreted to mean that a field
with an F zone will be treated as NOT NUMERIC.  If you have the
misfortune to have CSP (Cross System Product?) superseded by Visual Gen
IIRC, you are in trouble because it forces all positive sign nibbles to
F.  There probably are other joys that William is aware of that I have
not had the displeasure of encountering.  Since Doc found that
NUMPROC(PFD) worked, I would be curious as to the code generated by a
direct MOVE CORR from packed to sign is separate and a MOVE CORR packed
to unpacked, then MOVE CORR to SIGN IS SEPARATE.
>
> INRECS  READ 00068353
> OUTRECS WRIT 00068353
>
> ... and (including a SORT to copy a VSAM to a &&TEMP for flatfile
> processing) runs in 2min 24sec wall-time, with a total CPU time of 8.52.
>
> The other job - the MAXBAT - was timed out after about 4.5 hrs on the wall
> and burning 9999.21 in CPU...  someone's gonna be really happy about that.
>
> Greatly appreciate the intelligence, Mr Klein... come Monday and I'll
> diddle a bit with SIGN SEPARATE clauses.
>
> DD