On Fri, 14 Feb 2020 12:26:44 -0800, Charles Mills wrote:
>I suspect they would not take an APAR
>
"Toleration is the mother of mediocrity." (source unknown)
>I suspect they would cite compatibility concerns if they changed it.
>
That's because they didn't do it right the first time. And programmers
tolerated it.
>Yeah, yeah, I know, could be controlled by an option. I don't think EDCDSECT
>is IBM's highest priority.
>
Adding options increases testing requirements exponentially.
>Yes, many control blocks are bilingual. So what? (Not trying to be rude; just
>mean ... so what?) PL/X is in any event a better starting point for C than is
>HLASM. Or am I missing your point?
>
Somewhat missing. I was thinking of those control blocks that are
currently delivered with PL/X appended. IIRC, Peter(?) has said that
the HLASM is extracted automatically from the PL/X.
>... DS CL8 is a perfectly fine way of defining a 64-bit integer in HLASM,
>
DS 0D,FL8 is finer. I was dismayed not to find an "FG" type for that.
>... but also a common way of course of defining a DD name or member name
>field.
>
Exactly the hazard I envisioned.
>I personally solved the problem by coding some small distinctive comment token
>-- something like $@$ or something like that -- on every 64-bit integer or
>address so that they were easy to find (and then fix) in the converted struct.
>
>
Portability when every programmer adopts a different convention.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
