Re: JCL parms

>I think we would prefer a non-LE solution to the environment-variable problem... Why? LE is not going away. And, most (if not all) compatibility issues have been resolved in the last few years. - Too busy driving to stop for gas!

Re: JCL parms

GAVIN Darren * OPS EAS wrote: John, Or better yet an enhancement by IBM to the JES Sub System itself so that it pushes the JCL Variables into Environment Variables as soon as the Job first fires up. Also I think LE adds a routine for Environment Variables as well called CEEENV at Z/OS levels 1.

Re: JCL parms

On Mon, 7 Jan 2008 08:29:46 -0600, Tom Marchant wrote: > >Then I don't see why there would be a different keyword. > >What is there to format? The NEWPARM would be a halfword length followed >by the specified value, wouldn't it? Just like the PARM, but without the 100 >byte restriction. > Such wo

Re: JCL parms

On Fri, 4 Jan 2008 22:00:15 -0600, Paul Gilmartin wrote: >On Sat, 5 Jan 2008 02:19:44 +, Bill Wilkie wrote: > >>Tom: >> >>No, only the one that is coded. If you have PARM=" " coded, it works as always. If you code NEWPARM="" they Getmain an area for something larger like 256 bytes and everyt

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/06/2008 at 07:36 PM, Ted MacNEIL <[EMAIL PROTECTED]> said: >The TSO TMP will do that if your PROC has more than one step. I routinely run the TMP in multistep jobs. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/06/2008 at 01:20 PM, Ed Gould <[EMAIL PROTECTED]> said: >I did not say that nor did I imply that. I don't recall it coming up >as a GUIDE requirement in the times I was active at GUIDE. Apparently >other people didn't think it important enough to ask IBM for a

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/06/2008 at 11:08 AM, Paul Gilmartin <[EMAIL PROTECTED]> said: >I once encountered an IBM program (I forget which) which deliberately >failed if invoked in a multistep job or not as a jobstep task. Ouch! >Is that what I know and often cite as "Conway's Law"? No,

Re: JCL parms

On Jan 6, 2008, at 1:38 PM, Anne & Lynn Wheeler wrote: --SNIP--- of course when watfor became available ... it eclipsed a lot of the work on one-step job monitors. FYI 20+ years ago I worked at a company that had a Assembler H batch compile 'initiator'

Re: JCL parms

The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Shmuel Metz , Seymour J.) writes: > No. The original design of OS/360 was that all programs were > subroutines. A program written to be called

Re: JCL parms

>I once encountered an IBM program (I forget which) which deliberately failed >if invoked in a multistep job or not as a jobstep task. The TSO TMP will do that if your PROC has more than one step. - Too busy driving to stop for gas! --

Re: JCL parms

On Jan 5, 2008, at 7:28 PM, Shmuel Metz (Seymour J.) wrote: In <[EMAIL PROTECTED]>, on 01/04/2008 at 08:41 PM, Ed Gould <[EMAIL PROTECTED]> said: Well all I can say is never say never. For 30+years 100 characters were "plenty" ObCamelDriver No. The fact that it didn't cause *you* proble

Re: JCL parms

On Sun, 6 Jan 2008 11:08:21 -0600 Paul Gilmartin <[EMAIL PROTECTED]> wrote: :>On Sat, 5 Jan 2008 20:21:27 -0500, Shmuel Metz (Seymour J.) wrote: :>>No. The original design of OS/360 was that all programs were subroutines. :>>A program written to be called as a jobstep task could also be called vi

Re: JCL parms

On Sat, 5 Jan 2008 20:21:27 -0500, Shmuel Metz (Seymour J.) wrote: > >No. The original design of OS/360 was that all programs were subroutines. >A program written to be called as a jobstep task could also be called via >LINK or ATTACH from another program. It was never designed for programs to >ass

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/04/2008 at 01:50 PM, Ulrich Krueger <[EMAIL PROTECTED]> said: >Ever since I've learned writing programs in COBOL, Assembler or a few >other languages many years ago, I have always coded a 100-byte storage >area to receive the PARM data area from JCL. That's the way

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/04/2008 at 11:15 AM, Ulrich Krueger <[EMAIL PROTECTED]> said: >You know, guys, as much as I'd like to see the JCL PARM expanded in >length, I'd hate to see the problems that will arise from it. Face it, >how many of your programs that process PARM values have a har

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/04/2008 at 08:41 PM, Ed Gould <[EMAIL PROTECTED]> said: >Well all I can say is never say never. For 30+years 100 characters were >"plenty" ObCamelDriver No. The fact that it didn't cause *you* problems doesn't negate the problems that it caused others. --

Re: JCL parms

In <[EMAIL PROTECTED]>, on 01/04/2008 at 12:49 PM, GAVIN Darren * OPS EAS <[EMAIL PROTECTED]> said: >Or better yet an enhancement by IBM to the JES Sub System itself Neither PARM nor symbolic parameters are handled by the JES. They're handled by the C/I and the Initiator. -- Shmuel (Se

JCL parms

> .. I wonder how Phil moved the PARM .. I've long since forgotten. One thing I _do_ know - it wouldn't have been with EXECUTE. It was banned in the installation standards manual. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 ---

Re: JCL parms

On Sat, 5 Jan 2008 19:44:19 -0400, Clark Morris wrote: >On 4 Jan 2008 13:50:22 -0800, in bit.listserv.ibm-main you wrote: > >>Gil, >>We're strictly talking _JCL_-_PARM_ parameters here, where there does exist >>a 100-byte length limit imposed by JCL syntax rules. >>Passing parameter values from on

Re: JCL parms

t; > >Regards, >Ulrich Krueger > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of Paul Gilmartin >Sent: Friday, January 04, 2008 13:19 >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: JCL parms > >On Fri, 4 Jan

Re: JCL parms

On Sat, 5 Jan 2008 15:47:33 -, Phil Payne wrote: > >One thing it did was a GETMAIN for the parm length and a move - and there was >at that time a >solid recommendation to do that. > Ah, but it was for the PARM length, not for 100 characters, so your macro was prepared to handle a CALL with a l

JCL parms

Tom and Rick's comments about moving the PARM. There was once a reason, but I've forgotten it. One of the first things I did when I learnt to write Assembler macros was to write my own initialisation and termination macros, making more use of the save area chain conventions than IBM's equivalen

Re: JCL parms

On Sat, 5 Jan 2008 09:16:22 -0600, Rick Fochtman wrote: > >Maybe a front-end process or that creates a long PARM string from >control statements? > Sure. Provided that symbol substitution within those control statements is supported. And provided that those control statements with substitutable s

Re: JCL parms

- No, only the one that is coded. If you have PARM=" " coded, it works as always. If you code NEWPARM="" they Getmain an area for something larger like 256 bytes and everything else works the same. That way you could have a controlled implementation without muck

Re: JCL parms

-- No! For compatibility, it should be exactly the venerable format produced by the CALL macro, etc. I'd have no problem with a different keyword for longer PARMs, provided that keyword also tolerated shorter PARMs. And I'd have little problem with

Re: JCL parms

Have you any real data to support your "just about all"? I have never encountered a problem invoking programs (including IBM products) from Rexx ATTCHMVS (assembler CALL would be the same) with PARM>100 chars. Any program which would fail as you suggest with

Re: JCL parms

--- I'd be overjoyed if IBM would admit to the possibility of a parm string up to 32,767 bytes, and design parm-driven software with that in mind. And allow JCL to accept a parm of that length. Changes to code would be minimal, since it already uses

Re: JCL parms

On 4 Jan 2008 18:19:58 -0800, [EMAIL PROTECTED] (Bill Wilkie) wrote: >No, only the one that is coded. If you have PARM=" " coded, it works as >always. If you code NEWPARM="" they Getmain an area for something larger like >256 bytes and everything else works the same. That way you could have a >

Re: JCL parms

On 4 Jan 2008 14:41:32 -0800, [EMAIL PROTECTED] (Steve Comstock) wrote: >> It's been over 30 years since I was a COBOL programmer, but I'm sure that I >> never moved the parm that was supplied in the JCL. Yes, I wrote quite a few >> programs that would accept a parm. The parm area was always c

Re: JCL parms

On Sat, 5 Jan 2008 02:19:44 +, Bill Wilkie wrote: >Tom: > >No, only the one that is coded. If you have PARM=" " coded, it works as >always. If you code NEWPARM="" they Getmain an area for something larger like >256 bytes and everything else works the same. That way you could have a >contro

Re: JCL parms

Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Friday, January 04, 2008 10:28 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JCL parms I'd be overjoyed if IBM would admit to the possibility of a parm string up to 32,767 bytes, and design parm-driven software with that in

Re: JCL parms

On Jan 4, 2008, at 12:07 PM, J R wrote: then instead of a half word do 8 byte length and provide 16G of storage. The halfword length is not the problem. This already allows for 64KiB which would take in the order of one thousand continuation cards to fill -- obviously more than would ever be

Re: JCL parms

p what's there. Once the support for newparm is in the system, you can add it where needed. Bill> Date: Fri, 4 Jan 2008 16:44:39 -0600> From: [EMAIL PROTECTED]> Subject: Re: JCL parms> To: IBM-MAIN@BAMA.UA.EDU> > On Fri, 4 Jan 2008 21:29:55 +, Bill Wilkie wrote:> >

Re: JCL parms

On Fri, 4 Jan 2008 17:10:18 -0600, Paul Gilmartin wrote: >On Fri, 4 Jan 2008 16:44:39 -0600, Tom Marchant wrote: > >>On Fri, 4 Jan 2008 21:29:55 +, Bill Wilkie wrote: >>> >>>Perhaps a new parameter like NEWPARM=" " that way they could add >>>support for a larger list without affecting old code

Re: JCL parms

On Fri, 4 Jan 2008 16:44:39 -0600, Tom Marchant wrote: >On Fri, 4 Jan 2008 21:29:55 +, Bill Wilkie wrote: >> >>Perhaps a new parameter like NEWPARM=" " that way they could add >>support for a larger list without affecting old code. When you need it, >>just code the new name in the JCL and chec

Re: JCL parms

On Fri, 4 Jan 2008 21:29:55 +, Bill Wilkie wrote: > >Perhaps a new parameter like NEWPARM=" " that way they could add >support for a larger list without affecting old code. When you need it, >just code the new name in the JCL and check the program. *If* this were to be implemented, would y

Re: JCL parms

>To protect both the guilty and the innocent, some who have complained here >about things have then taken it up formally with Mr. Palmisano. Okay. I appologise to the list. I may have over-reacted. But, there are some who have complained and admitted they have just complained and not moved forwa

Re: JCL parms

Tom Marchant wrote: On Fri, 4 Jan 2008 15:27:56 -0600, McKown, John wrote: From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Blaicher, Chris I always parse right out of the parameter area passed to me by the caller. At worst I store the value in R1 so I can get back t

Re: JCL parms

On Fri, 4 Jan 2008 13:50:00 -0800, Ulrich Krueger wrote: >Gil, >We're strictly talking _JCL_-_PARM_ parameters here, where there does exist >a 100-byte length limit imposed by JCL syntax rules. Any program that is invoked in JCL can also be called by another program. Do you know any program th

Re: JCL parms

-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Friday, January 04, 2008 4:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JCL parms >However, initial discussion and concensus might be of some use to those who would like

Re: JCL parms

On Fri, 4 Jan 2008 15:27:56 -0600, McKown, John wrote: >> From: IBM Mainframe Discussion List >> [mailto:[EMAIL PROTECTED] On Behalf Of Blaicher, Chris >> >> I always parse right out of the parameter area passed to me by the >> caller. At worst I store the value in R1 so I can get back to it. And

Re: JCL parms

>> Beefing here is just so much f**t gas. >Not beefing, Ted, just wishing. Maybe beefing was too strong a word in this case. But, I have seen so many complaints here that never seem to be followed up with action. The same set of complaints come up all the time and the complainent(?) never seems

Re: JCL parms

>However, initial discussion and concensus might be of some use to those who >would like to prepare a request to IBM via SHARE. Has that ever happened? All I've seen is the same complaints month after month, with nobody ever mentioning that they have ever posted a requirement through SHARE or IB

Re: JCL parms

>> Beefing here is just so much f**t gas. You must have read the Toronto Star yesterday ;-) Actually, I did. But, I got the quote from Cheech in "Yellow Beard". - Too busy driving to stop for gas! -- For IBM-MAIN subscribe

Re: JCL parms

believing in Santa Claus and all I ever get is a lump of coal. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Friday, January 04, 2008 13:58 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JCL parms >If

Re: JCL parms

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL > Sent: Friday, January 04, 2008 3:58 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: JCL parms > > > >If the SET values do not exist in storage

Re: JCL parms

> Beefing here is just so much f**t gas. You must have read the Toronto Star yesterday ;-) http://www.thestar.com/living/article/290034 > Date: Fri, 4 Jan 2008 21:58:18 + > From: [EMAIL PROTECTED] > Subject: Re: JCL parms > To: IBM-MAIN@BAMA.UA.EDU > > >

Re: JCL parms

>If the SET values do not exist in storage anymore at the time of step >execution, perhaps IBM would be so good and consider making them available in >some standard interface / method ... CEEENV or ENVAR, as someone else >suggested, does sound good to me, too. Then make request through proper

Re: JCL parms

Paul Gilmartin Sent: Friday, January 04, 2008 13:19 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JCL parms On Fri, 4 Jan 2008 11:15:57 -0800, Ulrich Krueger wrote: >You know, guys, as much as I'd like to see the JCL PARM expanded in length, >I'd hate to see the problems that will arise

Re: JCL parms

On 4 Jan 2008 11:46:00 -0800, [EMAIL PROTECTED] (McKown, John) wrote: >Yes. I know of some programs which move the PARM into their own, >predefined, storage. Said storage is DC CL100. And they don't check that >the input is <=100 characters. Poor planning, but none-the-less. > >I also like my "env

Re: JCL parms

code. When you need it, just code the new name in the JCL and check the program. Bill > Date: Fri, 4 Jan 2008 13:45:42 -0600> From: [EMAIL PROTECTED]> Subject: Re: > JCL parms> To: IBM-MAIN@BAMA.UA.EDU> > > -Original Message-> > From: > IBM Mainframe Discu

Re: JCL parms

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Blaicher, Chris > Sent: Friday, January 04, 2008 3:25 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: JCL parms > > > I always parse right out of the paramet

Re: JCL parms

: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Friday, January 04, 2008 3:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JCL parms On Fri, 4 Jan 2008 11:15:57 -0800, Ulrich Krueger wrote: >You know, guys, as much as I'd like to see the JCL PARM exp

Re: JCL parms

On Fri, 4 Jan 2008 11:15:57 -0800, Ulrich Krueger wrote: >You know, guys, as much as I'd like to see the JCL PARM expanded in length, >I'd hate to see the problems that will arise from it. Face it, how many of >your programs that process PARM values have a hard-coded 100-byte storage >area to rece

Re: JCL parms

>it appears that JCL variables (SET) do not exist in any form available to the >initiator. They are processed and substituted during the conversion step. You cannot recreate the original JCL from the converter text. - Too busy driving to stop for gas! ---

Re: JCL parms

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of GAVIN Darren * OPS EAS > Sent: Friday, January 04, 2008 2:50 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: JCL parms > > > John, > > Or better yet an

Re: JCL parms

John, Or better yet an enhancement by IBM to the JES Sub System itself so that it pushes the JCL Variables into Environment Variables as soon as the Job first fires up. Also I think LE adds a routine for Environment Variables as well called CEEENV at Z/OS levels 1.7 and later. Darren __

Re: JCL parms

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee > Sent: Friday, January 04, 2008 1:38 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: JCL parms > > > On 4 Jan 2008 10:28:37 -0800, in bit.

Re: JCL parms

On 4 Jan 2008 10:28:37 -0800, in bit.listserv.ibm-main you wrote: >I'd be overjoyed if IBM would admit to the possibility of a parm string >up to 32,767 bytes, and design parm-driven software with that in mind. >And allow JCL to accept a parm of that length. Changes to code would be >minimal, s

Re: JCL parms

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Krueger > Sent: Friday, January 04, 2008 1:16 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: JCL parms > > > You know, guys, as much as I'd like to

Re: JCL parms

IL PROTECTED] On Behalf Of Rick Fochtman Sent: Friday, January 04, 2008 10:28 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JCL parms I'd be overjoyed if IBM would admit to the possibility of a parm string up to 32,767 bytes, and design parm-driven software with that in mind. And allow JCL to accept

Re: JCL parms

--- While I agree, I also disagree. There is really a big balancing act that IBM is always on and I can feel sympathy for them (to a certain extent). I would suggest that to implement something in this area to provide backward compatibility IBM could leave

Re: JCL parms

y a human-keyed language. > Date: Fri, 4 Jan 2008 11:44:36 -0600 > From: [EMAIL PROTECTED] > Subject: Re: JCL parms > To: IBM-MAIN@BAMA.UA.EDU > > Paul, > > While I agree, I also disagree. There is really a big balancing act > that IBM is always on and I can feel s

Re: JCL parms

On Jan 4, 2008, at 9:12 AM, Paul Gilmartin wrote: On Fri, 4 Jan 2008 02:17:36 -0500, J R wrote: You appear to be using a setup step(s) prior to invoking an application in a subsequent JCL step. Why not have the setup step invoke the application directly, thus avoiding the 100-character PARM

Re: JCL parms

On Fri, 4 Jan 2008 02:17:36 -0500, J R wrote: >You appear to be using a setup step(s) prior to invoking an application >in a subsequent JCL step. Why not have the setup step invoke the >application directly, thus avoiding the 100-character PARM limit of JCL? > Likely because the PARM to that

Re: JCL parms

bject: Re: JCL parms > To: IBM-MAIN@BAMA.UA.EDU > > That is more or less the solution we are using now: to circumvent the > limitations of PARM= we pipe the template through several steps of the > utility. Every step replaces as much of the variables in the template as > the PARM

Re: JCL parms

That is more or less the solution we are using now: to circumvent the limitations of PARM= we pipe the template through several steps of the utility. Every step replaces as much of the variables in the template as the PARM will allow. I consider this rather clumsy and was looking for a more elegant