Alan, Using LOADMOD with ORIGIN is just an old habit to simplify debugging of a relocatable CMS module. Easier to calc addresses/offsets of entry points from a loadmap and reuse PER TRACE commands and address ranges multiple times.
The Operation Exception occurs just running this relocatable CMS program in whatever address space to gets loaded into. It runs fine sometimes, and other times it fails repeatedly. Segments of the module are not getting loaded into storage which is very strange. PER STORE INTO the missing address range of code, followed by the LOADMOD cmd never triggers either. This is a test environment with multiple VM LPARs and releases. I just noticed that this LPAR, which is running V4 R4.0, is taking daily PRG004 CP abends as well. There is a larger issue that is making the system unstable. This system is at a remote location and I have limited access to it, so I am going to let those folks who own this test system deal with the issue. I suspect that there is a DASD sharing/Page space/Cache issue of some kind. Regards, Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, November 27, 2008 9:58 AM To: [email protected] Subject: Re: CMS module doesn't get loaded completely on CMS level 20 On Wednesday, 11/26/2008 at 09:12 EST, Mike Rydberg <[EMAIL PROTECTED]> wrote: > I have a CMS module that when loaded on CMS level 20 is missing a large chunk > of code for some reason. Executable code is missing beyond offset 4D4B0 and > the program gets an operation exception branching to zeros. > > When loaded on CMS level 22 it runs fine. It also runs fine on earlier versions > of CMS as far back as CMS level 15. The program hasn?t been recompiled in > several years. > > To debug the problem I used the loadmod and progmap commands. I then displayed > the routines entry point at offset 4D4B0 (6D4B0?base 20000) > > CMS level 22 has executable code at this offset, CMS 20 does not, at least not > today anyway. It has run on CMS 20 in the past and the problem seems to be > intermittent. > > Anyone know of a bug of this type on VM 4.4.0 CMS 20? I've never heard of it and there's nothing relevant I can see in the problem tracking system. Mike D. may know something. (ORIGIN has been on LOADMOD since VM/ESA 2.0.) If you do a "STORMAP 20000-70000" prior to your LOADMOD, does it show all of the range is unallocated? If you just let the program load wherever it wants (no ORIGIN), is the code at origin+4D4B0 there? Also try this: IPL CMS PARM NOSPROF INSTSEG NO ACCESS (NOPROF ACCESS the disk with the MODULE LOADMOD .. DISPLAY .. This ensures that there isn't a rogue nucleus extension or other program running about. Alan Altmark z/VM Development IBM Endicott
