On Monday, 08/28/2006 at 08:08 AST, Peter Relson/Poughkeepsie/[EMAIL PROTECTED] wrote: > >Your "astonishment" only shows your own limitations. > Maybe true. > > The reason it is not reasonable and useful is for exactly the reason that > Roland ran into trouble: we might choose to "roll back" a definition at any > point for any reason that we feel useful.
This discussion has been elightening. As an operating system designer/developer, I can confirm that only those fields specifically designated as "customer use" (whether that's the end user or an ISV) are guaranteed to exist from one system update to the next. Think about it: Without a universal registry of "Who is using what fields in what control blocks on what releases?" there can be no guarantees. Leaving unused fields in control blocks simply allows dirt and dust to accumulate in the system. Sure, the mainframe development culture typically requires unused fields to lie fallow for some period of time before reuse, and we make an effort not to needlessly shift fields around, but we have never promised to manage control block content to the field name level and restrict names to certain releases, nor have we promised never to delete a field once it has been introduced. If there is a requirement for assembly-time knowledge of the macro library level being used, or if what is currently provided is not sufficient, then get those requirements opened. Yes, that will create a period of transition from the old way to the new way that will not be convenient for ISVs, but if we never start the process, it will never be finished. When there is no design point to solve a problem, then we all depend on luck. But someday the luck runs out.... Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
