|
View previous topic :: View next topic
|
| Author |
Message |
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
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
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? 
Any pointers gratefully recieved,
Daniel. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
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  |
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 
Daniel. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Show the JCL that you are using. The error may well lie there. |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
DECB=X'4100000000800000 '
just a thought : x'41' = 65 by coincidence the old length ?
so somehow somewhere 65 comes up. |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
| 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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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  |
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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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
|
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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 
Thanks,
Dan. |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
| 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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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.
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 |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| 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
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 .
Thanks to those of you who helped  and I hope this thread might provide an insight to others who experience similar difficulties.
Dan. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
Can you show us your LOAD control card?
You mentioned that a column was added to the table in environment A and then the table was unloaded. Was the column added to the table in environment B? If not, then you have to code your LOAD control card carefully. |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| don.leahy wrote: |
Can you show us your LOAD control card?
You mentioned that a column was added to the table in environment A and then the table was unloaded. Was the column added to the table in environment B? If not, then you have to code your LOAD control card carefully. |
Don, the problem has been resolved now - thanks anyway.
Daniel |
|
| Back to top |
|
|
ederrod
New User
Joined: 06 Jun 2005
Posts: 5
Location: Sao Paulo - Brazil
|
|
|
|
Hi Daniel,
I have the same problem. In my case, the record length has been changed from 200 to 201 bytes.
What have you done to solve the problem?
Thanks!
Eder |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Just scroll upwards from your message for the penultimate one from the TS. That's all they know... |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
Ederrod,
I'm not sure if your problem is similar but for us we just TERMinatedthe utility.
Good luck
Dan |
|
| Back to top |
|
|
|
|
