On 30 Aug 2006 00:49:08 -0700, in bit.listserv.ibm-main you wrote: >Hello John, > >One "thing" which happened to our CICS transactions after we increased our >ECSA size were "random" wild branches. > >Not every instance of a transaction would break.....but many did. > >Why? > >Increasing our ECSA size moved the EDSA up the region, so that many >transaction programs etc were being loaded higher up in memory. > >The transaction that broke were accessing storage above "1,000,000,000". > >The transactions, written in COBOL, were making use of the ADDRESSING (I >think I have that correct), but had been compiled with TRUNC(OPT). >The COBOL variable to hold the address was adequate for a hex number, but >were being truncated at the high order because the arithmetic was being >performed in decimal. Addresses greater than 9 digits were being used. > >We re-IPLd with smaller ECSA to allow more of the transactions to >complete....until all affected programs had been recompiled with TRUNC(BIN).
Was the code moving non-decimal numbers into the fields used for addresses. I did quite a bit of experimentation with TRUNC(OPT) versus TRUNC(BIN) and found the following: 1. If you display a field that is USAGE BINARY (or COMP) truncation is according to PICTURE. 2. If one of the fields involved is not USAGE BINARY, truncation is according to picture even if the move is from S9(11) USAGE PACKED-DECIMAL to S9(9) USAGE BINARY. 3. If all fields involved are USAGE BINARY and literals are assumed USAGE BINARY, truncation is at the word boundary rather than by picture. A move from S9(8) BINARY to S9(11) BINARY followed by a DISPLAY of the S9(11) BINARY field showed that. 4. With the release of COBOL for MVS and VM that I was using, USAGE BINARY caused all arithmetic to be done in PACKED-DECIMAL thus involving CVD, do the arithmetic, CVB. This is supposed to have gotten better with subsequent releases. 5. Usage of S9(8) USAGE BINARY versus S9(9) USAGE BINARY avoided double precision arithmetic when using TRUNC(OPT). 6 With new compilers changing all USAGE BINARY and USAGE COMP fields to USAGE COMP-5 should allow use of TRUNC(OPT) safely. In another posting I will note some changes to the COBOL compiler that could be done to improve efficiency and allow more efficient code to be written. > >We were able to expand our ECSA safely about 6 months later. > >Regards >Bruce Hewson > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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
