Jon Perryman has given you the essentials of a solution to your problem, but exactly what should be done depends upon your detailed requirements.
Do you, for example, need to support two or more separate usage streams for your macro within the same assembly? Will they be concurrent/overlapping? Or sequential? A generic solution to problems of this sort makes use of some addfitional keyword parameters. Consider | macro | EXAMPLE &handle=,&usage=, . . . | . . . Here handle= values are used to distinguish one usage stream from another, and usage= values are typically at least three: o usage=initial, which defines a new usage stream, o usage=entry, which makes substantive use of the macro, and o usage=final, which terminates a stream and perhaps initiates some other action. To implement such a scheme handle= values, perhaps edited ones, can be used as a part of the identifier of a created global binary/boolean set symbol. Suppose that &ehandle is the edited value of &handle. (Stripping framing single quotes and leading and trailing blanks and using one of the bifs LOWER or UPPER is a good practice.) Then something like |&stream_id setc '&macname'.'__stream__'.'&ehandle' |&initialized_id setc '&stream_id'.'__initialized__' | gblb &(&initialized_id) --stream initialized? can be used to make your macro definition 'reentrant' in a Pickwickian but important sense. Different usage streams for it can overlap, precede, or follow each other in arbitrary ways. I, for example, use such a scheme to permit multiple instances of some table type to be assembled concurrently. You of course need one other piece of plumbing, a GBLC array in which you keep edited handle= values to prevent collisions; but that is straightforward. Worth noting also is that a more 'natural' alternative to handles is sometimes available. For certain table-generation operations I, for example, use an &RSECT= value both as the name of a table RSECT and a handle. Finally, as is obvious, you need to reestablish the status quo ante for usage=final; but that is trivial too. John Gilmore, Ashland, MA 01721 - USA
