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/dnsdatb&SYSCLONE.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=EZ2ZO10K&DT=20070427231644&CASE=
>
>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 //STDOUT DD SYSOUT=*
>> 13 //STDERR DD 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
