Some comments. The terms 'local' and 'global' have well-established definitions and uses---They specify the scopes of set symbols at assembly time---in the HLASM macro language, and their usurpation for other purposes is ill-advised. '...that way madness lies; let me shun that; No more of that'.
Moreover, persistence and scope are very different notions. They are sometimes hard to disentangle; but it is always unwise to confound them. Persistence can be characterized in two ways, in terms of maximal lifetime and dynamism. The obvious maximal lifetimes are termination by o z/OS shutdown/IPL, o jobstep, o task, and o block or routine exit It may or may not be possible to allocate and free a block of storage dynamically. Thus, for example, the automatic/scratch storage of PL/I and then C is allocated when control for a dispatchable unit enters a routine or block and freed when it exits from that routine or block. It cannot, that is, be allocated sooner or freed later. Automatic storage is also LIFO, stack-based storage, allocated from a stack and freed/returned to that stack for reuse. Typically, pools are also stacks, not because FIFO democracy is important for them but because stacks are the easiest constructs to use to manage interchangeable, reusable blocks of storage. Most other storage is non-LIFO, and a block of it is typically called a heap. There are management issues for heaps, but most modern operating systems handle them efficiently. Once allocated from a heap, storage within such a block of can of course be suballocated/managed as a stack or pool. The questions how best to manage heaps and where to put them do not have any generic answers, but the lawyers' de minimis principle is important for them. A system may usefully contain many stacks, but it shouild not usually contain more than a very few heaps. Accesses to heaps must [almost] always be serialized; and adult, asynchronous systems cannot be built without using serialization machinery. Satisfactory systems can be written primarily in some statement-level procedural language (SLPL), but routines written in that SLPL must typically be supplemented by others written in assembly language. The Scots poet Blair described archangelic visits to the earth, necessary to keep things in order here below, as 'short and far between'; and these assembly-language routines can have these two characteristics too. They are, however, necessary 1) to close gaps in the SLPL being used, 2) to avoid really ugly, infelicitous constructs in that SLPL, and to circumvent serious inefficiencies in that SLPL's implementation. For these reasons programmers who do not write assembly language with facility are all but useless. The routines they write always reflect the more or less radical imperfections of the SLPL they use. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
