I am confused. Is this still the case of where you are referencing data that was NOT passed to the subprogram's Linkage Section? If so, I can *guarantee* that there has NEVER been any "documented" support for Passing a 3-byte field and having the subprogram be able to get binary zeroes, spaces, or anything else in the 4th thru Nth byte.
Actually, there is ONE exception to this rule. If you PASS a data item with an Occurs Depending On it, then the subprogram must be able to access the "maximum" length. But other than that, you MAY only "count on" accessing the data that is actually passed to a subprogram (or VIA the PARM JCL parameter). "Jousma, David" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED] om>... > I guess the rules did change(names removed), from my ETR: > > > David, > OK, found two pmrs claiming behavior changed by the APAR. It's related > > to search/search all comparing the key. In this case we closed a > loophole after enhancing National datatypes and some XML/JAVA related > stuff. > There are two possibilities for the change in behavior. > 1) APAR PQ95214 from June, 2005 changed the > behavior to be consistent with an alphameric > compare. That requires that after the > matching parts of the key and argument are > tested, then the rest of the longer field > must be blanks (not ignored as before). > 2) A second possibility was that the unused part > of the table was not filled or initialized > with a high key, either HIGH-VALUES or all 9's. > If the unused keys are not initialized to a > high value, the residual data can throw off > the binary search. > Rgds, > > xxxxxx, > > ------------------------------------------------------------- > > thanks for the update. Regarding #1, what you are saying seems to be a > change then from > > This is found in 6.1.6.5 of manual Enterprise COBOL for z/OS, Language > Reference, Version 3 Release 3, Document Number SC27-1408-02, Program > Number 5655-G53 > > > Operands of > unequal size If the operands are of unequal size, the comparison is made > as though the shorter operand were extended to the right with enough > spaces to make the operands equal in size. > > If this is the case, why wouldn't there be a HOLD(ACTION), or at least a > HOLD(DOC) on the PTF? Seems like this is the ENT COBOL 3.3 was designed > and documented. > > Dave > ---------------------------------------------------------- > > David, > You're absolutely right. The reason there is no HOLD card there is > because we accidently fixed the loophole. I will publish this to web > to warn other users and update PSP bucket. > thanks, > -------------------------------------------------------- > > > Ok, now we are getting somewhere. > > If the old behavior is documented in the V3.3 reference manual and was > working as documented pre PQ95214, then you didnt fix a loophole, you > changed documented functionality. I don't understand how this can be? > > Dave > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] > Behalf Of Jousma, David > Sent: Tuesday, October 11, 2005 7:38 AM > To: [email protected] > Subject: Re: COBOL/LE runtime changes > > All, I was just reviewing my applied PTF's, and see that PQ95214 went > on. It provides runtime support for ent cob 3.4. ee are at 3.3, but > I'm wondering it it "tightened" some of the rules. I've asked this of > IBM. I may back this PTF off on one of my tech systems to see if it > makes a difference. Again, I've only had a handful of jobs abend to this > point, but I just need to be able to explain this to our management. > ---------------------------------------------------------------------- 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
