Binding times are an old topic about which much has been written. Classically, coding time, translation time and execution time are distinguished, but this trichotomy does not capture many important, if nuanced, differences.
It is clear enough, as Peter Relson has reminded us, that execution-time errors cannot be diagnosed at translation time. Only decisions that are irrevocable once made at or before translation time can be diagnosed as correct or in error at translation time. Even this is not always trivial. Much HLASM syntax is, not to coin a phrase, context-sensitive. I have a macro, imaginatively named INDXSRTC. There are others, but its two crucial keyword parameters, viz., 1) &inputGBLCaid, the identifier/data name of the input created global character set-symbol array for which an ordering isto be found, and 2) &indexGBLAaid, the identifier of the output created global arithmetic set-symbol array that is to contain the index/ordering subscript set for these elements. Within this macro there are two declarations of the usual sort | gblc &(&inputaid)(1) --input array | gbla &(&indexaid)(1) --index array where &inputaid is an ordinary local character set symbol, the edited value of the inputGBLCaid= keyword parameter, and &indexaid is of course another ordinary local character set symbol, the edited value of the indexGBLAaid= keyword parameter. Now in general a character set symbol may not have a VALUE that is more than 1023 characters in length, but these two---because they are used as the identifiers of other [created] set symbols--may not have values that are more than 62 (sic) characters in length. Here and frequently elsewhere context is crucial. Moreover, storage usage is often not straightforward. The array &(&inputGBLCaid) may be empty (have no elements) and, in principle at least, at most 2^31 - 1 = 2147483647 elements. The statement |&nin seta n'&(&inputaid) --element count is available; and the macro INDXSRTC must determine this element count dynamically, using this statement or the like to do so. There is indeed very little difference in kind between the kinds of error checking sometimes required at translation time and those that may be deferred until execution time in the interests of flexibility and wider usefulness. (Deferred, later binding times almost always confer further flexibility. The trick is to decide when this further flexibility should be provided.) In my experience the HLASM macro language is usable for most error checking. Occasionally I find it necessary to use SETAF or SETCF to supplement its facilities with routines written directly in assembly language or (for floating-point arithmetic and matrix algebra) PL/I; but I do not need to do this often. In general, as I have had occasion to note here before, the HLASM's macro language and conditional-assembly facilities are both underused and badly used. This is a pity, not least because another such assembler is very unlikely to be developed. I use others from time to time, and they all seem to have discouragement of their use as a principal design objective. John Gilmore, Ashland, MA 01721 - USA
