Re: Strange behavior of START command(Keyword parms)

[Chris Mason]

I wonder what "bad advise" that may have been.

Reviewing my post I see only that I implied some suggestions regarding 
testing - and unearthed  a rather confusing comment regarding commas in the 
description of the START command in the manual.


Perhaps this is yet another case of not bothering to read everything in the 
post - typical of this contributor - "par for the course".


I wonder what significance using lower case for a name has. Perhaps there is 
a cultural angle here.


Given that the observed behaviour is declared errant by a representative 
from development, perhaps "the same *ought to be* true for operator 
commands" would be more accurate.


From the context "advise" takes on the role of a noun. Had the adjective 
been modified to become an adverb as in "bad" becoming "badly", "advise" 
could be understood to be a verb - with some other adjustments to the phrase 
of course. I wondered if this wasn't some transatlantic variation of the 
word "advice", as in "defence" becoming "defense" for example, but Googling 
didn't offer any confirmation of this surmise. Indeed, the normal English 
use was confirmed. For example:




American Heritage Dictionary

ad·vise (ad-viz')
v. ad·vised, ad·vis·ing, ad·vis·es

v. tr.
1. To offer advice to; counsel.
2. To recommend; suggest: advised patience.
3. Usage Problem To inform; notify.

v. intr.
1. To take counsel; consult: She advised with her associates.
2. To offer advice.



So it's a mystery.

Chris Mason

- Original Message - 
From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, August 28, 2007 1:51 AM
Subject: Re: Strange behavior of START command(Keyword parms)



...

Thanks. I learned from dealing with assembler macros that only if
some positional parms are omitted between two positional parms commas
are required to occupy the position.


The same is true for operator commands; chris gave you bad advise.
...


--
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: Strange behavior of START command(Keyword parms)

[Chris Mason]

Peter

Just what exactly is that "Note" from the description of the START command I 
quoted earlier in the thread supposed to mean? Perhaps some examples would 
help.


Now it has been acknowledged to be "working as coded" rather than "working 
as designed", is it possible than the logic parsing the character string is 
trying to treat the string following the "devicetype" as a "volumeserial" 
which, of course, has a 6-character limit. This assumes that the equal sign 
is regarded as a delimiter. There would also need to be some subsequent 
processing which somehow "lost" the false "volumeserial" and interpreted, 
for example, the DISP=SHR parameter as intended - although this isn't 
actually confirmed by Johnny's example.


Chris Mason

- Original Message - 
From: "Peter Relson" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, August 27, 2007 5:13 PM
Subject: Strange behavior of START command(Keyword parms)



Getting
IEE308I STARTTERM LENGTH ERROR
when you issue
S STC1,3390,JOBNAME=JOHNNY,SUB=JES2

is an error. We suggest you open a PMR.

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

Re: Strange behavior of START command(Keyword parms)

[Peter Relson]

>IIRC, I had the same error on a START LLA,SUB=MSTR before.  I think I
>blamed it on automation.

The only error case appears to be when you specify the device type / device
number on the command.

There must be some good reason to specify that, it just does not come to me
at the moment..
So if you don't need to, don't, and you won't encounter the error.

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

Re: Strange behavior of START command(Keyword parms)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
08/25/2007
   at 10:42 PM, Johnny Luo <[EMAIL PROTECTED]> said:

>Thanks. I learned from dealing with assembler macros that only if
>some positional parms are omitted between two positional parms commas
>are required to occupy the position.

The same is true for operator commands; chris gave you bad advise.

>Ok. Let's add the commas:
>S STC0001,,,3390,JOBNAME=JOHNNY,DISP=SHR,DSN=SYS1.PARMLIB

That passes "3330" as a parameter, not as a unit. Read the message
from Peter Relson and open a PMR as he asks.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Strange behavior of START command(Keyword parms)

[John P Kalinich]

> Getting
> IEE308I STARTTERM LENGTH ERROR
> when you issue
> S STC1,3390,JOBNAME=JOHNNY,SUB=JES2
>
> is an error. We suggest you open a PMR.
>
> Peter Relson
> z/OS Core Technology Design

Peter,

IIRC, I had the same error on a START LLA,SUB=MSTR before.  I think I
blamed it on automation.

Regards,
John Kalinich
CSC

--
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: Strange behavior of START command(Keyword parms)

[Johnny Luo]

Chris,

Thanks. I learned from dealing with assembler macros that only if some
positional parms are omitted between two positional parms commas are
required to occupy the position. I think it's reasonable but...

Anyway I did some extra tests:

S STC0001,3390,DISP=SHR,DSN=SYS1.PARMLIB,JOBNAME=JOHNNY

STC was started successfully and to verify the parse of parms was correct I
checked JESJCL:

//JOHNNY   JOB MSGLEVEL=1
//STARTING EXEC STC0001
XXSTC0001 PROC
XXIEFPROC  EXEC PGM=STC0001,TIME=1440
XXSTEPLIB  DD DISP=SHR,DSN=DMAP001.ADVASM.LOAD
//IEFPROC.IEFRDER DD UNIT=3390,DISP=SHR,DSN=SYS1.PARMLIB

So the JOBNAME and DD parms overriding is correct.

Now place JOBNAME as the first keyword parm:

S STC0001,3390,JOBNAME=JOHNNY,DISP=SHR,DSN=SYS1.PARMLIB
IEE308I STARTTERM LENGTH ERROR

Ok. Let's add the commas:

S STC0001,,,3390,JOBNAME=JOHNNY,DISP=SHR,DSN=SYS1.PARMLIB
$HASP100 JOHNNY   ON STCINRDR

Oh... it's started without error. However, I remember that I did a similar
test (adding commas) and it failed too and that's why I asked for help here.
What happened at that time? After searching the log I found it:

S STC0001,3390,,,JOBNAME=3390
IEE309I STARTUNIDENTIFIABLE KEYWORD

   I should have been more careful: What I got was not a TERM LENGTH
error any more! Adding commas did solve the problem and the new error I got
is because of the misspelled jobname '3390': it's not a valid jobname.

On 8/25/07, Chris Mason <[EMAIL PROTECTED]> wrote:

> Johnny
>
> Off the top of my head, you need commas in order to show that the two
> possible positional operands are not specified. Maybe this is necessary
> only
> when you specify one of the positional operands.
>
> But then "off the top of my head" isn't really good enough when the manual
> is potentially before me so, pulling up the START command in the MVS
> Commands manual I found the following under "Syntax":
>
> 
>
> Note:  For any variation of the START command, if you omit devicetype  (or
> devnum), or classes, or volumeserial, you must supply a  comma for each
> one
> of these parameters that you leave out. Do not supply any commas, however,
> after the last parameter you specify.
>
> 
>
> which looks like it might be some way to explaining your experiences.
> Maybe
> it's just not that well expressed!
>
> Here's the template for the START command in the manual for reference:
>
> 
>
> S
>
> membername[.identifier][,devicetype|,[/]devnum][,volumeserial][,parameters][,JOBNAME=jobname],JOBACCT=acct_info][,SUB=subsystemname][,keyword=option[,keyword=option]...]
>
> 
>
> Certainly you don't need extra commas when you supply keyword parameters
> in
> order to supply values for the keywords specified in the procedure - and -
> you are not specifying any positional parameters.
>
> I *think* the "TERM LENGTH ERROR" is because the logic behind the START
> command is trying to treat the keyword=value as a positional parameter
> with
> a fixed length. The volume serial number seems likely, length limit 6
> characters, but "SUB=JES2" would also be too long! - unless the parsing
> stops at the equal sign and discards the rest. The mystery deepens!
>
> Anyhow there are a few ideas to continue your testing.
>
> I hope one of the very many JCL/system command gurus in the list can
> clarify
> these wild surmises come the working week.
>
> Chris Mason
>
>


-- 
Best Regards,
Johnny Luo

--
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: Strange behavior of START command(Keyword parms)

[Chris Mason]

Johnny

Off the top of my head, you need commas in order to show that the two 
possible positional operands are not specified. Maybe this is necessary only 
when you specify one of the positional operands.


But then "off the top of my head" isn't really good enough when the manual 
is potentially before me so, pulling up the START command in the MVS 
Commands manual I found the following under "Syntax":




Note:  For any variation of the START command, if you omit devicetype  (or 
devnum), or classes, or volumeserial, you must supply a  comma for each one 
of these parameters that you leave out. Do not supply any commas, however, 
after the last parameter you specify.




which looks like it might be some way to explaining your experiences. Maybe 
it's just not that well expressed!


Here's the template for the START command in the manual for reference:



S 
membername[.identifier][,devicetype|,[/]devnum][,volumeserial][,parameters][,JOBNAME=jobname],JOBACCT=acct_info][,SUB=subsystemname][,keyword=option[,keyword=option]...]




Certainly you don't need extra commas when you supply keyword parameters in 
order to supply values for the keywords specified in the procedure - and - 
you are not specifying any positional parameters.


I *think* the "TERM LENGTH ERROR" is because the logic behind the START 
command is trying to treat the keyword=value as a positional parameter with 
a fixed length. The volume serial number seems likely, length limit 6 
characters, but "SUB=JES2" would also be too long! - unless the parsing 
stops at the equal sign and discards the rest. The mystery deepens!


Anyhow there are a few ideas to continue your testing.

I hope one of the very many JCL/system command gurus in the list can clarify 
these wild surmises come the working week.


Chris Mason

- Original Message - 
From: "Johnny Luo" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, August 25, 2007 12:48 PM
Subject: Strange behavior of START command(Keyword parms)



Hi,

I'm testing START command on a z/os 1.7 system and something surprised me.
Note the following console message:

First time:

S STC0001,3390,JOBNAME=JOHNNY,SUB=JES2
IEE308I STARTTERM LENGTH ERROR
IEA989I SLIP TRAP ID=X33E MATCHED.  JOBNAME=*UNAVAIL, ASID=0019

Then change the order of two keyword parms:

S STC0001,3390,SUB=JES2,JOBNAME=JOHNNY
$HASP100 JOHNNY   ON STCINRDR

So the order of keyword parms does matter?

But after I removed the positional parm 3390(device type):

S STC0001,JOBNAME=JOHNNY,SUB=JES2
$HASP100 JOHNNY   ON STCINRDR

It works. However, why 'S STC0001,3390,JOBNAME=JOHNNY,SUB=JES2 ' will give
me a TERM LENGTH ERROR is still beyond my knowledge.

Anyone can help me?

Thanks.

--
Best Regards,
Johnny Luo


--
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: Strange behavior of START command(Keyword parms)

[Johnny Luo]

Your message is empty...


On 8/25/07, Itschak Mugzach <[EMAIL PROTECTED]> wrote:
>
>
>
>
>




-- 
Best Regards,
Johnny Luo

--
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: Strange behavior of START command(Keyword parms)

[Itschak Mugzach]

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Johnny Luo
Sent: Saturday, August 25, 2007 12:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Strange behavior of START command(Keyword parms)

Hi,

I'm testing START command on a z/os 1.7 system and something surprised me.
Note the following console message:

First time:

S STC0001,3390,JOBNAME=JOHNNY,SUB=JES2
IEE308I STARTTERM LENGTH ERROR
IEA989I SLIP TRAP ID=X33E MATCHED.  JOBNAME=*UNAVAIL, ASID=0019

Then change the order of two keyword parms:

S STC0001,3390,SUB=JES2,JOBNAME=JOHNNY
$HASP100 JOHNNY   ON STCINRDR

So the order of keyword parms does matter?

But after I removed the positional parm 3390(device type):

S STC0001,JOBNAME=JOHNNY,SUB=JES2
$HASP100 JOHNNY   ON STCINRDR

It works. However, why 'S STC0001,3390,JOBNAME=JOHNNY,SUB=JES2 ' will give
me a TERM LENGTH ERROR is still beyond my knowledge.

Anyone can help me?

Thanks.

--
Best Regards,
Johnny Luo

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