|
Bob: So, the problem was in trying to initialize an unsigned value with a signed value and it isn't a bug when that doesn't work. Feeling my way somewhat cautiously here, then the code is working as designed but the error message didn't completely explain the problem that the PRM/translator was having with the initialization value. What do you think of that statement? For what it's worth, until someone else pointed up the H" situation, I was seeing X". My comment that the behavior was a bug was based on seeing the X" string. It probably wouldn't have made any difference - I probably would have assumed that X" and H" had the same semantics - but that specification difference is not intuitively different. Wheels within wheels :) Thanks for helping with this. Do you have a machine readable MI manual? Richard Jackson mailto:richardjackson@richardjackson.net http://www.richardjacksonltd.com Voice: 1 (303) 808-8058 Fax: 1 (303) 663-4325 -----Original Message----- From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On Behalf Of rjd@us.ibm.com Sent: Thursday, August 24, 2000 7:36 AM To: MI400@midrange.com Subject: Re: how to create unsigned hexadecimal initial value On 08/24/2000 at 12:32:29 AM, "Peter Dow" <pdow@earthlink.net> wrote: What's the difference between H"80000000" in Gene's initial post and X'80000000' that everyone else used? Is there some significance to using H and " instead of X and '? Are they supposed to be equivalent? H'80000000' is a numeric literal. More specifically, it has the attributes of a signed integer. X'80000000' is a character literal. It has the attributes of a character type. Given the following declaration of FLAG, DCL DD FLAG AUTO BIN(4) UNSGND; we've observed several behaviors which can be explained in terms of the integer vs character attributes of the literal values: DCL DD FLAG AUTO BIN(4) UNSGND INIT(H"80000000"); -- fails at compile time because the assembler recognizes that the initial value is negative (recall that H-literals are signed). DCL DD FLAG BIN(4) UNSGND AUTO INIT(X'80000000'); -- works because the initialization of automatic data is implemented using "copy bytes"-like instructions, which ignore numeric atrributes of the data. CPYNV FLAG, H"80000000"; -- fails at runtime with binary overflow (mch1210). The exception occurs when the signed integer value (-2147483648) is converted to unsigned in preparation for the store to FLAG. CPYNV FLAG, X'80000000'; -- fails at compile time because operand 2 has character attributes instead of numeric attributes CPYBLA FLAG, X'80000000'; -- works because CPYBLA ignores the numeric attributes of the receiver CPYNV FLAG, 2147483648; -- works because an unsigned literal is specified DCL DD FLAG AUTO BIN(4) UNSGND INIT(2147483648); -- works because an unsigned literal is specified Bob Donovan +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +--- +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.