TRUNC(BIN) *definitely* has performance implications. If you compile with TRUNC(OPT) have USAGE POINTER fields redefined or have other reasons that you want binary fields with the MAXIMUM available size per the storage, not the PICTURE, then define the fields as COMP-5. This avoids the overhead of TRUNC(BIN) for the entire application and lets specific fields "semi-ignore" the picture.
""Bruce Hewson"" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Hello Clark, > > Someone had decided that TRUNC(OPT) was better(performance reasons!). > Even though the base vendor product recommendation was TRUNC(BIN). > > I am not sure what COBOL compiler was involved, but it definitely was not > the latest. We are still trying to get the developers to use the latest. > > The code did some arithmetic on a ADDRESS OF values....they were stepping > their way through a table. If the table entry was placed above address > 1,000,000,000 (decimal) they got sent all over the place. > > And yes it was the CVD instructions in the assembler map of the COBOL code > that let us work out what was really happening. > > This is an old problem. One that has been "fixed" in our site. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
