Does anyone know how to read the current JCL symbols from a program?
ASASYMB apparently won't do it. Its frustrating, since you might be
able to use for some interesting things.
Thanks for any help,
Kirk Wolf
Dovetailed Technologies
>> > > Example:
>> > >
>> > > // SET PARM1=NEW
>> > > // EXEC PROC=FOO,PARM2=OLD
>> > >
>> > > In this example, while executing the FOO proc, you have
>> JCL symbols
>> > > PARM1 and PARM2.
>> > >
>> > > My question is this: does anyone know a way for a program to
>> > > read the
>> > > current JC
I would agree that a program having access to JCL symbols would be handy.
I've seen NO traffic from Development suggesting it'll happen.
Martin
Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[EMAIL PROTECTED]
Unless stated otherwise above:
IB
Try opening a requirement and providing a business case, then get your
family, friends and neighbors to do the same. Otherwise IBM is not going to go
off and pioneer this solution based on some mutterings on a listserv.
If your employer is not a member of SHARE, contact IBM directly. They have a
What are you defining a current JCL symbol to be? Show us an example.
On Tue, 12 Jun 2007 15:17:57 -0500, Kirk Wolf <[EMAIL PROTECTED]> wrote:
>Does anyone know how to read the current JCL symbols from a program?
>
>Kirk Wolf
>Dovetailed Technologies
>
---
Kenneth E Tomiak wrote:
What are you defining a current JCL symbol to be? Show us an example.
On Tue, 12 Jun 2007 15:17:57 -0500, Kirk Wolf <[EMAIL PROTECTED]> wrote:
Does anyone know how to read the current JCL symbols from a program?
Kirk Wolf
Dovetailed Technologies
JCL Symbols a
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Wolf
> Sent: Wednesday, June 13, 2007 8:10 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Read JCL Symbols from a program?
>
>
> Kenneth E Tomiak wrote:
M
> > To: IBM-MAIN@BAMA.UA.EDU
> > Subject: Re: Read JCL Symbols from a program?
> >
> >
> > Example:
> >
> > // SET PARM1=NEW
> > // EXEC PROC=FOO,PARM2=OLD
> >
> > In this example, while executing the FOO proc, you have JCL symbols
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM
> Sent: Wednesday, June 13, 2007 8:33 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Read JCL Symbols from a program?
>
>
>
>
>
Well, as a first stab at this...
Since the "symbols" you are interested in are JCL type symbols, then you could
have the executing program pull them in through the PARM='" on the EXEC JCL
card. As long as the combined length of the symbols your program has an
interest in less than 100 (ass
On Tue, 12 Jun 2007 15:17:57 -0500, Kirk Wolf <[EMAIL PROTECTED]> wrote:
>Does anyone know how to read the current JCL symbols from a program?
>
>Kirk Wolf
>Dovetailed Technologies
>
I have a customer who maintains a simple program for the purpose of writing the
PARM= value out to
an allocated D
On Wed, 13 Jun 2007 08:38:52 -0500, McKown, John wrote:
>>
>> You can, of course, pass the required symbols as parm to the program:
>> //PGM EXEC PMG=PROG1,PARM='SYMBOL1=&SYMBOL1,SYMBOL2=&SYMBOL2,"'
>> Kees.
>
>Very true. But I got the idea that the original person may have wanted
>to write a s
D] On
Behalf Of Kirk Wolf
Sent: Tuesday, June 12, 2007 1:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Read JCL Symbols from a program?
Does anyone know how to read the current JCL symbols from a program?
ASASYMB apparently won't do it. Its frustrating, since you might be
able to use for som
On Wed, 13 Jun 2007 08:48:16 -0700 GAVIN Darren * OPS EAS
<[EMAIL PROTECTED]> wrote:
:>The user defined symbols in JCL are handled by the JES (or equivalent)
:>facilities.
More likely the C/I, a part of MVS.
:>There is no information I could find on how to access these, other them
:>passing them
esday, June 13, 2007 5:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Read JCL Symbols from a program?
The user defined symbols in JCL are handled by the JES (or equivalent)
facilities.
There is no information I could find on how to access these, other them
passing them on a PARM= statement.
I suspec
---
I don't know why JCL imposes a harsher limit. Just doing JCL's thing, I
guess. Likewise, I don't see why DYNALLOC imposes a harsher limit, since
I see in IEFZB4D0:
S99TULNG DS XL2 LENGH OF 1ST (OR ONLY) PARAMETER
which would easily acco
On Wed, 13 Jun 2007 17:26:31 -0500, Rick Fochtman <[EMAIL PROTECTED]> wrote:
>
>Probably because 40+ years ago, when this was designed, nobody in their
>wildest dreams could envision a need for a PARM longer than 100 bytes. :-)
>
Very few years earlier, nobody could envision a need for an address
s
On Wed, 13 Jun 2007 09:20:40 -0500, Paul Gilmartin
<[EMAIL PROTECTED]> wrote:
>
>I don't know why JCL imposes a harsher limit. Just doing JCL's
>thing, I guess. Likewise, I don't see why DYNALLOC imposes a
>harsher limit, since I see in IEFZB4D0:
>
>S99TULNG DS XL2 LENGH OF 1ST (O
Rick Fochtman wrote:
Probably because 40+ years ago, when this was designed, nobody in their
wildest dreams could envision a need for a PARM longer than 100 bytes. :-)
I doubt it. There were several components, Assembler F for one,
where specifying most options would require more than 100 byte
On Jun 13, 2007, at 11:49 PM, Gerhard Postpischil wrote:
Rick Fochtman wrote:
Probably because 40+ years ago, when this was designed, nobody in
their wildest dreams could envision a need for a PARM longer than
100 bytes. :-)
I doubt it. There were several components, Assembler F for one,
Here's what I do to pass a DB2 plan name to a subroutine 10 level below the
step-level prog:
//SET PLAN=PlanName
...
//DB2PLAN DD DISP=(,PASS),SPACE=(0,0),DSN=&&&PLAN
The DSN expands into SYSx.Txx.RAxxx..PlanName.Hxx, and so
the subroutine issues RDJFCB against DD=DB2PLAN
Gerhard Postpischil wrote:
Rick Fochtman wrote:
Probably because 40+ years ago, when this was designed, nobody in
their wildest dreams could envision a need for a PARM longer than 100
bytes. :-)
I doubt it. There were several components, Assembler F for one, where
specifying most options
Rick Fochtman wrote:
Most default/desirable options for the Assembler and the compilers, etc.
could be set at System Generation time, avoiding those long parm
strings. And as I recall, SYS1.JOBQUEUE had a record size limit but it
was significantly larger that 100 bytes; 1024 comes to mind, but
In <[EMAIL PROTECTED]>,
on 06/13/2007
at 08:48 AM, GAVIN Darren * OPS EAS <[EMAIL PROTECTED]>
said:
>The user defined symbols in JCL are handled by the JES (or
>equivalent) facilities
No. They're handled by the Converter.
>I suspect there is some callable JES service for it,
No. You might be
In <[EMAIL PROTECTED]>, on 06/14/2007
at 04:39 PM, Rick Fochtman <[EMAIL PROTECTED]> said:
>Most default/desirable options for the Assembler and the compilers,
>etc. could be set at System Generation time,
Yes.
>avoiding those long parm strings.
No.
>And as I recall, SYS1.JOBQUEUE had a re
In <[EMAIL PROTECTED]>, on 06/14/2007
at 06:42 AM, Ed Gould <[EMAIL PROTECTED]> said:
>IIRCC they did offer up a way to shorten the "verbs" so that the 100
> character limitation was semi mute.
ITYM moot, and even with abbreviations I ran into the 100 character
limit setting up procs for IBM
In <[EMAIL PROTECTED]>, on 06/13/2007
at 06:05 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>Very few years earlier, nobody could envision a need for an address
>space larger than 16 MiB.
Well, I was shocked by the small address size on the S/360, and the
Ferranti Atlas certainly suggested tha
In <[EMAIL PROTECTED]>, on 06/13/2007
at 05:26 PM, Rick Fochtman <[EMAIL PROTECTED]> said:
>Probably because 40+ years ago, when this was designed, nobody in
>their wildest dreams could envision a need for a PARM longer than
>100 bytes. :-)
Perhaps not, but 39 years ago I ran into issues beca
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, June 19, 2007 7:46 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Read JCL Symbols from a program?
>
> In <[EMAIL PROTECT
On Tue, 19 Jun 2007 09:24:38 -0600 "Jeffrey D. Smith"
<[EMAIL PROTECTED]> wrote:
:>The compilers at http://www.dignus.com/ allow indirection for options.
:>Just specify a file name (DD name or data set name) in the PARM=
:>string. The compiler reads the file to get the options. Indirection
:>compl
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Binyamin Dissen
> Sent: Tuesday, June 19, 2007 9:30 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Read JCL Symbols from a program?
>
> On Tue, 19 Jun 2007 09:24:38
Sorry about the formatting in this text only newsgroup. However, you
can see it formatted correctly in the Jol Reference Guide at
http://members.ozemail.com.au/~oscarptyltd/Jol_Reference_Guide.pdf.
That said, there is a special command in Jol for storing or saving
symbolic variables for reu
esday, June 19, 2007 5:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Read JCL Symbols from a program?
In <[EMAIL PROTECTED]>,
on 06/13/2007
at 08:48 AM, GAVIN Darren * OPS EAS <[EMAIL PROTECTED]>
said:
>The user defined symbols in JCL are handled by the JES (or
>equivalent)
Kirk Wolf wrote:
> Kenneth E Tomiak wrote:
>> What are you defining a current JCL symbol to be? Show us an example.
>>
>> On Tue, 12 Jun 2007 15:17:57 -0500, Kirk Wolf <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Does anyone know how to read the current JCL symbols from a program?
>>>
>>> Kirk Wolf
>>> Do
I think I have time to start looking into this. By now the thread veered off
into
complaints from eons ago. Most current compilers allow passing parameters in
with the source code so JCL limitations are not what they once where for
compile procs. The PARM='' limit has not changed. Asking IBM ho
Kenneth,
No, I haven't seen any acceptable workarounds.
The main requirement is to allow data to flow from JCL variables into
programs, without a 100 character limit.
Yes, I would be willing to follow unsupported control blocks to get the
information, if that is what it took.
Kirk Wolf
Dove
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Wolf
> Sent: Monday, June 25, 2007 8:29 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Read JCL Symbols from a program?
>
>
> Kenneth,
>
>
My first assumption is that you really do not want to start adding steps to
every job in order to do this. But just in case you do, the 100 character PARM
limit is not the big deal people are making of it. I doubt the majority of
people
who code JCL even know how to continue a value beyond one
In <[EMAIL PROTECTED]>,
on 06/19/2007
at 09:08 AM, GAVIN Darren * OPS EAS <[EMAIL PROTECTED]>
said:
>Curiously, what is the Converter part of, base z/OS services?
Long ago in a galaxy far away it was part of the Scheduler.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position
In <[EMAIL PROTECTED]>, on 06/19/2007
at 09:24 AM, "Jeffrey D. Smith" <[EMAIL PROTECTED]> said:
>The compilers at http://www.dignus.com/ allow indirection for
>options.
That solves a problem, but it doesn't solve the problem that I was
addressing.
>Indirection completely relieves the 100-byte
*** keeping old topic for the archives ***
I just had a need to access JCL symbols from a program. The below 2 steps
[really the last one, the first is merely a convenience] capture the full
original
JCL at the bottom of ISFOUT, which can be then read and parsed
programmatically:
//* (1) SU
41 matches
Mail list logo
