Tweet
Separate source and object libraries may be holdovers from a mainframe system, or even a S/36 system. Dave
-
-
Seperate Library for Source and Objects
Whether the software vendor sells source with the objects or not, as far as I remember working for several vendors is that the source is stored in separate libraries and would ship that way. Business often uses the same model as the primary software vendor for their business. I have never seen source stored with objects, but I haven't worked for small shops. Only in my personal library do I let the default of compile to the same library take place. I'm not much of an admin type person and there is always some system in place whereever I've been, but I can't imagine storing source with production objects on any computer (different directories, etc.) I just can't recall seeing source in the same library or directory with executables very often in Windows as well, or can imagine that if Windows were shipped with source the source for Windows/System executables would be in Windows/System, for example. On authority administered systems such as the AS/400, most would have different authority profiles for production executables from source physical files that would be much easier to administer in separate libraries. I guess that and the basis from software vendors of separating the two are the main reasons. rd -
Seperate Library for Source and Objects
As a SCM vendor with over 4000 installations, we have seen just about every possible configuration for every possible reason. Reasons for keeping them separate: * Because that's they way they've always been, so why change it? * To facilitate backups, e.g. we back up source more often, we store those tapes differently, etc. * To facilitate security. This is especially prevalent now in the age of increased auditing. While public must have at least read access to production objects, most best practice standards are calling for zero to little access of production source, even by the developers! This is only possible, of course, if you implement a solid SCM system that manages the access (check in, check out). With this solution, only the tool has access to the source code, and it tightly manages (and documents) who has used the tool to alter the code. The bottom line in this mode: if you are a developer and want access to the code, the only way for you to get it is through the managed tool. Reasons for keeping them together: * Because that's the way they've always been, so why change it? * Just one library to backup One other thought just came to mind that I'm not completely sure about, perhaps others in the community could address it...What happens if your source code library is in one ASP and your production objects library is in another? Will the compiler be able to handle that?Comment
-
Seperate Library for Source and Objects
The reason we do it at my company is because all development takes place in a seperate lpar - called development. There is no source code in production and the programming staff has no authority in the real world (stupid Sarbanes-Oxley). If the source was in the same library with the objects it would get wiped out when a refresh of the development library was done, unless you were very careful. Seperating the source code also allows me to run nightly backups on the source only libraries in development and not worry about filling my tapes with needless data. SteveComment
-
Seperate Library for Source and Objects
yeah, I was thinking more historically. I guess Sarbanes-Oxley says it all, doesn't it, Steve. rdComment
-
Seperate Library for Source and Objects
I'm thankful I work for a private company! chuck Opinions expressed are not necessarily those of my employer. "Ralph Daugherty"Comment
-
Seperate Library for Source and Objects
Hello, I just wondered what people's views are on this. Having used PDM extensively, and not seeing any obvious benefits of doing otherwise, I have always put source and objects in the same library. When I have worked for Software Vendors, we simply shipped libraries without the source files. The last 3 employers I've had are all using seperate Source Libraries and Object libraries, but nobody seems to know why. Are there any benefits to either way of doing things? Laters MattComment
-
Seperate Library for Source and Objects
As systems get larger, the benefits of segregating (read as "classifying") things increase. So if your application is small, then maybe you want to keep everything together in a single library. However there's a nebulous dividing line beyond which it's better to add more structure. Here's one simple benefit to keeping source separate: Where is, exactly, the source code? It's a question experienced developers usually know well, but what about new developers, or customers, who may not know the system intimately? In PDM, the 100% way of finding out is to filter for files with a type of "PF-SRC". This is one common way of finding those source files when everything is mixed together. However, in an enterprise class product with thousands of objects in a library, running the filter can take a minute or more. It's a small but telling detail that displays professionalism and maturity. Here's another. Perhaps you don't ship source code to customers, or only to certain customers. Perhaps as a developer you want to keep your options open according to what the marketing folks come up with. There is value in having flexibility built in. Also, by keeping the source code completely separate, you lessen the chance of making mistakes. I would suggest that sending source code to a customer that isn't supposed to have it is a bigger mistake than the opposite. If you forget to send source code to a customer that needs it, that can easily be corrected. However just try to recall source code from a customer not licensed for it! My experience tells me to segregate the code. There's little to no downside. Remember, systems never get smaller and simpler.Comment
Comment