Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Peter Relson wrote: >I on the other hand do have sympathy. A highly significant reason that >z/OS still exists (and the same could have been said for its >predecessors OS/390 and MVS) is because of the enormous amount of time >and effort we have put into maintaining as much compatibility as we

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

That should just be made a syntax error. I have no sympathy for the "compatibility" argument. I on the other hand do have sympathy. A highly significant reason that z/OS still exists (and the same could have been said for its predecessors OS/390 and MVS) is because of the enormous amount of

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Wed, 11 Oct 2023 15:44:39 +, Peter Relson wrote: > >As it happens, the offending sentence had already been removed from the 3.1 >book. Since the thread started before those books were generally available to >be looked at, it's not surprising that that was not realized. > I see that.

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Paul G wrote I fear "unpredictable" is too often the writers' excuse when they don't know the answer to a request for clarification and can't find out. I don't think you will find that that is true in z/OS books. Writers do not make up usage of that word. They are asked to do so because the

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Processing date from control card input is endemic to the financial industry, not just banks. I believe it stems from the fact that "daily" processing occurs after midnight, Michael At 11:08 AM 10/8/2023, Paul Gilmartin wrote: On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote: >To be honest I consider date-related variables as pooor when >compared to batch scheduler features, especially ControlM (it is not >advertisement, just opinion). > You worked for a bank. I had a co-worker who had worked for a bank.

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 18:42:42 +, Farley, Peter wrote: >I’ll admit I have NOT used symbol substitution in the “name” part (left of the >“=”) at all, only on the right (value) side, so the true answer is “I don’t >know”. Never had a reason to use substitution in the “name” part. > However

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 13:10:36 -0500, Michael Oujesky wrote: >Dynamic symbols (date/time) can be evaluated at different points in >time during conversion, so if used multiple time in the JCL, they can >resolve to different values. My ROT was to never use a dynamic >symbol more that once in coding

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

ctober 7, 2023 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?] On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote: On 9/20/2023 8:23 AM, Farley, Peter wrote: ... JCL symbols as part of the definition of othe

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

that need. When I get a chance I will try the new feedback process. Peter From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Saturday, October 7, 2023 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Dynamic symbols (date/time) can be evaluated at different points in time during conversion, so if used multiple time in the JCL, they can resolve to different values. My ROT was to never use a dynamic symbol more that once in coding and where it was needed multiple time, set it to my own

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote: >On 9/20/2023 8:23 AM, Farley, Peter wrote: >> ... JCL symbols as part of the definition of other JCL symbols works >> flawlessly every time. > Is this true alike for substitution both in the name (left of the "=") and in the value (right of

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On 9/20/2023 8:23 AM, Farley, Peter wrote: I believe that statement in the JCL Reference is in error and needs to be deleted or at the very least completely rewritten. My quite substantial experience using this technique over the last 10-15 years is that using JCL symbols as part of the

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Farley, Peter wrote: >I believe that statement in the JCL Reference is in error and needs to >be deleted or at the very least completely rewritten. My quite >substantial experience using this technique over the last 10-15 years >is that using JCL symbols as part of the definition of other JCL

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Thanks for changing the Subject: as the topic drifted. On Wed, 20 Sep 2023 15:23:31 +, Farley, Peter wrote: >I believe that statement in the JCL Reference is in error and needs to be >deleted or at the very least completely rewritten. My quite substantial >experience using this technique

Re: JCL EXEC PARM= default?

On Mon, 17 Apr 2023 14:57:22 +, Seymour J Metz wrote: >Sorry, that should be "That's not a GUPI." > SDSF? >>On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote: >>> >>>No. The only way to distinguish them is to scan the JCL or the internal text. -- gil

Re: JCL EXEC PARM= default?

3 11:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? But that's not a From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Saturday, April 15, 2023 11:04

Re: JCL EXEC PARM= default?

But that's not a From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Saturday, April 15, 2023 11:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Sun,

Re: JCL EXEC PARM= default?

On Sun, 16 Apr 2023 02:42:46 +, Seymour J Metz wrote: >I'm questioning "a program could determine that PARM was not specified". > ... which you said it could do by "scan[ning] the JCL or the internal text." >On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote: >> >>No. The only way to

Re: JCL EXEC PARM= default?

dmarc-requ...@listserv.ua.edu] Sent: Saturday, April 15, 2023 10:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote: >> Meticulously distinguishing the case of PARM is absent from PARM='', >> possibly because a p

Re: JCL EXEC PARM= default?

On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote: >> Meticulously distinguishing the case of PARM is absent from PARM='', >> possibly because a program could determine that PARM was not >> specified and take action different from PARM=''. > >No. The only way to distinguish them is to scan

Re: JCL EXEC PARM= default?

3 3:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Thu, 13 Apr 2023 17:01:40 -0600, Robert Raicer wrote: > >The z/OS MVS JCL Reference contains the prose shown below regarding >the PARM parameter of the JCL EXEC PGM statement. Yes, in order to >understand the details

Re: JCL EXEC PARM= default?

On Thu, 13 Apr 2023 17:01:40 -0600, Robert Raicer wrote: > >The z/OS MVS JCL Reference contains the prose shown below regarding >the PARM parameter of the JCL EXEC PGM statement. Yes, in order to >understand the details you need to look at the referenced >publication (z/OS MVS Programming:

Re: JCL EXEC PARM= default?

I am rather late adding to the topic discussion, so, apologies if my information is essentially redundant. The z/OS MVS JCL Reference contains the prose shown below regarding the PARM parameter of the JCL EXEC PGM statement. Yes, in order to understand the details you need to look at the

Re: JCL EXEC PARM= default?

On Thu, 6 Apr 2023 16:16:24 +, Peter Relson wrote: >Gil asked if the location linked to by Shmuel is the right place for the doc >about the case of no PARM. > >... We don't want the information in multiple places, > Usually I agree rather strongly with that principle. It makes

Re: JCL EXEC PARM= default?

Gil asked if the location linked to by Shmuel is the right place for the doc about the case of no PARM. To be clear, that location is here: https://www.ibm.com/docs/en/zos/2.5.0?topic=list-program-in-primary-asc-mode within the assembler services guide linkage conventions section. This is the

Re: JCL EXEC PARM= default?

79d-dmarc-requ...@listserv.ua.edu> Sent: Thursday, April 6, 2023 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Thu, 6 Apr 2023 14:01:24 +, Seymour J Metz wrote: >I've always seen cut used as a generic term for both C-C/C-V and C-X/C-V. > I'll be ped

Re: JCL EXEC PARM= default?

On Thu, 6 Apr 2023 14:01:24 +, Seymour J Metz wrote: >I've always seen cut used as a generic term for both C-C/C-V and C-X/C-V. > I'll be pedantic. "cut" deletes the selected string. >I find the relevant material in the manual, copy the URL from the URL line, >and manually type the

Re: JCL EXEC PARM= default?

<042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, April 5, 2023 2:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Wed, 5 Apr 2023 17:51:22 +, Seymour J Metz wrote: >Yes. > >Cut and paste. > "Cut" (ITYM "Copy") from

Re: RCF address [was: RE: JCL EXEC PARM= default?]

I have had the different RCF addresses respond over night to a week or so later depending on time of year and other scheduling (internal to IBM). But they have gotten back to me. Steve Thompson On 4/5/2023 4:22 PM, Bob Bridges wrote: FWIW, I've sent comments to the ibmdocs address from time

Re: RCF address [was: RE: JCL EXEC PARM= default?]

On Behalf Of Paul Gilmartin Sent: Wednesday, April 5, 2023 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RCF address [was: RE: JCL EXEC PARM= default?] On Wed, 5 Apr 2023 19:17:45 +, Farley, Peter wrote: > >In the latest (V2R5) "Callable Services for HLL's" manual the RCF a

Re: RCF address [was: RE: JCL EXEC PARM= default?]

FWIW, I've sent comments to the ibmdocs address from time to time over the years, and they've always responded, always in less than a week but never (IIRC) the next day. Never tried the mhvrcfs address, that I recall. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every year, on

Re: RCF address [was: RE: JCL EXEC PARM= default?]

On Wed, 5 Apr 2023 19:17:45 +, Farley, Peter wrote: > >In the latest (V2R5) "Callable Services for HLL's" manual the RCF address is >still documented as mhvr...@us.ibm.com not the "ibmdocs" address you mentioned. > >Do you know which one is correct please? I sent one to the "mhvrcfs"

RCF address [was: RE: JCL EXEC PARM= default?]

day but have received no reply or acknowledgement yet. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Wednesday, April 5, 2023 2:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Wed, 5 Apr 2023 17:51:22 +, Seymour J Metz

Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 17:51:22 +, Seymour J Metz wrote: >Yes. > >Cut and paste. > "Cut" (ITYM "Copy") from where? (I'm trying do decide whether it's worth an RCF to ibmd...@us.ibm.com) > >From: Paul Gilmartin >Sent: Wednesday, April 5, 2023 1:04 PM >

Re: JCL EXEC PARM= default?

E ARE... TEST Welcome in Colossal Cave. You are not yet at wit's end. /P > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Peter Sylvester >> Sent: Wednesday, April 5, 2023 10:14 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >>

Re: JCL EXEC PARM= default?

ssion List On Behalf Of Peter Sylvester Sent: Wednesday, April 5, 2023 10:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? [EXTERNAL EMAIL] test 'sys1.linklib(iefbr14)' TEST l 1R 1R 0002AF60 TEST l 1r% 0002AF60. 8002AF64 TEST l 1r%% 0002AF64. TEST On 05/04/

Re: JCL EXEC PARM= default?

Yes. Cut and paste. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, April 5, 2023 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Wed,

Re: JCL EXEC PARM= default?

Everything beyond the halfword of 0 is irrelevant. From: IBM Mainframe Discussion List on behalf of Peter Sylvester Sent: Wednesday, April 5, 2023 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? test 'sys1.linklib(iefbr14

Re: JCL EXEC PARM= default?

I agree that it's a fullword of zeros. But, this demonstration is not JCL > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter Sylvester > Sent: Wednesday, April 5, 2023 10:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JCL

Re: JCL EXEC PARM= default?

<03b5261cfd78-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, April 5, 2023 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? So, R1 in //R EXEC PGM=IEFBR14 points to ??? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmarti

Re: JCL EXEC PARM= default?

t; > Sent: Wednesday, April 5, 2023 11:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JCL EXEC PARM= default? > > So, R1 in > //R EXEC PGM=IEFBR14 > points to ??? > > -- For IBM-MAIN subscribe / sign

Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 16:48:35 +, Seymour J Metz wrote: >The fragment page= is the normal way to request a specific page within a PDF, >but the number is the sequential page within the PDF rather than the number on >the page. Your PDF viewer should show you that number. > When you click (with

Re: JCL EXEC PARM= default?

on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, April 5, 2023 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote: ><https://www-40.ibm.com/servers/resourcelink/

Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote: > " If the PARM field was omitted in the EXEC statement, the count is set to zero." Good catch! But is that a good place to

Re: JCL EXEC PARM= default?

behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, April 5, 2023 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote: >For EXEC PROC=, the default is no PARM override. F

Re: JCL EXEC PARM= default?

DCH'0' From: IBM Mainframe Discussion List on behalf of Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, April 5, 2023 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL EXEC PARM= default? So, R1

Re: JCL EXEC PARM= default?

So, R1 in //R EXEC PGM=IEFBR14 points to ??? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Wednesday, April 5, 2023 8:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JCL EXEC PARM= default? > > [EXTERNAL E

Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote: >For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the default is >an empty string. > > That was my guess. Where did you find that documented? > >From: Paul Gilmartin >Sent:

Re: JCL EXEC PARM= default?

For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the default is an empty string. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin

Re: JCL Procedure help

UA.EDU Subject: Re: JCL Procedure help On Wed, 8 Feb 2023 14:14:47 +, Seymour J Metz wrote: >... > 2. Make SYSIN in the swecond step a backwards reference to SYSIN in the first > step. I'm not sure whether that will work. > How about: //JOBSTEP EXEC MYPROC

Re: JCL Procedure help

Add a new first step. Which reads the SYSIN and passes it to the function (now 3rd) step > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gadi Ben-Avi > Sent: Wednesday, February 8, 2023 4:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: JCL Procedure help > >

Re: JCL Procedure help

On Wed, 8 Feb 2023 14:14:47 +, Seymour J Metz wrote: >... > 2. Make SYSIN in the swecond step a backwards reference to SYSIN in the first > step. I'm not sure whether that will work. > How about: //JOBSTEP EXEC MYPROC //STEP2.SYSIN DD * (as in:

Re: JCL Procedure help

There are static and dynamic System Symbols ... There is a JOBCLASS parm SysSym that ALLOWs or DISALLOWs the use of either of them.. if DISALLOW, none of these are available to the jobs with a class marked as such.. There is also a PARMLIB IEASYMxx that system programmers may add additional

Re: JCL Procedure help

I think that is the best idea, if changing the job JCL is an option. But it may be that it's more feasible to change one proc instead of who knows how many jobs. That's one of the reasons to have procs. Also, I believe your "plexname" should be "systemname". sas On Wed, Feb 8, 2023 at 10:28

Re: JCL Procedure help

>> I was asked to add a step that would check that the JOB is running on the >> correct LPAR. Gadi, I agree with Mikael of using SYSAFF parm to route the JOB to that LPAR it needs to run. This will not only eliminate making any changes to the PROC and you don't need to add a rexx exec to

Re: JCL Procedure help

o IBM-MAIN@listserv.ua.edu Date 2/8/2023 9:17:22 AM Subject Re: JCL Procedure help You can probably just invoke the original program in your REXX (ADDRESS LINKMVS, etc.) when it's on the correct system. Then your proc is still one step. sas On Wed, Feb 8, 2023 at 8:56 AM Willy Jensen wrote:

Re: JCL Procedure help

You can probably just invoke the original program in your REXX (ADDRESS LINKMVS, etc.) when it's on the correct system. Then your proc is still one step. sas On Wed, Feb 8, 2023 at 8:56 AM Willy Jensen wrote: > Since you are running a REXX anyway, that REXX could copy DDname SYSIN to > a

Re: JCL Procedure help

In addition to copying SYSIN, as a previous poster suggested, there are other options. 1. Let your REXX code call the application. As long as it doesn't need authorization or program control, that should work fine. 2. Make SYSIN in the swecond step a backwards reference to SYSIN in the first

Re: JCL Procedure help

Since you are running a REXX anyway, that REXX could copy DDname SYSIN to a temporary dataset, which is then used for SYSIN in the 2nd step, A simple REPRO INFILE(SYSIN) OUTFILE(TEMP) should do it. -- For IBM-MAIN subscribe /

Re: JCL Procedure help

Not an answer to your question, but have you looked at the JCL statements SYSTEM, SYSAFF or SCHENV? //Mikael -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gadi Ben-Avi Sent: den 8 februari 2023 13:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: JCL Procedure help Hi, I

Re: JCL // SET SYMBOL indirection

79d-dmarc-requ...@listserv.ua.edu> Sent: Thursday, February 2, 2023 1:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL // SET SYMBOL indirection On Wed, 1 Feb 2023 13:52:56 +, Seymour J Metz wrote: >Or IBM knows something that you do not. > IBM guarantees that with their indolent d

Re: JCL // SET SYMBOL indirection

On Wed, 1 Feb 2023 13:52:56 +, Seymour J Metz wrote: >Or IBM knows something that you do not. > IBM guarantees that with their indolent documentation practice. An example: : The following keywords are the

Re: JCL // SET SYMBOL indirection

, January 31, 2023 10:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL // SET SYMBOL indirection On Wed, 1 Feb 2023 00:20:26 +, Farley, Peter wrote: >Not necessarily what you may want, but this works: > >//SYM1 SET SYM1=VALUE1 >//SYM2 SET SYM2=VALUE2 > >//T

Re: JCL // SET SYMBOL indirection

On Wed, 1 Feb 2023 00:20:26 +, Farley, Peter wrote: >Not necessarily what you may want, but this works: > >//SYM1 SET SYM1=VALUE1 >//SYM2 SET SYM2=VALUE2 > >//TARGET SET TARGET= > >//RESULT SET RESULT= (and end up with being set to VALUE1 >and not SYM1) > >I know Gil will

Re: JCL // SET SYMBOL indirection

>>//RESULT SET RESULT=& (and end up with being set to VALUE1 >>and not SYM1) Rob, Try this // EXPORT SYMLIST=* //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=SYM1 //RESULT SET RESULT= /* //STEP0100 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //LOGDD1 DD

Re: JCL // SET SYMBOL indirection

I don't know about your question. But herewith a brief side hike: I have always been inclined to experiment with systems, hoping to find sense in what seemed like senseless behavior and looking for shortcuts. (Apparently I was born to be a programmer.) When I was handed a form to fill out, and

Re: JCL // SET SYMBOL indirection

Unfortunately, you can not have "nested" symbols...just one and done. Thank you and best regards, Billy Ashton -- Original Message -- From "Robert Garrett" To IBM-MAIN@listserv.ua.edu Date 1/31/2023 7:07:31 PM Subject JCL // SET SYMBOL indirection I love symbols. I've been trying

Re: JCL // SET SYMBOL indirection

Not necessarily what you may want, but this works: //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET= //RESULT SET RESULT= (and end up with being set to VALUE1 and not SYM1) I know Gil will complain the observed JCL symbol behavior (assigning the value of (a)

Re: JCL Output statement question

On Tue, 6 Dec 2022 07:06:01 +, Gadi Ben-Avi wrote: >... >We have a series of jobs (Control-D print missions) that allocate output DD >statements dynamically. > >We coded an OUTPUT Statement with DEFAULT=YES in these jobs with INTRAY=2, but >this doesn't seem to work. > >Should it be

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 20:30:03 +, Seymour J Metz wrote: >> Would it be a favor to programmers to make misiplacing IF, etc. >> within a job step, or SET within IF ... ENDIF a syntax error? The >> effect is probably not what the programmers intend. > >IMHO, the current behavior is a bug, but it

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Friday, January 7, 2022 12:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote: >

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Hobart Spitz [orexx...@gmail.com] Sent: Friday, January 7, 2022 1:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I think it's worth mentioning that the reason that SET must be unconditional is that JES has to issue ENQs after, AFAIK, the initial JCL scan and before execution starts. If a dataset has an embedded symbolic, doing the correct ENQ when the value might change at execution time could cause all

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote: > >... I was just >working on some JCL and I had just assumed that I >could set symbolics using IF THEN ELSE ENDIF: > >// IF (STEP1.RC = 0) THEN >// SYMB=GOOD >// ELSE >// SYMB=BAD >// ENDIF > >but I found out that BOTH SET

Re: JCL (was: Python ... REXX)

Discussion List On Behalf Of Farley, Peter x23353 Sent: Thursday, January 6, 2022 5:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: JCL (was: Python ... REXX) Reading 6250BPI minireels into new formats isn’t as hard as you may think . . . There are places that could do it for you

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yeah, IF is EXEC COND in a different suit of clothes. It must control an entire jobstep. :-( Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nash, Jonathan S. Sent: Thursday, January 6, 2022 8:30 PM To:

Re: JCL (was: Python ... REXX)

, January 6, 2022 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL (was: Python ... REXX) Peter Farley asked: >Ahh! But did you save a copy of the tape? (Not that you could share >them with anyone anyway, I was just curious - as an invulnerable young whippersnapper I would have d

Re: JCL (was: Python ... REXX)

Peter Farley asked: >Ahh! But did you save a copy of the tape? (Not that you could share them with anyone anyway, I was just curious - as an invulnerable young whippersnapper I would have done so and not told anyone either . . . without ever considering the possible consequences. Such is

Re: JCL (was: Python ... REXX)

-Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Thursday, January 6, 2022 6:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL (was: Python ... REXX) At one point in the 1990s, IBM PartnerWorld started charging a $5K/year fee. We ponied up. One

Re: JCL (was: Python ... REXX)

At one point in the 1990s, IBM PartnerWorld started charging a $5K/year fee. We ponied up. One of the benefits was that you could now get the PL/X (or maybe PL/AS by then) compiler, so I requested and got it. A few months later they reversed the decision about the $5K and I got a call

Re: JCL (was: Python ... REXX)

: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL (was: Python ... REXX) On Thu, 6 Jan 2022 at 15:39, Matt Hogstrom wrote: > > That’s true for all source code and not unique to the PLX language. I > suspect that PLX originally was not intended to be held to the same rigor as >

Re: JCL (was: Python ... REXX)

On Thu, 6 Jan 2022 at 15:39, Matt Hogstrom wrote: > > That’s true for all source code and not unique to the PLX language. I > suspect that PLX originally was not intended to be held to the same rigor as > commercial languages and was specialized so IBM never er let it out of the > lab. Well

Re: JCL (was: Python ... REXX)

That’s true for all source code and not unique to the PLX language. I suspect that PLX originally was not intended to be held to the same rigor as commercial languages and was specialized so IBM never er let it out of the lab. Matt Hogstrom A generalist knows less and less about more and

Re: JCL (was: Python ... REXX)

On Thu, 6 Jan 2022 19:25:11 +, Seymour J Metz wrote: >I believe that it was Hitachi that stole MVS/XA source code. I don't know the >terms of the settlement. > I know we sold a version of a software product customized for hardware system and OS that could not legally be imported to the U.S.,

Re: JCL (was: Python ... REXX)

https://books.google.nl/books?id=ldk7z4Q-WWYC=RA14-PT5=RA14-PT5=hitachi+ibm+source+code=bl=wu-vjyCcCR=ACfU3U1kpVpCkQgJDtFT-jskySEtVGcAPw=en=X=2ahUKEwj7oJuY7p31AhUDTDABHVQ2AZ4Q6AF6BAgCEAM#v=onepage=hitachi%20ibm%20source%20code=false

Re: JCL (was: Python ... REXX)

PL/X started as BSL in the 1960s. At the time it supported imbedded assembler, which would not be portable. PL/S II still did. Open sourcing BSL or PL/S might not have been enough to prevent C; could you fit a compiler on a PDP-7 or PDP-11? -- Shmuel (Seymour J.) Metz

Re: JCL (was: Python ... REXX)

[colinpai...@gmail.com] Sent: Thursday, January 6, 2022 1:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL (was: Python ... REXX) Making PLX Internal to IBM may be to protect its Intellectual Property. I remember a vendor taking some IBM source,, renaming it and shipping it. When it went to court

Re: JCL (was: Python ... REXX)

On Thu, 6 Jan 2022 18:37:01 +, Colin Paice wrote: >Making PLX Internal to IBM may be to protect its Intellectual Property. I >remember a vendor taking some IBM source,, renaming it and shipping it. >When it went to court, ... > We did that. Through MVS 3.8 IBM source code was open. We took

Re: JCL (was: Python ... REXX)

On Thu, 6 Jan 2022 16:28:42 +, Jeremy Nicoll wrote: >... >Absolutely. But what's a decent alternative to JCL? > o Forgo compatibility. Whip sockets were long ago removed from automobile dashboards. They are no longer mourned. (But provide a conversion tool.) o Free-form input. No

Re: JCL (was: Python ... REXX)

Making PLX Internal to IBM may be to protect its Intellectual Property. I remember a vendor taking some IBM source,, renaming it and shipping it. When it went to court, they compared the vendor code with IBM code, and noticed that the code was similar, the developers had the same initials, and

Re: JCL (was: Python ... REXX)

PLX puts a value in the IDR data that can be plainly seen in the load module. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Thursday, January 6, 2022 1:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JCL (was: Python ... REXX) EXTERNAL EMAIL On

Re: JCL SPIN not working

Try $Tstc12345,SPIN,DDNAME=TLVLOG Joe On Thu, Jul 29, 2021 at 1:49 PM Roberto Halais wrote: > Hello! > > I have a stc which has the following jcl in it: > > //KLS1 JOB JESLOG=(SPIN,100K),MSGLEVEL=1 > .. > //TLVLOG DD SYSOUT=,SPIN=(UNALLOC,100K) > > The SPIN would normally function but

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

Smith [sasd...@gmail.com] Sent: Monday, May 24, 2021 6:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies The problem I have with COND= is that it's back-asswards. First, it specifies conditions to NOT run the step. You have

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

The problem I have with COND= is that it's back-asswards. First, it specifies conditions to NOT run the step. You have to keep in mind that with multiple conditions, any TRUE condition means don't run the step. Except for ONLY & EVEN, which specify conditions for which the step *will* run.

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

Gil,    I attach a discussion about the IF/THEN vs COND= we had in 2011.    That COND= BTW was for a real case of a chemical company running its payroll 100+ step job on our mainframe, but with a COND=(4,LT) on its job card. Each time one of its jobsteps hit a CC GT 4, the job ended and the ops

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Friday, May 21, 2021 11:30 PM

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

du/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Friday, May 21, 2021 11:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Te

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

rom: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Friday, May 21, 2021 10:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS > Technologies > >

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

...@bcs.org.uk] Sent: Friday, May 21, 2021 10:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies A well-known Bank I was working at, as a systems programming consultant (in '99,) asked me to install custompac. So I did

  1   2   3   4   5   6   7   8   >