Hello, Clem?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of J R
Sent: Friday, November 15, 2013 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could
it be ?
Yes
Yes, sorry Charles. I was responding to Mitch's comment about his JCL checker.
I too would be more interested in JOL.
=
=
Date: Thu, 14 Nov 2013 17:50:30 -0800
From: charl...@mcn.org
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could
it be ?
To: IBM-MAIN
-0500
From: mitc...@aol.com
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could
it be ?
To: IBM-MAIN@LISTSERV.UA.EDU
J R:
Yes, it goes far beyond z/OS. It can clone JCL for multiple environments, it
can generate JCL from COBOL source programs as the source
On Thu, 14 Nov 2013 23:33:20 -0500, Mitch wrote:
...
it can verify that any incorrect handling of datasets is flagged before any
JCL object is submitted, i.e.:
DISP=(,CATLG) followed by
DISP=OLD followed by
DISP=(OLD,DELETE,DELETE) followed by
DISP=SHR
This is an obvious JCL error, but if
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, Nov 13, 2013 7:58 pm
Subject: Jol - Next Generation JCL- was JCL - What is it and what could it be ?
There has been much discussion about JCL and how enhance it. There is a
rogram that does much of what you require in an enhanced or next
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Jol - Next Generation JCL- was JCL - What is it and what could it be ?
There has been much discussion about JCL and how enhance it. There is a program
that does much of what you require in an enhanced or next generation JCL. And
it can be enhanced to add
: Thu, Nov 14, 2013 8:22 am
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could it
be ?
I'm curious -- and if someone wants to reply RTFM I guess it would be deserved
- how the product integrates with core/traditional/IBM-authored z/OS.
Does it generate real JCL under
: Charles Mills charl...@mcn.org
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Nov 14, 2013 8:22 am
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could
it be ?
I'm curious -- and if someone wants to reply RTFM I guess it would be
deserved
- how the product
, November 14, 2013 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could
it be ?
So, as far as what ends up being submitted to z/OS is concerned, your
competitive product does not provide any functionality that isn't already
available with z
-Original Message-
From: J R jayare...@hotmail.com
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Nov 14, 2013 10:47 am
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could it
be ?
So, as far as what ends up being submitted to z/OS is concerned, your
@LISTSERV.UA.EDU
Sent: Thu, Nov 14, 2013 5:51 pm
Subject: Re: Jol - Next Generation JCL- was JCL - What is it and what could it
be ?
I think Mitch and JR are speaking about some JCL front-end commercial
roduct such as CA JCLCheck.
I was looking for a response about JOL from its author.
Charles
In 9831656372670249.wa.jmcd520gmail@listserv.ua.edu, on
11/12/2013
at 11:18 PM, John McDowell jmcd...@gmail.com said:
I honestly have no idea if you are agreeing with my position that,
in the general sense, dataset names are not allowed to contain
lowercase alphabetic characters or if
I honestly have no idea if you are agreeing with my position that,
in the general sense, dataset names are not allowed to contain
lowercase alphabetic characters or if you are disagreeing with my
characterization of the restriction as arguably artificial and
perhaps unfortunate.
Neither; I am
There has been much discussion about JCL and how enhance it. There is a
program that does much of what you require in an enhanced or next
generation JCL. And it can be enhanced to add other facilities
relatively easily.
It is available NOW, and is called Jol.
You can read about it here:
Clem:
In the early 80's we had looked at JOL and came away with mixed
feelings about it.
I see it has been kept up to date (and thats good).
Maybe in a few years we will look at it again when our plate is not
to full.
Thanks.
Ed
On Nov 13, 2013, at 9:57 PM, Clem Clarke wrote:
There has
On 11/14/2013 12:52 AM, Ed Gould wrote:
In the early 80's we had looked at JOL and came away with mixed feelings
about it.
I see it has been kept up to date (and thats good).
Maybe in a few years we will look at it again when our plate is not to
full.
I looked at it a few years ago, and just
In 8420266817299524.wa.paulgboulderaim@listserv.ua.edu, on
11/11/2013
at 09:58 AM, Paul Gilmartin paulgboul...@aim.com said:
Doesn't JES3 already provide a similar facility?
No. DJC doesn't run parallel steps within a job, it handles
dependencies among a network of separate jobs.
--
In 5756776272434376.wa.paulgboulderaim@listserv.ua.edu, on
11/11/2013
at 10:24 AM, Paul Gilmartin paulgboul...@aim.com said:
Yet, I appeal to consistency. If some designer pranced into the
room and announced, There's never any reason to skip the first
step, so I'm designing IF so the
In
CAAJSdjhH6D+uOVEtmxx4rOL=w2csasxtn8saahkj68g5wpg...@mail.gmail.com,
on 11/11/2013
at 12:16 PM, John McKown john.archie.mck...@gmail.com said:
I always got the feeling that orignal OS/360 JCL programmers
either stole the parsing code from the then-existant assembler,
or vice versa.
If so,
In 1285038259930504.wa.jmcd520gmail@listserv.ua.edu, on
11/11/2013
at 08:41 PM, John McDowell jmcd...@gmail.com said:
However neither of your points can overcome the fact that ISPF,
most (all?) TSO commands, IBM utilities (e.g. IEBUPDTE, etc.),
etc. impose the (arguably artificial and
On Mon, 11 Nov 2013 22:14:19 -0500, Shmuel Metz (Seymour J.) wrote:
Doesn't JES3 already provide a similar facility?
No. DJC doesn't run parallel steps within a job, it handles
dependencies among a network of separate jobs.
But can those jobs run in parallel? If so, the desire for
parallelism
On Sun, 10 Nov 2013 09:02:10 -0600, John McDowell wrote:
=== really difficult === parallel job steps. JCL runs each STEP in the
order it exists in the JCL, perhaps bypassing some steps based on return
codes. How about
// PARALLEL
// ENDPARALLEL
Ouch! DDNAME collisions. Everyone wants to use
On Sun, 10 Nov 2013 10:31:49 -0500, Scott Ford wrote:
... Reading through this thread I was trying to understand why you would need
a IF/THEN prior to a EXEC PGM..
Tailoring. Sometimes you want to suppress the first step entirely
(I suggested an initial IEHINITT step). The bypassing condition
Gil,
Thx for the explanation ..I see the need based on what you said
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Nov 11, 2013, at 11:04 AM, Paul Gilmartin paulgboul...@aim.com wrote:
On Sun, 10 Nov 2013 10:31:49 -0500, Scott Ford wrote:
...
On Sun, 10 Nov 2013 11:06:52 -0600, John McDowell wrote:
Riddle me this grasshopper; How do you suppress the execution of the 1st step
in a job using existing JCL facilities ?
If you want to suppress it all the time, you don't need it in the
first place. FACETIOUS If you want to suppress it
On Sun, 10 Nov 2013 11:38:42 -0600, John McDowell wrote:
Having said that the limitation of using characters outside of uppercase
alphabetic and national (#@$) characters in JCL for PROCs and INCLIUDEs (in my
judgement) is predicated upon the parsing engine that the Converter has.
Having
On Sun, 10 Nov 2013 11:44:03 -0600, John McDowell wrote:
You got me there :-) I should have been more careful setting my constraints,
let me try again :-)
How do you suppress the execution of the 1st step in a job using existing JCL
facilities without modifying the JOB statement ?
Ya gotta
On Sun, 10 Nov 2013 09:26:12 -0500, Shmuel Metz (Seymour J.) wrote:
Keep in mind that CMS batch can't handle preallocation of shared
resources, e.g., data sets.
what would be needed?
A proc for batch TMP. Everything would run within a single job step.
I'd suggest, rather, an extension to
On Sun, 10 Nov 2013 12:16:21 -0600, John McKown wrote:
//NORUN EXEC PGM=IEFBR14,COND=ONLY
A colleague once did this. A prior step (a program I had written,
alas) ABENDed. He blamed me for consequential damages -- he
really didn't want that step to run. Ever since, I use and recommend:
Having said that the limitation of using characters outside of uppercase
alphabetic and national (#@$) characters in JCL for PROCs and INCLIUDEs (in my
judgement) is predicated upon the parsing engine that the Converter has.
Having written a parsing engine the prospect of tinkering with the
On Mon, 11 Nov 2013 11:28:42 -0600, John McDowell wrote:
For the specific case we are talking about (e.g. the use of lower case
alphabetic characters in PROC/INCLUDE names) I would actually feel much more
comfortable if the parser allowed for them to be treated differently than say
a ddname.
On 11/11/2013 1:16 PM, John McKown wrote:
And, again, we go back to old style keypunches
as to what the original JCL thought was reasonable to expect. Keying in
lower case on a 026 - is that even possible?
AFAIK the 026 was useful only for S/360 predecessors, and the 029 was
the first
John McKown's description of how the assembler handles alphabetic case
characterizes its default behavior correctly.
Finer control is, however, available. Specifying either or both of
the keyword values NOCASE and NOMACROCASE of the COMPAT assembler
option instructs the assembler NOT to make
On Mon, 11 Nov 2013 14:03:22 -0500, John Gilmore wrote:
John McKown's description of how the assembler handles alphabetic case
characterizes its default behavior correctly.
Finer control is, however, available. Specifying either or both of
the keyword values NOCASE and NOMACROCASE of the COMPAT
These ojects are easily enough created/manipulated with Assembler,
and Binder can easily create load modules (not only program objects)
with mixed case names. I think it's a dog-in-the-manger attitude for
JCL to prohibit what some (not all) utilities readily support.
I have always held that
John,
I share your feeling :-) Stealing (sharing :-) code is a time honored
technique, one that I have every intention of making part of my new JCL
proposal (if it ever gets that far :-)
My memory of the 026/029 keypunches was that you could enter lower case
alphabetic characters, you just
COND=ONLY
On Mon, Nov 11, 2013 at 4:44 AM, John McDowell jmcd...@gmail.com wrote:
Dan,
You got me there :-) I should have been more careful setting my
constraints, let me try again :-)
How do you suppress the execution of the 1st step in a job using existing
JCL facilities without
In 7564746716020611.wa.jmcd520gmail@listserv.ua.edu, on
11/09/2013
at 12:07 PM, John McDowell jmcd...@gmail.com said:
With this context in mind I would be interested in hearing ideas
about what JCL could be.
Are you including allocation and disposition messages?
- Creating a new
Shmuel,
In 7564746716020611.wa.jmcd520gmail@listserv.ua.edu, on
11/09/2013
at 12:07 PM, John McDowell jmcd...@gmail.com said:
With this context in mind I would be interested in hearing ideas
about what JCL could be.
Are you including allocation and disposition messages?
No, I am trying
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
at 12:07 PM, John McDowell jmcd...@gmail.com said:
With this context in mind I would be interested in hearing ideas
about what JCL could be.
Are you including allocation and disposition messages?
No, I am trying to limit the scope. It is possible that the scope may turn
out to broader
Bernd,
I agree. This is what I was thinking of in a previous post calling it new
JCL. Not enhanced JCL. Something totally new. But that means a lot of
cost. I would almost think the only hope for this would be something like a
FOSS project of z/OS heavy weights getting together, designing and
On Sun, Nov 10, 2013 at 9:02 AM, John McDowell jmcd...@gmail.com wrote:
My thought is to contain the changes to the Converter only, no changes to
the Interpreter or any other components. This will restrict what new
functions can be provided but I think it has the potential to provide some
John,
A phased in approach to a new JCL could work. Let me thunk
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Nov 10, 2013, at 10:35 AM, John McKown john.archie.mck...@gmail.com
wrote:
On Sun, Nov 10, 2013 at 9:02 AM, John McDowell
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
be interested in hearing ideas
about what JCL could be.
Are you including allocation and disposition messages?
No, I am trying to limit the scope. It is possible that the scope may turn
out to broader than I expect but I am trying to keep the effort more
contained.
- Creating a new attribute
John,
/My opinion/
If the cost of this effort can not be sufficiently contained then it will
collapse under it's own weight.
JOL will never be made part of z/OS, there are many reasons for this some
technical and some non-technical.
/End my opinion/
FOSS and z/OS exist in different
Riddle me this grasshopper; How do you suppress the execution of the 1st
step in a job using existing JCL facilities ?
Jobcard ... RESTART=STEP2
Dan
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
John,
To the best of my knowledge, you are absolutely correct regarding the
syntactical limitation (or lack thereof) regarding PDS member names, the length
limitation is baked in but other then not allowing 8x'FF' you are free to use
anything you want for a member name :-)
The rules regarding
Hey John,
Can I see an example ole master
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Nov 10, 2013, at 12:44 PM, John McDowell jmcd...@gmail.com wrote:
Dan,
You got me there :-) I should have been more careful setting my constraints,
let
In 527e86cc.4080...@t-online.de, on 11/09/2013
at 08:02 PM, Bernd Oppolzer bernd.oppol...@t-online.de said:
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,
Keep in mind that CMS batch can't
In
CAAJSdjhUjOS-+pERaZHK8g-agKJsRqeoKtwmZSge=rqpndw...@mail.gmail.com,
on 11/09/2013
at 04:06 PM, John McKown john.archie.mck...@gmail.com said:
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
Very old trick I learned from an IBMer (who actually help write part OS/360)
//MYJOB JOB
//NORUN EXEC PGM=IEFBR14,COND=ONLY
//STEP2 EXEC PGM=IEFBR14
The NORUN step will be flushed (not run).
//TESTRUN JOB (H0I),MCKOWN,CLASS=Z,MSGCLASS=X,NOTIFY=SYSUID
//IEFBR14 EXEC PGM=IEFBR14,COND=ONLY
In
caajsdjj6wcoje54ilhz6fzpvajj7f2v75o4vts8ip+kv-sn...@mail.gmail.com,
on 11/09/2013
at 11:01 PM, John McKown john.archie.mck...@gmail.com said:
//MEMBERS DD DISP=SHR,DSN=SYS1.PARMLIB(BPXPRM*)
And what the program which opens the MEMBERS DD gets is the
contents of the BPXPRM* members in
In 9108055056292798.wa.jmcd520gmail@listserv.ua.edu, on
11/10/2013
at 09:20 AM, John McDowell jmcd...@gmail.com said:
The Scheduler JCL Facility (SJF) is very useful but it is built on
top of the preexisting C/I infrastructure, I am not looking to
usurp SJF but rather the infrastructure
John,
I hadn't seen that trick before, excellent
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Nov 10, 2013, at 1:16 PM, John McKown john.archie.mck...@gmail.com wrote:
SWAPS
--
In 9108055056292798.wa.jmcd520gmail@listserv.ua.edu, on
11/10/2013
at 09:20 AM, John McDowell jmcd...@gmail.com said:
The Scheduler JCL Facility (SJF) is very useful but it is built on
top of the preexisting C/I infrastructure, I am not looking to
usurp SJF but rather the infrastructure
John,
Good trick :-) And with some minor modification:
//MYJOB JOB
// SET RUN=ONLY or EVEN ONLY will never run , EVEN will always run
step 1
//*
//STEP1 EXEC PGM=MYPROG1,COND=RUN
//STEP2 EXEC PGM=MYPROG2
it can be made to either run or not run the 1st step (albeit somewhat
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
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
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
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.
Don't you need a SET RUN ON first?
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
Not if you #CP DISC#B
On Sat, Nov 9, 2013 at 5:20 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:
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.
Don't you need a SET RUN ON first?
-
Ted
Bernd,
I believe REXX has great potential to help in the new JCL.
But before we go any further in this discussion I need to caution that trying
to bring the CMS batch model you describe is much more akin to using REXX in
(batch) TSO (e.g. PGM=IKJEFT01 or IKJEFT1A or IKJEFT1B). As such it
On Sat, Nov 9, 2013 at 8:48 PM, John McDowell jmcd...@gmail.com wrote:
Bernd,
I believe REXX has great potential to help in the new JCL.
But before we go any further in this discussion I need to caution that
trying to bring the CMS batch model you describe is much more akin to
using REXX
65 matches
Mail list logo
