On Fri, 16 Dec 2016 06:01:56 -0600, Bill Woodger wrote: > >The RC for the message goes up steps of four, and is already busted. Other RC >values have multiple items. Some are not even inclusive, and probably can't be. > >I think it is unrealistic to expect a separate RC for each possible >combination of something which is invalid. > Not for "each possible combination" but it should specifically identify one particular violation. The the programmer can repair that; re-test and iteratively fix the remaining up to seven problems.
"busted" I've had some facilities give me a 32-bit RC. Surely that's enough. Whereby hangs a sad tale. Rexx takes that 32-bit RC and displays it in decimal. It used to truncate to 8 digits; now it extends to 9 or 10 if needed. (My APAR; thanks). But still decimal whereas the diagnostic manuals are mostly hex. Maybe time for an RFE. Except the more useful behavior would be incompatible. "steps of 4"? Why? Who depends on that nowadays? On Fri, 16 Dec 2016 07:41:59 -0500, Tony Thigpen wrote: > >Does anybody know (historically) why z/OS does not support a true 32K >block? z/VSE has supported it since "way back" in the DOS days. > I've asked this question here, repeatedly. The mostly satisfactory answer was that buffers should page-aligned for performance, and a few bytes of overhead are required. And when the rule was made no DASD supported records so large, and no one could affort the core storage for such buffers anyway. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
