John, So what you call setting a token, IEANTCR ..then allocating storage based on the return address ? A block of storage ? Curious ...
Scott ford www.identityforge.com from my IPAD > On May 13, 2014, at 1:32 PM, John Gilmore <jwgli...@gmail.com> wrote: > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
