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. 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). Jonathan Scott, HLASM IBM Hursley, UK
