Possible Suprtool's MOVE is a COMPUTE what looks like a MOVE?

Al Karman
Senior Operations Analyst
Administrative Management Group
847.870.9288
[log in to unmask] <mailto:[log in to unmask]>

        "WARNING:  All e-mail sent to or from this address will be
received by The Administrative Management Group Inc. corporate e-mail
system and is subject to archival, monitoring or review by, and/or
disclosure to, someone other than the recipient."


        -----Original Message-----
        From:   JIM McINTOSH [SMTP:[log in to unmask]]
        Sent:   Wednesday, April 26, 2000 4:20 PM
        To:     [log in to unmask]
        Subject:        Large integers in a double word (ODBC vs
non-ODBC input)

        Gentle Listers:

        Can someone please explain this one?

        We have a IMAGE database with a J2 field.  The COBOL definition
of this
        field is S9(9) COMP.  We have an introduced process that updates
the field
        from an MSACCESS database via an ODBC connection accessing the
IMAGE
        database through IMAGESQL.  Since we omitted limiting the
MSACCESS process
        to only accept values with 9 digits or less, the MSACCESS
database now
        contains values larger than 9 digits and the update from
MSACCESS to IMAGE
        now places these large values into the J2 field with no problem.
When we
        discovered this, we were not surprised.

        However, there exists a process which, subsequent to the ODBC
update just
        described, moves the value from the original J2 field into
another J2 field
        (also defined as S9(9) COMP) in another IMAGE database.  This
process is a
        straight COBOL MOVE statement.  When the value in the original
J2 field is
        larger than 9 digits because of the ODBC update, this COBOL MOVE
does NOT
        fail.  However, when we place the same value in the original J2
field via
        SUPRTOOL, this COBOL MOVE fails with an "Integer overflow"
error.  Why?