This is very common. If you know Cobol, you know it handles compares of different variable types automatically. If a number say called N is defined as USAGE DISPLAY with a PIC of say 99, and another number M is defined as USAGE PACKED-DECIMAL with a PIC of say 99, the instruction
IF N EQUAL M will generate a PACK so that a ComparePacked can be used for a numeric compare. IF N EQUAL 2 will generate a PACK so that a ComparePacked can be used for a numeric compare. IF M EQUAL 2 will not generate a PACK. Disiplined use of variables in the Working Storage Section for intermediate or temporary results yields positive results. The biggest performance problem involving PACK is related to using USAGE DISPLAY variables to subscript an array or for reference modification. Only USAGE BINARY should be used for that if performance is an issue. Or subscripting can be efficiently done using indexes and index data items. It comes to mind that this issue let to my first consulting job 30 yrs ago. A worst case scenario let me decrease the cpu time of a typesetting program by over 50% just by changing variable types. silverback pup Peter Vander Woude <[EMAIL PROTECTED]>9/23/2005 1:42 PM wrote I'm doing an analysis of one of our application programs. As part of this, I'm seeing the COBOL code generate a lot of PACK/UNPACK instruction pairs. Does anyone have an idea on the performance impact of all these (potential millions of executions in a single run)? What's the impact of just the PACK instruction? I see lots of comparisons where COBOL has to generate PACK statements before doing the compare. Thanks, Peter I. Vander Woude Sr. Mainframe Engineer ----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you ---------------------------------------------------------------------- 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
