Going back many many years I spent a lot of time with IMS/360 on MVT/MFT. The DL/1 database system is essentially ISAM; the channel? end appendages logic that you refer to relates to a part of DL/1 called OSAM - the Overflow Sequential Access Method - used by IMS to maintain data segments that have been inserted into a running DL/1(ISAM) database. Such insertions could optionally be stored in an additional dataset labelled OVFLOW in the JCL (in the latest IMS/VS version, OSAM is still there, but the allocation protocol in the JCL is completely different).
I have never used IMS/360 under MVS, but I can confirm that IMS/360 worked fine on SVS. I never had to run it V=R or anything like that. Presumably the OSAM stuff was not a problem on SVS. It sounds like the consensus is that it could be an issue on MVS.
So my suggestion would be to try to avoid OSAM under MVS.
I would suggest using the ISAM-VSAM bridge (AMP='AMORG') instead of an ISAM/OSAM database. So you would define the database as a VSAM dataspace and run IMS/360 against that. Hopefully VSAM would handle all the I/O without having to worry about the OSAM channel end appendages stuff when data segments are inserted.
Just a suggestion. I would love to have a go at getting IMS/360 running again, but I just don't have the time at the moment.
If you have an opportunity to try this, I be very interested to hear how you get on.
JJ
