On 2020-04-20, at 14:05:06, Jonathan Scott wrote: > > On 4/20/2020 9:40 AM, Paul Gilmartin wrote: >>> For such a case, I will always code: >>> >>> DC CL8'&RQS. ' >>> >> Does that truncate properly, but quietly if: >> o &RQS is 8 bytes? >> o &RQS is 9 bytes? (Should warn.) > That's correct, with a warning only if FLAG(TRUNC) is enabled. > > Edward E Jaffe writes: >> Your "should warn" above is an incorrect assertion. >> >> DC CL8'12345678901234567890' is perfectly legal and should *NOT* warn >> (unless some new warning option was added to HLASM that I missed). > You missed it, but it was quite recent. > > If you enable the helpful FLAG(TRUNC) warning added by APAR > PH06572 in January 2019, then a warning will be issued if an > initial value gets truncated because of an explicit length, > causing its value to change. > Thanks. This also leads me to wonder whether the behavior of HLASM for: &RQS SETC 'ABCD' FOO DC Cl8'&RQSxxxxxxxx' ... matches that of Assembler H, or whether there's a COMPAT setting to preserve the IEV90 behavior.
Most of us haven't IEV90 to test with, but some may have dusty source code needing continued support. > For a character value, the loss of trailing spaces is not > considered truncation, and neither is the loss of leading zeros > for a numeric value. However, if you want to check for those > cases too (which are normally harmless and likely to be > intentional) then the option FLAG(LONGER) will give a warning in > the case where an initial value is longer than the explicit > length but truncation is not considered to have occurred. > > There's also another option FLAG(SIGNED). If you code a signed > value for an unsigned field, for example AL2(-1), then the main > FLAG(TRUNC) option will not issue a warning if the value would > be in range for a signed field of the same size, as this is > likely to be harmless but the option FLAG(SIGNED) will issue a > warning in this case too. > > The intention is that FLAG(TRUNC) is intended to give warnings > only if there is probably an error, so an installation can turn > it on by default. FLAG(LONGER) and FLAG(SIGNED) provide extra > warnings for cases which are much less likely to be in error > and could well be intentional, so they can be turned on for > extra checking temporarily but should not normally be turned > on (and IBM-supplied macros may well trigger these warnings). Thanks again, gil
