On Fri, 13 Jul 2018 09:56:45 +1000, Andrew Rowley wrote:
>On 13/07/2018 1:55 AM, Seymour J Metz wrote:
>> WTF? Dynamic allocation has supported temporary data sets since Old Man
>> Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for
>> that.
>I assume you're correct (I
On 13/07/2018 1:55 AM, Seymour J Metz wrote:
Again it is something that we take for granted in JCL that becomes
difficult to do correctly without it.
WTF? Dynamic allocation has supported temporary data sets since Old Man Noach
cornered the market in Gopher Wood. We don't need mo stinking JCL
On Thu, 12 Jul 2018 12:32:55 +, Pew, Curtis G wrote:
>On Jul 11, 2018, at 11:27 PM, Andrew Rowley wrote:
>> That's sort of true, but it vastly expands the competition. It makes HTML,
>> even GML programming languages. Is JCL a worse programming language than GML?
>
>That’s kind of how I
@LISTSERV.UA.EDU
Subject: (External):Re: Using JCL Symbld and TYPRUN=SCAN
I doubt that many programmers ,or lexicographers, would agree with that.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Ed
Jaffe
12:05 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
> I don’t think it’s true that JCL is the worst programming language
> (with all due respect to Fred Brooks) because it isn’t really a
> programming languag
) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Andrew Rowley
Sent: Wednesday, July 11, 2018 11:18 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 11:47 AM, Paul Gilmartin
@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
> I don’t think it’s true that JCL is the worst programming language
> (with all due respect to Fred Brooks) because it isn’t really a
> programming language. Should it have been a programming
:56 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 2:48 PM, Ed Jaffe wrote:
>
> If you are referring to the GameMaker Language (GML) then yes, JCL is
> clearly much, much worse...
>
> https://secur
U
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
>
> And that's the point...
>
> SR 14,14
> BR 15
>
> is easier and clearer than machine language, but
>
> main {}
>
> is (sorta) clearer than that.
>
> sas
>
> p.s. bonus points if you see what I di
And that's the point...
SR 14,14
BR 15
is easier and clearer than machine language, but
main {}
is (sorta) clearer than that.
sas
p.s. bonus points if you see what I did there ;-)
On Thu, Jul 12, 2018 at 9:19 AM, John Eells wrote:
> Ed Jaffe wrote:
>
>> On 7/11/2018 4:04 PM, Pew, Curtis
Ed Jaffe wrote:
On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
I don’t think it’s true that JCL is the worst programming language
(with all due respect to Fred Brooks) because it isn’t really a
programming language. Should it have been a programming language?
Almost certainly, as shown by Unix
On Jul 11, 2018, at 11:27 PM, Andrew Rowley
wrote:
>
> That's sort of true, but it vastly expands the competition. It makes HTML,
> even GML programming languages. Is JCL a worse programming language than GML?
>
That’s kind of how I meant it. I think of JCL as much closer to XML or JSON
On 12/07/2018 2:48 PM, Ed Jaffe wrote:
If you are referring to the GameMaker Language (GML) then yes, JCL is
clearly much, much worse...
https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/
No, Generalized Markup Language i.e. SCRIPT.
--
Andrew
On 7/11/2018 9:27 PM, Andrew Rowley wrote:
On 12/07/2018 2:05 PM, Ed Jaffe wrote:
With all due respect to whomever deserves it, ANY instructions
telling the computer what to do constitute programming...
That's sort of true, but it vastly expands the competition. It makes
HTML, even GML
On 12/07/2018 2:05 PM, Ed Jaffe wrote:
With all due respect to whomever deserves it, ANY instructions telling
the computer what to do constitute programming...
That's sort of true, but it vastly expands the competition. It makes
HTML, even GML programming languages. Is JCL a worse
On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
I don’t think it’s true that JCL is the worst programming language
(with all due respect to Fred Brooks) because it isn’t really a
programming language. Should it have been a programming language?
Almost certainly, as shown by Unix scripting
On 12/07/2018 11:47 AM, Paul Gilmartin wrote:
On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote:
Creating temporary files has its own security exposures. I am always
wary in case I am creating a security problem I don't understand.
You'd better not use SORT.
I am comfortable that the
On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote:
>
>Creating temporary files has its own security exposures. I am always
>wary in case I am creating a security problem I don't understand.
>
You'd better not use SORT.
-- gil
On 12/07/2018 10:46 AM, Paul Gilmartin wrote:
Is it any worse than if the processes operated sequentially; no overlap.
Second guy wins. Conscientious second guy will create the file with
O_EXCL. If you don't trust the second guy, lock him out with RACF profile
or file permissions.
It probably
On Thu, 12 Jul 2018 09:40:50 +1000, Andrew Rowley wrote:
>
>On a unix system, you can open a file for writing and another process
>can delete it while you have it open and create a new file with the same
>name. The file you are writing disappears when you close it.
>
That's a sort of LUW
On 12/07/2018 3:22 AM, John McKown wrote:
I've seen a lot of UNIX programs which implement the same concept using
shell environment variables. Simple, universal almost, examples are
${HOME}, ${TMPDIR} (and variants), ${CLASSPATH} for Javca, ${PATH} for an
//STEPLIB equivalent.
I have a PERL
On 12/07/2018 12:51 AM, Hobart Spitz wrote:
It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done.
Here is an example of something that is simple in JCL, but very
difficult to get right in a scripting language (i.e. 6 equivalent
On Jul 11, 2018, at 5:47 PM, Ed Jaffe wrote:
>
> I disagree. BASIC has iterations ('for' loops), forward and backward
> branching, and subroutine call/return. These fundamental programming language
> constructs are missing from JCL. This is why it's such a bad programming
> language.
I don’t
On 7/11/2018 3:16 PM, Paul Gilmartin wrote:
So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence. Provided BASIC is still viable; otherwise JCL
reclaims last place.
I disagree. BASIC has
On Wed, 11 Jul 2018 09:56:26 -0700, Tom Brennan wrote:
>I've always considered DD's one of the major differences between MVS and
>other platforms. I remember one of my first BASIC programs in college
>where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
>and sort. The first
On Wed, Jul 11, 2018 at 11:57 AM Tom Brennan
wrote:
> I've always considered DD's one of the major differences between MVS and
> other platforms. I remember one of my first BASIC programs in college
> where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
> and sort. The first
I've always considered DD's one of the major differences between MVS and
other platforms. I remember one of my first BASIC programs in college
where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
and sort. The first thing I thought of was, "So we have to update the
program
On Wed, 11 Jul 2018 11:40:19 -0400, Steve Smith wrote:
>Not sure if this was pointed out before, but DDNAMEs are required by z/OS
>access methods, not JCL. There is no reason these or dataset names need to
>be arguments just because REXX is used instead of JCL.
>
Most programs that don't expose
Not sure if this was pointed out before, but DDNAMEs are required by z/OS
access methods, not JCL. There is no reason these or dataset names need to
be arguments just because REXX is used instead of JCL.
DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a
bunch of
Andrew wrote:
>I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.
Then you haven't fully considered the alternatives. That's not a
criticism, just a statement of fact. How many of us really know how our
computers, cars, phones, bodies or
On Sun, Jul 1, 2018 at 12:12 PM Hobart Spitz wrote:
> )Why don't we just skip the JCL, and write our jobs in REXX? The two
>
> Here, here!! Actually, there is one thing that is critical to retiring
> JCL. It's a host command that allows a REXX program to list and wait for
> all it's datasets
On Sun, 1 Jul 2018 13:11:27 -0400, Hobart Spitz wrote:
>)Why don't we just skip the JCL, and write our jobs in REXX? The two
>
>Here, here!! Actually, there is one thing that is critical to retiring
>JCL. It's a host command that allows a REXX program to list and wait for
>all it's datasets
)Why don't we just skip the JCL, and write our jobs in REXX? The two
Here, here!! Actually, there is one thing that is critical to retiring
JCL. It's a host command that allows a REXX program to list and wait for
all it's datasets and their enqueues to be available. This is not trivial,
so
On 22/06/2018 11:21 AM, Steve Smith wrote:
Why don't we just skip the JCL, and write our jobs in REXX? The two
main things JCL does, EXEC and DD, are just as easy in REXX, (call,
alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are
lipstick for a pig.
I actually like JCL.
On Thu, 21 Jun 2018 21:21:56 -0400, Steve Smith wrote:
>My only point was the SET wasn't needed the way I used symbols. It's
>hardly any big deal if it's needed for library PROCs. The fact that
>there doesn't seem to be any obvious logical reason for it, is just one
>of things you take for
My only point was the SET wasn't needed the way I used symbols. It's
hardly any big deal if it's needed for library PROCs. The fact that
there doesn't seem to be any obvious logical reason for it, is just one
of things you take for granted with JCL.
Why don't we just skip the JCL, and
On Fri, 22 Jun 2018 10:34:54 +1000, Andrew Rowley
wrote:
>On 21/06/2018 11:05 PM, Steve Smith wrote:
>> I've gotten good results with the EXPORT before the PROC
>
>Which means the EXPORT needs to be in the calling job, not the PROC. My
>examples used inline PROCs for convenience, but I was
On 21/06/2018 11:05 PM, Steve Smith wrote:
I've gotten good results with the EXPORT before the PROC
Which means the EXPORT needs to be in the calling job, not the PROC. My
examples used inline PROCs for convenience, but I was trying to do it
with a PROC in a PROCLIB. If the EXPORT needs to
I've gotten good results with the EXPORT before the PROC, this example is
cut down from a working job:
//TSRCMHL1 JOB 1000,STEVE.SMITH,NOTIFY=,
// CLASS=C,MSGCLASS=X,COND=(1,LT)
// EXPORT SYMLIST=(PFX,VER,REL,FIX)
//HLDLIBS PROC PFX=RCM,VER=VV,REL=RR,FIX=TAC9
//AMS1EXEC
On 21/06/2018 12:28 PM, Paul Gilmartin wrote:
I believe that symbols assigned values in a PROC statement or in EXEC PRC=
are local to that PROC (and its children?) Symbols assigned values in a SET
statement within a PROC are global. Ugh! It may be better to eschew SET
within a PROC; rather
.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lucas Rosalen
> Sent: 21 June, 2018 9:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
>
> Thanks Kees, that's exactly what I
e which system will do
> what.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Lucas Rosalen
> > Sent: 21 June, 2018 8:57
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re:
Of Lucas Rosalen
> Sent: 21 June, 2018 8:57
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
>
> On the side topic...
>
> Based on our latest "experience":
> - without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR
On the side topic...
Based on our latest "experience":
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the
Andrew Rowley wrote:
>> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in
>> a JCL comment):
>> //* DELETE KVPO.MOST.DB2DATA.
>> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
>> SET MAXCC = 0
>Unfortunately that may not work because the symbols in SYSIN are not
>substituted the
> Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD
> SYMBOLS=, but it's pretty easy to just use it:
>
> // EXEC PGM=IEBGENER
> //SYSUT1 DD DATA,SYMBOLS=EXECSYS
> ...your job here
> /*
> //SYSUT2 DD SYSOUT=*
Or just use the logging-DDname option of the SYMBOLS= parameter.
On Thu, 21 Jun 2018 10:45:01 +1000, Andrew Rowley wrote:
>
>Unfortunately [ ... ] the symbols in SYSIN are not
>substituted the same way as in the regular JCL. I have been playing
>around with them and my conclusion is that the whole feature seems to
>have been badly thought out.
>
Yes.
>-
On 20/06/2018 8:53 PM, Elardus Engelbrecht wrote:
Easy, a quick and dirty trick I sometimes do is this little change:
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.
SET MAXCC = 0
to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a
JCL comment):
//*
On Wed, 20 Jun 2018 18:35:01 -0400, Steve Smith wrote:
>Actually, the upshot is exactly not that. Symbols in SYSIN are always
>resolved when requested by SYMBOLS=. The program that reads that SYSIN
>never sees any symbols.
>
>The 2nd parm of SYMBOLS is a DDname for a substitution report. I
Actually, the upshot is exactly not that. Symbols in SYSIN are always
resolved when requested by SYMBOLS=. The program that reads that SYSIN
never sees any symbols.
The 2nd parm of SYMBOLS is a DDname for a substitution report. I would
have assumed you'd get that regardless, but evidently, the
...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: Wednesday, June 20, 2018 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Using JCL Symbld and TYPRUN=SCAN
Well, I think "amazing" ma
nks,
> Kolusu
>
> IBM Mainframe Discussion List wrote on
> 06/20/2018 10:26:15 AM:
>
> > From: Elardus Engelbrecht
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 06/20/2018 10:27 AM
> > Subject: Re: Using JCL Symbld and TYPRUN=SCAN
> > Sent by: IBM Mainframe
RV.UA.EDU
> Date: 06/20/2018 10:27 AM
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
> Sent by: IBM Mainframe Discussion List
>
> Sri h Kolusu wrote:
>
> >If you are interested to see the symbol substitution then you can
> use the EZACFSM1 symbol translator utility.
>
Of Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
EXTERNAL EMAIL
Sri h Kolusu wrote:
>If you are interested to see the symbol substitution then you can use the
>EZACFSM1 symbol translator utility.
My oh my!
I learned something very useful here...thanks, Kolusu!
On Wed, Jun 20, 2018 at 1:26 PM Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> Sri h Kolusu wrote:
>
> >If you are interested to see the symbol substitution then you can use the
> EZACFSM1 symbol translator utility.
>
> My oh
Sri h Kolusu wrote:
>If you are interested to see the symbol substitution then you can use the
>EZACFSM1 symbol translator utility.
My oh my! That is amazing!
Where is that EZACFSM1 thing documented?
I really appreciate your most helpful reply. I am really humbled by your kind
reply. I
>> Do you know of a way to check the parameter substitution in DD *?
If you are interested to see the symbol substitution then you can use the
EZACFSM1 symbol translator utility. Once you have verified the symbols are
substituted correctly then you can route that to a dataset and use that as
: Re: Using JCL Symbld and TYPRUN=SCAN
Thanks,
Do you know of a way to check the parameter substitution in DD *?
Gadi
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re
That's a good way to bypass it
Thanks
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Gadi Ben-Avi wrote:
>Do you know of a
Elardus Engelbrechtwrote:
>>Do you know of a way to check the parameter substitution in DD *?
>Easy, a quick and dirty trick I sometimes do is this little change:
>//SYSIN DD *,SYMBOLS=(JCLONLY,X)
> DELETE KVPO.MOST.DB2DATA.
>SET MAXCC = 0
>to this one (clear out the SYSIN - at least for IDCAMS
Gadi Ben-Avi wrote:
>Do you know of a way to check the parameter substitution in DD *?
Easy, a quick and dirty trick I sometimes do is this little change:
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.
SET MAXCC = 0
to this one (clear out the SYSIN - at least for IDCAMS SYSIN and
I have had to do the indirection described in this document to make it work.
http://www-01.ibm.com/support/docview.wss?uid=isg1OA47958
Alan
From: Gadi Ben-Avi
Sent: Tuesday, June 19, 2018 22:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using JCL Symbld and
Thanks,
Do you know of a way to check the parameter substitution in DD *?
Gadi
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Gadi
Gadi Ben-Avi wrote:
>The variables in the IDCAMS DELETE statement were not substituted.
>When I ran the job without TYPRUN=SCAN, the variables were substituted.
>Is there a way to have the variables get substituted, without actually running
>the job.
No. This is both WAD and BAD. In the JCL Ref
64 matches
Mail list logo
