It's clear enough; maybe too clear. But, the last sentence isn't correct; the lower half of a binary field is neither signed nor unsigned (although I presume you meant "regarded as unsigned"), it's just a broken-off piece with no meaning at all. Special case of the absolute value being less than what the lower half can hold notwithstanding. I do get that your point is that sign-extension from the lower half is incorrect.
So, you're correct about CVTLSOL as being incorrectly identified as signed. I'd say both CVTLSOH & CVTLSOL are useless anyway, but the "SIGNED" should be removed from both. In CVTLSOH, while technically correct, saying it's signed is specious. Bottom, line, sure is a lot of words for a small problem. sas On Tue, Dec 20, 2022 at 12:08 AM Paul Gilmartin < 0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > In a Data Areas manual for CVT, I find: > ... > LEAP SECOND > 80 (50) DBL WORD 8 CVTLSO(0) OFFSET > IN TOD FORMAT > 80 (50) SIGNED 4 CVTLSOH HIGH WORD > > 84 (54) SIGNED 4 CVTLSOL LOW WORD > > I disagree with the characterization if CVTLSOL as "SIGNED". > For example, the current value of CVTLSO, 27 seconds is: > 0000 0019 BFCC 0000 which is is greater than: > 0000 0019 0000 0000 even though the sign bit of CVTLSOL > is set. In general, the lower full word of a signed double word must > be regarded as signed, even as the lower byte of a signed halfword > is unsigned. E.g. H'0080' represents 128, not -128. > > Is my statement clear enough for an RCF? > > -- > gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
