Yes, DS "skips" bytes for alignment, and those skipped aren't guaranteed to be anything. But why would you care?
In any case, plain DC 0H (or any other unit) has been supported for a long time, if not from the beginning of HLASM. I don't care what's in padding, but DC does pad with 00 text, and more usefully, prints the padding. I often want to eliminate alignment gaps. Also, for those who care, it doesn't break up text generation in the object deck. Note that I don't think EQU * should be used in data areas either, where it is potentially more dangerous. This is the kind of error that motivated me to write this up. sas On Wed, Aug 1, 2018 at 7:15 PM, <jba...@ngssallc.com> wrote: > Gary, > > I discontinued the use of - > > label DS 0H > > in lieu of - > > label DC 0H'0' > > long ago. > > As best as I can recall, there was a bug identified (subsequently > corrected (?)) where the buffer into which code was assembled was not > always initialized to zeroes, and it was possible to have memory locations > skipped over by virtue of alignment issues contain random data. > > The use of " DC " in lieu of " DS " ensures that memory locations skipped > over by virtue of alignment are initialized to zeroes. > > John P. Baker >
