× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



If the problem happens in Run SQL Scripts as well as the program, then the issue is not an RPG issue. FWiW the MCH0601 is a generic /machine exception/ which has little meaning without its context; i.e. the program & instruction to which it is sent, and often the program and instruction that signaled the exception. The message text suggests the error was probably addressing storage within the runtime cursor. If the problem can be so easily recreated, especially if using a new CREATE TABLE as the target of the insert, then there is likely a PTF... or this problem reported will almost surely be origin for issue of such a PTF. However to know if the problem is already known, the details of the failure [there may be some specific diagnostics preceding the MCH0601 of interest] which identify the symptom string as a match for a known problem. Note: The mch0601 error defaults to dump some data [if unmonitored] in a QPSRVDMP and issue a DSPJOB [which includes a program stack], which provides more context for the failure.

The SQL supports mapping between the P(11,2) and P(9,2) given all of the data does not cause an overflow, if null capabilities are compatible, if using OVERRIDING SYSTEM VALUES if the column is an IDENTITY, and all values meet any uniqueness and referential & check constraints. Thus generally there should be no errors in a request with that mapping\casting. There really should be no MCH0601 in OS database\SQL code regardless; undiagnosed in quoted text, so it may be user code. There is however one consideration beyond those for normal mapping, and that is for use of an INSERT trigger. Coded incorrectly, an external trigger could cause difficulties. FWiW there is also one possible issue where mapping may be limited; i.e. for existence of any temporary indexes over the column which impose mapping restrictions, but that is probably unrelated here.

Regards, Chuck

MattLavinder wrote:
Receiving the following message when embedded SQL statement runs in RPG (using execute immediate):

MCH0601 - Space offset X'00101400' or X'0000000000000000' is outside current limit for object FUNDDNRP DMIGPLS C00J75D.

This error actually occurs during the SQL Statement according
to the program dump that is created. Statement is performing
an INSERT INTO. Have tested this query in Run SQL Scripts.
Statement runs fine without the INSERT INTO. When I add in the
INSERT INTO, Run SQL Scripts receives the exact same error.
Have checked that values being selected and all should fit in
target file. Verified that no null values are in results.
This particular program has been running fine but failed last
night. A PTF for SQL was applied over the weekend, but not
sure why it would only affect this particular program.

Running V5R4.


After sending the email , I actually found something on Google that gave me an idea. As opposed to doing my INSERT INTO, I did a CREATE TABLE AS (sql statement) WITH DATA. The resulting table
had one field that was different from my destination file.
There was one destination field defined as decimal(11,2) while
the source field was defined decimal(9,2). When I modified the
query to manually convert the source field to decimal(11,2), the
query started working.

This has me confused. I could see this being a problem if the source field was larger than the destination, but it seems that SQL should handle moving a smaller field into a larger one. I have never seen this problem before and this program has been running in its current form since (at least) March 2007. I am confused as to why the issue suddenly popped up this morning.

Anyone aware of a recent PTF that would likely trigger this problem? Maybe this should have come up a long time ago and I've
just been lucky for nearly 3 years. Seems hard to imagine..

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.