X-no-Archive:yes
I am sorry. I guess that I should have read more carefully, or not replied
at the end of the day... When a COBOL program is reading a file with a
code-set defined, the results for non DISPLAY data is undefined, both
according to "COBOL 85 for Programmers" by Don Nelson, chair of the 85
CODASYL COBOL Committee, and according to the HP COBOL II/XL Reference
Manual, Chapter 7 DATA DIVISION, File Description Clauses, Description of
the CODE-SET clause http://docs.hp.com/cgi-bin/doc3k/B3150090013.11820/51:

When the CODE-SET clause is used for a file, all data in that file must be
described as USAGE IS DISPLAY, and any signed numeric data must be described
with the SIGN IS SEPARATE clause.

NOTE  The HP utility FCOPY can be used to translate EBCDIC files containing
records with elements that are other than USAGE DISPLAY. Refer to the FCOPY
Reference Manual for more information.

END-QUOTE.

Which means that your mainframers are wrong. Where there is no feature,
there is no bug. Perhaps IBM provides extensions or a compiler directive to
automagically read non-DISPLAY data in ASCII, to keep people from loathing
them for having chosen EBCDIC to imprison their customers.

Now, I dumped 049484071C into the Windows calculator, scientific view, hex
mode, and converted to decimal. I got 1,229,471,857, which overflows S9(9)
anyway. So there may be another issue. It looks like the original field can
be ten chars. The windows calculator only lets me enter 8 Fs, but converting
to decimal and multiplying by 255, I get a maximum value of
1,095,216,660,225. It looks like you could conceivably need a 9(13) DISPLAY
field as a target. Or, you could just
COMPUTE output = INPUT
    ON SIZE ERROR PERFORM INPUT-SIZE-ERROR-ROUTINE
END-COMPUTE

Greg Stigers
Senior Consultant
http://www.cgiusa.com