Bernd,

I think (but I'm not sure) that you and I are talking about the same goals :-)  
Does the "second way" you envision have a static (execution) definition that 
does not allow human interaction ?  If so we are on the same page, if not then 
we are talking about different things. 

I believe the most significant complaint about JCL is it's syntax and perhaps 
it's "look and feel" which are so different than other "scripting" languages.  
There are other limitations that I personally would like to see removed but I 
am really trying to understand what others would like to see in the "new JCL" 
(really need a snappy name for it :-). 

I am not particularly focused on the question of allowing other "scripting" 
languages beyond REXX to be used, but on the other hand I do not see any 
significant reason why it couldn't be done in theory.  In practice, I suspect 
that the stumbling blocks will be a combination of technical and non-technical 
so for the time being I want to see how far REXX can take us.

John McDowell

>Hello John,
>
>I would like to clarify my viewpoint:
>
>first, I believe that traditional JCL must stay and needs to be improved
>in the way that the other posters suggested.
>
>What I would like to see is a second way of doing batch on z/OS, where
>we have a sort of command line interface, like TSO ALLOC, FREE and
>ISPF SELECT PGM, for example, but without the burden of starting
>TSO, REXX and ISPF first - and with the power of REXX to manipulate
>the batch commands.
>
>We need some sort of clever replacements for
>
>- DD statements
>- EXEC statements
>- STEPLIB concatenations
>
>which can be used from this new command line interface (in batch !)
>without much limitation compared to the existing JCL interface, if 
>possible,
>but with the possibility to add REXX as a control language (or other
>scripting languages, BTW).
>
>I don't want this to replace traditional JCL, but to add a second line of
>batch processing. Maybe some shops do more and more work with this 
>technique,
>maybe others stay with (old) JCL.
>
>Restart problems have to be solved; if the new batches contain loops 
>etc, the
>restart information has to contain information about the status of the 
>controlling
>REXX. There is no general solution to that, and there will be batches 
>that are
>not restartable (same situation as today, I believe).
>
>Could we maybe make the mainframe platform more attractive this way to
>younger people? I could imagine that JCL is one of the reasons why they
>don't like the mainframe now. At least that's what I often hear when doing
>classes with 20 year old students on PL/1 and similar topics ... they like
>the language, but they dislike the environment and especially JCL ...
>
>BTW: I don't really think that this will happen, but if we're talking about
>dreams, that's what I'd really like to see. There are some efforts to make
>the platform attractive (RDZ etc.), but that's too expensive IMO, and it
>leaves the platform unchanged and only hides the old things from the
>novice users, instead of really improving the platform itself.
>
>Kind regards
>
>Bernd

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to