Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

04E - 00E40071
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DB2
View previous topic :: :: View next topic  
Author Message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 3:20 pm    Post subject: 04E - 00E40071
Reply with quote

Dear All,

whilst executing a LOAD to a table I recieve the 04E abend code, with the accompanying messages. N.B. This LOAD had previously failed because the wrong input dataset was being used.

Code:
DSNU032E   I/O ERROR ON WORKFILE        ,PWWKLDH3,STEP03  ,A7C4,D,SYSREC00,READ ,WRNG.LEN.RECORD,00000060000000,BSAM
DSNU040I    DSNUGSDA - ERROR ACCESSING DDNAME SYSREC00, DECB=X'4100000000800000 0001C76181A105000001CD3E0' 


Now the last column descriptor in my SYSP is

Code:
MYCOLUMN  POSITION( 66) CHAR( 2)


The input data is in a FB dataset of LRECL 67. (this has increaded from 65 due to MYCOLUMN being new.)

I have read the manuals for messages 04E, DNSU032E, DSNU040I however I am at a loss to find the problem. The only thing I can find is that maybe the previous utility was still active, however I don't see why it would still give me the
Quote:
WRNG.LEN.RECORD
error. I don't have access to see if the utility was running.

The input data is of the correct length, I have tripple checked the correct input DS is being used.

Does anyone have any idea where the problem might be? icon_redface.gif

Any pointers gratefully recieved,

Daniel.
Back to top
View user's profile Send private message

enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10203
Location: italy

PostPosted: Fri Apr 15, 2011 3:42 pm    Post subject: Reply to: 04E - 00E40071
Reply with quote

here is the link to the relevant manual pages for the 00E40071 reason code
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2z9.doc.codes/src/tpc/00e40071.htm

Quote:
The input data is of the correct length, I have tripple checked the correct input DS is being used.


that' s not what the system thinks

Quote:
SYSREC00,READ ,WRNG.LEN.RECORD,00000060000000,BSAM


I tend to trust more the system point of view than Yours icon_biggrin.gif
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 3:52 pm    Post subject: Re: Reply to: 04E - 00E40071
Reply with quote

Enrico,

thanks for the quick response - as I mentioned I have read the relevent portions of the manuls.

Quote:
I tend to trust more the system point of view than Yours icon_biggrin.gif


icon_confused.gif

I completely understand the system is undoubtedly right it's diff for me to see why. I shall look again and if/when I get to the bottom of this I'll post it back icon_eek.gif

Daniel.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Fri Apr 15, 2011 4:32 pm    Post subject:
Reply with quote

Show the JCL that you are using. The error may well lie there.
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 4:36 pm    Post subject:
Reply with quote

Akatsukami wrote:
Show the JCL that you are using. The error may well lie there.


The JCL has been in production for a long long time already, we added a column to the table in environment A, unloaded it, FTP'd the file to environment B and performed the LOAD with the new file and descriptor.

I really don't think it's a JCL issue. We will FTP the file again and see if that helps.

Thanks.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Apr 15, 2011 4:49 pm    Post subject:
Reply with quote

Quote:
The input data is of the correct length, I have tripple checked the correct input DS is being used.
When you say "correct length" here -- how did you determine that? The system has determined that the record length needed is NOT what you are providing, so you have two choices: (1) keep saying the record length is correct, in which case the system will keep telling you there is a wrong length record, or (2) accept that there is a length problem somewhere, find it, and fix it.

Quote:
The JCL has been in production for a long long time already, we added a column to the table in environment A,
Adding a column means -- obviously -- that the JCL being in production a long time is completely and totally irrelevant now. The environment changed (a column was added), so the fact the JCL ran last (year, week, month) with the old definition does not mean it will work today with the new definition.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Apr 15, 2011 4:50 pm    Post subject:
Reply with quote

TGIF.

I work with a bunch of thick-heads like this.

you are pointing at the correct load file?
are you pointing at the correct sysrec? (file description?)
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 5:02 pm    Post subject:
Reply with quote

Robert Sample wrote:
When you say "correct length" here -- how did you determine that?


By looking at the file definition, FB, LRECL 67. I can inspect the file contents and there are indeed 67 characters in every record.

Quote:
Adding a column means -- obviously -- that the JCL being in production a long time is completely and totally irrelevant now.


I would argue that it's not totally irrelevent, though I appreciate your point. The JCL has not changed, the contents of the SYSP has changed with the new column, and the table definition has changed.

Quote:
The environment changed (a column was added), so the fact the JCL ran last (year, week, month) with the old definition does not mean it will work today with the new definition.


Clearly :-)

Strange as it may seem I have looked carefully at the issue and was kind of hoping that someone might offer something I had not considered.

Quote:
(2) accept that there is a length problem somewhere, find it, and fix it.


This is what I am trying to do.

Thanks for your advice, like I said if I discover the issue I will let you know there's no need to me waste your time further.
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 5:10 pm    Post subject:
Reply with quote

dbzTHEdinosauer wrote:
TGIF.

I work with a bunch of thick-heads like this.

you are pointing at the correct load file?
are you pointing at the correct sysrec? (file description?)


Jeez you're not a very friendly lot here are you.

I'm not a thick-head thank you very much, you should keep your consescending attitude to yourself.

YES I am pointing to the correct load file.
YES I am pointing to the correct SYSREC.

But you only have my word for that.

I can appreciate you immediately think that my first thought was to post a message here and someone else to solve the problem, but that is not the case.

I guess I shouldn't have bothered posting here.

I was hoping for more than RTFM which I had already done.

Please don't feel the need to waste your and my time with this issue. (Unless of course you're having a slow friday and need to insult people you don't even know)
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Apr 15, 2011 5:39 pm    Post subject:
Reply with quote

Quote:
By looking at the file definition, FB, LRECL 67
Either you are looking at the wrong file (not the WORKFILE DD name), or 67 is not the right record length -- as the system tells you.
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 5:49 pm    Post subject:
Reply with quote

Robert Sample wrote:
Quote:
By looking at the file definition, FB, LRECL 67
Either you are looking at the wrong file (not the WORKFILE DD name), or 67 is not the right record length -- as the system tells you.


I know it's hard to believe.

But I am looking at the:
Right Job
Right step
Correct DD - SYSREC00

And when I look at the DS Info it really does give :

Organization . . . : PS
Record format . . . : FB
Record length . . . : 67
Block size . . . . : 27939

icon_confused.gif

I do really appreciate your time and effort thanks, either...

1) I really am a thick head and cannot read what is in front of my nose.
2) Something else is going on and the error msg is misleading.

Either way I'll be sure to let you know.

thanks again

Dan.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Apr 15, 2011 5:57 pm    Post subject:
Reply with quote

Quote:
Organization . . . : PS
Record format . . . : FB
Record length . . . : 67
Block size . . . . : 27939
I have no doubt that this is the file specification.
HOWEVER, THE SYSTEM IS TELLING YOU THESE PARAMETERS ARE NOT RIGHT.
Whether or not you agree, whether or not you like it, whether or not you think they are right -- the SYSTEM is tellig you no, 67 is not the record length it is looking for.

I think your best bet would be to work with your DBA or other site support people to look into the cause and resolution of the issue. You persist in doing nothing but telling us the same thing over and over -- and the system has already told you that what you tell us is wrong.
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1278
Location: Belgium

PostPosted: Fri Apr 15, 2011 6:09 pm    Post subject:
Reply with quote

DECB=X'4100000000800000 '

just a thought : x'41' = 65 by coincidence the old length ?
so somehow somewhere 65 comes up.
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1278
Location: Belgium

PostPosted: Fri Apr 15, 2011 6:30 pm    Post subject:
Reply with quote

Quote:
I don't have access to see if the utility was running

I would defenitely try or get someone to try DB2 command :
-dis util(*)

and if necessary -term util(xxx)
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 6:43 pm    Post subject:
Reply with quote

Robert Sample wrote:
Quote:
Organization . . . : PS
Record format . . . : FB
Record length . . . : 67
Block size . . . . : 27939
I have no doubt that this is the file specification.
HOWEVER, THE SYSTEM IS TELLING YOU THESE PARAMETERS ARE NOT RIGHT.
Whether or not you agree, whether or not you like it, whether or not you think they are right -- the SYSTEM is tellig you no, 67 is not the record length it is looking for.

I think your best bet would be to work with your DBA or other site support people to look into the cause and resolution of the issue. You persist in doing nothing but telling us the same thing over and over -- and the system has already told you that what you tell us is wrong.



As in
Quote:
...these are not the droids you're looking for icon_rolleyes.gif


I know the system is telling me it doesn't like the length of the record I can read - my problem is I don't understand why it doesn't like the 67 RECL.

There really is no need to shout, I have been kindly telling you for a while now not to waste your time.

I am only telling you the same thing over and over again beacuse you are asking the same question over and over again.

sigh...
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 6:45 pm    Post subject:
Reply with quote

GuyC wrote:
DECB=X'4100000000800000 '

just a thought : x'41' = 65 by coincidence the old length ?
so somehow somewhere 65 comes up.


Hi Guy,

That would indeed be a remarkable coincidence :-)

I was looking at the meanings of the DECB. In the manual it states

Quote:
Explanation
An error has occurred during BSAM access of a utility temporary file identified by 'ddname'. The DECB indicating the error is given as a hexadecimal string


Quote:
Problem determination
The DECB provided contains the ECB in the first four bytes. The first byte of the ECB contains status bits that indicate the cause of the error. Refer to the appropriate MVS™ publication for the meaning of the status bits


Which makes me think that the x'41' are more for determining the reason not for conveying information as recl.

I found the following which confirms the record length error.

Quote:
Table 44. Exception Code Bits—BISAM Exception Code Bit in DECB READ WRITE Condition If On
0 X Type K Record not found
1 X X Record Length Check
2 Type KN Space not found
3 X Type K Nonvalid request
4 X X Uncorrectable I/O error
5 X X Unreachable block
6 X Overflow record
7 Type KN Duplicate record
8-15 Reserved for control program use


I am left with the RECL of the dataset being 67, and the file descriptor expecting the last field at position 66 for a length of 2.

The system is telling me it's the wrong length I know, but I can't see why it thinks it's wrong.

When the attempt to upload the old file (with a LRECL of 65) the error was reported as.

Code:
(DBP3    DSNURWI -    MYCOLUMN POSITION(66) CHAR(2))                             
(DBP3 DSNURWBG - INPUT FIELD 'MYCOLUMN' NOT ENTIRELY WITHIN INPUT RECORD       
(DBP3 DSNURWBF - (RE)LOAD PHASE STATISTICS - NUMBER OF INPUT RECORDS PROCESSED=1
  DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40323'


Thanks
icon_confused.gif
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 6:47 pm    Post subject:
Reply with quote

GuyC wrote:
Quote:
I don't have access to see if the utility was running

I would defenitely try or get someone to try DB2 command :
-dis util(*)

and if necessary -term util(xxx)


Guy,

another good idea thanks. I have been trying but you know how it is on a friday getting people to give constructive help icon_wink.gif

Thanks,

Dan.
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1278
Location: Belgium

PostPosted: Fri Apr 15, 2011 6:57 pm    Post subject:
Reply with quote

Code:
//STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DBxx)
-DISPLAY UTIL(*)
END
//SYSIN DD DUMMY
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Fri Apr 15, 2011 7:02 pm    Post subject:
Reply with quote

GuyC wrote:
Code:
//STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DBxx)
-DISPLAY UTIL(*)
END
//SYSIN DD DUMMY


Thanks Guy,

unfortunately I don't have access to the machine the abend occured on. icon_rolleyes.gif

Usually I do that kind of thing myself via DB2I - DB2 Command

the job is scheduled to run again and I've requested the guys to take a look so I hope they will and we can at the very least eliminate that as a cause.

Hope you have a great weekend,

Daniel.
Back to top
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 41
Location: Amsterdam

PostPosted: Mon Apr 18, 2011 1:31 pm    Post subject: Re: 04E - 00E40071
Reply with quote

Daniel Prosser wrote:
Dear All,

...<snip>...

I have read the manuals for messages 04E, DNSU032E, DSNU040I however I am at a loss to find the problem. The only thing I can find is that maybe the previous utility was still active, however I don't see why it would still give me the
Quote:
WRNG.LEN.RECORD
error. I don't have access to see if the utility was running.

The input data is of the correct length, I have tripple checked the correct input DS is being used.

...<snip>...



Well friday the utility was still active (though it's impossible to say from the 1st or 2nd execution) It was stopped and the job executed successfully with the SAME DATASET, LOAD CARDS and JCL ! So it would appear that if the ulility is still active then the resulting abend might be a little misleading icon_rolleyes.gif .

Thanks to those of you who helped icon_lol.gif and I hope this thread might provide an insight to others who experience similar difficulties. icon_wink.gif

Dan.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DB2 All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:



Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us