Re: PARM=
[Note the date: On 5/23/2005 1:06 PM, Don Ault wrote: Well I did ask for comments, so I got what I deserved. I do appreciate the time you have all spent. If I do use some of your great ideas, please do me a favor and don't sue IBM for taking your intellectual property. I hate talking to lawyers. I'll try to address some (hopefully all) of the issues: 1. Hitching your cart to the wagon. That is, adding on marginally relevant (however worthwhile) enhancements to the PARM=100 line item. So far: a. The START command should support more than 61 characters on a passed parm string. I've let the Console folks know about the requirement. b. The ASIS issue. Quotes in JCL, who knows on CALL, TEST, etc. I will not likely be changing this, due to enough compatibility concerns already. Would make a good SHARE requirement. c. Support for inline DD * within procedures. I want it too. 2. Length 32K or 64K. I've flip-flopped on this one and agree 32K is safer and likely big enough for anything reasonable. This will avoid the issue of a negative length and I hope to retire before I see JCL with more than 32K of parms. Note that long parms are diced into SWA block sized pieces (x'B0') bytes in length. Long parm processing will be slow. 3. PARMLIB option to activate PARM100 This is needed, not just for the compatibility issue. Even if we forced a binder attribute, we still need a control to allow a customer to get all systems in a JES plex to a level that supports long parms before it is activated. Once you accept that, then if we don't support a command to change the setting, then we potentially force a sysplex wide IPL. z/OS developers get demerits for these. I believe we could do away with the DISPLAY support, in particular if we add the message to JCL output when long parms are active. 4. Compatibility issue. Everyone is right. We shouldn't have to worry about it, since it will unlikely be a problem, yet it will break somewhere and cause lots of yelling and screaming. To do it safe, we need a binder attribute. I am working on getting that sized. If we can't contain the cost, then I would likely go with only unauthorized programs getting long parms and if you don't want to take the chance, then turn off the system wide option. Since LE already supports long parms, we would want the C compiler to automatically specify the long parm binder option. As for a separate option for whether authorized programs can have long parms, I would rather go with the binder attribute, since it would be hard to verify that all authorized programs had been checked. 5. As for TSO commands, CALL, TEST, TESTAUTH. This has increased in complexity due to the untimely death of Martin Gally. I will need to find someone else to take up where Martin left off. We will all miss him. 6. SWA changes. Any program which cares about viewing or modifying the parms in SWA will be exposed to an incompatible change. Once this gets settled and targeted to a release, we will give as much warning as possible. The SCTX would be unchanged. The SCT would have a new field anchoring the chain of parm blocks. All parm blocks would be above the line. 7. As for user exits, I imagine that one could code IEFUSI to look at the SCT and make a determination as to whether to fail a job with parms 100. This assumes we don't have the binder option. With the binder option, I would see no point in having any exit care about this. 8. As for allowing the parmlib option to specify the max size parm string to support, instead of just an on/off switch. Sounds like a good idea. The default would be 100. Customers could set it to 256 and get some benefit out of it. I will look into this further. The message we add to JCL output when the length is anything but 100 could be something like this: IEF777I PARAMETER LENGTH n DETECTED OUT OF POSSIBLE mm SUPPORTED. 9. The other solutions involving a different JCL keyword (e.g. PARMX=) or a PARMDD type solution were rejected due to cost and incompatibility with exiting batch job streams. We would need to implement the symbolic substitution in the specified file. Ding/Ding - Round 2 Don Ault, 8-295-1750, 845-435-1750 Don, found this while going through old emails. Whatever happened with this? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff /
Re: PARM=
At 18:23 -0700 on 01/01/2011, Steve Comstock wrote about Re: PARM=: [Note the date: On 5/23/2005 1:06 PM, Don Ault wrote: Well I did ask for comments, so I got what I deserved. I do appreciate the time you have all spent. If I do use some of your great ideas, please do me a favor and don't sue IBM for taking your intellectual property. I hate talking to lawyers. I'll try to address some (hopefully all) of the issues: [snip] Don Ault, 8-295-1750, 845-435-1750 Don, found this while going through old emails. Whatever happened with this? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. It resumed as A Modest PARM Proposal and An Alternate Modest PARM Proposal in October 2009. -- 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: PARM problem - HELP
John Not understanding why you still have a problem after all the suggestions you have had! Here is the precise solution for you according to the reference given by Bob Rutledge. 1 2 3 4 5 6 7 8 123456789012345678901234567890123456789012345678901234567890123456 78901234567890 // PARM='SH echo sftp -b /u/bpxbatch/mccheckftpfis-depot-test.ucdavis.e // du |su -s bpxbtch' When I positioned your example I see you had somehow taken on board the idea that the continuation of the text on the second card image might need to start in column 16. Here is the example from Bob's reference for comparison with the solution: 1 2 3 4 5 6 7 8 123456789012345678901234567890123456789012345678901234567890123456 78901234567890 //STEP1 EXEC PGM=IEFBR14,PARM=(PARM1,'/DIR1/DIR2 // /DIR3/DIR4/DIR5/DIR6/DIR7/DIR8/DIR9/DIR10/DIR11/DIR12/DI // R13/FILENM') Ha!, now I position it under the column template I see the manual is wrong! It should be - according to the text and in some sort of conformance with the ancient original rules of JCL - as follows: 1 2 3 4 5 6 7 8 123456789012345678901234567890123456789012345678901234567890123456 78901234567890 //STEP1 EXECPGM=IEFBR14,PARM=(PARM1,'/DIR1/DIR2 // /DIR3/DIR4/DIR5/DIR6/DIR7/DIR8/DIR9/DIR10/DIR11/DIR12/DI // R13/FILENM') I have repositioned all the text following EXEC on all three card images one position to the left. 10 marks for the author and 0 marks for the type-setter. I went back in order to check the redbook example and whoever typed that up got the positioning correct. You should make sure you read this post with a nonproportional font such as Courier New. You may need to copy and paste in something like Notepad and set the font with Format-Font. Although it lacks readability, I believe that this is the simplest solution. I hope you are now in a position (sic) to move on. Chris Mason On Tue, 5 Aug 2008 14:28:09 -0700, John Norgauer [EMAIL PROTECTED] wrote: Lizette - // SET P1='abc/def/ghi -sh' // SET P2='continue away' //STEP1 EXEC PGM=IEFBR14,PARM=(PARM1,'P1P1') not understanding your statement : PARM=(PARM1,'P1P2') Where does PARM1 get defined? John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
Bob Rutledge provided the answer - even if it obliged those interested to
locate the manual reference.
But it's very short so here goes:
quote
3.4.1.2 Continuing Parameter Fields Enclosed in Apostrophes
To continue a parameter that is enclosed in apostrophes:
Extend the parameter to column 71. Do not code an apostrophe in column 71
of a JCL statement that is continued.
The system interprets the apostrophe in column 71 as the final character in
the statement and ignores the continuation.
Code // in columns 1 and 2 of the following statement.
Continue the parameter in column 16 of the following statement even if this
splits the parameter. Trailing blanks or commas within the apostrophes do not
indicate a continued statement; the system treats them as part of the
parameter.
The following example shows the specification of a long file name in the PARM
field:
//STEP1 EXEC PGM=IEFBR14,PARM=(PARM1,'/DIR1/DIR2
// /DIR3/DIR4/DIR5/DIR6/DIR7/DIR8/DIR9/DIR10/DIR11/DIR12/DI
// R13/FILENM')
/quote
The example is a bit artificial so here's an example I found just about a
quarter
of an hour before spotting this thread[1] in a redbook and then wondered
whether I should post it as a heads-up having had to deal with something like
the same problem a little while ago where I used one of the alternative
techniques.[2]
quote
//NAMED9B PROC PARMS='-d 0'
//NAMED9B EXEC PGM=BPXBATCH,REGION=0K,TIME=NOLIMIT,
// PARM=('PGM /usr/lpp/tcpip/sbin/named -V v9 -c /etc/dnsdatbSYSCLONE.X
// /named9b.conf PARMS')
/quote
This example indicates that the column 71/column 16 technique can handle
use of lower case which was the particular problem I had a while ago.
What is fascinating about this technique - and shows that it is not a trick
which is how I would normally describe it - is that it looks very much as if it
dates from JCL as I first used it (see [3]). Then, apart from the // in
columns
1 and 2, assembler rules were followed meaning that text had to be extended
to column 71 and had to be continued in column 16. I seem to remember that
you needed to put a continuation punch in column 72 but that requirement
seems to have been dropped - in terms of column 72 being ignored I suppose.
It had not occurred to me until I saw that example in the redbook today that
that old syntax could still apply. However there is that old IBM rule - nearly
always valid - that what once worked will continue to work - e'en to the
edge of doom.
As a consequence, I don't think you will be able to specify this type and
length of PARM field for this program via JCL.
Well, of course, you can. Nevertheless there is still the 100 character length
limit for the PARM field which Steve has confirmed still exists.
Chris Mason
[1] A genuine coincidence!
[2] Many years ago[3] I wrote a little program to take PARM data and create
small files to use in utilities so that I could run utilities - say, LISTVTOC
and
the like - purely from a 3270 on which I was running my MVS test system
console, that is, I avoided having to mess about creating little files in a
data
set and then submitting. I had not supposed that the code to 71 (put a
continuation punch in 72) and continue from 16 technique would still work
and so I had a convention that one of three special characters killed the
next character as a way of dealing with those pesky commas using the William
Blair technique. Strangely enough, one of my other special characters was to
arrange to have a continuation punch in column 72 and continue from column
16.
[3] Many years before that, actually 1967, shortly before I started working
with IBM 360s full time but knowing I would soon, I decided to prepare myself
by doing some programming. The facilities offered by the organisation where I
worked, a research laboratory, were the old-fashoined RJE which required
leaving cards at a hatch so that the work could be taken by van to the HQ
location and returned the next day with the printout to the same hatch. The
program cards needed to be wrapped in some other cards and those cards had
to be punched up from some coding sheets handed out by a particular office.
Before I could say What (expletive deleted) is all this rubbish!, the lady
said Don't ask, just do it!. Furthermore I particularly remember the warnings
about how to handle columns 1/2, columns 71/72 and column 16!
On Mon, 4 Aug 2008 19:09:11 -0400, Bob Rutledge
[EMAIL PROTECTED] wrote:
http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2B670/3.4.1.2?
SHELF=EZ2ZO10KDT=20070427231644CASE=
Bob
John Norgauer wrote:
Here's my error:
10 //PS082 EXEC PGM=BPXBATCH,
//**
**
// PARM='SH echo sftp -b /u/bpxbatch/mccheckftp
// fis-depot-test.ucdavis.edu |su -s bpxbtch'
11 //SYSPRINT DD SYSOUT=*
12 //STDOUTDD
Re: PARM problem - HELP
Sorry am I late into this thread and this may have already been offered.
Would the use of the SET Statement in JCL also be a solution?
// SET P1='abc/def/ghi -sh'
// SET P2='continue away'
//STEP1 EXEC PGM=IEFBR14,PARM=(PARM1,'P1P1')
I would think that so long as the concatenated P1P2 etc... does not
exceed 100 characters, that this also might work.
I use this technique with BPXBATCH because I like simple solutions. It also
makes it easier when I have redundancy in the parms for multiple executions.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chris Mason
Sent: Tuesday, August 05, 2008 8:37 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: PARM problem - HELP
Bob Rutledge provided the answer - even if it obliged those interested
to
locate the manual reference.
But it's very short so here goes:
quote
3.4.1.2 Continuing Parameter Fields Enclosed in Apostrophes
To continue a parameter that is enclosed in apostrophes:
Extend the parameter to column 71. Do not code an apostrophe in column
71
of a JCL statement that is continued.
The system interprets the apostrophe in column 71 as the final
character in
the statement and ignores the continuation.
Code // in columns 1 and 2 of the following statement.
Continue the parameter in column 16 of the following statement even if
this
splits the parameter. Trailing blanks or commas within the apostrophes
do not
indicate a continued statement; the system treats them as part of the
parameter.
The following example shows the specification of a long file name in
the PARM
field:
//STEP1 EXEC
PGM=IEFBR14,PARM=(PARM1,'/DIR1/DIR2
//
/DIR3/DIR4/DIR5/DIR6/DIR7/DIR8/DIR9/DIR10/DIR11/DIR12/DI
// R13/FILENM')
/quote
The example is a bit artificial so here's an example I found just about
a quarter
of an hour before spotting this thread[1] in a redbook and then
wondered
whether I should post it as a heads-up having had to deal with
something like
the same problem a little while ago where I used one of the alternative
techniques.[2]
quote
//NAMED9B PROC PARMS='-d 0'
//NAMED9B EXEC PGM=BPXBATCH,REGION=0K,TIME=NOLIMIT,
// PARM=('PGM /usr/lpp/tcpip/sbin/named -V v9 -c
/etc/dnsdatbSYSCLONE.X
// /named9b.conf PARMS')
/quote
This example indicates that the column 71/column 16 technique can
handle
use of lower case which was the particular problem I had a while ago.
What is fascinating about this technique - and shows that it is not a
trick
which is how I would normally describe it - is that it looks very much
as if it
dates from JCL as I first used it (see [3]). Then, apart from the //
in columns
1 and 2, assembler rules were followed meaning that text had to be
extended
to column 71 and had to be continued in column 16. I seem to remember
that
you needed to put a continuation punch in column 72 but that
requirement
seems to have been dropped - in terms of column 72 being ignored I
suppose.
It had not occurred to me until I saw that example in the redbook today
that
that old syntax could still apply. However there is that old IBM rule -
nearly
always valid - that what once worked will continue to work - e'en to
the
edge of doom.
As a consequence, I don't think you will be able to specify this type
and
length of PARM field for this program via JCL.
Well, of course, you can. Nevertheless there is still the 100 character
length
limit for the PARM field which Steve has confirmed still exists.
Chris Mason
On Mon, 4 Aug 2008 19:09:11 -0400, Bob Rutledge
[EMAIL PROTECTED] wrote:
http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2B670/3.4.1.2?
SHELF=EZ2ZO10KDT=20070427231644CASE=
Bob
John Norgauer wrote:
Here's my error:
10 //PS082 EXEC PGM=BPXBATCH,
//**
**
// PARM='SH echo sftp -b /u/bpxbatch/mccheckftp
// fis-depot-test.ucdavis.edu |su -s bpxbtch'
11 //SYSPRINT DD SYSOUT=*
12 //STDOUTDD SYSOUT=*
13 //STDERRDD SYSOUT=*
MT NO. MESSAGE
10 IEF642I EXCESSIVE PARAMETER LENGTH IN THE PARM FIELD
Thanks.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
Lizette - // SET P1='abc/def/ghi -sh' // SET P2='continue away' //STEP1 EXEC PGM=IEFBR14,PARM=(PARM1,'P1P1') not understanding your statement : PARM=(PARM1,'P1P2') Where does PARM1 get defined? John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
I was just using the supplied JCL in the post I was responding to. So PARM1 has no play in my example of the use of SET statement However, You could do the same thing with BPXBATCH JCL // SET P1=' echo sftp -b /u/bpxbatch/mccheckftp' // SET P2=' fis-depot-test.ucdavis.edu |su -s bpxbtch' //* //PS082 EXEC PGM=BPXBATCH,PARM='P1P2' //* //SYSPRINT DD SYSOUT=* //STDOUTDD SYSOUT=* //STDERRDD SYSOUT=* Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Norgauer Sent: Tuesday, August 05, 2008 5:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM problem - HELP Lizette - // SET P1='abc/def/ghi -sh' // SET P2='continue away' //STEP1 EXEC PGM=IEFBR14,PARM=(PARM1,'P1P1') not understanding your statement : PARM=(PARM1,'P1P2') Where does PARM1 get defined? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
Your PARM field is too long to fit on one card:
// PARM='SH echo sftp -b /u/bpxbatch/mccheckftp
// fis-depot-test.ucdavis.edu |su -s bpxbtch'
The rules of continuation for the PARM field would ostensibly
require that you specify it as follows (that is, the correct
syntax for continuation would be):
// PARM=('SH echo sftp -b /u/bpxbatch/mccheckftp',
// 'fis-depot-test.ucdavis.edu |su -s bpxbtch')
where each piece is enclosed in apostrophes, and all
but the last piece is followed by a comma, and all of
the pieces are enclosed in parentheses.
However, doing so will cause a comma to be included in the
actual PARM information that will be passed to the program.
The JCL will work, and the long PARM will be passed to the
program, but I suspect that the program will not accept the
resulting embedded comma, or do something else undesirable.
As a consequence, I don't think you will be able to
specify this type and length of PARM field for this
program via JCL.
--
WB
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
John Norgauer wrote: Here's my error: 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp // fis-depot-test.ucdavis.edu |su -s bpxbtch' 11 //SYSPRINT DD SYSOUT=* 12 //STDOUTDD SYSOUT=* 13 //STDERRDD SYSOUT=* MT NO. MESSAGE 10 IEF642I EXCESSIVE PARAMETER LENGTH IN THE PARM FIELD Thanks. John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon Try without any excess spaces in the first PARM line, maybe: // PARM='SH echo sftp -b /u/bpxbatch/mccheck ftpfis-depot-test.ucdavis.edu |su // -s bpxbtch' Those trailing spaces you had in the first line count against your 100 limit. You can even break up a parameter in mid-string if your data needs it; but the above should work. Alternatively, you can define SET symbols and concatenate them. // SET PART1='/u/bpxbatch/mccheck' // SET PART2=' ftpfis-depot-test.ucdavis.edu ' // SET PART3=' | su -s bpxbtch' //PS082 EXEC PGM=BPXBATCH,PARM=PART1PART2PART3 Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2B670/3.4.1.2?SHELF=EZ2ZO10KDT=20070427231644CASE= Bob John Norgauer wrote: Here's my error: 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp // fis-depot-test.ucdavis.edu |su -s bpxbtch' 11 //SYSPRINT DD SYSOUT=* 12 //STDOUTDD SYSOUT=* 13 //STDERRDD SYSOUT=* MT NO. MESSAGE 10 IEF642I EXCESSIVE PARAMETER LENGTH IN THE PARM FIELD Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
How about moving those into a shell script? PARM='SH /u/user/my.sh' /u/user/my.sh would contain the stmts currently on your PARM stmt. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Norgauer Sent: Monday, August 04, 2008 5:49 PM To: IBM-MAIN@BAMA.UA.EDU Subject: PARM problem - HELP Here's my error: 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp // fis-depot-test.ucdavis.edu |su -s bpxbtch' 11 //SYSPRINT DD SYSOUT=* 12 //STDOUTDD SYSOUT=* 13 //STDERRDD SYSOUT=* MT NO. MESSAGE 10 IEF642I EXCESSIVE PARAMETER LENGTH IN THE PARM FIELD Thanks. John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM problem - HELP
On Mon, 4 Aug 2008 18:06:56 -0500, William H. Blair wrote:
The rules of continuation for the PARM field would ostensibly
require that you specify it as follows (that is, the correct
syntax for continuation would be):
// PARM=('SH echo sftp -b /u/bpxbatch/mccheckftp',
// 'fis-depot-test.ucdavis.edu |su -s bpxbtch')
where each piece is enclosed in apostrophes, and all
but the last piece is followed by a comma, and all of
the pieces are enclosed in parentheses.
However, doing so will cause a comma to be included in the
actual PARM information that will be passed to the program.
The JCL will work, and the long PARM will be passed to the
program, but I suspect that the program will not accept the
resulting embedded comma, or do something else undesirable.
As a consequence, I don't think you will be able to
specify this type and length of PARM field for this
program via JCL.
This misconception is so prevalent that I wonder whether it
reflects a syntactic rule from days of yore. I know that's
what I was taught in my first brush with JCL decades ago,
and I never learned better until long pathnames in MVS-OE
impelled me to seek a better answer.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
It is what it is! Deal with it or submit a requirement! snip On Fri, 25 Jan 2008 10:40:43 -0600, Paul Gilmartin wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: I HATE JCL! I invite any IBM representative participating on this list to defend such divergence of conventions; I expect a conspicuous silence, much less an apology to customers. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote:
normally I have seen a null parm coded as adjacent comma's.
//OUT01OUTPUT USERDATA=('A',,'C')
On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin
wrote:
snip
I HATE JCL!
Nope. Same error:
3 // SET SYMBOL=''
4 // SET SYMBOL=
5 //STEP0EXEC PGM=IEFBR14,PARM=
//*
6 //STEP EXEC PGM=IEFBR14,PARM=''
//*
7 //OUT00OUTPUT USERDATA=('A','B','C')
//*
8 //OUT01OUTPUT USERDATA=('A',,'C')
//*
9 //OUT02OUTPUT USERDATA=('A','','C')
//*
//* :w ! submit lstc3mvs
STMT NO. MESSAGE
-
8 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
9 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
Note that in SET and PARM (which surprised me) either nothing
or '' is accepted as a representation of the null string. One
major flaw of JCL is its inconsistency. Conway's Law. It seems
that each feature of JCL was assigned to a different coder, and
they didn't coordinate on conventions.
In fact, since:
22.70 z/OS V1R7.0 MVS JCL Reference
__
22.70 USERDATA Parameter
Purpose
The purpose and use of this keyword is defined by the installation.
... I.e. anything the user wants, there's strong reason not to impose
frivolous lexical restrictions on its values. In fact, limitation
of each subparameter value to 60 chararcters (even less than 100)
may be an imposition on some intended uses. And the prohibition
of empty strings has an unpleasant astonishment factor for users
who assign the empty string to a JCL symbol, then attempt to use
that symbol's value in USERDATA.
Would any IBM representative care to supply a rationale for
the restriction?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: snip I HATE JCL! It gets worse: 22.1.4.1 z/OS V1R7.0 MVS JCL Reference __ 22.1.4.1 Using enclosing apostrophes in OUTPUT parameters [ ... ] Symbolic Parameters: Do not enclose symbolic parameters within apostrophes . Symbolic parameters enclosed in apostrophes are not resolved for this keyword. C'mon, guys: Why! More often than not, things enclosed in apostrophes are treated as literals rather than variables. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: snip I HATE JCL! It gets worse: 22.1.4.1 z/OS V1R7.0 MVS JCL Reference __ 22.1.4.1 Using enclosing apostrophes in OUTPUT parameters [ ... ] Symbolic Parameters: Do not enclose symbolic parameters within apostrophes . Symbolic parameters enclosed in apostrophes are not resolved for this keyword. C'mon, guys: Why! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 10:17:55 -0600, Chase, John wrote: On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: snip I HATE JCL! More often than not, things enclosed in apostrophes are treated as literals rather than variables. Why, then, is it ever otherwise? Why isn't it Always, rather than More often than not? Why are not the same rules used for parsing strings in all contexts? Why are symbols within apostrophes resolved for the PATH keyword of the DD statement, but not for for the USERPATH keyword of the OUTPUT statement when the two are so notionally similar? It's not as if Development were struggling to get Release 1.0 of OS/360 out the door, as 40+ years ago. Both PATH and USERPATH are relatively recent enhancements to a mature product; designers should have had time to consider the need for uniformity. Heck, the parser code could even have been reused, saving development resource while providing such uniformity. I invite any IBM representative participating on this list to defend such divergence of conventions; I expect a conspicuous silence, much less an apology to customers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 10:40:43 -0600, Paul Gilmartin wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: I HATE JCL! I invite any IBM representative participating on this list to defend such divergence of conventions; I expect a conspicuous silence, much less an apology to customers. Why not end your constant ranting and submit a requirement to IBM Marketing or SHARE (or your favorite other user group, if any) so that you are using the official channels and NOT wasting everyone's bandwidth on ibm-main??? Seriously! -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
Paul, If you think IBM JCL is bad you would go completely mental over how DPS-8 systems JCL was done. As Tom mentioned, submit a requirement to IBM if the Parm length limit bugs you too much. They will not change anything based on ranting on a forum or a listserv. This isn't the gaming industry where the loudest rant gets the changes. If you want IBM to do something about it, contact them! I have a few times in the past and they are always helpful and even fixed an issue for our shop once. Darren -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
In [EMAIL PROTECTED], on 01/23/2008 at 03:22 PM, Ed Gould [EMAIL PROTECTED] said: We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I see no such circumvention. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. The OUTPUT statement is not an extension of the EXEC statement and has nothing to do with PARM. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. No. IBM would still have needed to add the OUTPUT statement and nothing in the code for the extended PARM could have been pirated for us in OUTPUT. As a side issue are these new JCL parameters supported in dynamic allocation? Yes. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
I have yet to find a way to access the information on an output statement. Can you give a hint as to where to find it? curious pup IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 01/23/2008 05:11:23 PM: And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' where abcd is the label of an // OUTPUT statement available to the application. You can then use many of the parameters on the OUTPUT statement for passing parameter information. For example, ADDRESS= can contain up to 4 subparameters, each of which can be up to 60 bytes. . . . Retrieving this data is left as an exercise for the user. But it would likely be done in an assembler subroutine. John McKown - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Jan 24, 2008, at 8:39 AM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 01/23/2008 at 03:22 PM, Ed Gould [EMAIL PROTECTED] said: We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I see no such circumvention. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. The OUTPUT statement is not an extension of the EXEC statement and has nothing to do with PARM. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. No. IBM would still have needed to add the OUTPUT statement and nothing in the code for the extended PARM could have been pirated for us in OUTPUT. As a side issue are these new JCL parameters supported in dynamic allocation? Yes. Shmuel: I guess we differ in what you see and what I see. However its not worth disagreeing about. Yes it is simpler to do it the way (adding new JCL statements ), but from my understanding about the last re- write if there had been no rewrite, the code that would have been needed would have been quite a bit, as it was originally written it had turned into a monster to add new JCL statements. Now it was a minor addition (from what I heard). If there had been no restriction of parm length I believe the new JCL statements could have been created using dynamic allocation. But its not worth talking about have it your way. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Wed, 23 Jan 2008 16:11:23 -0600, McKown, John wrote:
And you just came up with a bit of a methodology that could be used
(with some difficulty) in our own application programs. In a step which
wants a PARM value 100 characters, use something like: // PARM='abcd '
where abcd is the label of an // OUTPUT statement available to the
application. You can then use many of the parameters on the OUTPUT
statement for passing parameter information. ...
I HATE JCL!
3 //STEP EXEC PGM=IEFBR14
//*
4 //OUT00OUTPUT USERDATA=('A','B','C')
//*
5 //OUT01OUTPUT USERDATA=('A','','C')
//*
//* :w ! submit lstc3mvs
STMT NO. MESSAGE
-
5 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
Yes, it's documented that way.
No, there's no reason they had to do it that way, other
than to deprive the customer of some flexibility. (Well,
maybe in some of their processing loops they use a null
subparameter as a list terminator. But that could have
been done otherwise. Or did they want the subparameter
values to be MVC-eligible? Still, that coding shortcut
doesn't justify the abandoning of generality.)
Would any IBM representative care to supply a rationale for
the restriction?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
Hi Gil,
I wonder if your null parameter is misinterpreting your quotes...something like
the rule that to support imbedded quote, you must code two in sequence, the
first as an escape character..
normally I have seen a null parm coded as adjacent comma's.
//OUT01OUTPUT USERDATA=('A',,'C')
On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin
[EMAIL PROTECTED] wrote:
snip
I HATE JCL!
3 //STEP EXEC PGM=IEFBR14
//*
4 //OUT00OUTPUT USERDATA=('A','B','C')
//*
5 //OUT01OUTPUT USERDATA=('A','','C')
//*
//* :w ! submit lstc3mvs
STMT NO. MESSAGE
-
5 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
Yes, it's documented that way.
No, there's no reason they had to do it that way, other
than to deprive the customer of some flexibility. (Well,
maybe in some of their processing loops they use a null
subparameter as a list terminator. But that could have
been done otherwise. Or did they want the subparameter
values to be MVC-eligible? Still, that coding shortcut
doesn't justify the abandoning of generality.)
Would any IBM representative care to supply a rationale for
the restriction?
-- gil
Regards
Bruce Hewson
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On 23 Jan 2008 13:22:31 -0800, [EMAIL PROTECTED] (Ed Gould) wrote: We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I am *NOT* complaining but just showing those who have complained how IBM got around its own 100 character max length restriction. This is the interesting as it shows how far IBM had to go to get around the restriction. Getting around a restriction often requires more hoops to jump through than removing the restriction. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Wednesday, January 23, 2008 3:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I am *NOT* complaining but just showing those who have complained how IBM got around its own 100 character max length restriction. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. I'll bet a beer that this cost IBM a fair amount of change in order to implement these new JCL fields. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. Yes I know it was re-written (and probably is for the best) but in any case it would have been less costly. As a side issue are these new JCL parameters supported in dynamic allocation? If not has anyone tried putting in a Share requirement and if so what was the outcome? Ed And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' where abcd is the label of an // OUTPUT statement available to the application. You can then use many of the parameters on the OUTPUT statement for passing parameter information. For example, ADDRESS= can contain up to 4 subparameters, each of which can be up to 60 bytes. That is 240 characters. BUILDING gives another 60 characters (300 so far). DEPT gives yet another 60 (now 360 bytes). MAILBCC can be up to 32 addresses of 60 characters each, or 1920 bytes (now at 2280 bytes). MAILCC gives the same as MAILBCC (now up to 4200 bytes). MAILFILE gives another 60 bytes (4260 total). MAILFROM another 60 (4320 bytes). MAILTO another 32 by 60 characters (1920 more for 6240 bytes). NAME= for 60 more (6300 types). PRTATTRS for 127 characters (6427 bytes). PRTOPTNS for 16 characters (6443 bytes). PRTQUEUE for 127 bytes (6570 bytes). REPLYTO for 60 bytes (6630 bytes total, so far). ROOM gives another 60 bytes (6690 bytes). TITLE, another 60 bytes (6750 bytes). USERDATA gives 16 times 60 or 960 bytes (7710 bytes). USERPATH for 8 times 254 bytes or 2032 bytes (9742 bytes). WRITER give a final 8 bytes for a grand total of 9750 bytes, assuming I haven't misadded anywhere. Retrieving this data is left as an exercise for the user. But it would likely be done in an assembler subroutine. Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, you could architect your main program to only accept OUTPUT statement names in the PARM=. A PARM is 100 bytes. Assuming that you'd need a space as a separator, what is the maximum number of possible labels which could be given to the main routine? The first characters must be alphabetic or national. That's 29 values. The second through 6th can also be numeric. That's 39 values. So, there are 29 single character labels, taking 2 characters (trailing blank). That's 58 characters, leaving 42. In that, you can put 14 more 2 character labels. That's a total of 43 possible labels of OUTPUT statements, each possibly having 9750 bytes of parameter information, for a super grand total of 419,250 bytes of parameter information. WOW! I exceeded the magic 64K! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Wed, 23 Jan 2008 16:11:23 -0600, McKown, John [EMAIL PROTECTED] wrote: ... And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' where abcd is the label of an // OUTPUT statement ... Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, ... WOW! I exceeded the magic 64K! ... Yes, that is a clever technique. But document it very carefully if you choose to use it because it is very non-standard, and very unintuitive. People may not remember that ROOM contains a list of userids, or that the freeform text started in PRTQUEUE is continued in USERDATA, etc. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
sigh I was struggling desperately to resist contributing to this (again) thread. I lost. I suppose we all lost. On Wed, 23 Jan 2008 17:27:47 -0600, Patrick O'Keefe wrote: On Wed, 23 Jan 2008 16:11:23 -0600, McKown, John wrote: ... And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' Or a wildcard? PARM='abcd*', representing abcd00, abcd01, ...? where abcd is the label of an // OUTPUT statement ... Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, ... WOW! I exceeded the magic 64K! ... Yes, that is a clever technique. But document it very carefully if you choose to use it because it is very non-standard, and very unintuitive. And it isn't conformant to the expectations of unmodified existing load modules. But a wrapper program: //STEP EXEC PGM=CATPARM,PARM='LOADMOD/ABCD*' ... that could string together the USERDATA fields, point R1 ... at the result and XCTL LOADMOD? Would there need to be both an authorized and an unauthorized version? I suppose one could force unauthorized with a STEPLIB catenation. And symbolic substitution would work, wouldn't it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Jan 23, 2008, at 4:11 PM, McKown, John wrote: ---SNIP--- Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, you could architect your main program to only accept OUTPUT statement names in the PARM=. A PARM is 100 bytes. Assuming that you'd need a space as a separator, what is the maximum number of possible labels which could be given to the main routine? The first characters must be alphabetic or national. That's 29 values. The second through 6th can also be numeric. That's 39 values. So, there are 29 single character labels, taking 2 characters (trailing blank). That's 58 characters, leaving 42. In that, you can put 14 more 2 character labels. That's a total of 43 possible labels of OUTPUT statements, each possibly having 9750 bytes of parameter information, for a super grand total of 419,250 bytes of parameter information. WOW! I exceeded the magic 64K! ---SNIP-- Chuckle that is why I suggested the length be permitted up to an address space size. I did that partly in jest but so there wouldn't be any real restrictions per se in the future. Looks like the future is coming at us a lot faster than we realized. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
In [EMAIL PROTECTED], on 01/07/2007 at 11:23 AM, Paul Gilmartin [EMAIL PROTECTED] said: It was explained to me on this list many months ago that instream data are stripped out of the JCL stream early in conversion, perhaps in a separate pass, before much other parsing is done. Not even early in conversion; JES2 and JES3 handle instream data well before they call the Converter. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
In a recent note, Jan MOEYERSONS said: Date: Thu, 4 Jan 2007 03:21:32 -0600 I never really understood why one can not have instream data in a PROC. Surely, it must not be complicated for IBM to solve that one... It was explained to me on this list many months ago that instream data are stripped out of the JCL stream early in conversion, perhaps in a separate pass, before much other parsing is done. At that point, the converter likely doesn't even understand that it's processing a PROC. Likewise, SET symbols are not yet available for substitution. This accounts for the former failure of: // SET X='DATA' // SET Y='YY' ... //SYSIN DD X,DLM='Y' ... YY ... sometimes with an OC7 in HASCDSAL (this 0C7 _was_ a system issue), sometimes with IEF465I - UNABLE TO ALLOCATE SUBSYSTEM DATA SET; never with a meaningful diagnostic. APAR OA03554 provided better reporting; it did not repair the underlying problem. 35 years ago, this fragmented design may have been a necessary accommodation to inconveniently small storage sizes; nowadays the only excuse for its persistence is inertia. o Supporting symbol substitution within the OPTFILE instream data Now, that would be tricky, no? Given the multi-pass (at least to external appearance) design of the C/I , yes, tricky. If the C/I were rewritten in a rational structure suited for the times, substitution in instream data sets would be SMOP. Some thought would need to be given to the constraints of FB80 records, however JES3 supports RECFM=V and longer LRECL in instream data sets (as does JES2 if a certain secret switch is set.) The list has had this discussion before. Let's not start it over. Just enter your requirements with Share or any other official way of communicating your needs to IBM. I had assumed that a Requirement for longer PARM support had long existed. How do I confirm or refute this? And if confirmed, how can I be added to an Interested Parties list? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. I really would like to see a (working!) example of such a gismo... I do it regularly with HLASM called from Rexx (not from JCL). Or, OK, if it is not from PARM= in JCL, then I can see that one can do that. you really need an example? No. You can use PARM='/OPTFILE(DD:COPT)' and then put all the parms in //COPT DD * o If this doesn't support symbol substitution, it falls short of many people's needs. One can combine the OPTFILE with other parameters in the PARM= in the JCL. Provided one can cram the parameters, requiring symbol substitution in the 100 bytes, that might just do the job. o If this can't be used with an instream data set in a library PROC, it falls short of many people's needs. (No, it's not satisfactory to provide the COPT with an overriding DD.) I never really understood why one can not have instream data in a PROC. Surely, it must not be complicated for IBM to solve that one... The OPTFILE circumvention is a stopgap with functional restrictions (above), which is implemented haphazardly in some, not all, utilities, likely with inconsistent syntax. True. If the Convertor/Interpreter/Initiator were to automate the process by: o Automatically reading the OPTFILE DD and converting to the traditional R1 points to halfword length followed by PARM text. Or much simpler: just allow and cater for more than 100 bytes PARM= field... o Supporting OPTFILE as an instream data set in library PROCs Or indeed any DD with instream data in PROCs! o Supporting symbol substitution within the OPTFILE instream data Now, that would be tricky, no? ... it would be closer to the requirement. But why not merely relax the 100-character limit on PARM? It makes no sense to retain a limit motivated by storage prices which have since dropped by five(?) orders of magnitude. The list has had this discussion before. Let's not start it over. Just enter your requirements with Share or any other official way of communicating your needs to IBM. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
In [EMAIL PROTECTED], on 01/02/2007 at 08:44 PM, Paul Gilmartin [EMAIL PROTECTED] said: Not obvious, apparently, to IBM (nor to many contributors to this list (I am not among them), who would prefer to see the restriction remain). FSVO many. I've seen messages criticizing specific implementation suggestions, discussing costs and suggesting that those who need the support submit formal requirements. I don't recall many posters saying that they preferred to see the restriction remain. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. I really would like to see a (working!) example of such a gismo... I was given a whole C library full of functios to recompile. the number of parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without editting indvidual functions what's the best work-around? You can use PARM='/OPTFILE(DD:COPT)' and then put all the parms in //COPT DD * Have a look at z/OS C/C++ User's Guide Document Number SC09-4767-03 Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
OPTFILE does it. From C/C++ User's Guide:
...
//DOCLGEXEC CBCCBG,
// INFILE='PETE.TEST.C(CBC3UBRC)',
// CPARM='OPTFILE(DD:CCOPT)'
//COMPILE.CCOPT DD *
LSEARCH('PETE.TESTHDR.H')
SEARCH('CEE.SCEEH.+','CBC.SCLBH.+
/*
...
rtFm
Walter Trovijo Jr.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
In a recent note, Jan MOEYERSONS said: Date: Wed, 3 Jan 2007 02:43:50 -0600 BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. I really would like to see a (working!) example of such a gismo... I do it regularly with HLASM called from Rexx (not from JCL). Or, at least I used to before we mostly converted to Tachyon. Do you really need an example? I was given a whole C library full of functios to recompile. the number of parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without editting indvidual functions what's the best work-around? You can use PARM='/OPTFILE(DD:COPT)' and then put all the parms in //COPT DD * o If this doesn't support symbol substitution, it falls short of many people's needs. o If this can't be used with an instream data set in a library PROC, it falls short of many people's needs. (No, it's not satisfactory to provide the COPT with an overriding DD.) The OPTFILE circumvention is a stopgap with functional restrictions (above), which is implemented haphazardly in some, not all, utilities, likely with inconsistent syntax. If the Convertor/Interpreter/Initiator were to automate the process by: o Automatically reading the OPTFILE DD and converting to the traditional R1 points to halfword length followed by PARM text. o Supporting OPTFILE as an instream data set in library PROCs o Supporting symbol substitution within the OPTFILE instream data ... it would be closer to the requirement. But why not merely relax the 100-character limit on PARM? It makes no sense to retain a limit motivated by storage prices which have since dropped by five(?) orders of magnitude. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
On Fri, 13 May 2005 14:49:53 +0200, R.S. [EMAIL PROTECTED] wrote: BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job for compilation, this job looks like regular JCL, but all the compiler options are in PARM field (many LINES of PARM) and that's why it is circumvented in some way. I don't remember details, but the need is obvious... I was given a whole C library full of functios to recompile. the number of parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without editting indvidual functions what's the best work-around? Andreas F. Geissbuehler AFG Consultants Inc. http://www.afgc-inc.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
Greetings, The Systems/C compiler from http://www.dignus.com/ supports indirect compiler options. In the PARM= or command line, you can point to a data set name or dd name that has the options. Check your compiler documentation to see if it has similar capabilities. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ -Original Message- On Fri, 13 May 2005 14:49:53 +0200, R.S. [EMAIL PROTECTED] wrote: BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job for compilation, this job looks like regular JCL, but all the compiler options are in PARM field (many LINES of PARM) and that's why it is circumvented in some way. I don't remember details, but the need is obvious... I was given a whole C library full of functios to recompile. the number of parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without editting indvidual functions what's the best work-around? Andreas F. Geissbuehler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
On Tue, 2 Jan 2007 17:09:06 -0600, Andreas F. Geissbuehler wrote: On Fri, 13 May 2005 14:49:53 +0200, R.S. wrote: BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job for compilation, this job looks like regular JCL, but all the compiler options are in PARM field (many LINES of PARM) and that's why it is circumvented in some way. I don't remember details, but the need is obvious... Not obvious, apparently, to IBM (nor to many contributors to this list (I am not among them), who would prefer to see the restriction remain). But a pat in the back for a good archive search. I was given a whole C library full of functios to recompile. the number of parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without editting indvidual functions what's the best work-around? o Invoke CCNDRVR from a Rexx EXEC. o Invoke c89 from make. This seems like a natural for make. Take your pick. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM= C compiler Options
First, I would cut my email address from the message you posted. I don't like spam-mail. Default behavior of your mail program is no excuse. Second, AFAIR, parameters can be provided using DD. -- Radoslaw Skorupka Lodz, Poland Andreas F. Geissbuehler wrote: On Fri, 13 May 2005 14:49:53 +0200, R.S. [EMAIL PROTECTED] address.PL wrote: BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job for compilation, this job looks like regular JCL, but all the compiler options are in PARM field (many LINES of PARM) and that's why it is circumvented in some way. I don't remember details, but the need is obvious... I was given a whole C library full of functios to recompile. the number of parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without editting indvidual functions what's the best work-around? Andreas F. Geissbuehler AFG Consultants Inc. http://www.afgc-inc.com/ . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM ALLDATA(*) - DFDSS
Thanks to all for your advice. I will listen to your suggestions and code the parm. Thanks Send instant messages to your online friends http://au.messenger.yahoo.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM ALLDATA(*) - DFDSS
Another potential issue is that if you use DFDSS to copy a load library PDS and do not specify ALLDATA(*) the new file will have only the amount of space currently in use. If it is defined with no secondary extent space, you will not be able to add any new members to it. I always use ALLDATA. Jon snip Given the consequences of failing to capture all the data, I'd say it's imprudent not to code it. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM ALLDATA(*) - DFDSS
On Wed, 7 Jun 2006 01:32:35 +1000, John Dawes [EMAIL PROTECTED] wrote: I was told that it is prudent to code the ALLDATA(*) when I am doing a selective DFDSSbackup. I don't share that opinion. Am I right? It's prudent to code it if you need it. Did you read the description? In my experience it was only needed for SYS1.DUMPxx datasets (but I'm sure there are others). My ROT is to use it for system packs and backups, but not for applications. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM ALLDATA(*) - DFDSS
The classic use for ALLDATA(*) in my recollection was JES SPOOL, which is always 100% full but shows as '0% used' externally. There may be others. As for whether it's 'prudent' to code the parm for a selective backup, that depends on what you're selecting. Given the consequences of failing to capture all the data, I'd say it's imprudent not to code it. Mark Zelden [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/06/2006 08:42 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: PARM ALLDATA(*) - DFDSS On Wed, 7 Jun 2006 01:32:35 +1000, John Dawes [EMAIL PROTECTED] wrote: I was told that it is prudent to code the ALLDATA(*) when I am doing a selective DFDSSbackup. I don't share that opinion. Am I right? It's prudent to code it if you need it. Did you read the description? In my experience it was only needed for SYS1.DUMPxx datasets (but I'm sure there are others). My ROT is to use it for system packs and backups, but not for applications. Mark -- Mark Zelden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM ALLDATA(*) - DFDSS
I agree with Skip - we ALWAYS code ALLDATA(*) ALLEXCP on every DFDSS dump or copy job, for both application and system data sets. Yes - it's not needed in most circumstances, but it is in SOME, and once you find out you need it for a good RESTORE, it's too late (becuase you had to have specified it on the DUMP command). If you don't back up all the tracks, they certainly won't be there when you run the RESTORE job. Better safe than sorry. Or that's my opinion, anyway. Brian On Tue, 6 Jun 2006 16:02:16 -0700, Skip Robinson [EMAIL PROTECTED] wrote: The classic use for ALLDATA(*) in my recollection was JES SPOOL, which is always 100% full but shows as '0% used' externally. There may be others. As for whether it's 'prudent' to code the parm for a selective backup, that depends on what you're selecting. Given the consequences of failing to capture all the data, I'd say it's imprudent not to code it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM ALLDATA(*) - DFDSS
- Original Message - From: Brian Peterson I agree with Skip - we ALWAYS code ALLDATA(*) ALLEXCP on every DFDSS dump or copy job, for both application and system data sets. Yes - it's not needed in most circumstances, but it is in SOME, and once you find out you need it for a good RESTORE, it's too late (becuase you had to have specified it on the DUMP command). If you don't back up all the tracks, they certainly won't be there when you run the RESTORE job. Better safe than sorry. Or that's my opinion, anyway. Brian On Tue, 6 Jun 2006 16:02:16 -0700, Skip Robinson wrote: The classic use for ALLDATA(*) in my recollection was JES SPOOL, which is always 100% full but shows as '0% used' externally. There may be others. As for whether it's 'prudent' to code the parm for a selective backup, that depends on what you're selecting. Given the consequences of failing to capture all the data, I'd say it's imprudent not to code it. What they said. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
(COBOL) Re: PARM=
I haven't PERSONALLY heard of anyone using it, but this is discussed in the LE customization guide at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea5150/2.7.3 2.7.3 Modifying the COBOL Parameter List Exit [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... In a recent note, Norbert Friemel said: snip Is this still in effect? Does it specify, or does experiment show what happens if the program is invoked (by LINK, ATTACH, CALL, XCTL, or address ATTCHMVS) with a PARM100 characters? Plausible actions: snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On May 25, 2005, at 1:59 AM, Paul Gilmartin wrote: In a recent note, Joe Zitzelberger said: Date: Wed, 25 May 2005 00:56:23 -0400 The original point was that an application programmer writing in COBOL...should not know it is possible for programs to be invoked by anything other than EXEC PGM=. Considering the prevalence of the CALL statement in common COBOL usage, that claim cannot be valid. There are may ways, other than EXEC PGM=, for a program to receive control -- and programmers know it. I can't really answer your 'main program' comment because there is no such thing in the z/OS COBOL world. There is nothing special that distinguishes a main program from any other program. If a program can be invoked via JCL it can be invoked via call. The parms, as shown above, can easily be identical for either JCL or call, and there is no special way for a callee to know how it was invoked. Does COBOL's CALL, like TSO's CALL limit the PARM passed to 100 characters? No, the current limit is 16M when calling another COBOL program. But multiple parms can always be passed, nor must they be JCL parm style pstrings. [EMAIL PROTECTED] There's no place like ~ There's no place like ~ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (COBOL) Re: PARM=
On May 25, 2005, at 1:21 AM, Paul Gilmartin wrote: In a recent note, Norbert Friemel said: Date: Tue, 24 May 2005 17:00:02 -0500 Yes. From the dusty IBM OS Full American National Standard COBOL, GC28-6396-5, Revised 12/1/75 by TNL GN26-0808, p. 234: ... At execution time, the USING option may be used to pass parameters from the EXEC job control statement to a main COBOL program. In this case, a USING option on the Procedure Division header of a main program may contain identifier-1 as its only operand. Information from the PARM field of the EXEC statement is then available in the Linkage Section at the location specified as identifier-1. The first two bytes of identifier-1 contain a count of the number of bytes of information in the PARM field; the two bytes are set to zero if the PARM field was omitted. This two-byte field is binary and should be defined with PIC S9(4) COMP. Immediately following these two bytes is the information in the PARM field. The maximum length of the field to be passed is 100 bytes. ... Is this still in effect? Does it specify, or does experiment show what happens if the program is invoked (by LINK, ATTACH, CALL, XCTL, or address ATTCHMVS) with a PARM100 characters? Plausible actions: o Runtime initialization terminates execution with an error indication. This is as benign as JCL error. o The PARM overlays adjacent data. o Runtime initialization truncates the PARM. (I consider this an integrity violation.) o The identifier-1 is opaquely based on the content of GR1 at program initiation. It is then the programmer's responsibility to do his own truncation or overlaying. Has anyone done the experiment? There is nothing to experiment -- the 100 byte limit referred to is from the JCL parm only. For that version of COBOL the limit on an individual data item should have been 32K -- but those were the days of BLL cells and managing your own based addressing -- parms could have had some sort of practical limit of 4K. However, if you passed MORE data into said program you would receive no error, the COBOL program would only map the first 100 bytes or whatever was defined. If you use the length to attempt a move that exceeded the size of the item current versions of COBOL will abend with a U4038 and a message that you attempted to reference an area outside of a defined data item. No truncation will occur. [EMAIL PROTECTED] Web Servers Do It With Cookies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I'll see what I can do; things tend to be busy enough around here that trying to get someone to take time to play probably won't fly. In any case, I need to restate what I was trying to say, because I think I got two posts from the PARM thread mixed up. I don't doubt that most of our programmers can invoke a COBOL program via a CALL statement, but I do doubt that most of them know they can run a batch COBOL program through TSO. I'm not trying to denigrate the abilities of our programmers, either; most of them simply have too much to do to be able to take time to do anything beyond simply getting their assignments done. Jon snip Humor me. Take this snippet to some of your COBOL programmers, good and bad, and ask them if they can write a program that will invoke it. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Wed, 25 May 2005 09:52:56 -0400, Jon Brock [EMAIL PROTECTED] wrote: ... I'm not trying to denigrate the abilities of our programmers, either; most of them simply have too much to do to be able to take time to do anything beyond simply getting their assignments done. ... More to the point, if the design specs were for a program to run as a step in a batch job, that's probably what the programmer wrote. And that has meant a parm of 100 bytes max. It doesn't matter what the programmer or what MVS could do with a different environment. It certainly does not denigrate a programmer to suggest he/she paid attention to the requested design. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On 25 May 2005 06:53:08 -0700, in bit.listserv.ibm-main you wrote: I'll see what I can do; things tend to be busy enough around here that trying to get someone to take time to play probably won't fly. In any case, I need to restate what I was trying to say, because I think I got two posts from the PARM thread mixed up. I don't doubt that most of our programmers can invoke a COBOL program via a CALL statement, but I do doubt that most of them know they can run a batch COBOL program through TSO. I'm not trying to denigrate the abilities of our programmers, either; most of them simply have too much to do to be able to take time to do anything beyond simply getting their assignments done. Jon snip Humor me. Take this snippet to some of your COBOL programmers, good and bad, and ask them if they can write a program that will invoke it. /snip I was aware both as an applications programmer and as a systems programmer that one COBOL program could call another one. I also thought that the limit was 144 bytes and the new limit of 100 bytes was due to LE. I also was paranoid and made sure that the parm length was within the expected set of values, normally less than 144. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM Survey in Text Format
In a message dated 5/23/2005 10:21:27 P.M. Central Standard Time, [EMAIL PROTECTED] writes: However, it worked. *I can read it*. Thank you! I noticed an anomaly: We need this feature: 66% agree or strongly agree This should be a Share req: 43% ditto Either some people use a different meaning of need than I do, or they are (or I am) confused about the reasons for Share requirements. Yipee! I sent the RTF format to Don Ault, but haven't heard back one way or the other. As I was fighting with zoomerrang composing the Survey, the thought just crossed my mind that this should really be a SHARE requirement so just hung it on at the last minute to kinda see what the group thought. Afraid I aided to the confusion in the manner and sequence of posing the questions. Guess if we do this again, I'll ask for volunteers for a test questionnaire. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
What bank would allow people to change JCL without control? Or to implement a 'typeo' in production without testing? Certainly not the bank I work for. If every z/OS machine in the world had this option installed next Tuesday, absolutely nothing would break until someone changed something, code or JCL. In stable environments where nothing changes, well, nothing would change -- no worries. In more dynamic environments you again have two possibilities -- changes are tested for correctness or they are not. Only in the final case is there even a risk of error. A SOC4 or a harmless overlay might occur -- no worries and an easy fix or a dont-care. Or the program might not recognize the 'typeo' on the JCL parm and offer a Unknown Parameter error. In the final case -- untested changes with a harmful parm overlay -- well, you were already playing Russian roulette by not testing your changes -- you just shot yourself in the foot. Of course, if you make a habit of not testing changes your feet are full of holes already. [EMAIL PROTECTED] I'm a guru, not a god. That is a completely different career path. On May 23, 2005, at 6:33 PM, John Krew wrote: I have to agree with Patrick and Peter on this. I am a bit bewildered by the attitude of those on the list that have pooh-poohed their down-to-earth objections with such academic-sounding observations as well, there would be an insignificant number of programs showing that kind of behavior. I guess they have never worked for a bank ... John Krew - Original Message - From: Patrick O'Keefe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 23, 2005 9:47 PM Subject: Re: PARM= On Sat, 21 May 2005 00:13:14 -0400, Joe Zitzelberger [EMAIL PROTECTED] wrote: On May 20, 2005, at 5:16 PM, Peter Hunkeler wrote: How many of the programs designed to run in batch are coded to cope with longer than 100 byte parms? ... Many programs are. ... Ok. So Peter asked the wrong question. Forget about those that are designed for the long parms. What about all the gazillion programs that are not? All the accounting programs, manufacturing support programs, time accounting programs, etc.; the home grown life-blood of industry (or at least that part still on MVS). Imagine some typo in the JCL makes the PARM longer than 100, say 102 bytes. ... You have put the cart before the horse. None of your existing, functional, JCL passes a parm longer than 100 bytes ... ... The fix is simple. Just don't pass more than a program is expecting. Today, that is a certain error (JCL error), tomorrow it will still be an error (program not expecting error). Either way it is an error. Nothing in this change can break a program that is currently working correctly today. He said ... typo Passing the additional data is unintentional. Fine. It's an error. Only in one case you get a JCL error. In the other case you get in incorrectly executing problem that may or may not abend. It may meerly produce a totally bollixed General Ledger for the month. No problem unless your company cares about money. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On May 24, 2005, at 3:16 AM, Vernooy, C.P. - SPLXM wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... In a recent note, Vernooy, C.P. - SPLXM said: Date: Mon, 23 May 2005 15:33:12 +0200 You don't have to change the JCL to change the PARM if it is specified by the operator on the Start-command, or is built from symbolics. How can you change a symbolic without changing JCL? By specifying in the JCL: // INCLUDE MEMBER=xxx where xxx is filled externally regularly with new values. We use is to include e.g. all sorts of date variables in our production JCL. Kees. That one routinely makes the rounds under the guise of using system symbols in JCL. So what you are saying is you have something today, perhaps this: SET LDATE='Tuesday, the 24th of May, 2005' SET SDATE='24-05-2005' And you are worried that when the date rolls to something longer, perhaps: SET LDATE='Tuesday, the 24th of December, 2005' SET SDATE='24-12-2005' That LDATE is going to push a parm past 100-bytes? This is possible, but if it could happen, your system today would provide you with JCL errors on the long named months. If your program freaks out one morning and starts putting in the include member: SET SDATE='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' Then you have a valid point -- but I would say, you need to go back to the oft asked question: 'what changed'? [EMAIL PROTECTED] Web Servers Do It With Cookies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Joe Zitzelberger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On May 24, 2005, at 3:16 AM, Vernooy, C.P. - SPLXM wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... In a recent note, Vernooy, C.P. - SPLXM said: Date: Mon, 23 May 2005 15:33:12 +0200 You don't have to change the JCL to change the PARM if it is specified by the operator on the Start-command, or is built from symbolics. How can you change a symbolic without changing JCL? By specifying in the JCL: // INCLUDE MEMBER=xxx where xxx is filled externally regularly with new values. We use is to include e.g. all sorts of date variables in our production JCL. Kees. That one routinely makes the rounds under the guise of using system symbols in JCL. So what you are saying is you have something today, perhaps this: SET LDATE='Tuesday, the 24th of May, 2005' SET SDATE='24-05-2005' And you are worried that when the date rolls to something longer, perhaps: SET LDATE='Tuesday, the 24th of December, 2005' SET SDATE='24-12-2005' That LDATE is going to push a parm past 100-bytes? This is possible, but if it could happen, your system today would provide you with JCL errors on the long named months. If your program freaks out one morning and starts putting in the include member: SET SDATE='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' Then you have a valid point -- but I would say, you need to go back to the oft asked question: 'what changed'? Yes, this an example of what I meant. I reacted to the statement that you cannot extend the parm over 100 bytes without changing the JCL. You can with INCLUDEd SET statements. The date variables are an example of how they are used today. Tomorrow they might be used for companynames, productcodes etc. etc. that can be reorganized overnigth from short cryptic to long explanatory names. 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. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
And why would you expect an application programmer writing in COBOL to even know that manual exists? Why should he/she even know it's possible for the programs to be invoked by anything other than EXEC PGM=... )where a 100-byte parm limit has existed forever)? And why do you expect that COBOL programmer is even aware of the 100-byte JCL limitation? The JCL Reference is a big manual -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Paul Gilmartin wrote: In a recent note, Bruce Black said: Date: Tue, 24 May 2005 09:49:27 -0400 And why do you expect that COBOL programmer is even aware of the 100-byte JCL limitation? The JCL Reference is a big manual I believe Bill Klein provided the correct answer from the COBOL perspective in: http://bama.ua.edu/cgi-bin/wa?A2=ind0505L=ibm-mainD=1O=DP=152693 I yield to his expertise and dutiful research. Apparently an LE manual example presumes the 100-character limit for COBOL and PL/I. -- gil What's really wierd is that LE has a callable service for obtaining the JCL parm value and it limits the return string to 80 characters! Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
For PL/I there is a simple circumvention of the 100-character limit available. From the current Programming Guide: Specifying options in the EXEC statement using an options file Another way to specify options in the EXEC statement is by declaring all your options in an options file and coding the following: //STEP1 EXEC PGM=IBMZPLI,PARM=Â’+DD:OPTIONSÂ’ This method allows you to provide a consistent set of options that you frequently use. This is especially effective if you want other programmers to use a common set of options. It also gets you past the 100-character limit. John Gilmore Ashland, MA 01721 U.S.A. _ DonÂ’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Tuesday 24 May 2005 07:51 What's really wierd is that LE has a callable service for obtaining the JCL parm value and it limits the return string to 80 characters! If the lengthening of PARM does go through, then I hope that all of IBM MF is tasked to check for restrictions like this. I wonder what LE for z/VSE does in this area. z/VSE has had PARMs 100 characters for a long time. Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Joe Zitzelberger wrote: On May 24, 2005, at 10:40 AM, Jon Brock wrote: I can guarantee that the majority of our application programmers would not know it is possible. And that includes the good ones. [snip] I find that amazingly unbelievable. Learning how to invoke separate compile units is usually taught in basic-intro-to-programming-101 classes somewhere after providing output to the user (hello world, my name is variable) and before opening a file. Humor me. Take this snippet to some of your COBOL programmers, good and bad, and ask them if they can write a program that will invoke it. IDENTIFICATION DIVISION. PROGRAM-ID. PGMRTEST. ENVIRONMENT DIVISION. DATA DIVISION. LINKAGE SECTION. 01 INPUT-PARMS. 05 INPUT-PARM-LEN BINARY PIC S9(4). 05 INPUT-PARM-DATAOCCURS 0 TO 100 DEPENDING INPUT-PARM-LEN PIC X. PROCEDURE DIVISION USING INPUT-PARMS. IF INPUT-PARM-LEN 0 DISPLAY 'Application programmers are not really that stupid after all.' ELSE DISPLAY 'OK, maybe they are really stupid.' END-IF GOBACK. - You might find yourself surprised at how capable they can be. I suspect that even the 'bad' ones will be able to invoke this with ease, without using 'EXEC PGM='. I doubt it. You get 'em with the word invoke. And besides, that wasn't the point being made. The point was most COBOL programmers do not know you can get parm data from a main program. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Joe Zitzelberger said: Date: Wed, 25 May 2005 00:56:23 -0400 The original point was that an application programmer writing in COBOL...should not know it is possible for programs to be invoked by anything other than EXEC PGM=. Considering the prevalence of the CALL statement in common COBOL usage, that claim cannot be valid. There are may ways, other than EXEC PGM=, for a program to receive control -- and programmers know it. I can't really answer your 'main program' comment because there is no such thing in the z/OS COBOL world. There is nothing special that distinguishes a main program from any other program. If a program can be invoked via JCL it can be invoked via call. The parms, as shown above, can easily be identical for either JCL or call, and there is no special way for a callee to know how it was invoked. Does COBOL's CALL, like TSO's CALL limit the PARM passed to 100 characters? There is an odd, unusual, COBOL keyword that can force a program never to return -- not exactly a 'main', but halfway there in spirit. If you use 'STOP RUN' instead of 'GOBACK' or 'EXIT PROGRAM' you convert the effect of a CALL into an XCTL. The effect isn't noticed when a program is invoked via EXEC PGM=. Is this analogous to issuing SVC 3? (BTW, what RM documents SVC 3?) -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On May 23, 2005, at 6:57 AM, Peter Hunkeler wrote: In order for you to receive the errors you fear, you will need to change your JCL to pass more bytes than your programs are expecting. This is always a problem -- for 100 bytes or 65535 bytes. That's what I said *but* a program will not get control today because of the JCL error you get. It will, however, get control with the suggested change. The fix is simple. Just don't pass more than a program is expecting. Sure, don't make a mistake and there will be no error ;-( Today, that is a certain error (JCL error), tomorrow it will still be an error (program not expecting error). Either way it is an error. Nothing in this change can break a program that is currently working correctly today. How about the code sniplet below? Sure it would be better to also verify the upper bound, i.e. 100 bytes, but is it really necessary, especially if the program was written when batch was the way to run programs? I would not count on the fact it was always done. And before someone else points at it: Yes, this program will not correctly handle the case when it is ATTACHed, LINKed, called from TSO, etc., etc. with a PARM longer than 100 bytes. The program was defined to run in batch. GetParm DS0H L R1,0(,R1) Get address of PARM field LHR5,0(,R1) Get length of PARM data specified LTR R5,R5 Anything specified? BZNoParmNone received BCTR R5,0 Adjust length for MVC EXR5,MoveParm Move PARM data to internal field ... ... MoveParm MVC ParmData(0),2(R1) ... ... ParmDataDS CL100 AjustmentFactor DC H'17' Used in converting X to Y According to the principle of least astonishment, we should not incompatibly change the rules to benefit a few programs. What is the purpose of moving the parm to an internal field? That just strikes me as broken as designed (BAD). You cannot change the value, it is truly input only. It also strikes me as more effort than just using the parm inplace in this age of reentrent and reusable code styles. All I'm saying is that it takes two objects to create this error. Your production program must do things incorrectly today AND your production JCL must change. If it works today, then only a change to one of these two (hopefully) controlled objects can break it. Unless you just let your production JCL be changed willy-nilly you are at no risk of exposure. [EMAIL PROTECTED] The most effective type of birth control is learning Cobol. -DT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Joe Zitzelberger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On May 23, 2005, at 6:57 AM, Peter Hunkeler wrote: All I'm saying is that it takes two objects to create this error. Your production program must do things incorrectly today AND your production JCL must change. If it works today, then only a change to one of these two (hopefully) controlled objects can break it. Unless you just let your production JCL be changed willy-nilly you are at no risk of exposure. You don't have to change the JCL to change the PARM if it is specified by the operator on the Start-command, or is built from symbolics. S TOOL,PARM='A NUMBER OF COMMANDS AND PARAMETER GIVEN TO THE TOOL' //T EXEC PGM=TOOL,PARM='VALUE1,VALUE2,VALUE3' 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. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Vernooy, C.P. - SPLXM said: Date: Mon, 23 May 2005 15:33:12 +0200 You don't have to change the JCL to change the PARM if it is specified by the operator on the Start-command, or is built from symbolics. How can you change a symbolic without changing JCL? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I did a quick scan on the sources of our tools and found several that move the parmarea, using its length field, to a 100 byte area. Glad to read I'm not the only one :-) Peter Hunkeler Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Peter Hunkeler quotes someone as posting the query can you cite a source for programs are expected to reserve 100 bytes for the PARM? I hope no such source can be found in an IBM publication. It would be wrong. The PARM= storage is NOT of the form exhibited in the PL/I declaration declare PARM character varying(100) ; for which 100 bytes preceded by a halfword current-length indicator is used. It is instead of the self-defining (again PL/I) form declare 1 PB based, 2 cpvl binary fixed(15,0), /* current-length prefix */ 2 PARM character(0 refer(PB.cpvl)) ; /* PARM value */ with the side condition that the value of PB.cpvl may not exceed 100. Since the halfword prefix can be examined before, exceptionally, a copy of a particular PARM value is made, there is never any need to allocate more storage than that PARM value occupies for such a copy. John Gilmore Ashland, MA 01721 U.S.A. _ DonÂ’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Mon, 23 May 2005 10:25:17 -0300, Shmuel Metz (Seymour J.) wrote: Yes, because all the way back to the early days of OS/360, a main program was just another subroutine with a specific type of PLIST. I know of no IBM documentation that ever suggested a limit of 100 characters for the program. If a batch program calls a second program, that second program is still running batch. The program was defined to run in batch. And when a program running in batch calls it, then it *is* running in batch, even if the parm string is longer than 100 characters. This brings up a counterargument I had considered a couple of weeks ago for providing simulated OS support for such an APAR-liable change: Why not, instead, create a single simple program that can (and does) read from a parameterized file, pulling the contents into storage as the downstream program's XPARM= data, setting R1 to point to the newly engorged PARM string? I see fewer APARs as an immediate result. The obvious bad thing is that the SMF type 30's would not show the XCTL- ed to program name... and one might offer a handy fix to that, too, if pressed. (Maybe CSRL16J would be better than XCTL here; I don't have clear specs for the program.) The only remaining sniggle is that those programs that Gil is so interested in getting vendor support of PARM100 would still claim it is via unnatural conditions. So maybe if Don, Greg, Jim (et al) would just state that it must be so this whole argument could become moot? A single, simple program front-end could offer the parm length granularity, provide for any file type source for the parm data, and even be shipped in a PTF. (Why wait?) -- Tom Schmidt Madison, WI (Who really says moot anyway?) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM Survey in Text Format
In a message dated 5/23/2005 1:44:24 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Management Concerns 12 3 4 5 Strongly Disagree Neutral Agree Strongly Disagree Agree Sorry don't know what I'm doing(wrong). All lines up in Courier New 10. Guess AOL is RTFing it and LISTSERV is parsing it back w/o the tabs and spaces. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Sat, 21 May 2005 00:13:14 -0400, Joe Zitzelberger [EMAIL PROTECTED] wrote: On May 20, 2005, at 5:16 PM, Peter Hunkeler wrote: How many of the programs designed to run in batch are coded to cope with longer than 100 byte parms? ... Many programs are. ... Ok. So Peter asked the wrong question. Forget about those that are designed for the long parms. What about all the gazillion programs that are not? All the accounting programs, manufacturing support programs, time accounting programs, etc.; the home grown life-blood of industry (or at least that part still on MVS). Imagine some typo in the JCL makes the PARM longer than 100, say 102 bytes. ... You have put the cart before the horse. None of your existing, functional, JCL passes a parm longer than 100 bytes ... ... The fix is simple. Just don't pass more than a program is expecting. Today, that is a certain error (JCL error), tomorrow it will still be an error (program not expecting error). Either way it is an error. Nothing in this change can break a program that is currently working correctly today. He said ... typo Passing the additional data is unintentional. Fine. It's an error. Only in one case you get a JCL error. In the other case you get in incorrectly executing problem that may or may not abend. It may meerly produce a totally bollixed General Ledger for the month. No problem unless your company cares about money. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a message dated 5/23/2005 2:07:34 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Well I did ask for comments, so I got what I deserved. I do appreciate the time you have all spent. If I do use some of your great ideas, please do me a favor and don't sue IBM for taking your intellectual property. I hate talking to lawyers. You want I should close the PARM survey and send you the results? I can spread sheet or WORD RTF whatever's your preference. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Mon, 23 May 2005 06:31:02 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: ... Title: z/OS V1R4.0 MVS Assembler Services Guide Document Number: SA22-7605-04 ..., And why would you expect an application programmer writing in COBOL to even know that manual exists? Why should he/she even know it's possible for the programs to be invoked by anything other than EXEC PGM=... )where a 100-byte parm limit has existed forever)? You seem to be thinking in system programming mode, but that's not where the problems will surface. Pat O'Keeefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Mon, May 23, 2005 at 04:13:20PM +0200, Peter Hunkeler ([EMAIL PROTECTED]) wrote: [snip] However, leaving utilities aside, I think that application programs are designed for a specific environment: MVS Batch, CICS transaction, IMS transaction, etc. You don't call a day-end-processing batch program from TSO forground, do you? So you've never run a batch program under TSO TEST? /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I have to agree with Patrick and Peter on this. I am a bit bewildered by the attitude of those on the list that have pooh-poohed their down-to-earth objections with such academic-sounding observations as well, there would be an insignificant number of programs showing that kind of behavior. I guess they have never worked for a bank ... John Krew - Original Message - From: Patrick O'Keefe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 23, 2005 9:47 PM Subject: Re: PARM= On Sat, 21 May 2005 00:13:14 -0400, Joe Zitzelberger [EMAIL PROTECTED] wrote: On May 20, 2005, at 5:16 PM, Peter Hunkeler wrote: How many of the programs designed to run in batch are coded to cope with longer than 100 byte parms? ... Many programs are. ... Ok. So Peter asked the wrong question. Forget about those that are designed for the long parms. What about all the gazillion programs that are not? All the accounting programs, manufacturing support programs, time accounting programs, etc.; the home grown life-blood of industry (or at least that part still on MVS). Imagine some typo in the JCL makes the PARM longer than 100, say 102 bytes. ... You have put the cart before the horse. None of your existing, functional, JCL passes a parm longer than 100 bytes ... ... The fix is simple. Just don't pass more than a program is expecting. Today, that is a certain error (JCL error), tomorrow it will still be an error (program not expecting error). Either way it is an error. Nothing in this change can break a program that is currently working correctly today. He said ... typo Passing the additional data is unintentional. Fine. It's an error. Only in one case you get a JCL error. In the other case you get in incorrectly executing problem that may or may not abend. It may meerly produce a totally bollixed General Ledger for the month. No problem unless your company cares about money. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM Survey in Text Format
In a message dated 5/23/2005 8:59:10 P.M. Central Standard Time, [EMAIL PROTECTED] writes: program). You could possibly save another problem by e-mailing it to yourself and trying the procedure. That was the first of many attempt(since early yesterday morning). I know what the rules are I just don't know who follows them and correspondingly who doesn't. As ungainly as .csv seems it's easy enough to do. ---CSV Follows:--- Management Concerns, ,1,2,3,4,5 ,Strongly Disagree,Disagree,Neutral,Agree,Strongly Agree 1. We need this feature,0%,7%,27%,27%,39% ,0,3,12,12,17 2. Current programs and systems should continue to run unaltered,2%,0%,5%,11%,82% ,1,0,2,5,36 3. This feature should not open integrity exposure;i.e. buffer overrun,2%,2%,2%,23%,70% ,1,1,1,10,31 4. This option should be customizable by site.,16%,9%,25%,36%,14% ,7,4,11,16,6 5. This option should be OPER setable.,20%,14%,34%,23%,9% ,9,6,15,10,4 6. This should be a SHARE requirement,0%,9%,48%,25%,18% ,0,4,21,11,8 Implementation preferences, ,1,2,3,4,5 ,Strongly Disagree,Disagree,Neutral,Agree,Strongly Agree , 1. Add DDNAME support, leave length alone.,41%,34%,14%,5%,7% ,18,15,6,2,3 2. Add DDNAME support and extend length.,34%,16%,30%,14%,7% ,15,7,13,6,3 3. Extend length without DDNAME.,0%,12%,21%,26%,42% ,0,5,9,11,18 4. Add a syntax scanner for PARM files.,9%,14%,58%,16%,2% ,4,6,25,7,1 Sysprog concerns, ,1,2,3,4,5 ,Strongly Disagree,Disagree,Neutral,Agree,Strongly Agree , 1. New PARM in IAESYS to set.,9%,16%,25%,43%,7% ,4,7,11,19,3 2. New system command to toggle.,14%,20%,34%,23%,9% ,6,9,15,10,4 3. Implemented in future release,2%,2%,30%,45%,20% ,1,1,13,20,9 4. Not retro'd to previous releases,2%,14%,39%,39%,7% ,1,6,17,17,3 5. New bit to query for PARM length,11%,18%,23%,39%,9% ,5,8,10,17,4 6. Backout scenarios should be documented,5%,0%,28%,51%,16% ,2,0,12,22,7 This Survey, ,1,2,3,4,5 ,Strongly Disagree,Disagree,Neutral,Agree,Strongly Agree , Would like to see more,0%,3%,50%,35%,13% ,0,1,20,14,5 Wish it were more detailed,0%,8%,67%,17%,8% ,0,3,24,6,3 ---End CSV- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM Survey in Text Format
On 23 May 2005 19:34:42 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] wrote: As ungainly as .csv seems it's easy enough to do. ---CSV Follows:--- That looked even uglier than I expected. I thought for sure that line-wrap had done something horrible to it. However, it worked. *I can read it*. Thank you! I noticed an anomaly: We need this feature: 66% agree or strongly agree This should be a Share req: 43% ditto Either some people use a different meaning of need than I do, or they are (or I am) confused about the reasons for Share requirements. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
The program was defined to run in batch. And when a program running in batch calls it, then it *is* running in batch, even if the parm string is longer than 100 characters. Sorry about that, should have been more specific: The program was designed to run as the job step task in a batch job, i.e. the one being called because it is named in the PGM= parameter on the EXEC statement. Peter Hunkeler Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I'd like to cast a vote for JCL PARMs longer than 100 bytes, using the current scheme simply (?) by increasing the upper limit. I agree with protecting APF authorised programs from inadvertent parameter overrun. I don't think non-APF authorised programs need this protection, although I would expect IBM to check its IEB/IEH utilities, and other common programs like service aids for problems in this area. Assuming a program is expecting a parm length no more than 50, code like LH R2,0(,R1) CH R2,=H'50' BH PARMLONG will not trap a 40,000 byte parm, but the JCL deck size may be a bit of a giveaway, so no big deal IMHO. I think computers can count data bytes better than humans, so I liked someone's idea (much earlier in this thread) of a JCL info message reporting the PARM length for each step which has one. This may provide a very handy diagnostic for long PARMs. Further, I think this message should be issued no matter what the PARM length (ie. even for very short PARMs) whenever the system has long PARMs enabled, as an obvious flag to all that long PARMs are currently allowed by the system. (Dispense with the DISPLAY command, perhaps?) Cheers, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Don Ault wrote: I would like to thank all of you for the posts on PARM=. I had asked Peter to make the initial posting, since I was not currently connected to the IBM-MAIN forum. It is my job to come up with an acceptable solution for long parms. I'm currently leaning towards the following set of externals: [snip very nice list of well-thought-out features] Don, it would be nice if no forcing to uppercase occurred in all situations, but at least when PARM is passed to TSO, REXX, or CLIST. Don't know if that was implicitly covered in your descriptions or not, but I saw a fair number of people with this concern, especially if you want to pass HFS path names or simply mixed-case strings. Kind regards, -Steve Comstock The Trainer's Friend, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Tom, your argument doesn't hold water. First, you want your s/360 program to run unchanged. I do too. So does Don. Don, If you limit the long parms to 32K instead of 64K I have little issue, but by raising your limit to unauthorized programs to 64K you create an architectural problem: Old programs loading the halfword length on a halfword boundary length value using the LH instruction will receive negative values for such long parameters. They are unlikely to successfully handle such arithmetic values as they would have been very unanticipated when they were written some 30-35 years ago. If a 32K PARM string isn't long enough I hold out little hope that a 64K string is going to always satisfy the user's requirements. -- Tom Schmidt Madison, WI (Yes, old programs will be using LH instead of ICM since they may well have been written using the 360 instruction set. IBM promised not to break old programs with incompatible changes, remember?) I voted for 32K too, but hey, 64K is even better. IBM, by implementing this, will not have broken anything. Your s/360 program that is runing today from JCL is expecting no more than 100 bytes. Fine. Why would you pass 64K bytes to a program that is expecting a max of 100? If you do, you've broken it, not IBM. Todd Burch -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
And I still would like to see the first JCL with a 64K PARM statement. Hopefully all application using a parser vs. a fix mapping structure for such a huge PARM. In the past it was difficult for our operating people to even set a 100 bytes parm corretly because of some mapping issue. I agree 100 Bytes is not that much but 64K or 32K will be pain without a parser. Roland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Fri, 20 May 2005 13:51:55 -0500, Todd Burch [EMAIL PROTECTED] wrote: ... IBM, by implementing this, will not have broken anything. Your s/360 program that is runing today from JCL is expecting no more than 100 bytes. Fine. Why would you pass 64K bytes to a program that is expecting a max of 100? If you do, you've broken it, not IBM. ... Technically true but effectively false. It doesn't much matter who was right when production applications die. I assume a JCL error is produced if you create a parm larger than 100 bytes. (Either that or the data is just struncated.) Change the parm behavior and instead of a JCL error you get abends or incorrect execution of some programs. A change in program behavior with no change to the program (whose source may have been lost 13 years ago). Late night phone calls to support people who've never heard of the dying programs. Late night phone calls to the system programmers supporting the recently upgraded MVS. Lots of finger pointing. Everything is someone else's problem. All parts are Broken As Designed because nothing prevented the problem. All because of a finger check no longer causes a JCL error. IBM should be praised for approaching this cautiously, and is looking for a solution with the least negative effect. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Hey Tom. Nothing personal implied - I, you, them, whoever. I think IBM has done a pretty good job over the years of protecting our investments in developed technology. And now, they are doing a good job of satisfying end user requirements. I would give them an A+ on this issue for involving their user community for feedback. I'm sure there are lots of ways that programs could have been written 30 years ago and they won't work today because of architecture changes. There are new instruction op codes for one. If a 360 program would have forced a program check (0C1)* for whatever reason that they wanted to run inside a recovery environment, perhaps that original invalid op code chosen is now valid? Who's to blame there?IBM made an architecture change, because their customers asked it. Perhaps CHANGE is to blame. I'm not a sysprog, but I would bet there is an exit somewhere that could be customized to make sure that a program can't be passed more than 100 bytes if a shop doesn't want that to happen. Todd *I started in the industry in '80, not in the '60s. I'm making an assumption that some form of ESTAE/ESTAI was available back then. - Original Message - From: Tom Schmidt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, May 20, 2005 2:43 PM Subject: Re: PARM= Todd, First, lets not make this personal. *I* didn't pass 64K bytes to a program not expecting it, someone else did. (I know better.) The result could be a program failure. Some sites will launch a witch hunt to assess guilt, etc. But the architecture in place when the program was written completely precluded that possibility... so it really was IBM who broke the program. Especially since the rules in place even TODAY continue to preclude the possibility. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I suppose there will be a new field/pointer in the SCTX for this larger parm? Anyone accessing SCTXPARM will have to update their code. Dan Original Message From: [EMAIL PROTECTED] Sent: Friday, May 20, 2005 11:07 AM So minimally have to reassemble all PGMs examining SCT and conditionally testing a new control block if length greater than 100? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Patrick O'Keefe said: Date: Fri, 20 May 2005 14:49:21 -0500 I assume a JCL error is produced if you create a parm larger than 100 bytes. (Either that or the data is just struncated.) Change the parm behavior and instead of a JCL error you get abends or incorrect execution of some programs. A change in program behavior with no change to the program (whose source may have been lost 13 years ago). IBM should be praised for approaching this cautiously, and is looking for a solution with the least negative effect. I believe Don Ault's proposal: Linkname: IBM-MAIN archives -- May 2005 (#1235) URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0505L=ibm-mainD=1O=DP=135818 - There will be a system wide option to turn on/off the ability of the system to process long parms. If the option is off, then a JCL error will occur with parms 100. ... pretty well addresses this requirement. But I might make the option a numeric value: 65535, 32767, 256, 100, or any value in between, or even smaller, at the site's option. Any site can elect to remain in the twentieth century, or to come to the twenty-first progressively, one byte of PARM length at a time. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Peter Hunkeler said: Date: Fri, 20 May 2005 23:16:19 +0200 How many of the programs designed to run in batch are coded to cope with longer than 100 byte parms? Not too many probably. I suspect a greater number than you believe. First, ASMA90. Well, that's only a single program, but it's heavily used. Likewise, the C compiler. And I suspect that load modules output from C suffer no 100-byte restriction. I'd strongly suggest the binder attribute is declared an absolute must to allow passing longer than 100 byte PARMS to the program. APF or not doesn't matter. The benefit: No need for a system wide option, no need for a system command, cheaper to implement, and most importantly, no unnecessary incompatibility. One of Don's concerns was for an NJE- or JES- plex. Hosts supporting readers shouldn't pass long PARMs to execution hosts that can't deal with them. a systemS wide option can enforce this. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/20/2005 at 08:47 AM, Don Ault [EMAIL PROTECTED] said: - To address the integrity issue, programs linked with AC=1, coming from APF authorized libraries, will require a new Binder attribute in order to get past the converter/interpreter with parms 100. Non-APF authorized programs will not require the new attribute in order to process parms 100. Have you considered a PARMLIB option to control whether unauthorized programs require the new attribute in order to process parms 100? How about a second flag for PARM 32767? And don't you mean Initiator rather than C/I? All comments appreciated. What about mixed case? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Ray Mullins said:
Date: Thu, 12 May 2005 16:03:50 -0700
Because...PARM was originally intended for passing of small values of data.
If you needed to pass more data than 100 bytes, that was a job for a control
card data set. Only the C/C++ compiler (from what I've seen in my
experience) has that capability.
I wouldn't care if it was 32767 or 65535 or 1024 or 4094 - just get off of
100.
A real-life example that happened to me just today:
96 *-*address 'TSO' 'call *(BPXWDYN) '''T1 'msg(1)'''
call *(BPXWDYN) 'alloc dd(SYSTSIN) PATHOPTS(ORDONLY)
recfm(F,B) lrecl(255) blksize(510) path(''/dev/fd0'') filedata(TEXT)
reuse msg(1)'
IKJ56003I PARM FIELD TRUNCATED TO 100 CHARACTERS
I wasn't trying to generate an example; merely following a
sincere recommendation of an IBM developer in another forum:
Linkname: [EMAIL PROTECTED] post from [EMAIL PROTECTED] :
URL: http://www2.marist.edu/htbin/wlvtype?MVS-OE.41231
It was colossal stupidity of TSO developers to emulate an inane
restriction in JCL when ATTACH has no such limit. Does anyone
happen to know their names?
Is it also proposed to relax the restriction for TSO CALL, as
well as for JCL?
-- gil
--
StorageTek
INFORMATION made POWERFUL
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
- Original Message - From: Leonard Woren [EMAIL PROTECTED] I've never understood why the exec parm needs to be copied somewhere by the receiving program, except for printing in which case you probably need to check the length anyway. I don't feel like groveling through my source libs right now, but I'd be surprised if any of my programs, going back to the 1970s, would break with long parms. Two obvious reasons for moving the PARM to a data field are conversion to upper case (which could be done for the EXEC PARM in situ), and to have a known terminator character (e.g., X'00') that would make it easier to use TRT relying on an ending character without also repeatedly checking the length. And obviously any good programmer would check the input length. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Skip Robinson wrote: [snip] Let's just KISS: increase the allowable string length to 256. That should be plenty for any well-designed application. [snip] I would say 4K would be a better number. If you wanted to pass two path names, an input and an output for instance, that would easily use up your 256 limit even though the parm strings themselves would be easy to read and understand. If someone is going to take the time, money and trouble to fix this, they may as well make the buffer so large that only extremely badly designed programs will run into the limitation. As you point out, abuse of the large parm string may occur, but that's shouldn't be JCLs concern, it should be the program designer's. Robin Murray Tel: (902) 453-7300 x4177 Cell: (902) 430-0637 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Fri, May 13, 2005 at 08:13:39AM -0400, Bob Shannon wrote: Seriously, we're talking about a parameter. I agree that 256 bytes ought to be sufficient. Indeed. I can't recall where I read it, but someone suggested that program designers avoid constraints that are powers of ten, for they are likely to be seen as artificial constraints rather than legitimate limits imposed by the design. There are good technical reasons for a 256-byte limit on parm length (MVC), and that would seem to be a good dividing line between what belongs on a PARM statement and what belongs elsewhere just for the sake of manageability. What would be a real advance is being able to provide SYSIN to a started task or other JCL proc without having to go through the gyrations of having a separate dataset... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Miklos Szigetvari Hi I would vote for the DD solution. A reserved (maybe changeable) DD name for the long PARM's That is already available. See, e.g., CICS: //STEPNAME EXEC PGM=DFHSIP,PARM=(START=INITIAL,SIT=6$,SYSIN) Although CICS uses the reserved name SYSIN, an application could be coded to accept literally any DDNAME. E.g., CICS could have been coded to use DFHSYSIN. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Raymond, That was my thought as well. It will not have a negative impact on older programs, and will clearly require a change to both the called program, and the caller. Wayne Driscoll Product Developer Western Metal Supply NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Thursday, May 12, 2005 6:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM= Have you ever heard the old adage - if it ain't broke, .. Instead of messing around with the PARM= field, how about adding a new one like zPARM= (since these are the days of z/OS, z/VM, z/Linux and (soon to be) z/TPF on our new z/Series processors). Have zPARM= specify a DDNAME, like, zPARM=ZPARMS, then code a //ZPARMS DD * file for the job. Now you can have 15PB (random number for the sake of the example) of data for your parameters. Maybe 15PB won't be enough, though, have you seen some of the parameters on an RPM command for Linux or some of the other open system commands? HITACHI DATA SYSTEMS Raymond E. Noal Lab Manager, San Diego Facility Office: (858) 537 - 3268 Cell: (858) 248 - 1172 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Thursday, May 12, 2005 2:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: PARM= We all know and love (well, at least know) that the limitation in JCL for PARM= is 100 total characters. We are thinking (again) about expanding this, and would like to hear your thoughts. Some of the possibilities include - just extending, in JCL processing, so that the target routine gets what it does today (halfword length followed by string, only the string would potentially be 100). This is obviously the nicest from the target routine's perspective if it can handle the extended length - a service that the target routine can call to give me my parameters. Obviously the target routine would have to change in order to utilize that service, and likely would have to dual-path for systems that do not have the service One choice that proved not feasible was using a second parameter. Various utilities already take advantage of the known structure and pass additional data as additional parameters. Some of the potential problems an existing target routine might have with an extended length parameter are - It provided an area via DS of 100 characters, knowing that the limit was 100, and then did an EX (execute) of an MVC to move the parameter string, using the length in the halfword. Unfortunately, if the length is (for example), 256, this would overlay the next 156 bytes - It did some operation (MVC, TRT, whatever) that is limited to 256 characters which works fine when the limit is 100, but if the routine was passed 257 characters of data, it might process that as 257 mod 256 characters in some ways. What do you think? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Chase, John said: Date: Fri, 13 May 2005 08:05:55 -0500 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy I agree with Gil and Charles. IMO, a DD statement would be pointless. Thanks for all the fish (but, not goodbye.) If a programmer wanted to receive a parm via DD, they could have done it already. One of the advantages of PARM= is that you can stick it in a proc, where DD * will not work. //A PROC //. //SYSIN DD DDNAME=SYSIN // PEND //BB EXEC A //. //BB.SYSIN DD * ... ... /* Works here But not here: //A PROC OPT1=DEFAULT1,OPT2=DEFAULT2,OPT3=DEFAULT3 //. // PEND //BB EXEC A,OPT2='Overriding value 2' ... /* ... You'd require the programmer to reassert the default values of PARM options not overridden. Supplying as examples any number of specific instances in which the 100-character limit is not constraining does not serve to refute those cases in which it is burdensome. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy Thank you, Eric, that is indeed what I meant -- you cannot place DD * before the PEND statement, or anywhere in a proclib member. And it is still a restriction in z/OS 1.4, producing error message: IEFC601I INVALID JCL STATEMENT if you put DD * in a proc. And I agree with everyone that said they should get rid of that restriction, in addition to increasing the PARM length. Seems to me that allowing instream data within a PROC would add little value unless it was accompanied by allowing variable substitution to occur within the instream data. Without substitution, any change desired in the instream data would require editing the PROC, which would affect all jobs that invoke it. I'm assuming that in the general sense, each job would require something unique in the instream data; that's why the DDNAME keyword is available on the DD statement. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I like most have had to deal with the strange limit of 100 characters on the PARM statement. I would support raising the limit in any way that would not break the old programs still running. That is the passing of the PARM value should be done in the same way as today. This way, current programs would not need to even be aware of the change. (Yes some person could change the JCL to pass more than 100 characters to a program that would not handle it, but then that person needs to change the program first. IE 255 as a max. Now as for breaking the 8 bit limit, I would say a new parameter in the JCL that can not be used if PARM is. The only thing with the keyword name is; one should look down the line when the current PARM is not used / supported, if ever, and only the new keyword is in use. Use XPARM, PARMX ... whatever as the keyword; but the way the parameter is passed would seem to be the important thing. RR1 = full word length followed by value, program would have to know that the new keyword was used. RR1 = 2 full words. One being the length of the value, the other pointing to the value. So the address of the value is not necessary in storage right next to the length of the value. Use R0 to contain the length and R1 point to the 8 bits of zeros followed by the value, so an old program thinks the length is zero and no PARM was passed. Use a macro to get the length of the PARM and its location, returned in R0 and R1. Let MVS deal with the where the PARM and address are hidden in some control block. R1 on entry would look as if no PARM was passed. Or any of a number of other ways to get a long parameter list to a program. The second thing IBM should provide is a macro that would convert the new PARM format, back to the old one, when the length is 100 characters or less. This way the JCL could be changed to the new way and with a small change, insert MACRO x in the program, all will be well. Kenneth Leidner Imagination is more important than knowledge. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Friday, May 13, 2005 11:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM= In a recent note, R.S. said: Date: Fri, 13 May 2005 14:49:53 +0200 256 bytes ? IMHO it is not worth to change from 100 to 256. Many should be enough limits occured much too short. BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job for compilation, this job looks like regular JCL, but all the compiler options are in PARM field (many LINES of PARM) and that's why it is circumvented in some way. I don't remember details, but the need is obvious. As you note, it's a pseudo job, so no circumvention is necessary. The compiler is invoked by an ATTACH macro; the JCL is never executed. Personally I vote for //STEP EXEC ... PARMX=ddname //DDNAME DD * put here as much as you want (i.e. 64k) /* Or (good for PROCLIB) PARMX1=' ', PARMX2='' etc. Then what? EXEC whatever,PARM=(PARMX1,PARMX2)? The constructed PARM string is still subject to the 100 character limit. Thinking on the idea of a Binder option to declare the ability of a program to accept a long PARM, there are a couple alternatives: o A PARMLIB option, allowing each installation to select what the JCL and TSO CALL PARM string limit should be. Any site could specify, 100, 255, 65535, or even a value less than 100 if that suited them. o A RACF privilege class identifying the set of users (none, some, or all) permitted to use long PARM strings in JCL or in TSO CALL. Otherwise, I wonder how the PARM is represented while a job is in the input queue? Does it reside in a control block? Is the structure of that block documented as a programming interface? Is there a hazard of other breakage if it changes? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/12/2005 at 04:09 PM, Raymond Noal [EMAIL PROTECTED] said: Instead of messing around with the PARM= field, how about adding a new one like zPARM= (since these are the days of z/OS, z/VM, z/Linux and (soon to be) z/TPF on our new z/Series processors). Have zPARM= specify a DDNAME, like, zPARM=ZPARMS, then code a //ZPARMS DD * file for the job. Now you can have 15PB (random number for the sake of the example) of data for your parameters. That makes sense only if they also support symbolic parameters and static system symbols for instream data. Personally, I'd prefer just raising the limits on PARM. Either way you face the issues that Peter mentioned. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/13/2005
at 09:57 AM, David Andrews [EMAIL PROTECTED] said:
Please also remember the START command processor: convince it to pass
parameters bigger than... what, 61 bytes? (Whatever fits on a single
generated // PARM='...' card image.)
S MYSTC,A=long,B=long,C=long
// EXEC PGM=IEBIBALL,PARM=('A','B','C')
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/13/2005 at 01:08 AM, Leonard Woren [EMAIL PROTECTED] said: I think you had the right idea and then missed: I propose that the solution should be // PARM and make it mutually exclusive with the PARM= keyword on EXEC. Why complicate things? That question applies as much to your proposal as to anything else. Adding a new statement is much more complicated than raising the limit on an existing keyword. Well, actually it does make things easier. Since // PARM would be all-new, it can be thoughtfully implemented to make it easy to code long continuations correctly. Having different continuation rules for different statements would be a complication for the user. Why complicate things? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On 13 May 2005 09:53:23 -0700, [EMAIL PROTECTED] (Chase, John) wrote: Seems to me that allowing instream data within a PROC would add little value unless it was accompanied by allowing variable substitution to occur within the instream data. Without substitution, any change desired in the instream data would require editing the PROC, which would affect all jobs that invoke it. I'm assuming that in the general sense, each job would require something unique in the instream data; that's why the DDNAME keyword is available on the DD statement. You're right in a general sense, of course. But in my personal experiences, the parameters that I was passing to a program via a control file were fairly static and usually didn't change very often. So, for me at least, having a sysin dataset embedded within a cataloged proc is valuable, even if no symbolic substitution was performed on the data. (Although it would definitely be a very nice feature to have.) Eric -- Eric Chevalier E-mail: [EMAIL PROTECTED] Web: www.tulsagrammer.com Is that call really worth your child's life? HANG UP AND DRIVE! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
