Re: JCL Question

a DSN (assuming the job runs today at 22:59) of: SYSTAPE.Z13DL1.D110712.T2259 There are literally hundreds (well, maybe "a lot" is a better term) of JCL variables that you can create using the exit and you are not limited to running as a Started Task for any of them. Some people don

Re: JCL Question

W dniu 2011-07-12 21:36, Ted MacNEIL pisze: I disagree. JCL meets all criteria to be a programming language. It doesn't do everything, but what language does? Watch the name: JOB CONTROL language. In fact there is no big value in JCL classification, especially as there is no single

Re: JCL Question

On Wed, 13 Jul 2011 10:28:33 +0200 "R.S." wrote: :>W dniu 2011-07-12 21:36, Ted MacNEIL pisze: :>> I disagree. :>> JCL meets all criteria to be a programming language. :>> It doesn't do everything, but what language does? :>Watch the name: JOB CONTROL l

Re: JCL Question

W dniu 2011-07-13 10:44, Binyamin Dissen pisze: On Wed, 13 Jul 2011 10:28:33 +0200 "R.S." wrote: :>W dniu 2011-07-12 21:36, Ted MacNEIL pisze: :>> I disagree. :>> JCL meets all criteria to be a programming language. :>> It doesn't do everything, but what l

Re: JCL Question

I'd likely use JES exit 2 to insert // SET DATE=... // SET TIME=... and so on into the JCL stream immediately after the JOB card. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225

Re: JCL Question

On 7/13/2011 6:52 AM, R.S. wrote: No, in general it is matter of definition. My English is poor, but let me present another example, as off topic as dog's one: A car. In my country, Combi (Wagon) car is named in folders as 5-doors car. Hatchback is also 5-doors or 3-doors. Does anyone use the tai

Re: JCL Question

In , on 07/12/2011 at 03:35 PM, Jonathan Goossen said: >Job Control Language Gesundheit! That's not even a claim that it's a programming language. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see We don't care. We don

Re: JCL Question

th recursion rather than explicit loops, but JCL doesn't have that either. -- 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

Re: JCL Question

In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on 07/12/2011 at 12:57 PM, "Staller, Allan" said: >IIRC, static system symbols can be substituted in JCL. For STC and TSU, but not for batch. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO

Re: JCL Question

In <1340844227-1310499369-cardhu_decombobulator_blackberry.rim.net-208261873-@b12.c1.bise6.blackberry>, on 07/12/2011 at 07:36 PM, Ted MacNEIL said: >I disagree. >JCL meets all criteria to be a programming language. Nonsense. >It doesn't do everything, but what langua

Re: JCL Question

DD DSN=SHRT.DUMMY.D&MCDATE,UNIT=VIO,SPACE=(TRK,(1,1)) The expanded JCL after execution looks like this: 1 //BJKBR14 JOB 1,'BRYAN K.',CLASS=Z,MSGCLASS=X,MSGLEVEL=(1,1) JOB54091 2 //INCL INCLUDE MEMBER=MCDATE XX*

Re: JCL Question

How about EZACFSM1? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mosley, George Sent: Tuesday, July 12, 2011 1:28 PM To: IBM-MAIN@bama.ua.edu Subject: JCL Question Hello All. We're trying to set up a batch job that will app

Re: JCL Question

On Wed, Jul 13, 2011 at 1:07 PM, Shmuel Metz (Seymour J.) wrote: > >>Looping constructs are not required to make it a programming >>language. > > The ability to iterate is. Of course, that can be done with recursion > rather than explicit loops, but JCL

Re: JCL Question

> The ability to iterate is. Of course, that can be done with recursion > rather than explicit loops, but JCL doesn't have that either Looping/iteration, while desirable, is NOT a requirement to be a programming language. Just stepping through is adequate! - Ted MacNEIL eamacn.

Re: JCL Question

> The trick is to run a process at 23:59:59 everyday to update the MCDATE > member > in a proclib that is in your JES2 proclib concatenation. We've done this for > years and it works well. This is exactly what we do at our shop. In case the user needs to use variables in SYSIN DD type datase

Re: JCL Question

W dniu 2011-07-13 14:52, McKown, John pisze: I'd likely use JES exit 2 to insert // SET DATE=... // SET TIME=... and so on into the JCL stream immediately after the JOB card. And I like Job Scheduler Utilities for such purposes. For example ControlM has %%variables, with strong suppor

Re: JCL Question

In , on 07/13/2011 at 09:04 PM, Mike Schwab said: >I have done an IEBGENER to a INTRDR to run the same job until I broke >the loop. That's not iteration in JCL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see <http://patriot.net/~shmuel/resume/b

Re: JCL Question

R. Skorupka wrote: >I believe this is main reason why JCL haven't been enhanced to have such >facilities. BIG customers - those which IBM listen to - already have such >facilities (in Job Scheduler) and have no reason to push IBM. Partly true, but the actual reason has been sta

Re: JCL Question

rote: > R. Skorupka wrote: > >> I believe this is main reason why JCL haven't been enhanced to have such >> facilities. BIG customers - those which IBM listen to - already have such >> facilities (in Job Scheduler) and have no reason to push IBM. > > Partly tru

Re: JCL Question

W dniu 2011-07-14 19:56, Elardus Engelbrecht pisze: R. Skorupka wrote: I believe this is main reason why JCL haven't been enhanced to have such facilities. BIG customers - those which IBM listen to - already have such facilities (in Job Scheduler) and have no reason to push IBM. P

Re: JCL Question

R.Skorupka wrote: >I dare to disagree. Completely. Feel free to do that. Search the archives. My reply is for those who don't have those automation software. >1. ControlM (and others) did that despite of the reasons above. Agreed. I'm indeed using those %%variables to generate datasets and rep

Amusing JCL Oddity

One would think that the following would generate a JCL error. Well, not on my system (zOS 1.08). Takes the first values for SP1 & SP2. Go figure //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=05

JCL "Mass Editor"

Hi, I am is seeking a JCL "Mass Editor" (basically, multiple file search and replace in an LPAR). We have 3,000 JCL scripts and are seeking to make changes to upgrade SAS versions. Would you know of an appropriate tools to use (I know that someone could write scripts to examine the J

Simple JCL Question

Hello IBM-Main, can I split a PARM on the EXEC statement, which is too long, in two parts (on two lines), without having a comma inserted? Thanks, regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions

JCL region parameter

Hi, I encountered the following error when i submitted a job while this disappared when the same job was executed via a PROC. IDI0001I Fault Analyzer V5R1M0 (UK15655 2006/06/26) invoked by IDIXDCAP using SY eror code was IEF450I SSPMKNCE S50EXT - ABEND=S000 U REASON= 043 Wi

JCL PROCEDURE QUESTION

I'm doing the following as shown below and receiving the following errors yet as far as I can see this should be o.k. Any suggestions would be appreciated. Thanks 2 //JST0010 EXEC PROC=SY065X, // FUNCTION=OPERLOG, // TYPE=CURRENT, // ENV=E18823, //

JCL Parm= Question

Apologies in advance when the answer ends in a Doh! moment. How do I code the PARM= in JCL such that each parm gets its own address? Both of these: PARM='ABC,DEF' or PARM=('ABC','DEF') end with one address pointed to by R1 with the high bit set, instead of

Re: JCL parser

On Fri, 22 Aug 2008 09:05:41 -0500 John McKown <[EMAIL PROTECTED]> wrote: :>Just to prove that I am indeed insane, I am attempting to write a JCL :>parser using the "flex" (lexical analyzer generator) and "bison" (parser :>generator) programs on Linux. Agai

Re: JCL parser

John McKown wrote: Just to prove that I am indeed insane, I am attempting to write a JCL parser using the "flex" (lexical analyzer generator) and "bison" (parser generator) programs on Linux. Again, this is just so that I can learn how to use those tools, not for

Re: JCL parser

Is JCL LALR(1) ? If not, I believe you will have to use a different parser generator, perhaps ANTLR. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of John McKown Sent: Friday, August 22, 2008 9:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: JCL parser

Re: JCL parser

On Fri, 22 Aug 2008, Schneiderwent, Craig wrote: > Is JCL LALR(1) ? If not, I believe you will have to use a different parser > generator, perhaps ANTLR. > That's a good question. And I'm so ignorant, I don't know how to tell. If it isn't, then I guess that I&

Re: JCL parser

Thomas David Rivers wrote: By the way - you can download flex/bison utilities that run on MVS from the 'freebies' section on our web site. - Dave Rivers - I just took a quick look - most of the text references OS/390. Does that mean things won't run on more current systems, or just tha

Re: JCL parser

In <[EMAIL PROTECTED]>, on 08/22/2008 at 09:05 AM, John McKown <[EMAIL PROTECTED]> said: >does anybody think that donating >this to the CBT would be worth while? Yes. >I was thinking either a tree structure which describes the JCL, Yes. >maybe the JCL converted

Re: JCL parser

You're not the only insane one! I've already written a JCL parser in Rexx (JCL2XML) as part of CBT File 647 (XML Parser in Rexx). I wonder whether 'flex' is flexible enough to cope with the relatively complicated JCL line continuation rules. Sure gave m

Re: JCL parser

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Armstrong > Sent: Thursday, August 28, 2008 6:23 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: JCL parser > > You're not the only insane one! I've

JCL parser status

Well, on the off chance that anybody is interested, my creating a JCL parser using Flex and Bison is coming along. My implementation is to read a single JOB and create XML output. Parts of my code are "crufty" because JCL is "crufty". But whoever designed the IF statem

STC JCL Question

of the other regions, just a particular one. What we found was in the STEPLIB statement, on the line where we had the SDFHLPA, the numbers that should be in columns 72-80 were pulled to the left, probably an oversight when the dataset name was changed. The JCL is below. You would think it

Re: JCL Problem...

: 214-775-3641 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Michael Knigge Sent: 22 October 2008 10:37 To: IBM-MAIN@BAMA.UA.EDU Subject: JCL Problem... All, I have a utility that outputs a string to SYSPRINT (but that can be changed). Now I

Re: JCL Problem...

EMAIL PROTECTED] On Behalf Of Michael Knigge Sent: 22 October 2008 10:37 To: IBM-MAIN@BAMA.UA.EDU Subject: JCL Problem... All, I have a utility that outputs a string to SYSPRINT (but that can be changed). Now I need to pass this string via SYSIN (or PARM) together with some other parameters to a s

Re: JCL Problem...

On Wed, 22 Oct 2008 11:37:12 +0200, Michael Knigge <[EMAIL PROTECTED]> wrote: >All, > > >I have a utility that outputs a string to SYSPRINT (but that can be >changed). Now I need to pass this string via SYSIN (or PARM) together >with some other parameters to a second utility. > >A little "pseudo-s

Re: JCL Problem...

On Wed, 22 Oct 2008 07:18:58 -0500, Scott Barry wrote: >On Wed, 22 Oct 2008 11:37:12 +0200, Michael Knigge wrote: >>//* >>//* IMAGINE FOO WILL OUTPUT AN IP-ADDRESS - BUT THE ADDRESS >>//* IS OF COURSE NOT KNOWN... >>//* >>//STEP01 EXEC PGM=FOO >>//SYSPRINT DD SYSOUT=* >>//* >>//* NOW I NEED TO

Re: JCL Problem...

Flint, Mike schrieb: Is there any reason why you aren't pointing SYSPRINT (or whatever) at a temporary (or permanent) file, and using that file as the SYSIN dataset for STEP02? For what reason do you *need* the SYSIN data to be instream? I don't really need it instream - it was just to clarify

ASG-PRO/JCL

Does anyone have experience with ASG's JCL/XREF (PRO/JCL and INFO/X Enterprise)? ASG has presented a proposal to move us away from ASG-JCLPREP to PRO/JCL. -- For IBM-MAIN subscribe / signoff / archive access instructions,

Another JCL "wish".

This may be another weird desire on my part. But I'm wondering why IBM does not enhance the QSAM and BSAM access methods to support the OPTCD=Q and CCSID= parameters on the DD statememt to work with datasets on media other than tape. Especially z/OS UNIX files. There are times when I would reall

Re: JCL PROBLEM

ailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes > Sent: Tuesday, June 05, 2012 4:02 PM > To: IBM-MAIN@bama.ua.edu > Subject: JCL PROBLEM > > G'Day, >   > I am having a problem (jcl error) trying to run this job.  > The object is to have

Re: JCL PROBLEM

At what step do you get this error? PROC001, PROC003, etc... Lizette -Original Message- >From: John Dawes >Sent: Jun 5, 2012 2:01 PM >To: IBM-MAIN@bama.ua.edu >Subject: JCL PROBLEM > >G'Day, >  >I am having a problem (jcl error) trying to run this job.

Re: JCL PROBLEM

At PROC002 //STEP01.TAPE From: Lizette Koehler To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:06 PM Subject: Re: JCL PROBLEM At what step do you get this error?  PROC001, PROC003, etc... Lizette -Original Message- >From: John Dawes &g

Re: JCL PROBLEM

I'll try out your suggestion.  Thanks. From: "McKown, John" To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:05 PM Subject: Re: JCL PROBLEM I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE --

Re: JCL PROBLEM

communication and leadership skills checkout Woodwinds Toastmasters. IBM Mainframe Discussion List wrote on 06/05/2012 04:05:05 PM: > From: "McKown, John" > To: IBM-MAIN@bama.ua.edu > Date: 06/05/2012 04:05 PM > Subject: Re: JCL PROBLEM > Sent by: IBM Mainframe Discussion L

Re: JCL PROBLEM

ussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jonathan Goossen > Sent: Tuesday, June 05, 2012 4:15 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: JCL PROBLEM > > I agree. > > Your names are confusing. PROC001 is the step name. STEP01 is > the proc > step name.

Re: JCL PROBLEM

John,   You were spot on.  Your suggestion worked.  Thanks a million.   Thanks to all who responded for my plea for help. From: "McKown, John" To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:05 PM Subject: Re: JCL PROBLEM I'm fairly su

Re: JCL PROBLEM

Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes wrote: > John, > > You were spot on.  Your suggestion worked.  Thanks a million. > > Thanks to all who responded for my plea for help. -- Mike A Schwab, Springfield IL USA Where do Fo

Re: JCL PROBLEM

e MEGA >Life and Health Insurance Company.SM > >> -Original Message- >> From: IBM Mainframe Discussion List >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes >> Sent: Tuesday, June 05, 2012 4:02 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: J

Re: JCL PROBLEM

Thanks for the tip.  If I need to code the vol parm  e.g. VOL=(,,,35)  if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. From: Mike Schwab To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5

Re: JCL PROBLEM

nd name for products underwritten and >>issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake >>Life Insurance Company®, Mid-West National Life Insurance Company of >>TennesseeSM and The MEGA Life and Health Insurance Company.SM >> >>> -O

Re: JCL PROBLEM

The keywords go after the positional parameters. On Tue, Jun 5, 2012 at 5:21 PM, John Dawes wrote: > Thanks for the tip.  If I need to code the vol parm  e.g. VOL=(,,,35)  if the > output exceedes 5 vols (system default) how would I go about it since I > already have a vol parm i

Re: JCL PROBLEM

TACLAS, you can set the "volume count" to something else. We started having problems with some backups of files which had ballooned suddenly, which was causing a lot of abends due to exceeding tape volumes. There were simply too many JCL streams to update in a timely manner (chang

Re: JCL PROBLEM

John, May I ask where you work? My friends in Australia may know some of the management folks at your site. Is there anything I can send to you to help your cause? What types of JCL issues do you typically have? May I ask what batch scheduler you use? Change management tool? .anything

Re: JCL PROBLEM

Where I work is in all my sig lines. Doesn't matter, if you're thinking of anything that costs money. We aren't spending any more than we currently do. And we may actually get more budget cuts in 2013. Our main OEM vendor is CA. We don't normally have JCL problems, the

JCL procedure parameters

A recent discussing in ASSEMBLER-LIST reminded me of something I tried to figure out a while ago (and didn't): Is is possible to somehow retrieve the JCL procedure parameters and their values in a program that's invoked in that procedure? I browsed the documentation of a large

Re: JCL parms

elegant solution that could be implemented in a single step. What we really need of course is variabel substitution in inline data by the system: // EXEC PGM=XXX //SYSINDD * PRINT &DATASET(&MEMBER) /* // where JES2, JES3, MVS or whatever treats those &VARs just like JCL pa

Re: JCL parms

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? > Date: Fri, 4 Jan 2008 07:55:12 +0100 > From: [EMAIL PROTECTED] > Su

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

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

Re: JCL parms

yed 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 a halfword length. Changes to JCL processing might be rather

Re: JCL parms

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 receive the PARM string into? Just about all of them,

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

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 woul

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

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 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

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

>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 f

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-by

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

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 one called _program_ to another called _program_ is a completely different animal and therefore not subject to the 100-byte

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

>> 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

> 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

> -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. Not beefing, Ted, just wishing. And following along someone else's "I wish there was ..." post, adding my 2cents' worth to it. And, I'm well aware of proper channels. However, changes and improvements to the JCL PARM length l

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

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

se written routines which use PARM than vendor routines. 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 coded in the

Re: JCL parms

L programmer would likely do. My worries for this would be more >about in-house written routines which use PARM than vendor routines. 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 pr

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 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 kn

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, >>

Re: JCL parms

t;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 you expect that the program would >>be passed two parameters, a short one and a long one? >&g

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 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

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 receive the PARM string into?

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

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 par

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 >

<    1   2   3   4   5   6   7   8   9   10   >