Source code in SYOBJ, a problem? (AREV Specific)
At 13 MAY 2005 11:17:04AM Michael Slack wrote:
Hello:
We are working with AREV 3.12. Is there any problem with putting the source code, object code and symbol row (*program_name) for a given program all into the SYSOBJ table? Or should the SYSOBJ only contain the object code of a program and the source and symbol rows should be stored somewhere else?Thanks,
Michael Slack
At 15 MAY 2005 01:16AM Curt Putnam wrote:
IMHO, SYSOBJ should be left pristine - as installed. There is, now & then, an argument for putting code in SYSOBJ. The strongest of these come from those who develop products for sale. I don't think that in house developers can muster a need.
At 15 MAY 2005 11:09AM Warren Auyong wrote:
Operationally I don't think there is a problem. For the sake of clutter I would just keep it object code only, however there are probably a few exceptions already.
If you need the source and symbol table for debugging purposes you can always use the "SO" and "SY" commands in the debugger to load them respectively. Syntax: SO/Y file program
At 16 MAY 2005 09:38AM Michael Slack wrote:
Hello Warren:
Thanks for the advice.Michael Slack
At 16 MAY 2005 09:40AM Michael Slack wrote:
Hello Curt:
We are not in the habit of adding to the SYSOBJ but this was one of those times where we needed to.Thanks,
Michael Slack
At 16 MAY 2005 08:59PM Warren Auyong wrote:
Actually, wasn't it recommended at one time that stuff like MFSes and User Conversion object code be placed in SYSOBJ/VERBS?
At 17 MAY 2005 10:06AM support@sprezzatura.com wrote:
Might have been recommended, but it would have been a bad idea.
I'm reasonably sure that the system checks VOC first the SYSOBJ (or VERBS) later if there's not a VOC record, so it would be one read slower.
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft
At 17 MAY 2005 10:10AM Matt Sorrell wrote:
I actually get to disagree with Sprezz here.
At least in ARev 3.02, SYSOBJ is checked first. I know this because I updated a program, recompiled, called SETPROGRAM, and the new version would not execute, even after logging out and back in.
The issue? There was a copy in SYSOBJ as well. Once I updated the copy in SYSOBJ (or removed it, tried both things) the new version started executing.
msorrel@greyhound.com
At 18 MAY 2005 09:57AM Michael Slack wrote:
Hello:
From my reading of the manuals and my experience, I believe it's the other way around. That the system will check SYSOBJ first, if it doesn't find the program that it's looking for then it'll check VOC.I've think I've learned this the hard way by having the same program in SYSOBJ and in a BP table (cataloged). This is a rare event. I modify the program in the BP table and recompile. Then I run the program and the modifiecaton didn't take. I go back and see the modification is in the code and correct. I usually have to go round and round before I think to look in SYSOBJ for the object code.Michael Slack
At 18 MAY 2005 10:02AM support@sprezzatura.com wrote:
The system will check SYSOBJ first.
The errant droid has been reprogrammed.
Normal service has resumed….
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft
At 18 MAY 2005 10:46PM Warren Auyong wrote:
Right, I thought the idea was that programs need not be cataloged to execute out of SYSOBJ and since the VOC file can be attached on different volumes a cataloged program may not be available in a timely manner during the login/startup process. Could be critical for some MFSes.
At 19 MAY 2005 12:47AM dsig _at_ sigafoos.org wrote:
i believe you are quite right michael .. that is why modifying and mfs, compiling and .. poof .. nothing happens .. oh my it is in the sysobj
been there .. done that ..
how are things on the Ice?
At 20 MAY 2005 09:58AM Michael Slack wrote:
From my tiny cubical, the snippets of what I can hear, things on the Ice are going well. I'm wishing I was there.
Michael Slack