When I think about JCL I always view it in the context of a means by which a person can describe what they want the (z/OS) system to do. To my way of thinking this is analogous to the many programming languages (e.g. COBOL, PL/I, JAVA, etc.) which are used by a person to describe what they want the (hardware) system to do. And just as the many programming languages demonstrate there are lots of ways a person can convey what they want, some of which are more complex than others :-)
With this context in mind I would be interested in hearing ideas about what JCL could be. Let's not try to "boil the ocean" :-) but rather limit ourselves to changing the human interface (e.g. JCL) and not require changes to the underlying (z/OS) system. (Note: To my way of thinking this guideline is the most important and also the most difficult to follow. It is important because the "cost" (e.g. complexity, etc.) gets higher and higher the wider the scope of change. And it is difficult to follow because it is not always obvious what system components are affected by changes to "JCL".) In broad terms I would offer the following: - Changing the basic nature of a "job" from a static entity to a dynamic one falls into the "boiling the ocean" category :-) - Modifying the maximum allowable value of an attribute (e.g. dataset name length, the number of steps, etc.) is likely to be in the "boiling the ocean" category - Creating a new attribute (that needs to be acted on by a component other than the Converter/Interpreter (C/I)) is difficult - Providing new functions that are performed by the C/I (e.g. iteration, simple arithmetic, etc.) is possible - Changing how an attribute gets assigned a value (e.g. a dataset name, a ddname, etc.) is easy John McDowell ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
