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
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
Wow two John Mcs, anyway, I liked Rexx for JCL type functions being a VMer
before I crossed over to the 'dark side' of the force, sorry, only kidding. I
have used SETs and IF conditions in the building of our product libraries
successfully. Reading through this thread I was trying to understand
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
Scott,
I guessing there are a lot more than two John Mcs :-)
Riddle me this grasshopper; How do you suppress the execution of the 1st step
in a job using existing JCL facilities ?
John McDowell
Wow two John Mcs, anyway, I liked Rexx for JCL type functions being a VMer
before I crossed over
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
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
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
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
50 matches
Mail list logo
