Jol - JCL Replacement Language - was JCL sheesh! for today
Would you like a free format language, similar to PL/i? Like full arithmetic and IF testing on Symbolic Variables? Like to be able to have inline card image files, and be able to replace symbolic parameters in them to dynamically create specialized control cards? Like to have your job checked for all data set availability before it starts? (No Not Found messages) Like 3,000 characters as parameter fields? Like the ability to actually create new user friendly commands for your users to use? Like to make Z/OS MUCH easier to use, and easier to sell? Like to be able to submit jobs every Monday? But not Monday the 31st? Like to have run the job under TSO, or submit it to Batch - unchanged? Like to have a Windows or OS/2 program make the JCL off line and submit to Z/OS? And MUCH more. Check out Jol at http://jol.oscar-jol.com/ And I'll answer some of the posts with a Jol solution over the next few days. Cheers, Clem Clarke -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 1698154905956185.wa.paulgboulderaim@bama.ua.edu, on 12/12/2011 at 08:06 PM, Paul Gilmartin paulgboul...@aim.com said: As in RC = BPXWDYN( ... )? Exectly. Well, RC really is a variable. A variable with a misleading name and one that you are liable to step on inadvertently when you add code. It has some special behaviors, as does SIGL. (Others? RESULT. In OOREXX there are others, but AFAIK that's not available on z/OS or z/VM. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Mon, 12 Dec 2011 23:21:08 -0500, Shmuel Metz (Seymour J.) wrote: In 1698154905956185.wa.paulgboulderaim@bama.ua.edu, on 12/12/2011 at 08:06 PM, Paul Gilmartin said: As in RC = BPXWDYN( ... )? Exectly. Well, RC really is a variable. A variable with a misleading name and one that you are liable to step on inadvertently when you add code. What would be a less misleading name? LASTCC simply because it's used by other utilities? I used it quite in the spirit of its special use; an indicator of the success or failure of the operation. You might better fault me for not checking for errors after the call. But it's a test, and I had trace R turned on. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 4958036703080127.wa.paulgboulderaim@bama.ua.edu, on
12/13/2011
at 09:27 AM, Paul Gilmartin paulgboul...@aim.com said:
What would be a less misleading name?
BPXresult? DYNresult? Anything that suggests that it is the result
from the BPXWDYN.
LASTCC simply because it's used by other utilities?
Definitely not, as it isn't a condition code.
I used it quite in the spirit of its special use; an indicator of
the success or failure of the operation.
Its special use is to indicate the success or failure of commands, not
of subroutine calls. I'd probably write something like
call BPXWDYN 'free dd(SYSUT1) msg(WTP)'
call BPXWDYN 'alloc dd(SYSUT1) pathopts(ORDONLY) filedata(TEXT)' ,
'path('''CWD'/'TestDir'/X'')' ,
'recfm(V) lrecl(99) msg(WTP)'
If I were testing the result then I might do something like
if result ¬= 0 then do
say BPXWDYN 'returned' result
exit
end
or imbed the BPXWDYN in an IF:
if BPXWDYN('free dd(SYSUT1)msg(WTP)') ¬= 0 then do
say BPXWDYN('free dd(SYSUT1)msg(WTP)') failed
exit
end
If I needed to retain the value for more than a line or two then I'd
call it something suggestive of BPXWDYN result.
--
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Ed Gould ps2...@yahoo.com wrote in message news:1323450663.14671.yahoomailmob...@web161404.mail.bf1.yahoo.com... Gil, It sounds like production is not fully implemented in the company. JCL, maybe but not where execution source resides. I have wired in places like that and it can be a nightmare. Ed That is one reason. Another is flexibility. In the SAS coding the user can calculate the exact dsname as it should be used in this run. JCL is not that flexible. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, December 11, 2011 2:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today In 9480536010373504.wa.paulgboulderaim@bama.ua.edu, on 12/11/2011 at 12:00 PM, Paul Gilmartin paulgboul...@aim.com said: At least one word. Sometimes several. Always enough to identify the text that I an responding to. If I'm responding to an entire paragraph then I quote the entire paragraph, but I don't quote extraneous text as some here do. Actually, often it is difficult to know what you are replying to and the attribution requires extra clicks, windows and effort. If fact, until this latest exchange, I had not previously noticed these links in your replies. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Kees, I think I would disagree with the flexibililty issue as all it takes some imagination with JCL and symbolic for the DSN in this case. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Saturday, December 10, 2011 8:05 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today snip C, for example, allows as many or as few (even only one) tokens on each line. C has no problem with zero tokens on a line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 3897078350657311.wa.paulgboulderaim@bama.ua.edu, on 12/11/2011 at 04:04 PM, Paul Gilmartin paulgboul...@aim.com said: OK. Done. Does this say the right stuff? Yes. Is the example suitable?: Yes, other than using RC as a variable name. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 0de6a9840123e547b061ac5b6765c026240...@exmb-05.ad.wsu.edu, on 12/12/2011 at 08:55 AM, Gibney, Dave gib...@wsu.edu said: Actually, often it is difficult to know what you are replying to and the attribution requires extra clicks, windows and effort. No. If fact, until this latest exchange, I had not previously noticed these links in your replies. Then it obviously didn't require extra clicks, etc. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Actually, even attempting to access the link provided here was unhelpful. I really don't care. Sometime your messages contain useful enough info to continue to read them long enough to hit the delete :) I would guess as much as 20% of time, there is enough context and your reply is timely. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, December 12, 2011 8:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today In 0de6a9840123e547b061ac5b6765c026240...@exmb-05.ad.wsu.edu, on 12/12/2011 at 08:55 AM, Gibney, Dave gib...@wsu.edu said: Actually, often it is difficult to know what you are replying to and the attribution requires extra clicks, windows and effort. No. If fact, until this latest exchange, I had not previously noticed these links in your replies. Then it obviously didn't require extra clicks, etc. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Mon, 12 Dec 2011 11:12:44 -0500, Shmuel Metz (Seymour J.) wrote: Is the example suitable?: Yes, other than using RC as a variable name. As in RC = BPXWDYN( ... )? Well, RC really is a variable. It has some special behaviors, as does SIGL. (Others? None come immediately to mind.) I really wish that any setting of RC0, as by assignment, parse, etc. would trigger the actions of trace Err/signal on Error. Or even that there were a simple way to force an error. I suppose one might write a command processor that simply returned with the value of its argument in R15: SETRC CSECT L R15,0(,R1) Point to first argument pointer. L R15,0(,R15) (I know; I know; I can make it work with address LINKPGM) BR R15 YREGS END (I am _not_ an assembler programmer.) I also wish that procedure expose ... would set SIGL inside the procedure, not outside. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On 12/12/2011 7:06 PM, Paul Gilmartin wrote: On Mon, 12 Dec 2011 11:12:44 -0500, Shmuel Metz (Seymour J.) wrote: Is the example suitable?: Yes, other than using RC as a variable name. As in RC = BPXWDYN( ... )? Well, RC really is a variable. It has some special behaviors, as does SIGL. (Others? None come immediately to mind.) There are three REXX reserved variable names: RC, RESULT, and SIGL I really wish that any setting of RC0, as by assignment, parse, etc. would trigger the actions of trace Err/signal on Error. Or even that there were a simple way to force an error. I suppose one might write a command processor that simply returned with the value of its argument in R15: SETRC CSECT L R15,0(,R1) Point to first argument pointer. L R15,0(,R15) (I know; I know; I can make it work with address LINKPGM) BR R15 YREGS END (I am _not_ an assembler programmer.) I also wish that procedure expose ... would set SIGL inside the procedure, not outside. -- gil -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * Special promotion: 15% off on all DB2 training classes scheduled by September 1, taught by year end 2011 * Check out our entire DB2 curriculum at: http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: SV: SV: JCL sheesh! for today
In a90e503c23f97441b05ee302853b0e6241dc0ac...@fspas01ev010.fspa.myntet.se, on 12/09/2011 at 11:54 PM, Thomas Berg thomas.b...@swedbank.se said: Ok, If I rephrase it like: as seen from the initiator before the actual execution starts ? :) That works. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 1323571698.77546.yahoomailmob...@web161406.mail.bf1.yahoo.com, on 12/10/2011 at 06:48 PM, Ed Gould ps2...@yahoo.com said: Someone (John?) suggested that a language (Pearl?) Presumably Perl. could do it Quoting the context would help. See RFC for the standard format of a quote in Internet message. An attribution line containing the message id would also help. I assume that you are referring to Perl certainly does not have any column orientation. Neither does awk. In fact, most UNIX originated languages don't do column orientation. Python being a major exception. Well, it's not column oriented, but indentation dependant for control structures. I think column oriented languages were invented by people who had keypunches and Hollerith cards. in very few statements and if I recall correctly his short example seem to say (at least to me) stack everything up in a pile. You were the one that wrote What good does it do to string out an entire program into one continuous line?; I don't recall anybody else, much less John, suggesting such a thing. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 3666973419482586.wa.paulgboulderaim@bama.ua.edu, on 12/10/2011 at 10:04 PM, Paul Gilmartin paulgboul...@aim.com said: I've seen it done So have I, but what reader of IBM-MAIN claimed that it was desirable? C, for example, allows as many or as few (even only one) tokens on each line. Which doesn't make that good style, any more than removing all optional white space would be good style. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 6321277460713310.wa.paulgboulderaim@bama.ua.edu, on 12/10/2011 at 09:56 PM, Paul Gilmartin paulgboul...@aim.com said: Does it merit an RCF? Yes. In fact the behavior of aliased DSNs is perhaps even worse. Yes, and hard to fix. Every approach that I can think of breaks something. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Sun, 11 Dec 2011 09:16:25 -0500, Shmuel Metz (Seymour J.) wrote: In 1323571698.77546.yahoomailmob...@web161406.mail.bf1.yahoo.com, on 12/10/2011 at 06:48 PM, Ed Gould said: Someone (John?) suggested that a language (Pearl?) Presumably Perl. could do it Quoting the context would help. PKB. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 0451543888042535.wa.paulgboulderaim@bama.ua.edu, on 12/11/2011 at 10:14 AM, Paul Gilmartin paulgboul...@aim.com said: PKB. ROTF,LMAO! I always quote the context, as well as providing an attribution line. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Sun, 11 Dec 2011 12:48:46 -0500, Shmuel Metz (Seymour J.) wrote: on 12/11/2011 at 10:14 AM, Paul Gilmartin said: PKB. ROTF,LMAO! I always quote the context, At least one word. Sometimes several. as well as providing an attribution line. Thanks. Sometimes I rely on the quotation level, but nowadays quoting conventions vary, especially among top-posters. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Sun, 11 Dec 2011 09:20:41 -0500, Shmuel Metz (Seymour J.) wrote:
Yes.
OK. Done. Does this say the right stuff? Is the example suitable?:
Hello, MHVRCFs,
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/12.47
Title: z/OS V1R12.0 MVS JCL Reference
Document Number: SA22-7597-14
12.47 PATH Parameter
And:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb6a0/6.6
Title: z/OS V1R12.0 Using REXX and z/OS UNIX System Services
Document Number: SA22-7806-13
6.6 Requesting dynamic allocation
And:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4c5b0/1.7.5
Title: z/OS V1R12.0 TSO/E Command Reference
Document Number: SA22-7782-13
1.7.5 ALLOCATE command operands
mention performing allocation by pathname. There should
somewhere be a Usage Note to the effect:
Allocation verifies the validity of the pathname. However
there is no ENQ or locking of the pathname, so it is possible
to modify a pathname component, even in an asynchronous
process. Doing this may cause errors in OPEN or unexpected
results with no errors reported.
This Usage note should be cross-referenced at major mentions of
allocation by pathname.
The Rexx example below is too verbose to appear in a Reference
manual; I supply it to help explain my concerns to any developers
you may consult.
Thanks,
gil
*/
/* Rexx */ signal on novalue
trace R
address SYSCALL 'getcwd CWD'
say CWD
address SH
TestDir = 'AllocTest'
'rm -r' TestDir'; mkdir' TestDir
'echo Before 'TestDir'/A; echo After 'TestDir'/B'
'ln -s A 'TestDir'/X'
RC = BPXWDYN( 'free dd(SYSUT1) msg(WTP)' )
RC = BPXWDYN( 'alloc dd(SYSUT1) pathopts(ORDONLY) filedata(TEXT)' ,
'path('''CWD'/'TestDir'/X'')' ,
'recfm(V) lrecl(99) msg(WTP)' )
address MVS 'execio * diskr SYSUT1 (finis stem L.'
say L.1/* Prints Before. */
'rm 'TestDir'/X; ln -s B 'TestDir'/X'
address MVS 'execio * diskr SYSUT1 (finis stem L.'
say L.1/* Prints After. ` */
'rm' TestDir'/X'
address MVS 'execio * diskr SYSUT1 (finis stem L.' /* IEC143I 213-FC
FC The OPEN function for BSAM or QSAM access to a UNIX file found
that the file does not exist. */
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 9480536010373504.wa.paulgboulderaim@bama.ua.edu, on 12/11/2011 at 12:00 PM, Paul Gilmartin paulgboul...@aim.com said: At least one word. Sometimes several. Always enough to identify the text that I an responding to. If I'm responding to an entire paragraph then I quote the entire paragraph, but I don't quote extraneous text as some here do. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On 12/10/2011 12:19 AM, Ed Gould wrote: Joel, My reading of your reply is frankly confused. Any DD card that needs to be continued must end with a comma and start (in the continuation card with a // and a blank) in CC 4 or at least up to CC 16 (no continuation in CC 72 is needed). A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). Ed - Original Message - From: Joel C. Ewingjcew...@acm.org To: IBM-MAIN@bama.ua.edu Cc: Sent: Friday, December 9, 2011 10:19 PM Subject: Re: JCL sheesh! for today On 12/09/2011 11:57 AM, Ed Gould wrote: JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. Ed All JCL statement continuation records are column peculiar, not just those involving PARM values or quoted strings. A continuation which splits a quoted string is column sensitive on where the first record ends (column 71) and on where you must resume the string on the continuation (column 16). But, all other statement continuation records are also column sensitive in that continued parameters must resume in columns 4 - 16. This complicates manual verification of JCL, because visually it is difficult to distinguish between any parameter continuation that resumes in column 16 versus one that resumes in column 17, but of course the latter fails. It is true that there are languages (e.g., COBOL, FORTRAN, Assembler) with column restrictions that are an integral part of the language syntax; but a number of other languages (e.g.,PL/I, C, REXX) are essentially free-form with a syntax that is column insensitive. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org ... Ed, As you indicated in your response, all DD statements (or any other JCL statement for that matter) that need to be continued at a point not in a quoted string require that the continuation must resume on the following card in columns 4 - 16. This is an *arbitrary* JCL column sensitivity that would be regarded by many as peculiar, especially when contrasted with the unrestricted location of the parameter field on the first card of the statement. This restriction is is easily violated accidentally by JCL programmers who attempt to align subsequent parameter continuation cards with a parameter field that just happens to start on column 17 or later on the first card of statement. I would call this a nasty column sensitivity in the JCL syntax as well, because I have seen so many cases over the years where this caused JCL syntax errors when the coding intent was obvious to a human. That the continuation rules for a quoted string are even worse doesn't mean that normal JCL continuation rules are adequate or column insensitive. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Only the 100 character restriction still applies Which is not a JCL *syntax* restriction per se. It was a specific design decision, presumably to conserve a little of that precious 44K region. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gerhard Postpischil Sent: Friday, December 09, 2011 11:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today On 12/10/2011 1:19 AM, Ed Gould wrote: A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). That hasn't been true for ages. A PARM in parentheses may be continued over multiple records, and may start in columns 4-16. Only the 100 character restriction still applies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
That's only true if you have PARM values that the invoked program allows to be separated by a comma and are not required to be a continuous string of data with no commas present. Embedded blanks in a PARM value require a quoted string as well. Obviously such restrictions are limited to user-written programs, as in my experience all IBM and OEM utilities which accept a PARM permit comma-separated PARM values, but user-written code is not always so easily modified (If it ain't broke, don't you dare fix it!). Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gerhard Postpischil Sent: Saturday, December 10, 2011 2:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today On 12/10/2011 1:19 AM, Ed Gould wrote: A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). That hasn't been true for ages. A PARM in parentheses may be continued over multiple records, and may start in columns 4-16. Only the 100 character restriction still applies. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Sat, 10 Dec 2011 13:24:35 -0500, Farley, Peter x23353 wrote: That's only true if you have PARM values that the invoked program allows to be separated by a comma and are not required to be a continuous string of data with no commas present. Embedded blanks in a PARM value require a quoted string as well. Obviously such restrictions are limited to user-written programs, as in my experience all IBM and OEM utilities which accept a PARM permit comma-separated PARM values, Exception: BPXBATCH. but user-written code is not always so easily modified (If it ain't broke, don't you dare fix it!). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
In CAJTOO585CQfAAzQA6Zu6WkAyTYOC1Q2H-Pk4D=cmvewpq2h...@mail.gmail.com, on 12/09/2011 at 03:45 PM, Mike Schwab mike.a.sch...@gmail.com said: Doesn't JES3 make sure the dataset is available and there is enough free space before it starts the job? Yes to the first. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 985915eee6984740ae93f8495c624c6c21de4be...@jscpcwexmaa1.bsg.ad.adp.com, on 12/10/2011 at 01:24 PM, Farley, Peter x23353 peter.far...@broadridge.com said: That's only true if you have PARM values that the invoked program allows to be separated by a comma and are not required to be a continuous string of data with no commas present. Reread Gerhard's message. What he wrote is true. That hasn't been true for ages. refers to what Ed actually wrote, not to what he should have written. The rest of the paragraph is correct as written; it saqys nothing about a PARM value not in parentheses. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 1323497971.82966.yahoomail...@web161401.mail.bf1.yahoo.com, on 12/09/2011 at 10:19 PM, Ed Gould ps2...@yahoo.com said: My reading of your reply is frankly confused. Read the JCL reference. Any DD card that needs to be continued must end with a comma and start (in the continuation card with a // and a blank) in CC 4 or at least up to CC 16 (no continuation in CC 72 is needed). That applies to the same extent to any JCL statement. A parm on the exec card in order to be continued had different rules No. must start in CC 16 The continuation of *any* quoted string must start in column 16. It is possible for the continuation of PARM to start before column 16. *AND* must have a continuation in 72 Only if you're continuing a quoted string. which IIRC there is no other DD parameter has any restrictions (that I can remember of). Try splitting SUBSYS in the middle of a quoted string. The rules ar3 *exactly* the same as for PARM. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 1323467026.30143.yahoomailmob...@web161402.mail.bf1.yahoo.com, on 12/09/2011 at 01:43 PM, Ed Gould ps2...@yahoo.com said: What good does it do to string out an entire program into one continuous line? Have you stopped beating your wife? Why are you asking for a defense of something that nobody but you has suggested? Languages that don't have column restrictions rarely or never force the programmer 'to string out an entire program into one continuous line'. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 5351837594734986.wa.paulgboulderaim@bama.ua.edu, on 12/09/2011 at 03:13 PM, Paul Gilmartin paulgboul...@aim.com said: I need a vocabulary lesson. I think I've heard of phases called Read, Convert, Interpret, and Execute. Are there actually four (or even move)? If you count Schedule then it's five. Or are some of these terms synonymous? No. And in my vocabulary (outside MVS), Interpret and Execute have always been synonymous. The reason that Interpreter is written with a capital I in the MVS context is that it is a proper noun; it refers to a specific program. Does Interpret transform the intermediate code from Convert ?into yet another form of intermediate code which is subsequently Execute[d]? Yes, it validates values in the internal text buffers and build control blocks for the job. Nonetheless, I believe the pathname in the DD statement is validated (by allocation?)sometime before step execution begins. Presumably the Conrter or the Interpreter check the syntax, but I wouldn't expect them to check whether the path exists. (by allocation?)sometime before step execution begins. My guess would be that it's not until OPEN. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 1323467271.22360.yahoomailmob...@web161404.mail.bf1.yahoo.com, on 12/09/2011 at 01:47 PM, Ed Gould ps2...@yahoo.com said: I was referencing mind you indirectly about continuation(s) with quotes, parenthesis . That issue is not limited to PARM. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 07aa01ccb6a0$b65c8100$23158300$@mcn.org, on 12/09/2011 at 10:31 AM, Charles Mills charl...@mcn.org said: Does C/C++? No. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Shmuel, Someone (John?) suggested that a language (Pearl?) could do it in very few statements and if I recall correctly his short example seem to say (at least to me) stack everything up in a pile. I was suggesting a pile was not a way to program no matter what language. Since we were talking about columns I suggested what I did. By the way I don#39;t beat my wife just like you try and keep kosher. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Peter, There is a 100 character limit that can be passed. This has been talked about. In the past. IBM has so many hard coded programs that to change it would be almost impossible. To fix and user programs might be affected as well. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Joel, Of course you are right. I am somewhat hesitant to agree with your saying cc 17 or greater is oppressive for continuation. With ISPF you can essentially make it easy. If you can remember the drums in the 026 or 029 that you could program to skip to any column. My memory is iffy here but I think there are products that can format JCL to put 1 parameter on each card for readability and debugging. The is formatting costs DASD space but it is a small cost for what it buys, in my opinion. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Sat, 10 Dec 2011 18:40:49 -0500, Shmuel Metz (Seymour J.) wrote: Nonetheless, I believe the pathname in the DD statement is validated (by allocation?)sometime before step execution begins. Presumably the Conrter or the Interpreter check the syntax, but I wouldn't expect them to check whether the path exists. (by allocation?)sometime before step execution begins. My guess would be that it's not until OPEN. Both. I've now done the experiment. If the path doesn't exist, allocation fails. But there's no locking -- it's possible to modify a path component (even asynchronously) between allocation and OPEN. Doing so may result in an error or unexpected behavior with no error detected. I can find no documentation of this behavior (can anyone else, or is it simply as enny fool kin plainly see?) Does it merit an RCF? In fact the behavior of aliased DSNs is perhaps even worse. Job initiation ENQs on the alias name. Only at step initiation does the system attempt to ENQ and allocate the related DSN; I believe there's no recovery if that fails. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Sat, 10 Dec 2011 18:30:49 -0500, Shmuel Metz (Seymour J.) wrote: What good does it do to string out an entire program into one continuous line? Have you stopped beating your wife? Why are you asking for a defense of something that nobody but you has suggested? I've seen it done with Rexx EXECs on CMS, prior to the advent of the Rexx compiler. Remove comments and indention; scrunch what remains as densely as possible with objectives: o improving performance by optimizing lexical analysis. o deliberate obfuscation to achieve some of the effect of OCO. Languages that don't have column restrictions rarely or never force the programmer 'to string out an entire program into one continuous line'. C, for example, allows as many or as few (even only one) tokens on each line. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
S. Thanks, I was not aware of the SUBSYS parameter issue. I have never coded it. I will admit to making more than couple of try#39;s of parms of longer than would fit on 1 card and having to hit the fine manual to figure out how to do it. Outside of the new printer parameters that s the only time I have had to hit the JCL manual in 20 years maybe more. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: SV: JCL sheesh! for today
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Shmuel Metz (Seymour J.) Skickat: den 8 december 2011 18:49 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: JCL sheesh! for today In a90e503c23f97441b05ee302853b0e62406f349...@fspas01ev010.fspa.myntet.se, on 12/08/2011 at 03:13 PM, Thomas Berg thomas.b...@swedbank.se said: Note that if You e g is using IDCAMS for allocating/deleting datasets it's even today under the radar as seen from the initiator. AMS uses DYNALLOC, so it's not under the radar. It's under the radar when the job cards is read and interpreted. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Thursday, December 08, 2011 7:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today John, I had a so called manager, he used to read gas meters. He had that level of mentality. Ed I understand. I think one of my ex-managers didn't just read the gas meter, he inhaled. grin/ -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
For companies running products from DTS Software, there's a feature called IPIO. Example, DD statement: //SYSPRINT DD SUBSYS=(IPIO,'IP=192.168.0.22,PORT=5000', // 'ASCII'),DCB=(LRECL=121,RECFM=F,BLKSIZE=121) Don -Original Message- From: Paul Gilmartin [mailto:paulgboul...@aim.com] Sent: Thursday, December 08, 2011 2:21 AM Subject: Re: JCL sheesh! for today On Thu, 8 Dec 2011 01:07:32 -0600, Peter Bishop wrote: A wish: //ddname DD IPADDR=n.n.n.n,PATHOPTS=R Wouldn't it be nice if you could just open a pipe to (or from, or both) an IP address straight into your JCL? Different pathopts for output, input, update, etc. Why an IP address? DNS is your friend. If you really want to do that, you really ought to specify a port number also. And a protocol. And arguments. How about, instead: //ddname DD POPEN='curl https://bama.ua.edu:80/cgi-bin/wa',PATHOPTS=ORDONLY, ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Right. In other words, *any* program that gets dataset information *other* than from DD statements: from its own SYSIN control statements, from some external source (such as connectivity to another machine), user key-in, created by internal logic, etc. -- joins the dataset ENQ party only during execution time. Schedulers, initiators, converters, etc. are blissfully unaware of its dataset requirements, and do not factor that into their scheduling or other processing. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Friday, December 09, 2011 1:28 AM To: IBM-MAIN@bama.ua.edu Subject: SV: SV: JCL sheesh! for today Note that if You e g is using IDCAMS for allocating/deleting datasets it's even today under the radar as seen from the initiator. It's under the radar when the job cards is read and interpreted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Yeah, we regulary have problems with SAS users who discovered the LIBNAME and FILENAME statements. These allocate files during execution and fail if the file is in use, resulting in aborted productions runs and we getting blames that 'someone else' allocated the file. We then advise JCL allocation to solve this problem, but this sometimes results in protests because they loose the flexibility to change filenames if this is in JCL. JCL allocation and dynamic allocation often look like z/os and windows trying to work together (try FTPing between those two). Kees. Charles Mills charl...@mcn.org wrote in message news:074d01ccb682$d2da3020$788e9060$@mcn.org... Right. In other words, *any* program that gets dataset information *other* than from DD statements: from its own SYSIN control statements, from some external source (such as connectivity to another machine), user key-in, created by internal logic, etc. -- joins the dataset ENQ party only during execution time. Schedulers, initiators, converters, etc. are blissfully unaware of its dataset requirements, and do not factor that into their scheduling or other processing. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Friday, December 09, 2011 1:28 AM To: IBM-MAIN@bama.ua.edu Subject: SV: SV: JCL sheesh! for today Note that if You e g is using IDCAMS for allocating/deleting datasets it's even today under the radar as seen from the initiator. It's under the radar when the job cards is read and interpreted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Fri, 9 Dec 2011 13:59:08 +, Don Thimsen wrote: For companies running products from DTS Software, there's a feature called IPIO. Example, DD statement: //SYSPRINT DD SUBSYS=(IPIO,'IP=192.168.0.22,PORT=5000', // 'ASCII'),DCB=(LRECL=121,RECFM=F,BLKSIZE=121) Hmmm. Will it not take a host name and resolve that? Hmmm. If the customer were to code ...IP=127.0.0.1... would that be resolved on the submitting host or on the execution host? And I thought of extending my followup to Robert Rosenberg: RANT I'm looking at a Data Set Utility display on each of two JES2 hosts which have SYS1.MACLIB cataloged on different volumes. If I code: //SYSLIB DD DSN=SYS1.MACLIB ... We haven't a spool shared between those two hosts. But, suppose, should the resolution be performed on the submitting host or on the execution host? In the extreme, I could imagine the submitting host's performing a complete resolution and passing the execution host control blocks containing a UCB address and a track/cylinder address. I wouldn't expect it to work. Resolution should be performed on the execution host; anything else is madness. /RANT But then I put my UNIX hat on. It fits well; my MVS hat is a little too tight. I tried: 494 $ ssh -p3222 localhost 'echo ~ $(uname -s) $(date)' /home/paulgilm Linux Fri Dec 9 08:45:37 MST 2011 Ah! The resolution is performed by the execution system, just as I'd want. But wait! Making the tiniest syntactic change: 495 $ ssh -p3222 localhost echo ~ $(uname -s) $(date) /Users/paulgilm Darwin Ven 9 déc 2011 16:45:41 CET ... Removing the quotation marks protecting the substitutions allows resolution on the submitting system instead. (3222 is the mapped Remote Login port of my Linux guest.) By analogy, I could imagine being able to code: PARM='amp;SYSNAME amp;SYSDATE', ... protecting the ampersands by doubling them on the submitting host, which would then pass: PARM='SYSNAME SYSDATE', ... to the execution host which would perform the final resolution. But that's far beyond the capabilities of JES. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Finlandia (was RE: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Lindy Mayfield [ snip ] Today, for 45 more minutes is Sibelius' birthday. Happy birthday. This is a nice Finlandia, if I didn't mistakenly post it already. I've been having fun on both IBM-MAIN and ASSEMBLER-LIST for the past few days, so I get mixed up. http://www.youtube.com/watch?v=ci3RPAOFok4 This rendition has better video: http://www.youtube.com/watch?v=XojVmivqDrA -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
On Fri, 9 Dec 2011 16:37:49 +0100, Vernooij, CP - SPLXM wrote: Yeah, we regulary have problems with SAS users who discovered the LIBNAME and FILENAME statements. These allocate files during execution and fail if the file is in use, resulting in aborted productions runs and we getting blames that 'someone else' allocated the file. We then advise JCL allocation to solve this problem, but this sometimes results in protests because they loose the flexibility to change filenames if this is in JCL. Why should it be harder to change a JCL proc than to change a SAS proc? If your JCL proc libraries are controlled, but your production SAS proc libraries aren't, you have a political problem. JCL libraries and JCL INCLUDE statements might much mitigate this. Or run the entire job through a tailoring filter. JCL allocation and dynamic allocation often look like z/os and windows trying to work together (try FTPing between those two). Why would I want to? But it should be effective, however tedious, with proper use of LOCSITE (z/OS client) or QUOTE SITE (Windows client) commands. (While my first inclination is usually to blame Windows, z/OS brings much baggage to this party.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Gil, It sounds like production is not fully implemented in the company. JCL, maybe but not where execution source resides. I have wired in places like that and it can be a nightmare. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: SV: JCL sheesh! for today
In a90e503c23f97441b05ee302853b0e6241dc0ac...@fspas01ev010.fspa.myntet.se, on 12/09/2011 at 10:28 AM, Thomas Berg thomas.b...@swedbank.se said: It's under the radar when the job cards is read and interpreted. Read the message again. In particular, as seen from the initiator. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 5425266154993050.wa.paulgboulderaim@bama.ua.edu, on 12/08/2011 at 08:44 PM, Paul Gilmartin paulgboul...@aim.com said: It should be expanded by Allocation, at interpretation time, Allocation is not at interpretaion time, it's at execution time. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 4ee121d3.5070...@acm.org, on 12/08/2011 at 02:45 PM, Joel C. Ewing jcew...@acm.org said: I don't think Fred Brooks was really thinking things through when he said he would have preferred language-specific support within higher-level programming languages for scheduling program execution rather than OS/360 JCL He wasn't thinking things through in his book 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 Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In caarmm9qua3vgiq3ahctpt4+xjvioocan8j7hk3fzgp_7tyr...@mail.gmail.com, on 12/08/2011 at 02:35 PM, Tony Harminc t...@harminc.net said: When would the name(s) be resolved/expanded? At conversion time? Execution time? Somewhere in between? OPEN. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In p06240810cb075f225d98@[25.249.252.205], on 12/09/2011 at 01:51 AM, Robert A. Rosenberg hal9...@panix.com said: You better hope that you run the interpretation on the same machine that the job stream will execute on (or is interpretation the first step of execution? Conversion, Interpretation and Execution could be on three different machines. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In caarmm9quktjumbrjtcnbhyssy0qra_te-2rn9xrvkhaqjr6...@mail.gmail.com, on 12/08/2011 at 02:33 PM, Tony Harminc t...@harminc.net said: When would the path be resolved/expanded? At conversion time? Execution time? Somewhere in between? IMHO, execution time is what makes sense. Dynamic Allocation should accept ~ and ~userid in a fashion consistend with the proposed semantics for PATH on a DD statement. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In a6b9336cdb62bb46b9f8708e686a7ea00b038bb...@nrhmms8p02.uicnrh.dom, on 12/08/2011 at 02:19 PM, McKown, John john.mck...@healthmarkets.com said: I'd expand it at JCL interpretation time. For SYSUIDL, I agree. However, IMHO both ~ and ~userid should be expanded at run time. E.g. if user bozo exists and has a HOME directory of u/bozo, then ~bozo expands to /u/bozo. If bozo does not exist, then ~bozo is passed to the program as ~bozo. In the z/OS world, I would expect a JCL error in this later case. A bit late, what? I would also expect a JCL error if bozo's HOME directory is specified, but either does not exist Does not exist where? If it exists on the execution system then it should be legitimate. The ~ would be resolved on the converting system. Why? And the converting/intepreting/executing system(s) should be consistent on the HOME subdirectory. That's the kiss of death. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Fri, 9 Dec 2011 09:57:38 -0800, Ed Gould wrote: JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. DSN? PATH? While most programmers would start DSN on a new line rather than breaking it with a continuation, when PATH exceeds 65 characters they have little choice. Even worse, if the Nasty contains a symbol reference, the symbol name must be complete on a single line (documented restriction), or if it contains an ampersand or an apostrophe doubled for protection, the pair must appear on a single line (I don't believe this is documented; I'm tempted to PMR it.) These are a real PITA when I attempt to generate code automatically, Oh, did I mention that I hate JCL!? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
any language that I am familiar with does have column restrictions of some type Does C/C++? #'s have to be the first token on the line, and //'s effectively end a line, but are there any *column* sensitivities? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Friday, December 09, 2011 9:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Gil, Here we go again. DSN does not need to be the first. For readability a lot of installations choose to have one item per line. I happen to agree. After several years of midnight perusal of attempting to read JCL and seeing some really badly written JCL think you will find. That 1 item per line, ie DSN, disp, space etc it#39;s the only way to go. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 1323453458.3290.yahoomailmob...@web161403.mail.bf1.yahoo.com, on 12/09/2011 at 09:57 AM, Ed Gould ps2...@yahoo.com said: My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. There's nothing special about PARM. The column sensitivity of for continuation of quoted strings and applies equally well to, e.g., AMP. Although there is some debate whether JCL is a language (or not) The only debate that I recall was whether it was a *programming* language. any language that I am familiar with does have column restrictions of some type. Ada? C? English? Rexx? -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
You can do what I do: // SET PTH1='/some/really/long' // SET PTH2='/and/involved/UNIX/' // SET PTH3='/path/with/' // SET PTH4=PTH3SYBOL //* //DD1 DD PATH=PTH1PTH2PTH3PTH4 Yes, another PITA. But less confusing, to me, than trying to get the continuation exactly right. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, December 09, 2011 12:25 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today On Fri, 9 Dec 2011 09:57:38 -0800, Ed Gould wrote: JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. DSN? PATH? While most programmers would start DSN on a new line rather than breaking it with a continuation, when PATH exceeds 65 characters they have little choice. Even worse, if the Nasty contains a symbol reference, the symbol name must be complete on a single line (documented restriction), or if it contains an ampersand or an apostrophe doubled for protection, the pair must appear on a single line (I don't believe this is documented; I'm tempted to PMR it.) These are a real PITA when I attempt to generate code automatically, Oh, did I mention that I hate JCL!? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Friday, December 09, 2011 12:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today any language that I am familiar with does have column restrictions of some type Does C/C++? #'s have to be the first token on the line, and //'s effectively end a line, but are there any *column* sensitivities? Charles Perl certainly does not have any column orientation. Neither does awk. In fact, most UNIX originated languages don't do column orientation. Python being a major exception. Well, it's not column oriented, but indentation dependant for control structures. I think column oriented languages were invented by people who had keypunches and Hollerith cards. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Fri, 9 Dec 2011 13:08:03 -0500, Shmuel Metz (Seymour J.) wrote: In 5425266154993050.wa.paulgboulderaim@bama.ua.edu, on 12/08/2011 at 08:44 PM, Paul Gilmartin said: It should be expanded by Allocation, at interpretation time, Allocation is not at interpretaion time, it's at execution time. I need a vocabulary lesson. I think I've heard of phases called Read, Convert, Interpret, and Execute. Are there actually four (or even move)? Or are some of these terms synonymous? And in my vocabulary (outside MVS), Interpret and Execute have always been synonymous. Does Interpret transform the intermediate code from Convert into yet another form of intermediate code which is subsequently Execute[d]? Nonetheless, I believe the pathname in the DD statement is validated (by allocation?)sometime before step execution begins. But there's no locking; it's possible to unlink the file after allocation and before OPEN and get yet a different error. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Doesn't JES3 make sure the dataset is available and there is enough free space before it starts the job? On Fri, Dec 9, 2011 at 8:57 AM, Charles Mills charl...@mcn.org wrote: Right. In other words, *any* program that gets dataset information *other* than from DD statements: from its own SYSIN control statements, from some external source (such as connectivity to another machine), user key-in, created by internal logic, etc. -- joins the dataset ENQ party only during execution time. Schedulers, initiators, converters, etc. are blissfully unaware of its dataset requirements, and do not factor that into their scheduling or other processing. Charles -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Shmuel, I was referencing mind you indirectly about continuation(s) with quotes, parenthesis . Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
John, I am not familiar with PERL, However the main point I am suggesting is that readability and debugging is EVERYTHING. What good does it do to string out an entire program into one continuous line? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
On 12/9/2011 1:45 PM, Mike Schwab wrote: Doesn't JES3 make sure the dataset is available and there is enough free space before it starts the job? Data set available? JES3 setup ensures allocation will not wait when the job gets into the initiator. Enough free space available? I believe the volumes have already been selected by SMS and JES3 before the job gets into the initiator. Not sure if that constitutes an absolute guarantee of free space availability, but it's a start... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: SV: SV: JCL sheesh! for today
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Shmuel Metz (Seymour J.) Skickat: den 9 december 2011 19:20 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: SV: JCL sheesh! for today In a90e503c23f97441b05ee302853b0e6241dc0ac...@fspas01ev010.fspa.myntet.se, on 12/09/2011 at 10:28 AM, Thomas Berg thomas.b...@swedbank.se said: It's under the radar when the job cards is read and interpreted. Read the message again. In particular, as seen from the initiator. Ok, If I rephrase it like: as seen from the initiator before the actual execution starts ? :) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On 12/09/2011 11:57 AM, Ed Gould wrote: JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. Ed All JCL statement continuation records are column peculiar, not just those involving PARM values or quoted strings. A continuation which splits a quoted string is column sensitive on where the first record ends (column 71) and on where you must resume the string on the continuation (column 16). But, all other statement continuation records are also column sensitive in that continued parameters must resume in columns 4 - 16. This complicates manual verification of JCL, because visually it is difficult to distinguish between any parameter continuation that resumes in column 16 versus one that resumes in column 17, but of course the latter fails. It is true that there are languages (e.g., COBOL, FORTRAN, Assembler) with column restrictions that are an integral part of the language syntax; but a number of other languages (e.g.,PL/I, C, REXX) are essentially free-form with a syntax that is column insensitive. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Joel, My reading of your reply is frankly confused. Any DD card that needs to be continued must end with a comma and start (in the continuation card with a // and a blank) in CC 4 or at least up to CC 16 (no continuation in CC 72 is needed). A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). Ed - Original Message - From: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@bama.ua.edu Cc: Sent: Friday, December 9, 2011 10:19 PM Subject: Re: JCL sheesh! for today On 12/09/2011 11:57 AM, Ed Gould wrote: JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. Ed All JCL statement continuation records are column peculiar, not just those involving PARM values or quoted strings. A continuation which splits a quoted string is column sensitive on where the first record ends (column 71) and on where you must resume the string on the continuation (column 16). But, all other statement continuation records are also column sensitive in that continued parameters must resume in columns 4 - 16. This complicates manual verification of JCL, because visually it is difficult to distinguish between any parameter continuation that resumes in column 16 versus one that resumes in column 17, but of course the latter fails. It is true that there are languages (e.g., COBOL, FORTRAN, Assembler) with column restrictions that are an integral part of the language syntax; but a number of other languages (e.g.,PL/I, C, REXX) are essentially free-form with a syntax that is column insensitive. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On 12/10/2011 1:19 AM, Ed Gould wrote: A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). That hasn't been true for ages. A PARM in parentheses may be continued over multiple records, and may start in columns 4-16. Only the 100 character restriction still applies. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 8 Dec 2011 01:07:32 -0600, Peter Bishop wrote: A wish: //ddname DD IPADDR=n.n.n.n,PATHOPTS=R Wouldn't it be nice if you could just open a pipe to (or from, or both) an IP address straight into your JCL? Different pathopts for output, input, update, etc. Why an IP address? DNS is your friend. If you really want to do that, you really ought to specify a port number also. And a protocol. And arguments. How about, instead: //ddname DD POPEN='curl https://bama.ua.edu:80/cgi-bin/wa',PATHOPTS=ORDONLY, ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On 8/12/2011 15:13 PM, zMan wrote: Indeed. The tiny improvements in JCL over time make me think that POK is afraid of the code -- never a good situation. Yes, a change that broke production jobs would be Bad, but that's what testing and ESPs are for. JCL is so primitive lo these almost 50 years later: I'm always astonished (and a bit depressed). I suspect the problem with JCL is that the base code was laid down about fifty years ago. I remember seeing eye catchers with 1968 dates in the late 1990's. At that time (1960's) I doubt that the developers had the rigourous documentation requirements of even yesteryear much less recent years. So I think that to days developers are as much in the dark about the code as you and I. Possibly someone out there who kept the source tapes (Seymour Metz (I apologize in advance about name spelling) could comment about code quality. And I must say that quality expectation between 1970 and 2010 are vastly different Ken -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
I put this up a while ago. It is a talk given by Fred Brooks, Jr. on the 40th year anniversary of the IBM/360. He doesn't seem to like JCL that much, either. :-) http://lilliana.eu/downloads/jcltalk.txt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ken Brick Sent: Thursday, December 08, 2011 11:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today I suspect the problem with JCL is that the base code was laid down about fifty years ago. I remember seeing eye catchers with 1968 dates in the late 1990's. At that time (1960's) I doubt that the developers had the rigourous documentation requirements of even yesteryear much less recent years. So I think that to days developers are as much in the dark about the code as you and I. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Lindy Mayfield wrote: I put this up a while ago. It is a talk given by Fred Brooks, Jr. on the 40th year anniversary of the IBM/360. He doesn't seem to like JCL that much, either. :-) http://lilliana.eu/downloads/jcltalk.txt Thanks. Very interesting. I see JCL as a way where the system makes input and output to be available to a program. Example: A COBOL program reads in a dataset and write it out somewhere. It does not care where that dataset really is residing. Tape? Dataset? Terminal. Where is that output? Anywhere, printer, JESSPOOL, another tape. Now JCL is a way to combine all these things. There is one catch ... Actual implementation gone * badly wrong. 'Backward compatibility' made it worse. Ok, ok, that is just my opinion. Feel free to flame me. ;-D If I can get a cent for everytime someone said 'I hate JCL', I could retire and get me that 100 metre yacht with a crew and girlies... :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 8 Dec 2011 11:40:15 + Lindy Mayfield wrote: I put this up a while ago. It is a talk given by Fred Brooks, Jr. on the 40th year anniversary of the IBM/360. He doesn't seem to like JCL that much, either. :-) http://lilliana.eu/downloads/jcltalk.txt From that paper: From the beginning it was seen as a few control cards that would go in front of your deck. This is (almost) how I remember things from Uni - on a CDC 6400 running Kronos IIRC. I have a feeling it was only *one* card there. Quite a rude awaking to be dropped into an IBM 370 environment on graduation. JCL included ... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Peter Bishop Sent: Thursday, December 08, 2011 1:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today On Wed, 7 Dec 2011 23:13:37 -0500, zMan zedgarhoo...@gmail.com wrote: On Wed, Dec 7, 2011 at 8:20 PM, Paul Gilmartin paulgboul...@aim.com wrote: All in all, it appears to me that the developers weren't sincerely motivated to make Unix System Services work as it should. It's a half-hearted (is that the right anatomical reference?) implementation. This shouldn't be something fundamentally difficult like making forked processes inherit DDNAMEs; they should just do it. I hate JCL! Indeed. The tiny improvements in JCL over time make me think that POK is afraid of the code -- never a good situation. Yes, a change that broke production jobs would be Bad, but that's what testing and ESPs are for. JCL is so primitive lo these almost 50 years later: I'm always astonished (and a bit depressed). -- zMan -- I've got a mainframe and I'm not afraid to use it A wish: //ddname DD IPADDR=n.n.n.n,PATHOPTS=R Wouldn't it be nice if you could just open a pipe to (or from, or both) an IP address straight into your JCL? Different pathopts for output, input, update, etc. Does the Co:Z toolkit already do this? A quick look at http://dovetail.com/docs/coz/index.html left me still wondering. thx Peter Co:Z does not have any impact on JCL at all. What protocol do you want for your IPADDR=a.b.c.d? Or are you thinking of something like netcat which doesn't really have a protocol per se, just sends a bunch of bytes down the line? And to what port number? So I guess we need IPADDR='a.b.c.d:n' where a.b.c.d is the IP address (IPV4 or IPV6 syntax) or a DNS name. And n is a port number. Hum, to be generic, perhaps we need PROTOCOL=TCP|UDP to select the TCP or UDP transport. And what about the new kid on the block, which is not supported by z/OS at this time, SCTP? http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol . -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, Dec 8, 2011 at 1:20 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 8 Dec 2011 01:07:32 -0600, Peter Bishop wrote: A wish: //ddname DD IPADDR=n.n.n.n,PATHOPTS=R Wouldn't it be nice if you could just open a pipe to (or from, or both) an IP address straight into your JCL? Different pathopts for output, input, update, etc. Why an IP address? DNS is your friend. If you really want to do that, you really ought to specify a port number also. And a protocol. And arguments. How about, instead: //ddname DD POPEN='curl https://bama.ua.edu:80/cgi-bin/wa',PATHOPTS=ORDONLY, ... -- gil DNS can be changed to point to another IP address. Either the main registry, or the DNS resolution host can be substituted. http://www.survivalblog.com/ http://64.92.111.122/dottedquad.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: JCL sheesh! for today
From my naive viewpoint it's not hard to do a better replacement, if it not were these two catches: 1. The corresponding functionality in the initiator code etc, etc... 2. The fact that everyone and everything is accustomed to the JCL as it is! As inline data is now allowed in procs as of z/OS 1.13 You could e g have a rexx pgm that reads input that can have any syntax of Your choice and execute it as allocations etc - and even interpret eventual rexx code in the data. The real problem is to get a formalized syntax that is easy to understand and non-ambiguous for operational personnel in general - but first and foremost accepted universally or at least by the majority of vendors et al. And here we stumble on the fact that everything (more or less) in this world is proprietary and dependent of IBM... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Elardus Engelbrecht Skickat: den 8 december 2011 13:33 Till: IBM-MAIN@bama.ua.edu Ämne: Re: JCL sheesh! for today Lindy Mayfield wrote: I put this up a while ago. It is a talk given by Fred Brooks, Jr. on the 40th year anniversary of the IBM/360. He doesn't seem to like JCL that much, either. :-) http://lilliana.eu/downloads/jcltalk.txt Thanks. Very interesting. I see JCL as a way where the system makes input and output to be available to a program. Example: A COBOL program reads in a dataset and write it out somewhere. It does not care where that dataset really is residing. Tape? Dataset? Terminal. Where is that output? Anywhere, printer, JESSPOOL, another tape. Now JCL is a way to combine all these things. There is one catch ... Actual implementation gone * badly wrong. 'Backward compatibility' made it worse. Ok, ok, that is just my opinion. Feel free to flame me. ;-D If I can get a cent for everytime someone said 'I hate JCL', I could retire and get me that 100 metre yacht with a crew and girlies... :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 8 Dec 2011 14:18:06 +0100, Thomas Berg wrote: From my naive viewpoint it's not hard to do a better replacement, Like JOL? As inline data is now allowed in procs as of z/OS 1.13 You could e g have a rexx pgm that reads input that can have any syntax of Your choice and execute it as allocations etc - and even interpret eventual rexx code in the data. One difficulty with trying to replace JCL with ReXX code is that the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 2011-12-08 at 04:24 -0500, Ken Brick wrote: At that time (1960's) I doubt that the developers had the rigourous documentation requirements of even yesteryear much less recent years. Some of the PLMs of the time were quite useful. When the HIPO fad was mandated circa 1974 the PLMs lost much of their usability. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 8 Dec 2011 07:35:36 -0600, Tom Marchant wrote: One difficulty with trying to replace JCL with ReXX code is that the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. That function could, and should, be provided to Rexx in a function package. I can even imagine an extension to BPXWDYN that would allow allocating multiple data sets in a single call. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: JCL sheesh! for today
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Tom Marchant Skickat: den 8 december 2011 14:36 Till: IBM-MAIN@bama.ua.edu Ämne: Re: JCL sheesh! for today On Thu, 8 Dec 2011 14:18:06 +0100, Thomas Berg wrote: From my naive viewpoint it's not hard to do a better replacement, Like JOL? Oh, Yes. I forgot that one for the moment. As inline data is now allowed in procs as of z/OS 1.13 You could e g have a rexx pgm that reads input that can have any syntax of Your choice and execute it as allocations etc - and even interpret eventual rexx code in the data. One difficulty with trying to replace JCL with ReXX code is that the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. Yes, but this also often causes unneeded queuing as I see it. If You e g does the allocations in a rexx You could check for ENQ's before allocation and/or retry the allocation repeatedly (per Your choice) with waits between the retries. And also in this situation select the needed allocation dependencies without the all or nothing approach that the initiator takes. Note that if You e g is using IDCAMS for allocating/deleting datasets it's even today under the radar as seen from the initiator. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
On Thu, 8 Dec 2011 15:13:04 +0100, Thomas Berg wrote: the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. Yes, but this also often causes unneeded queuing as I see it. If You e g does the allocations in a rexx You could check for ENQ's before allocation and/or retry the allocation repeatedly (per Your choice) with waits between the retries. And also in this situation select the needed Than merely substitutes a livelock for a deadlock. If Job 1 holds resource A and repeatedly attempts to obtain resource B while Job 2 holds resource B and repeatedly attempts to obtain resource A, the process never terminates, and both resources remain inaccessible to other jobs for the duration. allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. Note that if You e g is using IDCAMS for allocating/deleting datasets it's even today under the radar as seen from the initiator. I doubt that IDCAMS allows deleting a data set while another job has it enqueued, even SHR. That would involve an integrity exposure. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Biggest gotcha here would be replacing CA-11 for automated restart of a job. CA-11 is very incestuous with the SWA control blocks, reading and modifying them. If you replace JCL with REXX or UNIX shell scripts, then the code you write needs to include restart logic. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand 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 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Thursday, December 08, 2011 7:18 AM To: IBM-MAIN@bama.ua.edu Subject: SV: JCL sheesh! for today From my naive viewpoint it's not hard to do a better replacement, if it not were these two catches: 1. The corresponding functionality in the initiator code etc, etc... 2. The fact that everyone and everything is accustomed to the JCL as it is! As inline data is now allowed in procs as of z/OS 1.13 You could e g have a rexx pgm that reads input that can have any syntax of Your choice and execute it as allocations etc - and even interpret eventual rexx code in the data. The real problem is to get a formalized syntax that is easy to understand and non-ambiguous for operational personnel in general - but first and foremost accepted universally or at least by the majority of vendors et al. And here we stumble on the fact that everything (more or less) in this world is proprietary and dependent of IBM... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Elardus Engelbrecht Skickat: den 8 december 2011 13:33 Till: IBM-MAIN@bama.ua.edu Ämne: Re: JCL sheesh! for today Lindy Mayfield wrote: I put this up a while ago. It is a talk given by Fred Brooks, Jr. on the 40th year anniversary of the IBM/360. He doesn't seem to like JCL that much, either. :-) http://lilliana.eu/downloads/jcltalk.txt Thanks. Very interesting. I see JCL as a way where the system makes input and output to be available to a program. Example: A COBOL program reads in a dataset and write it out somewhere. It does not care where that dataset really is residing. Tape? Dataset? Terminal. Where is that output? Anywhere, printer, JESSPOOL, another tape. Now JCL is a way to combine all these things. There is one catch ... Actual implementation gone * badly wrong. 'Backward compatibility' made it worse. Ok, ok, that is just my opinion. Feel free to flame me. ;-D If I can get a cent for everytime someone said 'I hate JCL', I could retire and get me that 100 metre yacht with a crew and girlies... :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, Dec 8, 2011 at 4:24 AM, Ken Brick kbr...@netspace.net.au wrote: I suspect the problem with JCL is that the base code was laid down about fifty years ago. I remember seeing eye catchers with 1968 dates in the late 1990's. At that time (1960's) I doubt that the developers had the rigourous documentation requirements of even yesteryear much less recent years. So I think that to days developers are as much in the dark about the code as you and I. Possibly someone out there who kept the source tapes (Seymour Metz (I apologize in advance about name spelling) could comment about code quality. And I must say that quality expectation between 1970 and 2010 are vastly different Sure, but that's an *explanation*, not an *excuse*. Here's the throwdown: would z/OS be easier to use and thus more popular and thus make more money for IBM if something better than JCL were available? -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
The inconvenient fact is that is the effective way to prevent deadlocks. Is not another technically plausible approach for this theoretical new JCL and initiator thing to always make the requests in alphabetical order? (Okay, ascending collating sequence?) That way all jobs that require both resources A and B would always ask for A first and prevent the dead- or livelock that you describe? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, December 08, 2011 6:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SV: JCL sheesh! for today On Thu, 8 Dec 2011 15:13:04 +0100, Thomas Berg wrote: the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. Yes, but this also often causes unneeded queuing as I see it. If You e g does the allocations in a rexx You could check for ENQ's before allocation and/or retry the allocation repeatedly (per Your choice) with waits between the retries. And also in this situation select the needed Than merely substitutes a livelock for a deadlock. If Job 1 holds resource A and repeatedly attempts to obtain resource B while Job 2 holds resource B and repeatedly attempts to obtain resource A, the process never terminates, and both resources remain inaccessible to other jobs for the duration. allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Wed, 7 Dec 2011 16:21:49 -0800, Charles Mills wrote: If the DDNAME parameter appears . the referenced DD statement must not contain a . PATH parameter. In other words, you can NOT do //DD1 DD DDNAME=DD2 //DD2 DD PATH='/my/hfs/path' Sheesh! Thanks for listening. All in all, it appears to me that the developers weren't sincerely motivated to make Unix System Services work as it should. It's a half-hearted (is that the right anatomical reference?) implementation. Perhaps medium-speed, as in 'half-fast'? :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 8 Dec 2011 07:56:52 -0600, Paul Gilmartin wrote: On Thu, 8 Dec 2011 07:35:36 -0600, Tom Marchant wrote: One difficulty with trying to replace JCL with ReXX code is that the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. That function could, and should, be provided to Rexx in a function package. I can even imagine an extension to BPXWDYN that would allow allocating multiple data sets in a single call. Yes, that would be easy. More difficult would be to maintain the ENQ across deallocation and reallocation to different DDNAMES for use in different steps. Would you want to allocate all of the data sets for a hundred steps at the same time in the beginning of the job? Even for those steps that are skipped? What happens if you need to add or remove a step? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Charles, I had to go back to the fine manual to see what you are talking about. In the post I got from you, the message said ...contain a . PATH... (note the dot before the word PATH). The way I read the post, you couldn't use the . in a PATH parameter which kinda makes sense, as in how do you have a current directory in a JCL statement. Only when I went back to the book and saw where is was saying you can't use a PATH parameter at all did your post make sense to me. In that case, I agree completely with you. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Wednesday, December 07, 2011 6:22 PM To: IBM-MAIN@bama.ua.edu Subject: JCL sheesh! for today If the DDNAME parameter appears . the referenced DD statement must not contain a . PATH parameter. In other words, you can NOT do //DD1 DD DDNAME=DD2 //DD2 DD PATH='/my/hfs/path' Sheesh! Thanks for listening. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, Dec 8, 2011 at 10:08 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: Yes, that would be easy. More difficult would be to maintain the ENQ across deallocation and reallocation to different DDNAMES for use in different steps. Would you want to allocate all of the data sets for a hundred steps at the same time in the beginning of the job? Even for those steps that are skipped? What happens if you need to add or remove a step? So maybe the job declares the data sets at the start, but the DDNAMEs are dynamic. Declaring and allocating/using are different... -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
On Thu, 8 Dec 2011 15:13:45 +, Pommier, Rex R. wrote: I had to go back to the fine manual to see what you are talking about. In the post I got from you, the message said ...contain a . PATH... (note the dot before the word PATH). The way I read the post, you couldn't use the . in a PATH parameter which kinda makes sense, as in how do you have a current directory in a JCL statement. ... To use Unix System Services, a process must be dubbed. If it's dubbed it must have a current directory. By default, that's the owner's HOME directory. It's worse than you indicate. Even if the process is has explicitly set a current directory, dynamic allocation still requires a fully qualified path. A valuable enhancement would be to support relative paths and tilde expansion in allocation. This would introduce no incompatibility because to date allocation accepts only paths that begin with '/' -- paths beginning with '.' or '~' would be syntactically distinct. Allowing relative paths in allocation would somewhat mitigate the 256-character limitation of dynamic allocation (but why is there such a limit? Isn't the TU length for SVC 99 a 16-bit field?) Allowing tilde expansion in allocation would significantly enhance the portability of JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: SV: JCL sheesh! for today
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 8 december 2011 15:34 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: JCL sheesh! for today On Thu, 8 Dec 2011 15:13:04 +0100, Thomas Berg wrote: the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. Yes, but this also often causes unneeded queuing as I see it. If You e g does the allocations in a rexx You could check for ENQ's before allocation and/or retry the allocation repeatedly (per Your choice) with waits between the retries. And also in this situation select the needed Than merely substitutes a livelock for a deadlock. If Job 1 holds resource A and repeatedly attempts to obtain resource B while Job 2 holds resource B and repeatedly attempts to obtain resource A, the process never terminates, and both resources remain inaccessible to other jobs for the duration. Here I presume an intelligent coder that has the needed knowledge of the application. Which is more or less the same knowledge that is needed to program the job chains/network in a job controller like OPC. allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. As I see it, deadlocks is not a big problem in well planned job chains. Note that if You e g is using IDCAMS for allocating/deleting datasets it's even today under the radar as seen from the initiator. I doubt that IDCAMS allows deleting a data set while another job has it enqueued, even SHR. That would involve an integrity exposure. But still: allocating datasets out of reach of the initiators all or nothing approach. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Yeah, I typed an ellipsis( . . .) and somewhere in the ether it got turned into a period or dot. Substitute ellipses for the dots in my OP and it will make more sense. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Thursday, December 08, 2011 7:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today Charles, I had to go back to the fine manual to see what you are talking about. In the post I got from you, the message said ...contain a . PATH... (note the dot before the word PATH). The way I read the post, you couldn't use the . in a PATH parameter which kinda makes sense, as in how do you have a current directory in a JCL statement. Only when I went back to the book and saw where is was saying you can't use a PATH parameter at all did your post make sense -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
YES! That was the JCL sheesh! for another day, that a DD statement has no home directory and that all paths must be absolute. I should be able to code PATH='foo/bar' and when I run the job that becomes /u/myuserid/foo/bar but when Gil runs the job it becomes /u/gilsid/foo/bar. Just like I could in a UNIX script (or PC-DOS BAT file, for that matter). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, December 08, 2011 7:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today On Thu, 8 Dec 2011 15:13:45 +, Pommier, Rex R. wrote: I had to go back to the fine manual to see what you are talking about. In the post I got from you, the message said ...contain a . PATH... (note the dot before the word PATH). The way I read the post, you couldn't use the . in a PATH parameter which kinda makes sense, as in how do you have a current directory in a JCL statement. ... To use Unix System Services, a process must be dubbed. If it's dubbed it must have a current directory. By default, that's the owner's HOME directory. It's worse than you indicate. Even if the process is has explicitly set a current directory, dynamic allocation still requires a fully qualified path. A valuable enhancement would be to support relative paths and tilde expansion in allocation. This would introduce no incompatibility because to date allocation accepts only paths that begin with '/' -- paths beginning with '.' or '~' would be syntactically distinct. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Thursday, December 08, 2011 10:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today YES! That was the JCL sheesh! for another day, that a DD statement has no home directory and that all paths must be absolute. I should be able to code PATH='foo/bar' and when I run the job that becomes /u/myuserid/foo/bar but when Gil runs the job it becomes /u/gilsid/foo/bar. Just like I could in a UNIX script (or PC-DOS BAT file, for that matter). Charles You could do: PATH='/u/RACUID/file.name.ext' And JCL will substitute your RACF id for RACUID. This does not help me because I would need RACUID in __lower case__ because that's how I do the UNIX home subdirectories. Before automount, when I had a hard coded /u subdirectory, I would have symlinks of upper case RACF id to the lower case directory name. But I can't do that, as best as I can tell, since I went to automount of /u. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Ack!!! I meant SYSUID not RACUID. RACUID is used in RACF profiles. SYSUID is used in JCL. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Thursday, December 08, 2011 10:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Thursday, December 08, 2011 10:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL sheesh! for today YES! That was the JCL sheesh! for another day, that a DD statement has no home directory and that all paths must be absolute. I should be able to code PATH='foo/bar' and when I run the job that becomes /u/myuserid/foo/bar but when Gil runs the job it becomes /u/gilsid/foo/bar. Just like I could in a UNIX script (or PC-DOS BAT file, for that matter). Charles You could do: PATH='/u/RACUID/file.name.ext' And JCL will substitute your RACF id for RACUID. This does not help me because I would need RACUID in __lower case__ because that's how I do the UNIX home subdirectories. Before automount, when I had a hard coded /u subdirectory, I would have symlinks of upper case RACF id to the lower case directory name. But I can't do that, as best as I can tell, since I went to automount of /u. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
At 06:50 -0800 on 12/08/2011, Charles Mills wrote about Re: SV: JCL sheesh! for today: The inconvenient fact is that is the effective way to prevent deadlocks. Is not another technically plausible approach for this theoretical new JCL and initiator thing to always make the requests in alphabetical order? (Okay, ascending collating sequence?) That way all jobs that require both resources A and B would always ask for A first and prevent the dead- or livelock that you describe? Charles Not going to fly since that requires that the programs ONLY issue 1 ENQ (listing all the needed datasets). So long as you allow dynamic allocation and its associated ENQ you have no way of insuring that you can not have the deadly embrace type of situation. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, December 08, 2011 6:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SV: JCL sheesh! for today On Thu, 8 Dec 2011 15:13:04 +0100, Thomas Berg wrote: the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. Yes, but this also often causes unneeded queuing as I see it. If You e g does the allocations in a rexx You could check for ENQ's before allocation and/or retry the allocation repeatedly (per Your choice) with waits between the retries. And also in this situation select the needed Than merely substitutes a livelock for a deadlock. If Job 1 holds resource A and repeatedly attempts to obtain resource B while Job 2 holds resource B and repeatedly attempts to obtain resource A, the process never terminates, and both resources remain inaccessible to other jobs for the duration. allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
At 08:34 -0600 on 12/08/2011, Paul Gilmartin wrote about Re: SV: JCL sheesh! for today: allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. This would be VERY easy to provide (so long as you can find a bit in the ENQ parms to ask for the EXC-SHR switch). There might need to be a tolerance PTF issued for older releases to insure that they will see the bit and wait for the DEQ as at present. All that is needed in the ENQ code itself is to switch the state in the record from EXC to SHR and then drive the routine in DEQ that runs the chain when you DEQ an EXC hold. This chain running would either release all the waiting SHRs (until chain end or running into another EXC) or leave the chain alone (depending on if the 2nd entry is an EXC, or there is no 2nd entry). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
In 6070967931553464.wa.paulgboulderaim@bama.ua.edu, on 12/08/2011 at 09:43 AM, Paul Gilmartin paulgboul...@aim.com said: A valuable enhancement would be to support relative paths and tilde expansion in allocation. Not just ~/foo but also ~bar/baz for access to another user's files. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
