Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Strange JCL error

1,747 views
Skip to first unread message

Steve Comstock

unread,
Feb 3, 2010, 3:58:41 PM2/3/10
to
Have a job I've been submitting many times, runs as
expected. Minutes ago I submitted the same job and
it fails with JCL ERROR and under SDSF I see:

STMT NO. MESSAGE
1 IEFC607I JOB HAS NO STEPS

Now, submitting various other jobs that have worked
in the past, they all fail this way.

Looking at the jobs using the SL line command in SDSF,
they all have only 10 lines (which are a JOB statement
and some comments, it turns out, so, yes, in the first
10 lines there are no EXEC statements).

Logged off and back on, same result.

This smells somewhat familiar, but I can't put my finger
on it. Anyone have any suggestions what's going on and
how to solve it?

(BTW, using the TSO SUB command works fine; it's just
using the ISPF SUB command from Edit or View that fails.
Also note, from a member list, entering the line commands
SUB or J work fine too.)


--

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

Ask me about our new, reduced rates for purchasing our course materials
for use by your own trainers or Subject Matter Experts (SMEs).

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

Hal Merritt

unread,
Feb 3, 2010, 4:05:42 PM2/3/10
to
Maybe a comment got continued right over the following EXEC statement?


--

Kind regards,

303-393-8716
http://www.trainersfriend.com

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

Mark Zelden

unread,
Feb 3, 2010, 4:14:17 PM2/3/10
to
On Wed, 3 Feb 2010 13:58:00 -0700, Steve Comstock <st...@TRAINERSFRIEND.COM>
wrote:

>Have a job I've been submitting many times, runs as
>expected. Minutes ago I submitted the same job and
>it fails with JCL ERROR and under SDSF I see:
>
>STMT NO. MESSAGE
> 1 IEFC607I JOB HAS NO STEPS
>
>Now, submitting various other jobs that have worked
>in the past, they all fail this way.
>
>Looking at the jobs using the SL line command in SDSF,
>they all have only 10 lines (which are a JOB statement
>and some comments, it turns out, so, yes, in the first
>10 lines there are no EXEC statements).
>
>Logged off and back on, same result.
>
>This smells somewhat familiar, but I can't put my finger
>on it. Anyone have any suggestions what's going on and
>how to solve it?
>
>(BTW, using the TSO SUB command works fine; it's just
>using the ISPF SUB command from Edit or View that fails.
>Also note, from a member list, entering the line commands
>SUB or J work fine too.)
>
>

If you look at what is allocated for ISPCTL0 using ISRDDN, do
you see anything strange there? Can you delete that data set so
it will get re-allocated.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

Thompson, Steve

unread,
Feb 3, 2010, 4:14:21 PM2/3/10
to
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Steve Comstock
Sent: Wednesday, February 03, 2010 2:58 PM
To: IBM-...@bama.ua.edu
Subject: Strange JCL error

<snip>

Were you supposed to have at least one EXEC statement?

If so, within SDSF, enter the line command SJ and see if what you have
there matches what is in the PDS where it came from.

Also, check and see if one of you comment statements does not have "*"
in CC3 while the rest of the line is empty.

Regards,
Steve Thompson

Steve Comstock

unread,
Feb 3, 2010, 4:19:50 PM2/3/10
to
Hal Merritt wrote:
> Maybe a comment got continued right over the following EXEC statement?

No, it's the exact same JCL. (Still, I went back and
double-checked; when you've been around awhile you
learn to look again.)

Steve Comstock

unread,
Feb 3, 2010, 4:23:39 PM2/3/10
to

There is nothing visible; there is no ISPCTLx DDname there at all.


--

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

Ask me about our new, reduced rates for purchasing our course materials
for use by your own trainers or Subject Matter Experts (SMEs).

----------------------------------------------------------------------

Tidy, David , D

unread,
Feb 3, 2010, 4:29:33 PM2/3/10
to
Have you tried renaming your ISPF profile data set (temporarily) and
using a completely fresh one for a session?


Best regards,
David Tidy Tel:(31)115-67-1745
IS Technical Management/SAP-Mf Fax:(31)115-67-1762
Dow Benelux B.V. Mailto:dt...@dow.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Steve Comstock
Sent: 03 February 2010 21:58
To: IBM-...@bama.ua.edu
Subject: Strange JCL error

Mark Zelden

unread,
Feb 3, 2010, 4:41:48 PM2/3/10
to
On Wed, 3 Feb 2010 14:22:58 -0700, Steve Comstock <st...@TRAINERSFRIEND.COM>
wrote:

>>>
>>


>> If you look at what is allocated for ISPCTL0 using ISRDDN, do
>> you see anything strange there? Can you delete that data set so
>> it will get re-allocated.
>>

>


>There is nothing visible; there is no ISPCTLx DDname there at all.
>
>

In that case, just search via ISPF 3.4 for userid.SPFTEMP*.CNTL
or userid.*.SPFTEMP*.CNTL and try deleting it.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------

Steve Comstock

unread,
Feb 3, 2010, 4:45:38 PM2/3/10
to

My colleague, Hunter Cobb, is having the same issue, and
he tried using a fresh ISPF profile, but no luck.

Here's an update: logging in under a different ID, the
problem goes away; logging off and re-logging on under
the original ID, the problem is back. That narrows
things down a little.

We'll keep poking around. Just thought someone on the
list might recognize this behavior.

Thompson, Steve

unread,
Feb 3, 2010, 4:53:48 PM2/3/10
to
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Steve Comstock
Sent: Wednesday, February 03, 2010 3:45 PM
To: IBM-...@bama.ua.edu
Subject: Re: Strange JCL error

Tidy, David (D) wrote:
> Have you tried renaming your ISPF profile data set (temporarily) and
> using a completely fresh one for a session?

<snip>

My colleague, Hunter Cobb, is having the same issue, and
he tried using a fresh ISPF profile, but no luck.

Here's an update: logging in under a different ID, the
problem goes away; logging off and re-logging on under
the original ID, the problem is back. That narrows
things down a little.

We'll keep poking around. Just thought someone on the
list might recognize this behavior.

<SNIP>

I have, and it was something in the concatenation that had a new item in
it. And I'm trying to remember if it was an Edit macro that was
inappropriately named SUB that did a SUBMIT but also changed some things
first or if it was some other change. But I have seen this and it was a
pain.

What was the clue to us was that SUBMIT outside of a member worked
correctly.

That's why I asked about the SJ and then looking at the original, with
some hints about an embedded NULL statement and the like.

However, if all the IDs are using the same logon proc (and same logon
CLIST/EXEC) then this gets more difficult to run down.

Regards,
Steve Thompson

Pommier, Rex R.

unread,
Feb 3, 2010, 4:54:51 PM2/3/10
to
Hi all,

I have a strange one that I can't figure out. As part of my testing of
z/OS 1.10, I'm running some test jobs that e-mail output to internal
users (namely, me). On my current 1.7 system, the e-mails flow almost
instantaneously. On the 1.10 test system, the actual e-mail step takes
exactly 1 minute to run. I get the e-mail like I should but I don't
like the 1 minute step run time. Any ideas as to what I'm missing or
have wrong? I am using essentially the same sendmail.cf file on both
systems.

I have to believe there is some kind of a timeout happening, but I can't
find it. The output from the sendmail step is the same from the test to
the production systems. During the 1 minute timeframe, the OMVSEX step
is sitting in long wait status.

BTW, never mind the outlandish TCB time. That is another problem for
another time...

JOBNAME STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK
SERV
RRPXSEND S30 00 89 0 551177 .00 .0
306
RRPXSEND *OMVSEX 00 1424 19 551177 .00 1.0
2101

TIA,

Rex

McKown, John

unread,
Feb 3, 2010, 4:57:20 PM2/3/10
to
DNS resolution? Perhaps the RESOLVER has multiple DNS servers listed and the first one is timing out? Just a WAG.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

> -----Original Message-----
> From: IBM Mainframe Discussion List

Steve Comstock

unread,
Feb 3, 2010, 4:58:06 PM2/3/10
to
Mark Zelden wrote:
> On Wed, 3 Feb 2010 14:22:58 -0700, Steve Comstock <st...@TRAINERSFRIEND.COM>
> wrote:
>
>>> If you look at what is allocated for ISPCTL0 using ISRDDN, do
>>> you see anything strange there? Can you delete that data set so
>>> it will get re-allocated.
>>>
>
>> There is nothing visible; there is no ISPCTLx DDname there at all.
>>
>>
>
> In that case, just search via ISPF 3.4 for userid.SPFTEMP*.CNTL
> or userid.*.SPFTEMP*.CNTL and try deleting it.
>
> Mark
> --
> Mark Zelden
> Sr. Software and Systems Architect - z/OS Team Lead
> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
> mailto:mark....@zurichna.com
> z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html


Well that gives me:

ISPF system data set allocation error - press Enter to continue.
Temporary control card data set cannot be allocated.
Error trying to open ''.
***

On a hunch I then logged off and logged back on.

Same problem.

--

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

Ask me about our new, reduced rates for purchasing our course materials
for use by your own trainers or Subject Matter Experts (SMEs).

----------------------------------------------------------------------

Field, Alan C.

unread,
Feb 3, 2010, 5:02:53 PM2/3/10
to
You know what the TCB problem is don't you? You need an updated IEFACTRT
exit. I don't remember the details but its something like what was a
halfword is now a fullword.

Alan

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On

Behalf Of Pommier, Rex R.
Sent: Wednesday, February 03, 2010 15:54
To: IBM-...@bama.ua.edu
Subject: sendmail on the mainframe strange behavior

BTW, never mind the outlandish TCB time. That is another problem for
another time...

JOBNAME STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK
SERV
RRPXSEND S30 00 89 0 551177 .00 .0
306
RRPXSEND *OMVSEX 00 1424 19 551177 .00 1.0
2101

----------------------------------------------------------------------

Bob Shannon

unread,
Feb 3, 2010, 5:13:30 PM2/3/10
to
Is there any space in your TSO pool?

Bob Shannon
Rocket Software

Thompson, Steve

unread,
Feb 3, 2010, 5:18:42 PM2/3/10
to
<SNIPPAGE>

Well that gives me:

ISPF system data set allocation error - press Enter to continue.
Temporary control card data set cannot be allocated.
Error trying to open ''.
***

On a hunch I then logged off and logged back on.

Same problem.

<SNIPPAGE>

The Mighty Fine Manual says:

-----

ISPA005 CNTLX allocate err msg - Temporary control card data set cannot
be allocated.

Explanation: The ISPF temporary ISPCTLx or ISPWRKx data set cannot be
allocated.

User response: Note the error message and text. Contact your system
programmer.

System programmer response: Diagnose the allocation error using the
appropriate IBM documentation. Contact IBM support.

-----

Which is almost as good as water is wet.

Along with TSO pool, check and see if your profile DS (or table) has
been corrupted. It may be that a variable that is needed has been
modified or deleted.

So compare against the ID that works correctly.

Like I said before, this one is a pain to run down.


Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those held by
poster's employer --

Dave Salt

unread,
Feb 3, 2010, 5:22:55 PM2/3/10
to
Try entering BUILTIN SUB and see what happens.

Dave Salt

SimpList(tm) - try it; you'll get it!

http://www.mackinney.com/products/program-development/simplist.html


> Date: Wed, 3 Feb 2010 13:58:00 -0700
> From: st...@TRAINERSFRIEND.COM
> Subject: Strange JCL error
> To: IBM-...@bama.ua.edu

_________________________________________________________________
Check your Hotmail from your phone.
http://go.microsoft.com/?linkid=9708121

Mark Zelden

unread,
Feb 3, 2010, 5:23:29 PM2/3/10
to
On Wed, 3 Feb 2010 14:57:34 -0700, Steve Comstock <st...@TRAINERSFRIEND.COM>
wrote:

>Mark Zelden wrote:
>> On Wed, 3 Feb 2010 14:22:58 -0700, Steve Comstock <st...@TRAINERSFRIEND.COM>
>> wrote:
>>
>>>> If you look at what is allocated for ISPCTL0 using ISRDDN, do
>>>> you see anything strange there? Can you delete that data set so
>>>> it will get re-allocated.
>>>>
>>
>>> There is nothing visible; there is no ISPCTLx DDname there at all.
>>>
>>>
>>
>> In that case, just search via ISPF 3.4 for userid.SPFTEMP*.CNTL
>> or userid.*.SPFTEMP*.CNTL and try deleting it.
>>
>> Mark
>> --
>> Mark Zelden
>> Sr. Software and Systems Architect - z/OS Team Lead
>> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
>> mailto:mark....@zurichna.com
>> z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
>> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
>
>

>Well that gives me:
>
>ISPF system data set allocation error - press Enter to continue.
>Temporary control card data set cannot be allocated.
>Error trying to open ''.
>***
>
>On a hunch I then logged off and logged back on.
>
>Same problem.
>

Okay, after you submit the job and then look at the ISPCTL0 data set,
what does it look like? I assume you only see the 10 card images in
there. Also what are the allocation attributes.

I you allocate ISPCTL0 as follows (use ISPF opt. 6) , does that fix
the problem (FREE it first if need be, use SYSALLDA if VIO is not
valid):

ALLOC FI(ISPCTL0) UNIT(VIO) NEW CYL SPACE(1,1) DELETE
REUSE LRECL(80) RECFM(F B) BLKSIZE(8000)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

Steve Comstock

unread,
Feb 3, 2010, 5:35:04 PM2/3/10
to

Same result.

Steve Comstock

unread,
Feb 3, 2010, 5:35:11 PM2/3/10
to
Bob Shannon wrote:
> Is there any space in your TSO pool?
>
> Bob Shannon
> Rocket Software

Interesting question. How would I check that?

--

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

Ask me about our new, reduced rates for purchasing our course materials
for use by your own trainers or Subject Matter Experts (SMEs).

----------------------------------------------------------------------

Don Leahy

unread,
Feb 3, 2010, 5:38:37 PM2/3/10
to
Have you looked at the JES2 LOG from your previous TSO session?

I have seen this sort of error caused by a RACF issue. (The user had
changed his TSO prefix to an invalid value).

Steve Comstock

unread,
Feb 3, 2010, 5:57:53 PM2/3/10
to

Well, I don't know what's happened. But our jobs are
now running fine.

One thing we both did was to delete the SPFTEMP0 dataset;
log of; log on; run a job; fails; run the same job: all's
well.

Hmmmm. It's nice that it's working, but I don't have any
confidence this is stable.

Very strange. We'll keep an eye on it and let you know if
we ever solve this strange problem.

Thanks for all the suggestions.


--

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

Ask me about our new, reduced rates for purchasing our course materials
for use by your own trainers or Subject Matter Experts (SMEs).

----------------------------------------------------------------------

DanD

unread,
Feb 3, 2010, 7:15:46 PM2/3/10
to
> My colleague, Hunter Cobb, is having the same issue, and
> he tried using a fresh ISPF profile, but no luck.
>
> Here's an update: logging in under a different ID, the
> problem goes away; logging off and re-logging on under
> the original ID, the problem is back. That narrows
> things down a little.
>
> We'll keep poking around. Just thought someone on the
> list might recognize this behavior.
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-393-8716
> http://www.trainersfriend.com


Any chance you have a "SUB" clist or REXX that's being run as an EDIT macro?

DanD

Paul Gilmartin

unread,
Feb 3, 2010, 7:50:45 PM2/3/10
to
On Wed, 3 Feb 2010 16:52:32 -0500, Thompson, Steve wrote:
>
>We'll keep poking around. Just thought someone on the
>list might recognize this behavior.
><SNIP>
>
>I have, and it was something in the concatenation that had a new item in
>it. And I'm trying to remember if it was an Edit macro that was
>inappropriately named SUB that did a SUBMIT but also changed some things
>first or if it was some other change. But I have seen this and it was a
>pain.
>
BTW, DDLIST won't necessarily help you here. If that "SUB"
is in a Unix directory in your SYSEXEC concatenation, it will
run, but DDLIST Member search won't show it. I started a PMR
on this. IBM says, "WAD; DDLIST is supposed to display only
members accessible through ISPF LM services."

-- gil

Steve Comstock

unread,
Feb 3, 2010, 8:12:54 PM2/3/10
to
DanD wrote:
>> My colleague, Hunter Cobb, is having the same issue, and
>> he tried using a fresh ISPF profile, but no luck.
>>
>> Here's an update: logging in under a different ID, the
>> problem goes away; logging off and re-logging on under
>> the original ID, the problem is back. That narrows
>> things down a little.
>>
>> We'll keep poking around. Just thought someone on the
>> list might recognize this behavior.
>>
>> Kind regards,
>>
>> -Steve Comstock
>> The Trainer's Friend, Inc.
>>
>> 303-393-8716
>> http://www.trainersfriend.com
>
>
> Any chance you have a "SUB" clist or REXX that's being run as an EDIT
> macro?

Good thought, but we checked that: no.


--

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

Ask me about our new, reduced rates for purchasing our course materials
for use by your own trainers or Subject Matter Experts (SMEs).

----------------------------------------------------------------------

Don Leahy

unread,
Feb 3, 2010, 9:57:20 PM2/3/10
to
I was able to set up a situation that generated a similar, but not
identical, error message when I issued the SUB command:

ISPF system data set allocation error - press Enter to continue.
Temporary control card data set cannot be allocated.

DAIR RC = 12 dec, DARC = 970C hex.
***

That was with my TSO profile set to NOWTPMSG. If I reset it to WTPMSG the
cause of the problem is obvious:

ICH408I USER(BSB945 ) GROUP(DX95 ) NAME(LEAHY, DON )
DXXX.BSB945.SPFTEMP0.CNTL CL(DATASET ) VOL(STRD17)
DEFINE - RESOURCE NOT PROTECTED


ISPF system data set allocation error - press Enter to continue.
Temporary control card data set cannot be allocated.

DAIR RC = 12 dec, DARC = 970C hex.
***

Do you have WTPMSG turned on? (It's a long shot, most people do).

Steve Comstock

unread,
Feb 4, 2010, 7:57:19 AM2/4/10
to
Don Leahy wrote:
> I was able to set up a situation that generated a similar, but not
> identical, error message when I issued the SUB command:
>
> ISPF system data set allocation error - press Enter to continue.
> Temporary control card data set cannot be allocated.
> DAIR RC = 12 dec, DARC = 970C hex.
> ***
>
> That was with my TSO profile set to NOWTPMSG. If I reset it to WTPMSG the
> cause of the problem is obvious:
>
> ICH408I USER(BSB945 ) GROUP(DX95 ) NAME(LEAHY, DON )
> DXXX.BSB945.SPFTEMP0.CNTL CL(DATASET ) VOL(STRD17)
> DEFINE - RESOURCE NOT PROTECTED
> ISPF system data set allocation error - press Enter to continue.
> Temporary control card data set cannot be allocated.
> DAIR RC = 12 dec, DARC = 970C hex.
> ***
>
> Do you have WTPMSG turned on? (It's a long shot, most people do).
>

Well, I went and checked, and, yes I do have it turned on.

A more likely cause has surfaced: at Mark's suggestion I
took a look a the allocation attributes of the SPFTEMP0.CNTL
data set, and it had LRECL or 80 and BLKSIZE of 800. Now you
may recall that one of the symptoms was SDSF only showed my
input as 10 lines of JCL. It's possible that only one block
was being read in, then maybe an I/O error (bad block) kept
the rest of the JCL out and that one block was passed to
the Converter.

Hard to be sure, and we're running under z/VM so there's
several layers of code here.

Since the problem has gone away, I'm moving on.

StevePratt

unread,
Feb 4, 2010, 8:53:18 AM2/4/10
to

> Since the problem has gone away, I'm moving on.

I really don't link not knowing WHY something magically gets fixed.
But, as you mentioned, it is harder and harder and harder to get to
the bottom things. Much harder than it used to be. "too many layers"
is a good synopsis. I, too, recently gave up trying to figure out why
it got fixed and was content that it is working. And that is damn
hard to do for a technician.

Greg Shirey

unread,
Feb 4, 2010, 10:02:24 AM2/4/10
to
When we have had users with similar problems submitting jobs, we have
discovered their SPFTEMP0.CNTL data set is multi-volume. This may not
be relevant because I don't recall anyone ever having only part of their
job read in and I know you're moving on, but I thought I'd throw this
out there.

Greg Shirey
Ben E. Keith Company

-----Original Message-----
From: IBM Mainframe Discussion List On Behalf Of Steve Comstock
Sent: Thursday, February 04, 2010 6:57 AM

A more likely cause has surfaced: at Mark's suggestion I
took a look a the allocation attributes of the SPFTEMP0.CNTL
data set, and it had LRECL or 80 and BLKSIZE of 800. Now you
may recall that one of the symptoms was SDSF only showed my
input as 10 lines of JCL. It's possible that only one block
was being read in, then maybe an I/O error (bad block) kept
the rest of the JCL out and that one block was passed to
the Converter.

Hard to be sure, and we're running under z/VM so there's
several layers of code here.

Since the problem has gone away, I'm moving on.

----------------------------------------------------------------------

Mark Zelden

unread,
Feb 4, 2010, 11:20:38 AM2/4/10
to
On Thu, 4 Feb 2010 05:56:41 -0700, Steve Comstock <st...@TRAINERSFRIEND.COM>
wrote:

>A more likely cause has surfaced: at Mark's suggestion I


>took a look a the allocation attributes of the SPFTEMP0.CNTL
>data set, and it had LRECL or 80 and BLKSIZE of 800. Now you
>may recall that one of the symptoms was SDSF only showed my
>input as 10 lines of JCL. It's possible that only one block
>was being read in, then maybe an I/O error (bad block) kept
>the rest of the JCL out and that one block was passed to
>the Converter.
>
>Hard to be sure, and we're running under z/VM so there's
>several layers of code here.
>
>Since the problem has gone away, I'm moving on.
>

You may want to update your ISPF configuration table with values
similar to these:

ISPCTL0_BLOCK_SIZE = 27920
ISPCTL0_PRIMARY_QUANTITY = 30
ISPCTL0_SECONDARY_QUANTITY = 300


--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------

Tony B.

unread,
Feb 4, 2010, 1:16:29 PM2/4/10
to
Intriguing! Edit the JCL in hex, look for oddities in column 72.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf

Of Mark Zelden
Sent: Thursday, February 04, 2010 10:19 AM
To: IBM-...@bama.ua.edu
Subject: Re: Strange JCL error

Paul Gilmartin

unread,
Feb 4, 2010, 2:18:59 PM2/4/10
to
On Thu, 4 Feb 2010 10:19:24 -0600, Mark Zelden wrote:
>
>You may want to update your ISPF configuration table with values
>similar to these:
>
>ISPCTL0_BLOCK_SIZE = 27920
>ISPCTL0_PRIMARY_QUANTITY = 30
>ISPCTL0_SECONDARY_QUANTITY = 300
>
Not BLOCK_SIZE=0? (Anything else is _so_ 20th-century!)

-- gil

Bruno Sugliani

unread,
Feb 4, 2010, 2:26:44 PM2/4/10
to
On Thu, 4 Feb 2010 12:16:32 -0600, Tony B. <tbab...@COMCAST.NET> wrote:

>Intriguing! Edit the JCL in hex, look for oddities in column 72.
>

Or binary zeroes instead of x'40' ?

Bruno Sugliani
zxnetconsult(at)free(dot)fr

Mark Zelden

unread,
Feb 4, 2010, 2:29:54 PM2/4/10
to
On Thu, 4 Feb 2010 13:18:28 -0600, Paul Gilmartin <PaulGB...@AIM.COM> wrote:

>On Thu, 4 Feb 2010 10:19:24 -0600, Mark Zelden wrote:
>>
>>You may want to update your ISPF configuration table with values
>>similar to these:
>>
>>ISPCTL0_BLOCK_SIZE = 27920
>>ISPCTL0_PRIMARY_QUANTITY = 30
>>ISPCTL0_SECONDARY_QUANTITY = 300
>>
>Not BLOCK_SIZE=0? (Anything else is _so_ 20th-century!)
>

Not sure... maybe zero wasn't supported at some point or the old
assembled version which eventually because the keyword driven
table. But your point is well taken.

Mark


--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------

Bob Rutledge

unread,
Feb 4, 2010, 3:09:27 PM2/4/10
to
Mark Zelden wrote:
> On Thu, 4 Feb 2010 13:18:28 -0600, Paul Gilmartin <PaulGB...@AIM.COM> wrote:
>
>> On Thu, 4 Feb 2010 10:19:24 -0600, Mark Zelden wrote:
>>> You may want to update your ISPF configuration table with values
>>> similar to these:
>>>
>>> ISPCTL0_BLOCK_SIZE = 27920
>>> ISPCTL0_PRIMARY_QUANTITY = 30
>>> ISPCTL0_SECONDARY_QUANTITY = 300
>>>
>> Not BLOCK_SIZE=0? (Anything else is _so_ 20th-century!)
>>
>
> Not sure... maybe zero wasn't supported at some point or the old
> assembled version which eventually because the keyword driven
> table. But your point is well taken.
>
> Mark

Or an artifact from an encounter with OA09618?

Bob

Pommier, Rex R.

unread,
Feb 5, 2010, 10:16:50 AM2/5/10
to
John,

You nailed it! Thanks. I'm not sure what changed between my 1.7 system
and my 1.10 system, but the DNS entries in our wintel-based nameservers
have such arcane names as "techlpar" pointing to the IP address of - you
guessed it - the tech LPAR. I had my wintel counterpart add the SMF
name of the tech LPAR (WSCU) as an alias in DNS and it started working.


Come to think of it, I'm not sure why it actually IS working under 1.7!

Thanks again - this list has helped save what few non-gray hairs I have
left! :-)

Rex

Pommier, Rex R.

unread,
Feb 5, 2010, 10:33:21 AM2/5/10
to
Alan,

Yeah, I knew the problem was in this exit. I had just grabbed the exit
source that I have running on my 1.7 system and installed it on 1.10. I
first noticed the TCB time problem when I was putting the e-mail
together asking for help with sendmail.

A simple pull of the latest sample code from samplib fixed the problem
for me. However, that does bring forth a curiosity question. IBM has
(at least) 2 IEFACTRT exit routines in samplib. The one I am using is
member ieeactrt. There is another sample in member smfexits. I grabbed
this one first and the linkedit failed with unknown external references.
It was/is looking for "TSMFWTM" and "IEFYS". Any idea what these
modules are? A quick google search tells me that IEFYS is supposed to
be in SYS1.AOSB3, but it ain't there.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On

Behalf Of Field, Alan C.
Sent: Wednesday, February 03, 2010 4:02 PM
To: IBM-...@bama.ua.edu

Barry Merrill

unread,
Feb 5, 2010, 11:02:04 AM2/5/10
to
APAR Identifier ...... OA31624 Last Changed ........ 10/01/26
Z/OS 1.11 IEFACTRT EXIT IN SYS1.SAMPLIB HAS A FIELD FOR THE
TOTAL SERVICE UNITS THAT IS USING SMF30SRB_L

Symptom ...... IN INCORROUT Status ........... OPEN
Severity ................... 3 Date Closed .........
Component .......... 5752SC100 Duplicate of ........
Reported Release ......... 760 Fixed Release ............
Component Name SMF SCHEDULER Special Notice
Current Target Date ..10/02/26 Flags
SCP ...................
Platform ............

Status Detail: REVIEW - APAR solution is being reviewed.

PE PTF List:

PTF List:


Parent APAR:
Child APAR list:


ERROR DESCRIPTION:
At z/OS 1.11 HBB7760 the IEFACTRT exit in SYS1.SAMPLIB uses the
field that gets displayed in the job log (total srvc units) and
it is using the new SMF30SRB_L field instead of the SMF30SRV_L
field for total SU.


LOCAL FIX:
Reassemble the exit and change the label under the
GET INFORMATION FROM PERFORMANCE SECTION
from
LG R01,SMF30SRB_L GET SERVICE UNITS USED
to
LG R01,SMF30SRV_L GET SERVICE UNITS USED

Shmuel Metz , Seymour J.

unread,
Feb 8, 2010, 12:20:06 PM2/8/10
to
In <745658B07912254E8D4B...@surfsd21.cnasurety.net>, on
02/05/2010

at 09:32 AM, "Pommier, Rex R." <Rex.P...@CNASURETY.COM> said:

>It was/is looking for "TSMFWTM" and "IEFYS".

Wow! A blast from the past. IEFYS is the old message writer from early
OS/360 days. AFAIK it's still around; you should be able to locate it on
one of the DLIB datasets. I'm surprised that anybody is still using it.

>A quick google search tells me that IEFYS is supposed to
>be in SYS1.AOSB3, but it ain't there.

SMP/E should tell you where it is, if it still exists.

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

0 new messages