|
Okay. From Gene's example, I conclude that the value in the type H constant is copied right adjusted into the variable being initialized - more or less as though: DCL DD CONSTANT CHAR(1) INIT(X'0F'); DCL DD VAR BIN(4); CPYBRA VAR,CONSTANT; Of course, if this was true in all elements of its description then Gene's original example would not have failed. So there is something special about Gene's original case copied in here: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following won't compile giving error CPD6416, "Number was either too large or negative." DCL DD FLAG AUTO BIN(4) UNSGND INIT(H"80000000"); The following compiles okay but run-time fails with MCH1210, "Receiver value too small to hold result." DCL DD FLAG AUTO BIN(4) UNSGND; CPYNV FLAG, H"80000000"; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I went back and reread the "create program API description. It says: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Integer Integers define signed and unsigned binary scalar data values. The two forms of integers are decimal and hexadecimal. The decimal form is a sequence of digits optionally preceded by a sign. The hexadecimal form is a string of hexadecimal digits delimited with apostrophes and preceded by an H. Neither form may exceed the 4-byte limit on binary numbers. When the value of the integer is between -4095 and +8191, the QPRCRTPG API converts the integer to an immediate operand where it can. Example +123 -1 54788 H'0F0D' H'0123' H'5E2D1AB4' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I don't think that this description is saying the decimal integers are signed and hex integers are unsigned. In fact, I don't see how to create an unsigned integer constant from this explanation - it appears to me that using either a type X constant or a type H constant means that you have to do some work for yourself. If I got it right from Leif's tests, when a type H integer constant is used to initialize a numeric constant its hex characters are copied into the variable right adjusted. When assigned to a character variable, the type H integer constant is stripped of its leading zeros then copied into the character variable left adjusted. Same thing with the AND operations. My neck is getting sore from looking at this stuff. I think I now understand that type H constants are integer values and that they behave in interesting but understandable ways when used with numeric versus character variables. But I keep looking at all this evidence and I cannot see why the CPU is throwing a runtime exception when you assign a large negative value to a bin(4). Gene, could you try your little demonstration below but make FLAG into an unsigned number? I'm wondering about the difference between run time versus initialization time. 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 Gene_Gaunt/ReviewWorks@reviewworks.com Sent: Friday, August 25, 2000 6:52 AM To: MI400@midrange.com Subject: Re: how to create unsigned hexadecimal initial value Try this: DCL DD FLAG(8) AUTO BIN(4) INIT( H"F", H"FF", H"FFF", H"FFFF", H"FFFFF", H"FFFFFF', H"FFFFFFF", H"FFFFFFFF"); BRK "LOOK"; PEND; STRDBG ADDBKP LOOK PGMVAR(FLAG) then breakpoint displays: 1: 15 2: 255 3: 4095 4: 65535 5: 1048575 6: 16777215 7: 268435455 8: -1 +--- | 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.