System 04E abend bringing up DB2 CONTROL ADDRESS SPACE

[Micheal Butz]

I have been getting system 04E abends trying to bring up the DB2 Control
Address Space

 

 

The following link
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnc1k16/9.0?ACTI
ON=MATCHES

&REQUEST=04E&TYPE=FUZZY&SHELF=&DT=20091012143256&CASE=&searchTopic=TOPIC&sea
rchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

 

 

 

In the DB2 for z/os codes lists what to do abend codes 04E and 04F  but
there isn't any specific documentation on specific reason codes 

 

My first reason code with this abend was 754 seemed to be something with the
Region parameter to so I changed the region to 0M

 

Now I get abend 04E with reason 800 

 

My question is .. is there anywhere the reason codes are documented

 

   


--
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: Dumb question on DEFINE ALIAS

[Tony @ Comcast]

Comments in context below... 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of R.S.
Sent: Sunday, July 11, 2010 4:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Dumb question on DEFINE ALIAS

W dniu 2010-07-11 22:41, Tony @ Comcast pisze:
> Years ago I worked for a small MVS shop that functioned quite well using
the
> "catalog name being the same as the hlq" trick to avoid the need for
> creating aliases en masse.  It was handy for the TSO user population to
have
> a catalog called ISPF, the prefixing everyone's personal datasets
> accordingly.

That leads to have single-alias catalogs.   < in limited cases, that's
fine.


Not to mention multi-level aliases.<-- OK, so what's the problem? 



It can be effective, but need not to be. <-- There's no "one size fits
all" solution, in prnciple I agree with you.


Even your rule had an exception for bunch of TSO ID's.  <- None that
come to mind but I admit the possibility.



My ROT is to document the changes and have ready to use tools to list 
the catalog HLQs, aliases to catalogs.   <--- Agree, we do al that. 


More flexibility, but still under 
control. <- We have so much documented, in so many different
places, I have trouble finding it 

Last but not least: I think we all agree that KISS is still good rule.
<- Definitely agree ! 

Regards
-- 
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w
caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj
warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z
dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r.,
moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym
kapitale zakadowym BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dumb question on DEFINE ALIAS

[Tony @ Comcast]

I thought it was a "good" thing at the time because it was.  We churned out
lots of work at minimal cost to our employer and it was bulletproof.  The
track record proved it out as we made a business case to forestall a
mainframe replacement for several years through the madness of Y2K.  Our
little staff and zOS box out-performed and out-economized the toy computer
gang for several years till the whole shebang was bought out.

The "hlq=catalog name" was a workable technique back then.  My employer was
a very small shop that served a holding company with about 20 subsidiary
companies with a business requirement to strictly segregate each body of
data.  A small company in a small town has (had sadly) a difficult task in
finding tech people, hence each of us wore several hats, worked long hours
during the years of no remote access, and had minimal time to maintain
anything or fix broken components. 

Fast forward to my present employer, a large US brand name in a large US
city.  10K TSO users time 40 lpars, a dozen or so master catalogs, and
limited skill people tasked with high skill work. Defining aliases en masse
isn't a constant problem but "NOT a problem" does not describe our
landscape.

Each case befits the YMMV disclaimer.  What works here may not work there,
what is liked here may be hated there, "good" and "bad" is trying to pin
jello to the wall. 







   

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Ted MacNEIL
Sent: Sunday, July 11, 2010 4:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Dumb question on DEFINE ALIAS

I don't understand why you think this a good thing!
It' not.
Aliases en masse is NOT a problem!
It reduces clutter, and makes a storage analyst's job a heck of a lot
easier!

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

-Original Message-
From: "Tony @ Comcast" 
Sender: IBM Mainframe Discussion List 
Date: Sun, 11 Jul 2010 15:41:32 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Dumb question on DEFINE ALIAS

Years ago I worked for a small MVS shop that functioned quite well using the
"catalog name being the same as the hlq" trick to avoid the need for
creating aliases en masse.  It was handy for the TSO user population to have
a catalog called ISPF, the prefixing everyone's personal datasets
accordingly.

If I were in the storage management business these days (glad I'm not!) I'd
continue to exploit this "feature." 



  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Darth Keller
Sent: Friday, July 09, 2010 2:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Dumb question on DEFINE ALIAS

>>Subject: Dumb question on DEFINE ALIAS

>>What is the reason for defining a catalog alias? I think I understand 
the technical effect but I don't understand the big picture purpose.
>>Suppose I wanted to define and catalog some new datasets FOO.THIS and 
FOO.THAT. Why would I issue something like

>>  DEFINE ALIAS (NAME(FOO ) RELATE(SOME.CATALOG))

>>I understand the "little picture" reason: to specify FOO as an alias for 
SOME.CATALOG but big picture, why would I not just create and catalog 
>>FOO.THIS and FOO.THAT using JCL? What is the advantage of or reason for 
defining the alias?

>>Is there an overview somewhere of catalogs and catalog management?

So isn't there sneaky way to get away without defining aliases?If your 
datasets all start with the 2 levels A.B and you have a usercatalog named 
"A.B", then all your A.B.** datasets end up cataloged in the usercatalog 
"A.B" by default.

I ran into this in one shop where they had a catalog named "A" and all the 
A.** datasets were cataloged in that usercatalog - no alias defined.  I 
did not like it and got rid of it as fast as I could. 

This method pretty much requires that you have a separate usercatalog for 
each 'set' of datasets. In my current shop, that would mean thousands of 
catalogs if we carried it out to the bitter end.
ddk




This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructi

Re: instream data

[Paul Gilmartin]

On Mon, 12 Jul 2010 10:03:58 +1000, Clement Clarke wrote:
>>
>For over 40 years, Jol has allowed you to do just that.
>
>Jol is a free format JCL replacement language, loosely based on PL/I.
>
>You can declare Data Sets and Programs, and use commands such as Run (a
>program) or Copy a data set and so on.
>
>Jol comes with the ability to declare "card" files in Jol Procedures or
>in Macros (which allow you to add new instructions to Jol in a high
>level language).
>
>Furthermore, you can replace Symbolic Parameters or Variables in card
>image files to create Utility Control Statements and so on.
>
JCL has changed a lot in 40 years.  Has Jol kept pace?

o Does Jol generate JCL and write it to INTRDR?  If not, how does
  it operate?

o Does Jol provide the ENQ deadlock protection provided by batch
  initiators?

o Does Jol provide flow control at least comparable to JCL's
  IF...THEN...ELSE...ENDIF?

o Does Jol support tapes with facilities such as RETAIN and VOL=REF?

o Can Jol's "card image" files have non-cardlike attributes such as
  RECFM=VB,LRECL=254

o Does Jol allow PARM length>100?

o Does Jol support jobs with a mixture of steps running authorized
  and unauthorized programs, with the security of batch JCL?

Most of these questions can be summarized as, "What facilities of
today's JCL would the programmer sacrifice to gain the benefits of
Jol?"

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: instream data

[Clement Clarke]

Frank Swarbrick wrote:

Now that we've been on z/OS for a few weeks I feel to need to ask a question that has 
annoyed me since I started working on z/OS two years ago.  Instream datasets are good.  
Why are they not supported inside of procs?  Is there a technical reason, or is it just 
"because"?  We use procs for almost all of our production jobs, with many steps 
that could take advantage of instream datasets if not for this restriction.

Thanks,
Frank



For over 40 years, Jol has allowed you to do just that.

Jol is a free format JCL replacement language, loosely based on PL/I.

You can declare Data Sets and Programs, and use commands such as Run (a 
program) or Copy a data set and so on.


Jol comes with the ability to declare "card" files in Jol Procedures or 
in Macros (which allow you to add new instructions to Jol in a high 
level language).


Furthermore, you can replace Symbolic Parameters or Variables in card 
image files to create Utility Control Statements and so on.


This example used predefined Symbolic Variables of %DAYNO, %MONTHO and 
%YEAR to place the current date in a control card.


  DCL CONTROL * REPLACE;
%DAYNO%MONTHNO%YEAR
EOF;

PRINT CONTROL;  /* Copy card to printer */

These statements create a Data Set Identifier (DSID) called CONTROL 
which will have:-


Columns   Data

1-2 day number, e.g. 09
3-4  month number, e.g. 07
5-8  year number, e.g. 2009

For example:

09072009

This control file can be used by a program to print headings on a report.

You can see more here:
For over 40 years, Jol has allowed you to do just that.

Jol is a free format JCL replacement language, loosely based on PL/I.

You can declare Data Sets and Programs, and use commands such as Run (a 
program) or Copy a data set and so on.


Jol comes with the ability to declare "card" files in Jol Procedures or 
in Macros (which allow you to add new instructions to Jol in a high 
level language).


Furthermore, you can replace Symbolic Parameters or Variables in card 
image files to create Utility Control Statements and so on.


This example used predefined Symbolic Variables of %DAYNO, %MONTHO and 
%YEAR to place the current date in a control card.


  DCL CONTROL * REPLACE;
%DAYNO%MONTHNO%YEAR
EOF;

PRINT CONTROL;  /* Copy card to printer */

These statements create a Data Set Identifier (DSID) called CONTROL 
which will have:-


Columns   Data

1-2 day number, e.g. 09
3-4  month number, e.g. 07
5-8  year number, e.g. 2009

For example:

09072009

This control file can be used by a program to print headings on a report.

You can see more here:
http://tinyurl.com/22jz7vj


Cheers,

Clem

--
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: JES2 Exit 53 problem

[Joe Reichman]

Doesn't reg 0 point to the XPL ???

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Mark Yuhas
Sent: Saturday, July 10, 2010 11:43 PM
To: IBM-MAIN@bama.ua.edu
Subject: JES2 Exit 53 problem

Maybe another set of eyes can show me the error of my ways.  I have
written JES2 Exit #53 to validate the accounting field of the JOB
statement.  The exit performs as designed except for a nagging problem.
I want to pass an error message to be added to the JCL data set.

According to the JES2 Exit Manual:  When passing a return code of 12,
your exit routine can pass an installation-defined error message to JES2
to be added to the JCL data set rather than the standard error message.
To send an error message, generate the message text in your exit
routine, move it to area pointed to by X053JXWR, and set the X053XSEM
bit in X053RESP to one.

I have included the code I have written to do this:
L   R1,XPL_ADDRESS
L   R2,X053JXWR-XPL(,R1)
MVC 0(80,R2),TEXTAREA_MESSAGE
OI  X053RESP-XPL(R1),X053XSEM

Yes, the return code is 12 as evidenced by this message:
/HASP119 MYUHASTU DELETED - ILLEGAL JOB CARD ACCT FIELD, RC=12

I have checked and rechecked this code and the contents of storage via
SVC dumps.  All looks good but the message is not being added to the JCL
data set.

Any suggestions?  



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dumb question on DEFINE ALIAS

[Ted MacNEIL]

I don't understand why you think this a good thing!
It' not.
Aliases en masse is NOT a problem!
It reduces clutter, and makes a storage analyst's job a heck of a lot easier!

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

-Original Message-
From: "Tony @ Comcast" 
Sender: IBM Mainframe Discussion List 
Date: Sun, 11 Jul 2010 15:41:32 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Dumb question on DEFINE ALIAS

Years ago I worked for a small MVS shop that functioned quite well using the
"catalog name being the same as the hlq" trick to avoid the need for
creating aliases en masse.  It was handy for the TSO user population to have
a catalog called ISPF, the prefixing everyone's personal datasets
accordingly.

If I were in the storage management business these days (glad I'm not!) I'd
continue to exploit this "feature." 



  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Darth Keller
Sent: Friday, July 09, 2010 2:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Dumb question on DEFINE ALIAS

>>Subject: Dumb question on DEFINE ALIAS

>>What is the reason for defining a catalog alias? I think I understand 
the technical effect but I don't understand the big picture purpose.
>>Suppose I wanted to define and catalog some new datasets FOO.THIS and 
FOO.THAT. Why would I issue something like

>>  DEFINE ALIAS (NAME(FOO ) RELATE(SOME.CATALOG))

>>I understand the "little picture" reason: to specify FOO as an alias for 
SOME.CATALOG but big picture, why would I not just create and catalog 
>>FOO.THIS and FOO.THAT using JCL? What is the advantage of or reason for 
defining the alias?

>>Is there an overview somewhere of catalogs and catalog management?

So isn't there sneaky way to get away without defining aliases?If your 
datasets all start with the 2 levels A.B and you have a usercatalog named 
"A.B", then all your A.B.** datasets end up cataloged in the usercatalog 
"A.B" by default.

I ran into this in one shop where they had a catalog named "A" and all the 
A.** datasets were cataloged in that usercatalog - no alias defined.  I 
did not like it and got rid of it as fast as I could. 

This method pretty much requires that you have a separate usercatalog for 
each 'set' of datasets. In my current shop, that would mean thousands of 
catalogs if we carried it out to the bitter end.
ddk




This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dumb question on DEFINE ALIAS

[R.S.]

W dniu 2010-07-11 22:41, Tony @ Comcast pisze:

Years ago I worked for a small MVS shop that functioned quite well using the
"catalog name being the same as the hlq" trick to avoid the need for
creating aliases en masse.  It was handy for the TSO user population to have
a catalog called ISPF, the prefixing everyone's personal datasets
accordingly.


That leads to have single-alias catalogs. Not to mention multi-level 
aliases. It can be effective, but need not to be. Even your rule had an 
exception for bunch of TSO ID's.
My ROT is to document the changes and have ready to use tools to list 
the catalog HLQs, aliases to catalogs. More flexibility, but still under 
control.


Last but not least: I think we all agree that KISS is still good rule.
Regards
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
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: Amusing JCL Oddity

[Shmuel Metz (Seymour J.)]

In <4c332ecc.90...@acm.org>, on 07/06/2010
   at 08:25 AM, "Joel C. Ewing"  said:

>This would be a semantic error (dealing with meaning),

No, it would be a syntax error that is easier to catch with a semantic
constraint than with classical parsing techniques. Do not confuse
"grammar" with, e.g., "CFG". Google for "W grammar" for an example of
how to handle complex grammars without resorting to semantic
constraints.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Backup/Restore products at z/OS sites

[Shmuel Metz (Seymour J.)]

In ,
on 07/06/2010
   at 09:49 PM, Dan Squillace  said:

>I never did say why I was asking.  In SAS 9.2, we already support
>z/OS software distribution via FTP,

Then why do you require your customers to use the Download Manager and
a proxy server for electronic delivery? Your installation
documentation certainly doesn't mention an option to simply run an FTP
client on the z/OS system.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dumb question on DEFINE ALIAS

[Tony @ Comcast]

Years ago I worked for a small MVS shop that functioned quite well using the
"catalog name being the same as the hlq" trick to avoid the need for
creating aliases en masse.  It was handy for the TSO user population to have
a catalog called ISPF, the prefixing everyone's personal datasets
accordingly.

If I were in the storage management business these days (glad I'm not!) I'd
continue to exploit this "feature." 



  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Darth Keller
Sent: Friday, July 09, 2010 2:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Dumb question on DEFINE ALIAS

>>Subject: Dumb question on DEFINE ALIAS

>>What is the reason for defining a catalog alias? I think I understand 
the technical effect but I don't understand the big picture purpose.
>>Suppose I wanted to define and catalog some new datasets FOO.THIS and 
FOO.THAT. Why would I issue something like

>>  DEFINE ALIAS (NAME(FOO ) RELATE(SOME.CATALOG))

>>I understand the "little picture" reason: to specify FOO as an alias for 
SOME.CATALOG but big picture, why would I not just create and catalog 
>>FOO.THIS and FOO.THAT using JCL? What is the advantage of or reason for 
defining the alias?

>>Is there an overview somewhere of catalogs and catalog management?

So isn't there sneaky way to get away without defining aliases?If your 
datasets all start with the 2 levels A.B and you have a usercatalog named 
"A.B", then all your A.B.** datasets end up cataloged in the usercatalog 
"A.B" by default.

I ran into this in one shop where they had a catalog named "A" and all the 
A.** datasets were cataloged in that usercatalog - no alias defined.  I 
did not like it and got rid of it as fast as I could. 

This method pretty much requires that you have a separate usercatalog for 
each 'set' of datasets. In my current shop, that would mean thousands of 
catalogs if we carried it out to the bitter end.
ddk




This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
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: Amusing JCL Oddity

[Shmuel Metz (Seymour J.)]

In <45e5f2f45d7878458ee5ca6796973355213...@usdaexch01.kbm1.loc>, on
07/06/2010
   at 08:22 AM, "Staller, Allan"  said:

>Again, what is syntactically incorrect?

Duplicate keywords.

>Everything after PROC=A# is a parameter or nullification (V=) passed
>to the procedure.

"SP1=3000" is not passed to the procedure.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Amusing JCL Oddity

[Shmuel Metz (Seymour J.)]

In <45e5f2f45d7878458ee5ca6796973355213...@usdaexch01.kbm1.loc>, on
07/06/2010
   at 07:27 AM, "Staller, Allan"  said:

>Why? What is syntactically incorrect with the below?

The duplicate keywords.

>Without observing the procedure being called, it is impossible to
>determine if a syntax error is in place.

No, it is trivial to detect the syntax error.

>The converter/interpreter will find syntax errors in JCL. 

Not this one.

>The "classic" JCL error.

There are many classics.

>although commonly referred to as a JCL error

There are many errors; syntax errors are a proper subset.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html