Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
The PASCAL compiler on the RS/6000 (with AIX) allowed the file names to be specified by the use of environment variables. IIRC: if you had environment variables that matched the names in your program statement, that is program anyname (FILE1, FILE2, FILE3); you could specify the final file names that are used by the values of those environment variables (and paths, of course). Don't know, if these were the pure names of the environment variables, or if it was DD_FILE1=/u/data/file1 or something like this - which would have been funny. Kind regards Bernd Am 08.11.2013 01:08, schrieb Clark Morris: On 7 Nov 2013 10:38:24 -0800, in bit.listserv.ibm-main you wrote: ? I worked with at least 1 Unix shell that allowed the specification of file name to be in the batch script. Those who know UNIX/LINUX are better able to describe how this is done. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Just an idea: if this was possible on today's Linux and C, too, the migration of mainframe C programs to Linux, which open files using dd:somename would be much easier. ( I have this problem sometimes, because management decides that some of our mainframe based test supporting C programs should be moved to Linux 64 on Intel). For now, the solution is #ifdef MAINFRAME fopen /* this way */ #else fopen /* the other way */ #endif Kind regards Bernd Am 08.11.2013 10:48, schrieb Bernd Oppolzer: The PASCAL compiler on the RS/6000 (with AIX) allowed the file names to be specified by the use of environment variables. IIRC: if you had environment variables that matched the names in your program statement, that is program anyname (FILE1, FILE2, FILE3); you could specify the final file names that are used by the values of those environment variables (and paths, of course). Don't know, if these were the pure names of the environment variables, or if it was DD_FILE1=/u/data/file1 or something like this - which would have been funny. Kind regards Bernd Am 08.11.2013 01:08, schrieb Clark Morris: On 7 Nov 2013 10:38:24 -0800, in bit.listserv.ibm-main you wrote: ? I worked with at least 1 Unix shell that allowed the specification of file name to be in the batch script. Those who know UNIX/LINUX are better able to describe how this is done. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
In 7701653492190617.wa.paulgboulderaim@listserv.ua.edu, on 11/07/2013 at 02:04 PM, Paul Gilmartin paulgboul...@aim.com said: When I said a couple weeks ago that alternate DDNAMES should be handled by ATTACH, transparent to the application, someone asked, What about programs that scan the TIOT for specific DDNAMEs? Alas, that's a relic of the early resource-constrained implementation of OS. No. The requirement for applications to access system control blocks should be minimized in favor of APIs to obtain their content. If this had been done, moving the TIOT above the bar (very hypothetical example) would not impact existing application programs. But it still would have left the original problem unresolved. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On Fri, 8 Nov 2013 10:58:46 +0100, Bernd Oppolzer wrote: ( I have this problem sometimes, because management decides that some of our mainframe based test supporting C programs should be moved to Linux 64 on Intel). For now, the solution is #ifdef MAINFRAME fopen /* this way */ #else fopen /* the other way */ #endif An unforseen and unfortunate consequence of too-early binding to the file naming conventions of a particular OS. But, yes, environment variables: fopen( getenv( SYSUT1 ), getenv( SYSUT1_OPTS ) ); ... where, outside the C program, for z/OS: SYSUT1=//DD:SYSUT1 export SYSUT1 ... and for Linux: SYSUT1=/home/$LOGNAME/sysut1 export SYSUT1 ... and whatever is necessary for the OS-dependent options. (It would be useful if the syntax of DD were extended to allow the options to be embedded in the TIOT entry. Do PATHOPTS, PATHMODE, and FILEDATA provide sufficient support already? More likely for UNIX files than for legacy data sets.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Let me add another complains about JCL, it allows changing source code meaning in run time and sometimes this is hairy: //XXX DD DSN= // DCB=(LRECL=80,R //... The above is legit although I would fire anybody who doed it. R could be resolved to: // EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Ze'ev, I work with a product that would prevent this type of thing from happening. JCL that does not meet site requirements would never make it into production. It can also optionally be prevented from being added to the production batch schedule, if so desired. Regards, Mitch McCluhan, Legacy Modernization Consultant www.lcmg.us -Original Message- From: Ze'ev Atlas zatl...@yahoo.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, Nov 7, 2013 8:39 am Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) Let me add another complains about JCL, it allows changing source code meaning n run time and sometimes this is hairy: //XXX DD DSN= / DCB=(LRECL=80,R /... The above is legit although I would fire anybody who doed it. R could be esolved to: / EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice ZA -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
And to throw another twist to this thread, some people say the LRECL and RECFM should not be coded in the JCL. That way when a change is made to the program source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to be updated. What are some opinions about that methodology? --- mitc...@aol.com wrote: From: Mitch mitc...@aol.com To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) Date: Thu, 7 Nov 2013 12:34:39 -0500 Ze'ev, I work with a product that would prevent this type of thing from happening. JCL that does not meet site requirements would never make it into production. It can also optionally be prevented from being added to the production batch schedule, if so desired. Regards, Mitch McCluhan, Legacy Modernization Consultant www.lcmg.us -Original Message- From: Ze'ev Atlas zatl...@yahoo.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, Nov 7, 2013 8:39 am Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) Let me add another complains about JCL, it allows changing source code meaning n run time and sometimes this is hairy: //XXX DD DSN= / DCB=(LRECL=80,R /... The above is legit although I would fire anybody who doed it. R could be esolved to: / EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice ZA -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On 11/7/2013 12:41 PM, Richard Pinion wrote: And to throw another twist to this thread, some people say the LRECL and RECFM should not be coded in the JCL. That way when a change is made to the program source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to be updated. What are some opinions about that methodology? DCB parameters should never be required for input files. An output block size should be used only in special situations (e.g., transfer to another system). For output files, I prefer to leave the attributes to the DCB exit, allowing me to route print to a PDS without destroying it (and the program/subroutine handles padding). What I detest are programs where nothing is specified, and there are no defaults, requiring explicit DCB parameters on each statement. I'm unhappy about the utilities, and sloppy CoBOL, forcing the DCB parameters thus requiring an extra step to copy the output someplace else with appropriate padding and carriage control conversion. I wish that IBM had provided a single output routine for the utilities, and made it generally available as a subroutine. (Ditto with writing messages) Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote: And to throw another twist to this thread, some people say the LRECL and RECFM should not be coded in the JCL. That way when a change is made to the program source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to be updated. What are some opinions about that methodology? If by changing the program source you mean coding LRECL and RECFM in the DCB, the JCL needn't be changed. Values coded in the DCB quietly override any coded in JCL. Shouldn't a warning of such disagreement be issued? I believe so, but via what channel? -Original Message- From: Ze'ev Atlas Sent: Thu, Nov 7, 2013 8:39 am Let me add another complains about JCL, it allows changing source code meaning n run time and sometimes this is hairy: //XXX DD DSN= / DCB=(LRECL=80,R /... The above is legit although I would fire anybody who doed it. R could be esolved to: / EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice I applaud languages such as Rexx in which lexical metacharacters are never recognized in text introduced by variable substitution. Rexx provides a workaround in the ever-so-controversial INTERPRET instruction. My first mentor in JCL had a habit disabling options by defaulting a PROC parameter to ' ' and enabling them by substituting ''. E.g.: FOO PROC C=' ' (set C='' to bypass step!) SEXEC PGM=WOMBATC,COND=(0,LE) PEND (Now you know how I got to be the way I am.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On 7 November 2013 12:41, Richard Pinion rpin...@netscape.com wrote: And to throw another twist to this thread, some people say the LRECL and RECFM should not be coded in the JCL. That way when a change is made to the program source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to be updated. What are some opinions about that methodology? Taking that to the extreme one could say that nothing should be coded on DD statements, i.e. that programs should deal with DSNAMEs rather then the intermediary of DDNAMEs. Which is indeed how most non-z/OS systems work. The late binding provided by DD statements is one of the strongest, if clumsiest, things about OS/360 and its descendants. Why should this not apply to LRECL, RECFM, and the other DCB parameters as much as anything else? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Paul (et al): As I have been alluding to, I work with a product that can do all of what has been discussed here, or any flavor of it. It can be invoked in a variety of ways, from direct calls, to part of an automated change management process, to flagging JCL at submission time to error notification when a schedule is built, to actually capturing the JCL as it is being written to the scheduler and changed (with the appropriate notifications made) so that the production batch environment NEVER fails with these types of conditions. Regards, Mitch McCluhan, Legacy Modernization Consultant www.lcmg.us -Original Message- From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, Nov 7, 2013 10:23 am Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote: And to throw another twist to this thread, some people say the LRECL and RECFM hould not be coded in the JCL. That way when a change is made to the program ource, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to e updated. What are some opinions about that methodology? f by changing the program source you mean coding LRECL and RECFM in the CB, the JCL needn't be changed. Values coded in the DCB quietly override ny coded in JCL. Shouldn't a warning of such disagreement be issued? believe so, but via what channel? -Original Message- From: Ze'ev Atlas Sent: Thu, Nov 7, 2013 8:39 am Let me add another complains about JCL, it allows changing source code meaning n run time and sometimes this is hairy: //XXX DD DSN= / DCB=(LRECL=80,R /... The above is legit although I would fire anybody who doed it. R could be esolved to: / EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice applaud languages such as Rexx in which lexical metacharacters are ever recognized in text introduced by variable substitution. Rexx rovides a workaround in the ever-so-controversial INTERPRET instruction. My first mentor in JCL had a habit disabling options by defaulting PROC parameter to ' ' and enabling them by substituting ''. .g.: FOO PROC C=' ' (set C='' to bypass step!) EXEC PGM=WOMBATC,COND=(0,LE) PEND (Now you know how I got to be the way I am.) -- gil -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Doing that would make the JCL poor (or apparently contradictory) documentation. So I would hope the disagreement would be flagged somehow. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@listserv.ua.edu Date: 07/11/2013 18:23 Subject:Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote: And to throw another twist to this thread, some people say the LRECL and RECFM should not be coded in the JCL. That way when a change is made to the program source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to be updated. What are some opinions about that methodology? If by changing the program source you mean coding LRECL and RECFM in the DCB, the JCL needn't be changed. Values coded in the DCB quietly override any coded in JCL. Shouldn't a warning of such disagreement be issued? I believe so, but via what channel? -Original Message- From: Ze'ev Atlas Sent: Thu, Nov 7, 2013 8:39 am Let me add another complains about JCL, it allows changing source code meaning n run time and sometimes this is hairy: //XXX DD DSN= / DCB=(LRECL=80,R /... The above is legit although I would fire anybody who doed it. R could be esolved to: / EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice I applaud languages such as Rexx in which lexical metacharacters are never recognized in text introduced by variable substitution. Rexx provides a workaround in the ever-so-controversial INTERPRET instruction. My first mentor in JCL had a habit disabling options by defaulting a PROC parameter to ' ' and enabling them by substituting ''. E.g.: FOO PROC C=' ' (set C='' to bypass step!) SEXEC PGM=WOMBATC,COND=(0,LE) PEND (Now you know how I got to be the way I am.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On Thu, 7 Nov 2013 13:37:54 -0500, Tony Harminc wrote: Taking that to the extreme one could say that nothing should be coded on DD statements, i.e. that programs should deal with DSNAMEs rather then the intermediary of DDNAMEs. Which is indeed how most non-z/OS systems work. In UNIX, I see the analogue of DDNAME as the descriptor. If a program insists on writing to stdout (descriptor 1, analogous to SYSTERM), I can redirect with: program 1logfile And, this handled correctly (IMO) by the kernel. The subject program needn't process, nor even be aware of, the redirection, in sharp contrast to the handling of the alternate DDNAME list in OS. So, I'll take the view quite opposite to yours. If the program looks for copybooks in SYS1.MACLIB, that's an undesirable early binding; if it looks in SYSLIB that's a preferable late binding that can be deferred until the programmer codes the JCL. When I said a couple weeks ago that alternate DDNAMES should be handled by ATTACH, transparent to the application, someone asked, What about programs that scan the TIOT for specific DDNAMEs? Alas, that's a relic of the early resource-constrained implementation of OS. The requirement for applications to access system control blocks should be minimized in favor of APIs to obtain their content. If this had been done, moving the TIOT above the bar (very hypothetical example) would not impact existing application programs. ... The late binding provided by DD statements is one of the strongest, if clumsiest, things about OS/360 and its descendants. Why should this not apply to LRECL, RECFM, and the other DCB parameters as much as anything else? Some HLL runtime libraries can readily deal with diverse RECFMs for a given DDNAME, even transparently to the application code. Most assembler programs are not coded that way. (Ed J. might jump in with exceptions.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On 7 Nov 2013 10:38:24 -0800, in bit.listserv.ibm-main you wrote: On 7 November 2013 12:41, Richard Pinion rpin...@netscape.com wrote: And to throw another twist to this thread, some people say the LRECL and RECFM should not be coded in the JCL. That way when a change is made to the program source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to be updated. What are some opinions about that methodology? Taking that to the extreme one could say that nothing should be coded on DD statements, i.e. that programs should deal with DSNAMEs rather then the intermediary of DDNAMEs. Which is indeed how most non-z/OS systems work. The late binding provided by DD statements is one of the strongest, if clumsiest, things about OS/360 and its descendants. Why should this not apply to LRECL, RECFM, and the other DCB parameters as much as anything else? I worked with at least 1 Unix shell that allowed the specification of file name to be in the batch script. Those who know UNIX/LINUX are better able to describe how this is done. Clark Morris Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCL (was: Re: Aging Sysprogs = Aging Farmers)
On Nov 6, 2013, at 8:45 AM, David Crayford dcrayf...@gmail.com wrote: Hey, how do I do a loop in this code? Forget it kid, they didn't have rewind on punch card readers. I think much of the disdain for JCL comes from inaccurate expectations set by calling it a “language”. JCL is *not a programming language*. It’s not even a minimal scripting language. It’s the punch-card-technology equivalent of gestures like double-clicking an app icon or selecting “open” from a file menu in a modern GUI. Yes, it’s far from perfect. The condition code thing is pretty goofy (although you’ve been able to use IF constructs instead for over two decades) and a lot of keywords and values are pretty obscure. But for what it was actually designed to do, it works pretty well. -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
quote it works pretty well. /quote Yeah, once you get past the backwards idea of executing the program before you allocate the datasets. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Wednesday, November 06, 2013 10:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JCL (was: Re: Aging Sysprogs = Aging Farmers) On Nov 6, 2013, at 8:45 AM, David Crayford dcrayf...@gmail.com wrote: Hey, how do I do a loop in this code? Forget it kid, they didn't have rewind on punch card readers. I think much of the disdain for JCL comes from inaccurate expectations set by calling it a language. JCL is *not a programming language*. It's not even a minimal scripting language. It's the punch-card-technology equivalent of gestures like double-clicking an app icon or selecting open from a file menu in a modern GUI. Yes, it's far from perfect. The condition code thing is pretty goofy (although you've been able to use IF constructs instead for over two decades) and a lot of keywords and values are pretty obscure. But for what it was actually designed to do, it works pretty well. -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Many organizations of linguists discourage, even forbid generic discussions of the origins of language on the ground that these discussions produce only acrimony. Perhaps we should avoid discussions of JCL, good or bad? in the same spirit. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Folks, I find it interesting that people are still talking about the various levels of difficulty in managing and coding JCL. Curtis, you are absolutely right, JCL is not a true language, but it is something that each individual has their own nuances with. Having said this, there are a number of tools on the market for managing JCL and a couple that can actually manipulate and create JCL. I have been in the JCL automation tool market space for 30 years and I can say unequivocally that I am shocked at the number of shops that have no JCL tool, an older JCL tool that just provides the basics, or a tool that can do some things, but not everything. I am available to talk with anyone offline from this discussion of you want to know more. Regards, Mitch McCluhan, Legacy Modernization Consultant www.lcmg.us -Original Message- From: Pew, Curtis G curtis@austin.utexas.edu To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, Nov 6, 2013 8:15 am Subject: JCL (was: Re: Aging Sysprogs = Aging Farmers) On Nov 6, 2013, at 8:45 AM, David Crayford dcrayf...@gmail.com wrote: Hey, how do I do a loop in this code? Forget it kid, they didn't have rewind on punch card readers. I think much of the disdain for JCL comes from inaccurate expectations set by alling it a “language”. JCL is *not a programming language*. It’s not even a inimal scripting language. It’s the punch-card-technology equivalent of estures like double-clicking an app icon or selecting “open” from a file menu n a modern GUI. Yes, it’s far from perfect. The condition code thing is pretty goofy (although ou’ve been able to use IF constructs instead for over two decades) and a lot of eywords and values are pretty obscure. But for what it was actually designed to o, it works pretty well. -- urtis Pew (c@its.utexas.edu) TS Systems Core he University of Texas at Austin -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On Wed, 2013-11-06 at 16:15 +, Pew, Curtis G wrote: JCL is *not a programming language*. I might have made the same claim on the basis that JCL isn't Turing-complete, but a minimal amount of googling informs me that programming languages need not be Turing-complete. JCL is a language. You sort-of program in it. QED. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
On Wed, 6 Nov 2013 12:35:37 -0500, Mitch wrote: ..., there are a number of tools on the market for managing JCL and a couple that can actually manipulate and create JCL. For money!? I build most of my JCL with either Rexx EXECs or POSIX shell (plus sed and awk) scripts. It relieves me of the need to wash my hands so frequently. Let's talk about the archaic LRECL limitations of the SUBMIT command(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
