I have often wished that JCL were more powerful. Or were replaced with something along the lines of REXX. But there is one simple phrase I will utter which explains why it would probably never fly: "What about automated restart?". Do people write REXX programs which can be easily restarted should a problem occur within them? There isn't anything like a "checkpoint" or "commit" and "rollback". OK, JCL doesn't do that either. But add CA-11 into the mix and our production control people can usually easily restart a job. Perhaps after running a recovery job, depending on which step abends and why. But imagine a REXX program which runs a number of various reporting and updating programs. REXX doesn't have a RESTART= to start things back up. So __each and every REXX program__ needs to have it own restart logic built into it.
The above is a very short reason why I doubt that JCL will ever be truly replaced. In order to replace it properly would take too long to develop (if the language were designed for "restartability") and that means it would cost too much to give away or even market. Just my basic take on it. Wish it weren't so. On Sat, Nov 9, 2013 at 1:02 PM, Bernd Oppolzer <bernd.oppol...@t-online.de>wrote: > Maybe this response will start some kind of religious war, but: > > today I'm working with z/OS most of the time, but in my former life I was a > VM/CMS person. And I enjoyed the way of doing batch there very much, > that is: > > you write a REXX exec, where you do the necessary file assignments using > FILEDEF (which is much the same as a DD statement) and then you call the > load module simply by entering its name (if there is no EXEC with this > name, > REXX looks for a MODULE with the given name). Of course, you could specify > some kind of special ADDRESS XXX command first. > > So we have the same language there for CMS dialog and batch; you simply > disconnect > from your CMS machine, and the execution continues as a batch machine. > > To modify your FILEDEF statements (for example, computing file names > etc.), you > have the full power of the REXX language. > > I would like it very much to do my batch job planning using REXX instead > of JCL syntax. > > With TSO and REXX, for example, we are able to compute data set names > using REXX > at run time ... I would like to have true scripting facilities in batch > processing, too. > > In fact, this is all possible today, if you start a batch TSO session and > REXX, and > then - for example - your COBOL or PL/1 programs under the control of this > environment, but it is normally not done for production work. And I > believe, it is not > done, because there is no control what happens by looking at the JCL any > more ... > > So I think the limitations of JCL which are bad for us (developers) make > other > people happy. > > If there are no "political" obstacles: > > what would be needed? The batch initiators need to be combined with a REXX > interpreter, and some kind of command (similar to FILEDEF) should replace > the DD statements ... > ok, this is maybe far too simple minded, but it could be possible, IMHO. > Like in VM/CMS, > you would have to issue the FILEDEF commands prior to the execution of the > module; > don't know, if there should be a FILEDEF * (CLEAR, too. Is this > automatically done at > the end of the job step? Do we still have a job step? Can we control the > begin and end > of a job step? Does the execution of the REXX survive the termination of > the job step? > Of course, it should ... these are some of the questions to be answered if > we go deeper > into the details ... > > Kind regards > > Bernd > > > > > Am 09.11.2013 19:07, schrieb John McDowell: > > 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 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 > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
