Basic question on passing JCL set symbol to proc
Charles Mills
I've got a PROC that says
//CBCC PROC INFILE=,
// CRUN=,
// CPARM=,
.
and
//COMPILE EXEC PGM=CCNDRVR,REGION=&CREGSIZ,
// PARM=('&CRUN/CXX &CPARM')
I had the bright idea of coding a SET symbol
// SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG'
And then invoking the proc with
//COMPMAIN EXEC CBCC,CPARM='&OPTS'
Unfortunately, all the program sees is effectively PARM='/CXX &OPTS" - a
literal "&OPTS" rather than my set symbol. I've tried a couple of variations
but to no avail.
How do I pass a set symbol as a parm to a proc?
Thanks and apologies in advance.
Charles Mills
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Steve Comstock
> I apologize for a very basic question. I'm a developer; not a PROC guy.
>
>
>
> I've got a PROC that says
> //CBCC PROC INFILE=,
> // CRUN=,
> // CPARM=,
>
>
> and
>
> //COMPILE EXEC PGM=CCNDRVR,REGION=&CREGSIZ,
> // PARM=('&CRUN/CXX &CPARM')
>
> I had the bright idea of coding a SET symbol
>
> // SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG'
>
> And then invoking the proc with
>
> //COMPMAIN EXEC CBCC,CPARM='&OPTS'
>
> Unfortunately, all the program sees is effectively PARM='/CXX &OPTS" - a
> literal "&OPTS" rather than my set symbol. I've tried a couple of variations
> but to no avail.
>
>
>
> How do I pass a set symbol as a parm to a proc?
>
//COMPMAIN EXEC CBCC,CPARM=&OPTS
should do it, I would think.
>
>
> Thanks and apologies in advance.
>
>
>
> Charles Mills
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
Charles Mills
STMT NO. MESSAGE
4 IEFC620I UNIDENTIFIABLE CHARACTER u ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER t ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER c ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER c ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER v ON THE EXEC STATEMENT
Charles
//COMPMAIN EXEC CBCC,CPARM=&OPTS
----------------------------------------------------------------------
Paul Gilmartin
>Thanks! That was one of the variations I tried. Fails on a JCL error:
>
Tough!:
5.4.4.3 "z/OS V1R10.0 MVS JCL Reference"
5.4.4.3 Coding Symbols in Apostrophes
You can code symbols in apostrophes
on the following keywords:
* The DD statement AMP parameter
* The DD statement PATH parameter
* The DD statement SUBSYS parameter
* The EXEC statement ACCT parameter
* The EXEC statement PARM parameter.
(and no other. -- gil)
Your problem in this instance is that JCL makes the colossal
design blunder of interpreting metacharacters _after_
symbol substitution. Rexx, for example, knows better.
I hate JCL!
Whenever I want to do anything serious, I keep my JCL as a
here-document in a POSIX shell script. The designers of shell
gave some consideration to what programmers need to do. The
designers of JCL apparently wanted only to collect their
paychecks and go home on Friday evening.
-- gil
Paul Gilmartin
>
>//COMPILE EXEC PGM=CCNDRVR,REGION=&CREGSIZ,
>// PARM=('&CRUN/CXX &CPARM')
>
>I had the bright idea of coding a SET symbol
>
>// SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG'
>
>And then invoking the proc with
>
>//COMPMAIN EXEC CBCC,CPARM='&OPTS'
>
>Unfortunately, all the program sees is effectively PARM='/CXX &OPTS" - a
>literal "&OPTS" rather than my set symbol. I've tried a couple of variations
>but to no avail.
>
// SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG',
Q=''''
And then invoking the proc with
//COMPMAIN EXEC CBCC,CPARM=&Q&OPTS&Q
This is still guaranteed to fail if the value assigned to &OPTS
contains an apostrophe. You might have to double it again.
I hate JCL!
Shane
> Your problem in this instance is that JCL makes the colossal
> design blunder of interpreting metacharacters _after_
> symbol substitution. Rexx, for example, knows better.
>
> I hate JCL!
>
> Whenever I want to do anything serious, I keep my JCL as a
> here-document in a POSIX shell script. The designers of shell
> gave some consideration to what programmers need to do.
Mmmm - I often need to pass (environment/shell) variables through to
called programs via the shell; along with globbing to be resolved by the
called.
Certainly not always intuitive to this little black duck ...
Shane ...
Mike La Martina
Did you know that Windows Media player can slow down music without
changing its pitch?
Google for the instructions.
I don't buy anything from the Andreas site, but I do like her approach
to teaching.
And yes, I was referring to Bill Alexander. I could not recall his name.
Thanks for the complement, but after all we did work together, and did
owe each other professional respect.
I have been on vacation since December 23 and this is my last day. I
have to gear back up for the grind tomorrow.
Lucky you, but luck has little to do with it.
Mike
Paul Gilmartin
>
>Mmmm - I often need to pass (environment/shell) variables through to
>called programs via the shell; along with globbing to be resolved by the called.
>Certainly not always intuitive to this little black duck ...
>
resolution by the shell. Otherwise shell always resolves globbing
and passes a list of resolved names to the called program.
I don't believe I see you on MVS-OE, although it appears you have a
question that might well be asked there.
Otherwise, this thread has just drifted in another ply far worse
than you or I could ever manage.
-- gil
Steve Comstock
> On Sat, 2 Jan 2010 18:08:21 -0800, Charles Mills wrote:
>
>> Thanks! That was one of the variations I tried. Fails on a JCL error:
>>
> Tough!:
>
> 5.4.4.3 "z/OS V1R10.0 MVS JCL Reference"
> 5.4.4.3 Coding Symbols in Apostrophes
>
> You can code symbols in apostrophes
> on the following keywords:
> * The DD statement AMP parameter
> * The DD statement PATH parameter
> * The DD statement SUBSYS parameter
> * The EXEC statement ACCT parameter
> * The EXEC statement PARM parameter.
>
> (and no other. -- gil)
>
> Your problem in this instance is that JCL makes the colossal
> design blunder of interpreting metacharacters _after_
> symbol substitution. Rexx, for example, knows better.
>
> I hate JCL!
>
> Whenever I want to do anything serious, I keep my JCL as a
> here-document in a POSIX shell script. The designers of shell
> gave some consideration to what programmers need to do. The
> designers of JCL apparently wanted only to collect their
> paychecks and go home on Friday evening.
>
> -- gil
Ah, that's it. The places where I tend to use symbolics
and lower case are in PATH parameters.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
Clark Morris
>On Sun, 3 Jan 2010 17:01:28 +1000, Shane wrote:
>>
>>Mmmm - I often need to pass (environment/shell) variables through to
>>called programs via the shell; along with globbing to be resolved by the called.
>>Certainly not always intuitive to this little black duck ...
>>
>Example? C-shell or POSIX shell? ", \, or ' always prevent globbing
>resolution by the shell. Otherwise shell always resolves globbing
>and passes a list of resolved names to the called program.
>
>I don't believe I see you on MVS-OE, although it appears you have a
>question that might well be asked there.
>
>Otherwise, this thread has just drifted in another ply far worse
>than you or I could ever manage.
JCL was designed for OS360 on a 256K real machine (the original design
point for PCP was 64K). In addition, I suspect that the design was
done by engineers or mathematicians for whom "not and" and "not or"
were familiar concepts. Virtually all of the printers were upper case
only and at least in my shop it was a struggle to get a printer that
printed the special characters correctly (the 48 character train was
adequate FSVO adequate). Lower case was out of the question. Memory
and instruction cycles were at a premium. Even on a 1 megabyte mod 65
we were stingy about region sizes.
While I share your (Paul's) distaste for JCL, the crime is that IBM
hasn't provided a clear migration path for at least new things to
either REXX or one of the shells. It also hasn't provided a migration
path so that we could have longer member names, longer data set names
and a generation data set facility for ESDS data sets. We are stuck
on software architecture that was designed for the limitations of the
original 360's using work arounds and kludges. It is for this reason
that I am not optimistic about the long term viability of the z series
and z/OS.
P S
<snip>
> It is for this reason
> that I am not optimistic about the long term viability of the z series
> and z/OS.
>
Well, zSeries is dead, so it has no long-term viability.
Yes, I'm being pedantic about the terminology -- but if WE don't get it
right, then we don't get to complain when the press farbles something about
mainframes, eh?
Paul Gilmartin
>
>JCL was designed for OS360 on a 256K real machine (the original design
>point for PCP was 64K). In addition, I suspect that the design was
>done by engineers or mathematicians for whom "not and" and "not or"
>were familiar concepts. Virtually all of the printers were upper case
>only and at least in my shop it was a struggle to get a printer that
>printed the special characters correctly (the 48 character train was
>adequate FSVO adequate). Lower case was out of the question. Memory
>and instruction cycles were at a premium. Even on a 1 megabyte mod 65
>we were stingy about region sizes.
>
subroutines. A reusable lexical analysis subroutine would have
alleviated the memory constraint while supporting resolution of
symbols wherever they appear (but perhaps not in SYSIN, which is
a different matter).
Does anyone know a plausible design rationale for the current
restrictions on symbol substitution?
Rather, I ascribe it to Conway's law at its perniciousest. Design
and coding of parsers for the various JCL operands was parceled out
to different programmers. Each could decide independently whether
to support symbol substitution. Since there was (apparently) no
reusable lexical analysis subroutine, support for symbol substitution
would have required considerable extra code in each context, and
was provided only where the need was most urgent.
>While I share your (Paul's) distaste for JCL, the crime is that IBM
>hasn't provided a clear migration path for at least new things to
>either REXX or one of the shells. It also hasn't provided a migration
Rexx, I'd say. Once again, the deficiencies I perceive in Rexx are:
o Lack of a bulk ENQ with WAIT facility to prevent deadlocks, one
thing JCL does well.
o Lack of support for APF authorized subcommands, though this can
mostly be achieved when Rexx runs under the TSO TMP.
o (For me particularly) Lack of support for multi-file tapes by
keyword/constructs such as RETAIN, PASS, and VOL=REF.
>path so that we could have longer member names, longer data set names
The longer names are available in the Unix filesystems. A plausible
migration path would be providing for migration of enterprise data
into Unix filesystems.
>and a generation data set facility for ESDS data sets. We are stuck
>on software architecture that was designed for the limitations of the
>original 360's using work arounds and kludges. It is for this reason
Most of that last is more fundamental than JCL.
>that I am not optimistic about the long term viability of the z series
>and z/OS.
>
I wonder if IBM is listening? I wonder if IBM doesn't see it a
sounder business position to cannibalize rather than nurture z/OS?
-- gil
Steve Comstock
Cool! I'm working on an utility to do that! In a month or two I
could use some beta testers.
>
>> and a generation data set facility for ESDS data sets. We are stuck
>> on software architecture that was designed for the limitations of the
>> original 360's using work arounds and kludges. It is for this reason
>
> Most of that last is more fundamental than JCL.
>
>> that I am not optimistic about the long term viability of the z series
>> and z/OS.
>>
> I wonder if IBM is listening? I wonder if IBM doesn't see it a
> sounder business position to cannibalize rather than nurture z/OS?
>
> -- gil
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
Lindy Mayfield
I tell my students, OS/360 Job Control Language is the worst programming language ever designed anywhere by anybody for any purpose and it was done under my management. Why is it? Well, I think there is an important take home lesson for us all in it. One is, it is one job control language for all six of these programming languages. Whereas what you really want is a schedule time operation in whatever language you're working in. Just like you have compile time operations in whatever language you're working in. Then at the very time we were moving the whole world to high level languages, such that at our computing center at Chapel Hill the year after the 360s were operating, only 1 percent of the jobs that ran were assembler, 99 percent were in high level languages, but the JCL was modeled on assembler rather than any of the high level languages. But it wasn't exactly like the assembler. And it was card column dependent. Column 73 was magic. And for years afterwards you sit do!
wn to a terminal and you wonder why column 73. Well it had to do with the fact that the cards on a 701 read in two sets of 36 bits and that used 72 columns. And JCL still preserves this column dependence. JCL was designed to have only six verbs. Well it turns out a schedule time language needs more than six verbs. But it was an article of faith that we were only going to have six verbs and so we put all the verby things into declarations. The DD cards do all the verby things, and parameters. The language has awkward, possible but awkward branching. It has no clean iteration, no for statement. No clean subroutine call. It is not really a good programming language. In fact it is the worst programming language. Now, how did a smart bunch of people get into this mess? This is where the lesson is: We did not see it as a programming language. From the beginning it was seen as a few control cards that would go in front of your deck. Anybody seen a JCL deck recently? They are norma!
lly known as a "dusty" deck. Why is it a dusty deck? Because you get s
omeone else's and you darst not change it. Why is it a deck? Because there are a lot of control cards by the time you get all these DD's and declarations and verby things in. But we didn't see it as a programming language. We saw it as a few control cards. And the other thing is, that it wasn't designed -- we had very good programming language designers, and they designed some very good programming languages, Fortran 6, Fortran H, PL/1, an improved RPG, various other improved programming languages -- but this was not tackled that way. Instead it just grew a parameter here, and a parameter there. So many things were done so right, and every now and then something was really royally messed up with superb competence.
Paul Gilmartin
>I transcribed this from a talk given by Fred Brooks, Jr. on the 40th
>year anniversary of the System 360. This is a wonderful talk given
>by the people who were involved in the original design, recorded >
at the Computer History Museum. This is what Fred Brooks said about JCL:
>
>I tell my students, OS/360 Job Control Language is the worst
>programming language ever designed anywhere by anybody for any
>purpose and it was done under my management.
>
Don't brag; it's always possible to do worse.
>Whereas what you really want is a schedule time operation in whatever
>language you're working in.
>
Here, I strongly disagree. This is the C-shell blunder. You want
a langage suited to the problem. C-shell attempts to do scripting
with a C-like flavor. JCL attempts to do scheduling with an
assembler-like flavor. Both are misguided in the choice of objective.
>but the JCL was modeled on assembler rather than any of the high
>level languages. But it wasn't exactly like the assembler. And it
>was card column dependent. Column 73 was magic. And for years
>afterwards you sit down to a terminal and you wonder why column
>73. Well it had to do with the fact that the cards on a 701 read
>in two sets of 36 bits and that used 72 columns. And JCL still
>preserves this column dependence.
> ...
>The language has awkward, possible but awkward branching. It has
>no clean iteration, no for statement. No clean subroutine call.
>It is not really a good programming language.
>
Some of this is deliberate. The enterprise run scheduling model
requires things to be static in a scheduler that can be dynamic
in programming languages for other purposes. Its objectives make
JCL more like a macro processor than a programming language, but
it failed to incorporate much of the current assembler's macro
processing capability. And neither JCL nor HLASM conditional
assembly has graceful branching nor clean iteration.
>So many things were done so right, and every now and then something
>was really royally messed up with superb competence.
>
The tragedy is that in 40 years no one undertook to fix it.
-- gil
Lindy Mayfield
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
Sent: 3. tammikuuta 2010 23:51
To: IBM-...@bama.ua.edu
Subject: Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc
>Whereas what you really want is a schedule time operation in whatever
>language you're working in.
>
Here, I strongly disagree. This is the C-shell blunder. You want
a langage suited to the problem. C-shell attempts to do scripting
with a C-like flavor. JCL attempts to do scheduling with an
assembler-like flavor. Both are misguided in the choice of objective.
----------------------------------------------------------------------
Paul Gilmartin
>>
>>> path so that we could have longer member names, longer data set names
>>
>> The longer names are available in the Unix filesystems. A plausible
>> migration path would be providing for migration of enterprise data
>> into Unix filesystems.
>
>Cool! I'm working on an utility to do that! In a month or two I
>could use some beta testers.
>
thinking that Classic data management should have enhanced
capabilities for using Unix files. This is the sense of the PATH=
operand in JCL and the more recent BPAM (read only; no DESERV)
support for z/OS Unix directories. The next big step might be
to have a Unix directory tree replacing the VTOC and catalog, with
Classic CKD data sets as the leaves. This would open the larger
Unix namespace, but provide compatibility and performance of
Classic access methods and EXCP once the data sets were opened.
I suspect you, OTOH, are working on a utility to copy Classic data
sets to Unix files.
Yah, I know either scheme leaves gaps to be filled concerning
security, integrity, and serialization.
-- gil
Paul Gilmartin
>what does he mean by "... a schedule time operation..."? what does that mean?
>
In the Bad Old Days, the production administrators would provide to
operations a handwritten Run Sheet for each job, specifying resources
such as expected execution time, storage requirements, number of
tape drives, and volumes to be mounted on each. The operators would
arrange these so that at no point were the available resources
overcommitted, the pass them on to the tape ape who would run up and
down the aisles pulling tapes and stacking them on a cart in the order
that jobs would need them.
JCL automated some of this. TMS, JES3 Setup, and automated tape libraries
did more.
Charles Mills
didn't know what I was doing. I thought one of you would say "you dummy --
you need to double the apostrophes and put it all in parentheses" or
something like that.
I "solved" the problem by splitting it in two. I was able to get the lower
case letters out of there by moving the information to a //SYSLIB DD PATH=
statement. Now the solution to the rest of the problem is just
// SET OPTS=(NOTEMPL,OE,OBJ,NOARG)
. . .
//COMPMAIN EXEC CBCC,CPARM=&OPTS
(In case anyone was wondering why I wanted to take a perfectly good PARM=
parameter and make it into a problematic SET symbol: there are multiple
compile jobsteps in the job and I got tired of changing the compile PARM= in
more than one place. Also, this way I can readily alternatively comment out
or use various sets of compile options. I might also use set symbols for
multiple sets of compile options that I could concatenate together as
appropriate -- but you have to save some fun for another day.)
Charles
Charles Mills
>>programming language ever designed anywhere by anybody for any
>>purpose and it was done under my management.
>Don't brag; it's always possible to do worse.
I recall that DOS/360 had a series of file-to-file utilities (no device
independence so you needed a disk to tape utility, a card to tape utility, a
tape to disk utility, ...) whose control card syntax was way worse than
OS/360 JCL. DOS/VSE JCL is arguably worse than OS/MVS JCL: the DLBL
statement with its umpteen positional parameters makes the DD statement look
downright user-friendly. And VSE is much more dependent on POWER control
cards than MVS is on JES control cards, and the syntax is totally different
from JCL -- JES statements are at least closer to JCL in syntax.
And anyone else ever write IV-Phase assembler? 5-character symbols, of which
only three (24 bit word machine) were significant, so NOTAG was the same
symbol as NOTUP. And it did not flag duplicates, it just silently redefined
the symbol. Nor did it flag undefined symbols -- just passed them to the
linker as externs. The JCL was pretty bad too ...
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Sunday, January 03, 2010 1:51 PM
To: IBM-...@bama.ua.edu
Subject: Re: Why is JCL so bad was Re: Basic question on passing JCL set
symbol to proc
Paul Gilmartin
>
>I recall that DOS/360 had a series of file-to-file utilities (no device
>independence so you needed a disk to tape utility, a card to tape utility, a
>tape to disk utility, ...)
>
Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the number of z/OS
utilities that balk at "DD PATH=...", not because their QSAM calls couldn't
perfectly well handle it, but merely because they're afraid to try.
>And anyone else ever write IV-Phase assembler? 5-character symbols, of which
>only three (24 bit word machine) were significant, so NOTAG was the same
>
Someone should have introduced them to RADIX50. But I always disapprove
of quiet truncation.
>symbol as NOTUP. And it did not flag duplicates, it just silently redefined
>the symbol. Nor did it flag undefined symbols -- just passed them to the
>linker as externs.
>
They could have got that idea from C (or perhaps vice-versa). But I
once wrote a very simple minded assembler that flagged duplicate
definitions only if the values differed. And JCL and Rexx both
leave an undefined symbol as it appeared in the source, with no
warning. And POSIX shell expands the containing string as if the
symbol weren't there at all. All irresponsible, IMO.
-- gil
Charles Mills
had to go to Gil's
// SET Q=''''
// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
//COMPMAIN EXEC CBCC,CPARM=&Q&OPTS&Q
Ugly? Whew!
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Sunday, January 03, 2010 2:33 PM
To: IBM-...@bama.ua.edu
Rick Fochtman
So that's where CMS got that idea. But z/OS device independence is
eroding. Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than
just doing QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the
number of z/OS utilities that balk at "DD PATH=...", not because their
QSAM calls couldn't perfectly well handle it, but merely because they're
afraid to try.
I've used QSAM, BSAM, TPUT/TGET and PUTLINE/GETLINE quite successfully
for terminal I/O under TSO for a wide variety of applications. Each has
advantages and disadvantages; none is "perfect".
Making generalizations is always a risky process; let's not make them
too widespread. Device independance is alive and well; it just requires
a certain amount for forethought in how the application might be used.
I'm sure that many, if not all, of us have used the so-called "batch
utilities" in the foreground, and some of us have wanted to use
foreground processors in the background. How easy or hard these might be
is very much dependant on the forethought of the designer/coder.
Rick
---
Unless you're the lead dog, the view never changes.
Gerhard Postpischil
>> the symbol. Nor did it flag undefined symbols -- just passed them to the
>> linker as externs.
>>
> They could have got that idea from C (or perhaps vice-versa). But I
> once wrote a very simple minded assembler that flagged duplicate
> definitions only if the values differed. And JCL and Rexx both
> leave an undefined symbol as it appeared in the source, with no
> warning. And POSIX shell expands the containing string as if the
> symbol weren't there at all. All irresponsible, IMO.
I doubt it. Treating undefined as externals was alive and well
on the 709/7090/7094 assemblers.
And it was a feature - none of those wimpy EXTRN/WXTRNs to worry
about <g>
Gerhard Postpischil
Bradford, VT
des...@verizon.net
> And neither JCL nor HLASM conditional
> assembly has graceful branching nor clean iteration.
JCL has forward branching thru condition codes and nested procs are a
little like a subroutine call.
HLASM is in another league entirely with forward and backward branching,
loop counts, nesting, arrays, global variables, etc.
What's ungraceful or unclean about HLASM?
Anne & Lynn Wheeler
PaulGB...@AIM.COM (Paul Gilmartin) writes:
> So that's where CMS got that idea. But z/OS device independence is eroding.
> Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
> QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the number of z/OS
> utilities that balk at "DD PATH=...", not because their QSAM calls couldn't
> perfectly well handle it, but merely because they're afraid to try.
a lot of CMS design reflects CTSS heritage. CMS then adopted a lot of
os/360 applications ... and therefor had to do a layer of OS/360
simulation (especially for assembler and compilers).
more information ... cp67/cms version 3 (oct70) users guide:
http://www.bitsavers.org/pdf/ibm/360/cp67/GH20-0859-0_CP67_Version_3_Users_Guide_Oct70.pdf
os macros .... pg 294
Later after the moph to vm370/cms (and cambridge monitor system renamed
conversational monitor system) ... there was some amount of DOS
simulation also added. There was also some joke about CMS 32kbyte
os/360 simulation code ... did almost as good as the 8mbyte mvs os/360
simulation code.
The biggest change from cp67/cms to vm370/cms ... was reorging the
kernel with application program loading at x'12000' to take advantage of
(original) 370 (64k) r/o shared segment support. Application programs
then were moved to starting at x'20000' ... and cms kernel "shared code"
moved to start at segment boundary at x'10000' (segment 0 was then data
and non-shared code ... since virtual page zero couldn't be shared, and
therefor virtual segment 0 couldn't be shared).
however, all the effort came to *NOT* ... before the full 370 virtual
memory architecture could be announced and shipped ... retrofitting the
full 370 virtual memory architecture to 370/165 ran into all sorts of
problems. 165 petitioned for dropping several features to gain back a
lot of the schedule; and one of the things dropped was 370 r/o shared
segment support. that forced m370 to quickly come up with a quick&dirty
hack using storage protection keys ... to simulate the original 370
virtual memory r/o segment protect.
with the addition of dos simulation ... for running dos programs in cms
... there then had to be option to specify whether non-cms service
requests went thru os simulation or dos simulation ... aka "set dos on"
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/topic/com.ibm.zvm.v54.dmsa5/hcsd2b00514.htm
in the wake of demise of FS and the head of POK convincing corporate to
kill vm370, shutdown the burlington development group and moving all the
people to POK (justification was that otherwise wouldn't be able to make
mvs/xa ship schedule) .... there was joke that head of POK was major
contributor to vax/vms (i.e. the people that didn't move to pok ... but
went to DEC to work on vax/vms); endicott eventually was able to obtain
the vm370 product mission ... but had to reconstitute the organization
from scratch.
the issue here was that one of the people in burlington (that didn't
move to pok) had done a pretty complete os disk i/o routines for os disk
r/w, vtocs, handle most kinds of files, understood and could process
PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but
supported full os/360 operation on os/360 disks). All of that
evaporated/disappeared with the shutdown of burlington development
group.
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
McKown, John
Relative to this is the internal control blocks created via JCL need to stay the same, or very similar. Why? We couldn't use the new if CA-11 doesn't support it. That is why we don't use UNIX and REXX stuff. CA-11 doesn't support restarting complex shell scripts or REXX programs. I guess doing that would require something akin to checkpoint restart for compiled programs. And who uses that???
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Clark Morris
> Sent: Sunday, January 03, 2010 9:28 AM
> To: IBM-...@bama.ua.edu
> Subject: Why is JCL so bad was Re: Basic question on passing
> JCL set symbol to proc
>
> On 3 Jan 2010 06:49:27 -0800, in bit.listserv.ibm-main you wrote:
<snip>
Shmuel Metz , Seymour J.
at 12:48 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Your problem in this instance is that JCL makes the colossal design
>blunder of interpreting metacharacters _after_
>symbol substitution. Rexx, for example, knows better.
There are two ways to design syntax for symbol substitution; expressions
and interpolation. Rexx uses the former, and has no need to recognize
metacharacters inside quoted strings, other than recognizing doubled
framing characters. JCL, like BASH, CLIST, Perl and Script, uses
interpolation. Each approach has advantages and disadvantages.
The blunders in JCL, IMHO, are not in the design but in implementation
details, e.g., the default for SPACE=.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
hanc...@bbs.cpcn.com
> the issue here was that one of the people in burlington (that didn't
> move to pok) had done a pretty complete os disk i/o routines for os disk
> r/w, vtocs, handle most kinds of files, understood and could process
> PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but
> supported full os/360 operation on os/360 disks). All of that
> evaporated/disappeared with the shutdown of burlington development
> group.
Per the question of the subject line, I believe the original developer
of JCL, Mr. Brooks, himself said it was a lousy language but it was
the best they could do under the circumstances of rushed development
of a complex new idea. ("The birth of a baby will take nine months no
matter how many women are assigned", and "Adding more people to a late
project will only make it later.")
Considering the incredibly many options and internal communications
shortcuts, it is pretty powerful. However, I'd rather spell things
out than depend on backward references, especially in procs, for ease
in understanding. Some of the substitution options in procs can get
confusing.
JCL includes a way to check the 'condition code' of a prior step.
Most of the time it's to see merely that a prior step didn't abend.
But all sorts of convoluted logic can be done on the COND= clause
which are very hard to understand.
Anne & Lynn Wheeler
> Per the question of the subject line, I believe the original developer
> of JCL, Mr. Brooks, himself said it was a lousy language but it was
> the best they could do under the circumstances of rushed development
> of a complex new idea. ("The birth of a baby will take nine months no
> matter how many women are assigned", and "Adding more people to a late
> project will only make it later.")
re:
http://www.garlic.com/~lynn/2010.html#22 Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc
the thread originated in ibm-main ... and I added in a.f.c. earlier in
the (ibm-main) part of the thread there. can be viewed in google groups:
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/8fb4c75d62fc6353/b31fc2570a47f078?q=why+is+jcl+so+bad+group:bit.listserv.ibm-main#b31fc2570a47f078
one of the earlier posts (by somebody else) starts out with:
I transcribed this from a talk given by Fred Brooks, Jr. on the 40th
year anniversary of the System 360. This is a wonderful talk given by
the people who were involved in the original design, recorded at the
Computer History Museum. This is what Fred Brooks said about JCL:
... snip ...
and then goes on for a couple paragraphs
Frank Swarbrick
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
On 1/3/2010 at 4:25 PM, in message <00fb01ca8ccb$f99b8890$ecd299b0$@org>,
>>>
The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
Shmuel Metz , Seymour J.
01/03/2010
at 07:01 PM, Lindy Mayfield <lindy.m...@SSF.SAS.COM> said:
>This is what Fred Brooks said about JCL:
As in his book, there are statements there that suggest he was not in
touch with his own projects.
>Whereas what you really want is a schedule time operation in whatever
>language you're working in.
That, of course, assumes that the job only uses programs written in a
single language.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 11:08 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Does anyone know a plausible design rationale for the current
>restrictions on symbol substitution?
The fact that things were added after the original design, including
symbols.
>Rather, I ascribe it to Conway's law at its perniciousest. Design and
>coding of parsers for the various JCL operands was parceled out to
>different programmers. Each could decide independently whether to
>support symbol substitution.
Most of the coding was done before there were symbols.
>Once again, the deficiencies I perceive in Rexx are:
OS issues rather than REXX issues. If z/OS had the suuport it would be
easy for Rexx to exploit it.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 11:28 AM, Clark Morris <cfmp...@NS.SYMPATICO.CA> said:
>JCL was designed for OS360 on a 256K real machine (the original design
>point for PCP was 64K).
256 KiB? We ran OS/360 PCP on a 128 KiB machine[1]. With 256 KiB we were
able to run MFT II for production.
> Virtually all of the printers were upper case
>only and at least in my shop it was a struggle to get a printer that
>printed the special characters correctly
Why? The TN train was available[2] for the 1403-N1. Did you have only 1443
printers or 1403 printers older than the Nancy One?
>Lower case was out of the question.
Why?
[1] Well, we did IPL on a 64 KiB machine, but not for production.
[2] Yes, it was slower than AN, HN or PN.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 05:56 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
>QSAM I/O to SYSTSPRT and SYSTSIN?
Because they provide functionality not present in QSAM.
>And JCL and Rexx both leave an undefined symbol as it appeared in
>the source, with no warning.
The first is necessary because symbols were an afterthought and IBM
overloaded the & when they added symbols. Both behaviors are actually
useful.
I take it that you adhere to the philosophy of always enabling NOVALUE in
Rexx?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Paul Gilmartin
>
>>coding of parsers for the various JCL operands was parceled out to
>>different programmers. Each could decide independently whether to
>>support symbol substitution.
>
>Most of the coding was done before there were symbols.
>
without symbols. Or was everything done with overrides?
>>Once again, the deficiencies I perceive in Rexx are:
>
>OS issues rather than REXX issues. If z/OS had the suuport it would be
>easy for Rexx to exploit it.
>
For most of what I cited, JCL/initiator exploits it. That
suggests that something is in initiator that would more properly
be in allocation.
-- gil
jcrud
Clark Morris
>In <a6d1k5hsqsjkmo5c9...@4ax.com>, on 01/03/2010
> at 11:28 AM, Clark Morris <cfmp...@NS.SYMPATICO.CA> said:
>
>>JCL was designed for OS360 on a 256K real machine (the original design
>>point for PCP was 64K).
>
>256 KiB? We ran OS/360 PCP on a 128 KiB machine[1]. With 256 KiB we were
>able to run MFT II for production.
>
>> Virtually all of the printers were upper case
>>only and at least in my shop it was a struggle to get a printer that
>>printed the special characters correctly
>
>Why? The TN train was available[2] for the 1403-N1. Did you have only 1443
>printers or 1403 printers older than the Nancy One?
The trains were available. The management desire for the fastest
print speed dictated the 48 character chain. I think that it was the
1980's before we got the QNC chain which had 60 characters where 45 of
them were in all of the sets (5 I think) and 15 were scattered 3 to a
set. The name and exact details are subject to hazy recollection. In
any case the problems with obtaining the chains were management
objectives and values, not technical ones.
>
>>Lower case was out of the question.
>
>Why?
Low print speed, no programs to take advantage of it and no perceived
business value.
>
>[1] Well, we did IPL on a 64 KiB machine, but not for production.
>
>[2] Yes, it was slower than AN, HN or PN.
>
----------------------------------------------------------------------
P S
> The trains were available.
>
...and Mussolini made them run on time!
(OK, I'm guessing that isn't the first time that joke has been made...)
Clement Clarke
> The tragedy is that in 40 years no one undertook to fix it.
> -- gil
>
>
>
replacement language called Jol. By 1973, it was re-written in
Assembler, and ran in 60K, just like the then JCL processor.
The real tragedy for users and the Z Series itself is that so few people
know it. And that IBM haven't supported it.
_______________
The language solves many of the problems that have been mentioned in
this newsgroup. It is totally free-form, has full symbolic variable
processing (testing, replacing, etc), a superb macro system, IF
statements, symbolic parameter replacements in "card files" - and much,
much more.
There is, for example, a Copy command that will copy various types of
files (SEQ, PDS, VSAM etc) and call in the appropriate IBM or other
utility to do the copy.
You can make a 3270 style "panel" using a simple Panel instruction. It
can create Menubars and Pulldown lists, similar to Windows or Linux
Guis. You can see an example of this here:
http://members.iinet.net.au/~clementclarke/oscar_jol_desc.html
A list of most of Jol supplied instructions can be found here:
http://alturl.com/6xqh
or: http://members.iinet.net.au/~clementclarke/JolWebManuals/Jol
Instructions Overview.html
You can click on the links to see the details of each instruction.
Jol also has a Network and Scheduling facility that allows you to submit
dependent jobs in a particular sequence, and on certain days using
JES2. The Manual can be viewed online here:
http://alturl.com/ph9f
or:
http://members.iinet.net.au/~clementclarke/JolWebManuals/SHD_Contents.html
and the PDF version can be downloaded here: http://alturl.com/u88c
or here:
http://members.iinet.net.au/~clementclarke/Jol_Scheduling_and_Networking_Guide.pdf
Additionally, it has a data base of data sets. You can specify
attributes for data sets and store all the information about in the data
base and Jol will extract the information required when creating New
data sets. This can be used to centralise all data set allocations to
one person, or department.
Versions of Jol: There is an Assembler version that runs on the
Mainframe, and a "C" one that runs on Windows, OS/2 and soon Linux. The
"C" version will run as a shell on it's native system, or it can produce
pseudo JCL to run on Z/OS style systems. A VSE version is awaiting testing.
Further Documentation: You can view the Jol Reference Guide online here:
http://alturl.com/6g6x
or you can download the PDF version here: http://alturl.com/u2x7
You can download the Concepts and Facilities Manual PDF here:
http://alturl.com/ehar
or:
http://members.iinet.net.au/~clementclarke/Jol_Concepts_And_Facilities.pdf
There is more documentation, for example Installation Guide, a full
General Information Manual, and more.
However, the above will give you sufficient to see what Jol is, and how
useful it can be to your organisations.
Some points of interest will probably be the description of the
Preprocessing Facilities here:
"http://members.iinet.net.au/~clementclarke/JolWebManuals/GDE_Compile
Time Facilities.html"
and Card Files (with Symbolic replacement):
http://members.iinet.net.au/~clementclarke/JolWebManuals/INS_DclCardImage.html
and Macros here:
http://members.iinet.net.au/~clementclarke/JolWebManuals/GDE_Macros.html
and http://members.iinet.net.au/~clementclarke/JolWebManuals/INS_Macro.html
How does it get any better than this?
Clement Clarke, Melbourne, Australia
Tel +61401054155
David Andrews
> And that IBM haven't supported
I imagine that's unlikely as long as you require that Jol not be used
for "war activities".
--
David Andrews
A. Duda and Sons, Inc.
david....@duda.com
Jack.H...@kp.org
did *not* make the trains run on time. Interesting how those catch
phrases become part of common knowledge, true or not.
--
Jack Hamilton
Management Information & Analysis
Kaiser Foundation Health Plan, Inc.
1950 Franklin Street, Oakland, California 94612
+1 510 987-1556 (KP tieline 8-427-1556)
NOTE: This email document and attachments are covered by CA Evidence Code
�1157 and CA Health and Safety Code �1370.
NOTICE TO RECIPIENT: If you are not the intended recipient of this
e-mail, you are prohibited from sharing, copying, or otherwise using or
disclosing its contents. If you have received this e-mail in error,
please notify the sender immediately by reply e-mail and permanently
delete this e-mail and any attachments without reading, forwarding or
saving them. Thank you.
P S <zos...@GMAIL.COM>
Sent by: IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
01/04/2010 06:48 PM
Please respond to
IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
Subject
Re: [IBM-MAIN] Why is JCL so bad was Re: Basic question on passing JCL set
symbol to proc
On Mon, Jan 4, 2010 at 9:10 PM, Clark Morris
P S
> According to <http://www.snopes.com/history/govern/trains.asp>, Mussolini
> did *not* make the trains run on time. Interesting how those catch
> phrases become part of common knowledge, true or not.
>
Tsk. You misunderstand the nature of a dictatorship. E.g.:
Stalin, Khruschev and Brezhnev were traveling on a train that had stopped.
Khruschev got up and went to the front of the train.
When he came back he smiled and said, "Will be leaving soon. I have had
engine-driver rehabilitated".
"I will see to it!" said Stalin leaving the compartment.
On his return, he declared, "we go now, I have had engine-driver shot".
Still the train didn't move. Finally Brezhnev stood up and pulled down the
blinds.
"There", he said, "now, train is moving".
:-)
Clement Clarke
remove. Pity people want to kill each other, though...
Clem
David Andrews wrote:
> On Tue, 2010-01-05 at 01:09 -0500, Clement Clarke wrote:
>
>> And that IBM haven't supported
>>
> I imagine that's unlikely as long as you require that Jol not be used
> for "war activities".
>
>
----------------------------------------------------------------------
Paul Gillis
when I changed jobs I had to relearn JCL. Jol certainly provided much
of what has been discussed here since the early 70s.
Never tried a parm greater than 100 bytes, wonder if that would work.
Probably no reason why it couldn't if the target program was able to
cope with it.
Cheers, Paul
Howard Brazee
wrote:
>I used Jol from 1970 through 1988 and was very happy with it, then
>when I changed jobs I had to relearn JCL. Jol certainly provided much
>of what has been discussed here since the early 70s.
>Never tried a parm greater than 100 bytes, wonder if that would work.
>Probably no reason why it couldn't if the target program was able to
>cope with it.
I used a beta version of an Amdahl operating system called Aspen,
running under VM. It was powerful and programmers loved it. But
it sometimes had performance problems - after all it was beta.
I don't know if it was IBM that wanted to stick with JCL. IBM seemed
to want to go more Rexx. But customers seemed more resistant to
change even than IBM. Too bad, as the mind set isn't to consider
the power of IBM mainframes in these distributed Unix environments
companies are moving to.
Shmuel Metz , Seymour J.
at 05:43 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Does that mean before there were PROCs?
No.
>PROCs are little use without symbols.
They were quite useful.
>Or was everything done with overrides?
Yes. As I recall, symbolic parameters came in with OS/360 Release 14.
>For most of what I cited, JCL/initiator exploits it.
The Initiator runs in Supervisor; Rexx does not.
>That suggests that something is in initiator that would more
>properly be in allocation.
There's more to Allocation then SVC 99. What's missing is an unprivileged
interface to the Allocation features that are either global or that are
local but have no TU assigned.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Clement Clarke
Yes, as you well know, it was used at Shell for decades, and Amoco, etc
etc. All the companies that used it (some really major ones such as
Amoco, Chicago) were taken over, or had the Computing systems moved back
to headquarters, and converted back to Type 1 JCL.
Had IBM supported the product, it would have won the day... (It still can).
Thank you for your support in helping to get it all going! Gosh, think
of all those midnight sessions getting it going and working out easier
ways of doing things... It really was a team effort with you, Fergus,
David, Andrew, Mike and all the others in the team. And thanks to Shell
Management for being brave enough to give it the go ahead.
And Fujitsu after that. And the many others involved in the project in
the decades that followed.
Cheers,
Clem
PS : Re Parms: I think we could easily allow 256 byte parms. Maybe a
1000, why not?
Thomas Berg
(that never has a value other than "null"):
//ANYPROC PROC X=,PARM1=,WHATEVER=
. . .
//STEPN EXEC PGM=ANYPGM,PARM=&X'&PARM1&WHATEVER'
. . .
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
> -----Ursprungligt meddelande-----
> Fr�n: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] F�r Charles Mills
> Skickat: den 4 januari 2010 01:05
> Till: IBM-...@bama.ua.edu
> �mne: Re: Basic question on passing JCL set symbol to proc
>
> CORRECTION. I got seduced by a good return code. The below
> does not work. I had to go to Gil's
>
> // SET Q=''''
> // SET OPTS='NOTEMPL,OE,OBJ,NOARG'
> //COMPMAIN EXEC CBCC,CPARM=&Q&OPTS&Q
>
> Ugly? Whew!
>
> Charles
>
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Charles Mills
> Sent: Sunday, January 03, 2010 2:33 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: Basic question on passing JCL set symbol to proc
>
> Sheesh! Thanks all for your input. And to think I thought it
> was just that I didn't know what I was doing. I thought one
> of you would say "you dummy -- you need to double the
> apostrophes and put it all in parentheses" or something like that.
>
> I "solved" the problem by splitting it in two. I was able to
> get the lower case letters out of there by moving the
> information to a //SYSLIB DD PATH= statement. Now the
> solution to the rest of the problem is just
>
> // SET OPTS=(NOTEMPL,OE,OBJ,NOARG)
> . . .
> //COMPMAIN EXEC CBCC,CPARM=&OPTS
>
> (In case anyone was wondering why I wanted to take a
> perfectly good PARM= parameter and make it into a problematic
> SET symbol: there are multiple compile jobsteps in the job
> and I got tired of changing the compile PARM= in more than
> one place. Also, this way I can readily alternatively comment
> out or use various sets of compile options. I might also use
> set symbols for multiple sets of compile options that I could
> concatenate together as
> appropriate -- but you have to save some fun for another day.)
>
> Charles
Charles Mills
// SET NIL=
// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
//* ...
//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS'
Weird design.
Paul Gilmartin
>Thanks. That works too:
>
>// SET NIL=
>// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
>//* ...
>//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS'
>
Really!? Because the value of the operand
is not _surrounded_ by apostrophes?
>Weird design.
>
Indeed.
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
>Of Thomas Berg
>Sent: Thursday, January 07, 2010 5:40 AM
>
>I have as a standard a X= parm in most of my procedures
>(that never has a value other than "null"):
>
>//ANYPROC PROC X=,PARM1=,WHATEVER=
> . . .
>//STEPN EXEC PGM=ANYPGM,PARM=&X'&PARM1&WHATEVER'
> . . .
>
But (I say from the doc, without testing) in this case
the &X is superfluous, because one of the cases where
symbols are substituted within apostrophes is the
PARM of the EXEC statement.
-- gil
Charles Mills
apostrophes?
Really. <g>
But it's "started with" that seems to matter, not "surrounded by."
// SET NIL=
// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
//* ...
//PROCLIB JCLLIB ORDER=CBC.SCCNPRC
//COMPMAIN EXEC CBCC,CPARM='&OPTS'&NIL
fails.
// SET Q=''''
// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
//* ...
//COMPMAIN EXEC CBCC,CPARM=&Q&OPTS'
succeeds.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Friday, January 08, 2010 4:10 PM
To: IBM-...@bama.ua.edu
Subject: Re: Basic question on passing JCL set symbol to proc
On Fri, 8 Jan 2010 15:15:11 -0800, Charles Mills wrote:
>Thanks. That works too:
>
>// SET NIL=
>// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
>//* ...
>//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS'
>
Really!? Because the value of the operand
is not _surrounded_ by apostrophes?
tml
Thomas Berg
regarding the substitution of &-variables. As soon
as a "substituionable" variable is found any variable
thereafter is substituted on that "card" (Sic!).
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
> -----Ursprungligt meddelande-----
> Fr�n: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] F�r Paul Gilmartin
> Skickat: den 9 januari 2010 01:10
> Till: IBM-...@bama.ua.edu
> �mne: Re: Basic question on passing JCL set symbol to proc