What are the pros and cons of keeping INT code
Our development server is set up to automatically keep the .INT code of compiled classes and routines, but the live servers are set to not keep the .INT code.
I know how to set the system to keep this code ($SYSTEM.OBJ.SetQualifiers() ?) but what are the ramifications of keeping this code on the live servers? Is it just a space issue? I always thought it was to keep the code more private.
I am just wondering if there's a good reason to keep, or not to keep, the INT code on live servers, since it comes in quite handy at times when needing to debug or even to see certain lines of code that received errors.
Thanks, Laura
Comments
INT code gives you the option to debug the related MAC, CLS or.. INT code. So it's for debugging purpose. And yes, it's stored in globals on disk and so needs disk space.
In addition to the reply from @Evgeny Shvarov :
INT is highly important to identify error locations.
eg. <DIVIDE>label+5^routinename refers to the location in routinename.INT
In addition to replies of Evgeny and Robert:
- source code globals (^oddDEF, ^rMAC, ^ROUTINE, ^rOBJ, etc) are usually negligibly small if compared to data globals;
- not keeping .INT does not harden privacy, as all the sources are still available as .CLS, .INC, .MAC.
Thank you all, for the comments. It sounds like there's not too much of a problem keeping the INT code. The space needed would indeed be smal compared to the space for the datasets. It doesn't increase privacy or security. Rather, it sounds more like the INT code is provided for our benefit, for debugging purposes, and is normally not saved on live systems almost out of tradition (and because who is debugging on live, eh? Well, I am, at times).
Thanks,
Laura