I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
How are you cataloging your subroutine?
Last auto-saved at: 07-28-2025 15:37
+1I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
Do you have multiple cataloged instances of different versions?
Regards
JJ
+1I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
Gary,
Each time I have coma across this error it has almost always been due to picking up one of:
LOGTO can be a culprit if you have different COMMON either in legacy accounts or test accounts.
On very rare occasions there could be some sort of memory corruption, though this would be a strange manifestation even of that were the case. A global recompile/strip catalogs and recatalog would not hurt, Make sure you get them ALL,,,
Regards
JJ
I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
I've occasionally experienced the same behavior. It's rare, but it happens. And it's maddeningly frustrating when it does. As I recall, the systems where I experienced such behavior had permissions issues. It seems Rocket has a hard time nailing the permissions issue down to the point where they can create an admin tool that automatically configures the system for proper operation. For example, a shop I support was having problems with files changing ownership and/or permissions in a way that they couldn't chase down. Users would suddenly be unable to do things they'd done only a minute earlier. So they set up a cron job to set the application's entire directory to app:users 777 every minute of every day, and nothing I could say would get them to let me fix it.
I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
Without knowing the details, I'd hazard a guess that at some point in the phantom process chain, maybe a subroutine/sub program gets called in rare conditions that has a different common size and fubars common for that phantom process. Possibly something that wasn't recompiled last time common was changed.
You could write/run a utility to VLIST all your object code and capture the common size for each (it's in the VLIST header section) that is being called to find any anomalies.
Also you could add some logging to the phantom processes and program to see the port, user, call stack/system(9001) and any other info that may help you determine how and when the problem gets triggered.
Stu.
I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
Thanks for the information. I started logging some data last night in hopes of getting the transactions that lead up to the moment/transaction that actually killed the process but is has not happened since, of course. I am going to take some other steps that you all mentioned.
I have a subroutine that is compiled and cataloged. It gets call by some phantom processes. Periodically a phantom process dies because it cannot load the subroutine. What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Update to the original post:
I have found the error for a common size mismatch but I am not sure why because it will run for hours processing many records without an issue.
What else can prevent universe from loading the subroutine besides not being compiled and cataloged?
Possibly an input timeout or terminal paging "Press any key to continue...", or a menu if using a >LOGTO.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
