Thanks Jonathan for the explanation... I doubt that many people care much about the tidiness of their object decks (but I am one :-). That is only part of the reason I insist on using DC over DS in text sections though.
The main reason is that any padding generated is shown in the listing, which can be important. Also, even in DSECTs, I often use DC for most fields, because you get a visual layout of the fields in the listing, not just a bare offset. Particularly in a "control block" type DSECT, it's useful for finding places where new fields can be tucked in without making the block larger. No text is generated for DSECTs, so there's no cost to using DC over DS, other than having to code a value for fields that aren't 0-length. Long ago, DS for largeish areas was better because no text was generated in the object deck (or load module). But in a strictly reentrant world, DS space in a module is usually pointless. Also, the enhancement to DC 0* to eliminate the need for the '0' value makes it a lot easier to use (and neater). sas On Thu, Oct 19, 2023 at 8:42 AM Jonathan Scott <jonathan_sc...@vnet.ibm.com> wrote: > In the past, DC 0H'0' was preferred for defining labels because > any DS, even of zero length, would cause a new TXT card to be > started in the object deck, making it larger than necessary. > The value is no longer needed, so DC 0H is allowed. > > If no alignment padding is required, DC 0H and DS 0H are > equivalent, but if alignment padding is required (which would > not occur within instructions) then DC 0H will pad with a zero > byte and continue on the same object code TXT card, but DS 0H > will simply start a new TXT card at the aligned location. > > Jonathan Scott, HLASM > IBM Hursley, UK >
