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
--
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.
>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
<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
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.)
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).
----------------------------------------------------------------------
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
>>>
>>
>> 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
----------------------------------------------------------------------
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.
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
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
--
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
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).
----------------------------------------------------------------------
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
Rocket Software
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 --
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 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
Same result.
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).
----------------------------------------------------------------------
I have seen this sort of error caused by a RACF issue. (The user had
changed his TSO prefix to an invalid value).
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).
----------------------------------------------------------------------
Any chance you have a "SUB" clist or REXX that's being run as an EDIT macro?
DanD
-- gil
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).
----------------------------------------------------------------------
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.
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
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.
----------------------------------------------------------------------
>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
----------------------------------------------------------------------
-----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
-- gil
>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
>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
----------------------------------------------------------------------
Or an artifact from an encounter with OA09618?
Bob
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
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
>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)