Version Upgrade-now getting maching error
5722SS1 V5R4M0 060210 AS/400 DUMP 201617/ESANTI
DUMP TAKEN FOR UNMONITORED ESCAPE MESSAGE
.MESSAGE ID- MCH0601
.MESSAGE FILE- QCPFMSG LIBRARY- *LIBL
.SEVERITY- 40
.MSGTYPE- 0F
.SENDING-
..PROGRAM- QDMCLOSE
LIBRARY- QSYS
..INSTRUCTION- 015A
.RECEIVING-
..PROGRAM- QDMCLOSE LIBRARY- QSYS
..INSTRUCTION- 015A
.MESSAGE-
Space offset X'0000F330' or X'0000000000000000' is outside current limit for MSTCOMP DATALIB MSTCOMP
.MESSAGE DATA- and there are pointers after this. Let me know if you need them.
We did a version upgrade over the weekend and now certain programs go into joblog loop and keep issuing this error. MCH0601. 2 of the programs are old S/38 RPG III programs but 1 is RPGLE program.
Any suggestions?
Software/Hardware used:
Software/Hardware used:
ASKED:
August 12, 2008 1:43 PM
UPDATED:
August 14, 2008 2:30 PM
Answer Wiki:
Hi Martin
It is related to 1 specific file MSTCOMP. This is a logical view of a component master. I checked the object description and it does not show damaged. Yesterday the system went into a job log loop that took us 2 1/2 hrs to kill the job. We can not IPL during the week as our 400 supports several sites in different countries. We created a different logical and changed 2 of the older RPGIII pgms to use the new file and they seem to be OK now. We are using committment control over MSTCOMP in the ILE program.
I appreciate your help. Direct email is reevesd@randacorp.com. Thanks-Doe
To see all answers submitted to the Answer Wiki: View Answer History.
Yes-all PTF’s that came with the update were applied. Do you know of a specific PTF for this error?
Hi,
Just wanted to check that you were up to date on PTF’s – sometimes the bare release without any fixes has problems.
Can you check whether your program and/or file is not marked as damaged? You should be able to use DSPOBJD to check this.
Do you get any other messages in your joblog before you get the MCH0601?
Regards,
Martin.
Not always, but often this message is due to mis-matching parameters. Check that all PARMS match in calling and called programs. If you are calling IBM API’s, you might also find that the API has new or changed parameters,
Hi,
Can you try running a query on this file to see whether that gives you any errors? You could also try running the query in debug mode using STRDBG first.
Regards,
Martin Gilbert.
Hi,
If this is a logical you should also check the physical to see whether that’s damaged.
I would suggest taking a copy of the file, re-creating it and copying the data back if this is possible.
Regards,
Martin.
No API’s applied in this program.
This is a logical over 5 physicals (very old S/38 files)
There may be a limit to the number of physicals and we don’t have many other very old S/38 type files.
I will look at each physical and see if query blows up.
Thanks again-Doe
I have seen this error come up when SQL tries to use a DDS-based logical file, but I have not seen it before in a non-SQL context. It may be some difference in the tree structure of the logical, between old and new versions of logicals, that only manifests itself when the index exceeds a particular size?
Martin’s idea of recreating the file is sound. Create the physicals from the DDS source in a new library, and create the logicals from the DDS source over them, and populate the physicals from the ‘real’ files using CPYF. Then test your programs over the new files.
If you don’t have DDS source, you can get enough information to create it from the file and file/field descriptions.
Doing it from source means that you won’t be just copying the problem from the originals, which would be the case if you used CRTDUPOBJ or CPYF CRTFILE(*YES).
Regards,
Sloopy
Late yesterday we were able to create a 3 line pgm that will trigger the MCH0601 error every time.
Just a SETLL and then SETON *LR on the logical will cause it.
With IBM level 2 assistance-they determined that V5R4 upgrade touches all file header info and that a multi physical logical file with *NONE as one of the keys to a physical gets corrupted during the upgrade process. The machine error is triggered during the close of the file. IBM is currently adding a PTF to the version upgrade so future release upgrades will not create this problem. We have recreated the logical and seem to have ended the MCH0601 error.
I want to thank each of you for the suggestions and assistance. It is nice to know the AS/400 community has a resource to discuss these types of situations and all the “big brains” are willing to help.
Thanks Again! Doe