Re: What goes where?

Responses inline

On 6/30/2010 3:29 AM, David FOXWELL wrote:

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de rob@xxxxxxxxx
Objet : Re: CPYSRCF SRCCHGDATE

Do what we do. Don't keep source on your production lpar.

Hey I've been thinking this over from time to time and I'm a wonderin':

Where then do you keep your production source?

Not everyone has separate LPARs for development and production. If you DO have a separate development LPAR, put source there - there's no reason to put it on the production LPAR - see debugging response below.

What do you actually push on to the prod lpar? Just objects? What about modules?

Again, modules don't belong on the production LPAR - we never distribute modules with our products, same thing for you. They do absolutely nothing except take up space. If you need to change something in a module, then create it, use a SAVF or SAVRSTOBJ to get it to the production LPAR, and use UPDPGM. Then remove that module from the production LPAR. Of course, that might be getting around your deployment process, so consider it an emergency technique.

What's the point of DSPOBJD to get the source member used to create the object? Can it be easily found?

For OPM *PGMs, DSPPGM shows the source on the first page. For ILE *PGMs, the source is in the *MODULE detail of DSPPGM (put a 5 on the module listed and see the DSPMOD output, where the source is given). You can't have source for an ILE *PGM, since it might be linked from several modules.

For other objects, the *SERVICE option of DSPOBJD can give you the source. I think there are some object types that require you to go here, but I forget which ones.

Aren't there any issues with debugging? Aren't the source files needed?

Source files are NOT needed to debug, if you pick the right debugging view for ILE and option for OPM. Basically you only need the listing, which can be selected on its own or is included in the *ALL options (*SOURCE for SQL programs). The drawback of using a listing is that it is included in the object, therefore, the program object is larger.

Take a look at the help text for DBGVIEW on, say, CRTBNDRPG or CRTRPGMOD for more explanation. For CRTRPGPGM (OPM program) you should look at the help for whatever parameter has *SRCDBG and *LSTDBG as values. I think it's either GENOPT or OPTION.

Any more fors and againsts for separating source and objects in this way?

If you don't have a separate development LPAR, be sure to put security blocks on the source, so that casual users can't go in and change anything. And maybe have some control of what developers CAN see - maybe lock out all production source and have a secure person who can make a copy into a developer's library for working on it.

Some source could contain private or confidential information, even passwords to other systems, so lock them down even further to only certain developers.

Huge topic - lots of possibilities for different opinions, of course.

Thanks.