Paul Gilmartin's question is a curious one. As the HLASM LR makes clear repeatedly, DS nominal values are optional, and nothing is ever assembled into the space they map or reserve.
The binder has an option, FILL, that permits any character, x'00' through x'ff', to be specified for use in filling uninitialized areas in [most] program objects. (It is ignored for load modules and for PM format 1 program objects.) I use nuls, x'00', to initialize any such areas in [other] program objects; and I have found this choice unproblematic; but I do not write non-refreshable code even in jest; and my use of such areas is exiguous for that reason. For STORAGE OBTAIN macro instructions things are a little more complicated: o no initializations are performed for fewer than 4 Kibytes, it being assumed that they may have specialized requirements that are better addressed by the requester or no such requirement at all; o for 8 Kibytes or more in a pageable private subpool, storage is cleared to nuls; o for 4 Kibytes or more in a pageable private subpool with BNDRY=PAGE specified, storage is cleared to nuls. Specifying CHECKZERO=YES yields information about what in fgact happens in these and, I think, all other cases too. The last time I looked into buffer initialization I found that the different access methods did things quite differently, but that was more than 10 years ago, and I cannot recite on what they do currently. Where it is important, e.g., for locate-mode I/O, my practice is to initialize them myself. As this not at all exhaustive catalogue I hope makes clear, there is no simple answer to questions like this one. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
