On Nov 7, 2011, at 06:02, Abe Kornelis wrote: > Replying to an old message by Paul Gilmartin: >> How many passes does HLASM make over the source? > Two passes. > >>> This could lead to a situation where the displacements oscillate >>> back and forth for each pass. >> Similar problems exist with the old-fashioned type attribute. >> I can code a test which, depending on the type attribute, >> defines that symbol with a different type. This really ought >> to cause an assembly error. > **--> Not at all! The T attribute is defined to return the type > of a symbol, provided it is pre-defined. That is, the symbol > must be defined at a source location before the T' type reference > is made to it. This is because the assembler needs to evaluate > the T' reference in the first pass, therefore the label must be > defined (hlasm must have processed its definition). > Look-ahead mode cannot be used, as the label may be > defined using conditional assembly - there might be > conflicting definitions - thus look-ahead might yield the > wrong variant of the defiinition.
"Look-ahead" considerably violates my notion of "two passes". Will look-ahead fail to resolve any symbol which potentially has conflicting definitions? Can conditional assembly even make this determination? This impinges on the notion of computability. > What you do in your own macro code is your own > business, the assembler is in no position to tell whether > or not your code is in error, or you ar purposely doing > something that may or may not look like an error to > someone else. I suppose one must view conditonal assembly as a procedural, not declarative, language. This is certainly the way John G. employs it. > Anyway - if you want to use attribute references like T' > then define your DSECTs at the top of your program, > rather than at the bottom. It will allow you to properly make > use of such references, it will allow proper derivation > (or inheritance) of field characteristics, et cetera. > On top of that, it severely reduces the need for hlasm > to use look-ahead mode, which shortens execution time > of your assemblies, and also saves processor cycles... > But it transgresses convention. Decades ago, I was (briefly) in a development project where we took a vote on coding standards; where to place DSECTs. I was in a minority of two favoring the top. (How long ago? Well, one of our requirements was that source code distributed to customers (a minority) had to be IFOX00 compatible because there was no requirement that they have IEV90. In such cases, it might be necessary to place DSECTs at the top, contrary to our otherwise standard.) -- gil
