To: tom rusnak who wrote (7150 ) 10/26/1997 9:28:00 PM From: TEDennis Respond to of 13949
tom: re: PACK/operation/UNPACK sequence ... The PACK works fine with either Bigits or "normal" hexadecimal data, so that the "operation" will perform normally. It's the UNPACK into the result field that concerns me. It will be UNPACK'd into a standard Zoned Decimal format, unless they (Bemer's solution) has also intercepted that part of the instruction sequence. If there are two instruction interceptions per arithmetic operation, and those two interceptions have to decide whether it's a 'Bemer' operation or not .. then this particular solution is adding LOTS of execution code to existing programs. Also, I'm a little concerned about the effect of COBOL's technique of using intermediate results areas during complex calculations. There could be several intercepts for any one calculation. If EVERY numerical process is setup to be intercepted prior to the program's execution start (it must do that, otherwise how would it be assured of capturing all date functions?) ... we're talking LOTS of linkage code to and from the routines that determine whether or not it's a date and what to do about it. Also, I think it's 'easy' to determine if the Zoned Decimal data you are operating on conforms to the "Bigit" format. Just check the appropriate zone bits. However, how do you make that same determination in date fields that are defined in binary (COMP4)? There are no zone digits in binary, so there's nothing to check. So, how would you know whether to prepend the 19 or 20? Hmmmm ????? Again, I think this solution will work to some extent with Zoned Decimal data (otherwise known as Display Decimal). Beyond that level, the whole thing gets really fuzzy. TED