Where then do you keep your production source?
Let's pretend your Production lpar has a library for programs, printer
files and that ilk called PRDLIBO. And for data files, data queues and
other volatile data called PRDLIBF. Production lpar will have no PRDLIBS
(for source). Now your development lpar will have a mirror of this. In
addition it will also have PRDLIBS for source. It will also have a
library call PRDLIBT for testing. And the developers have their
individual libraries. With Change Management software when you check out
a source member(s) from PRDLIBS it will copy them into the developers
individual libraries. They can develop, compile and test there. Then
then can promote it up to PRDLIBT. Run it through some more testing. Then
promote it up to production. Which will move source to PRDLIBS, and the
proper stuff to PRDLIBO and PRDLIBF. As part of the promotion to
production the proper stuff will get promoted to PRDLIBO and PRDLIBF on
the production lpar. No source gets moved to the production lpar.
What do you actually push on to the prod lpar? Just objects? What about
modules?
Just objects. No modules. No point to it.
What's the point of DSPOBJD to get the source member used to create the
object? Can it be easily found?
DSPOBJD died with OPM. With ILE use DSPPGM or DSPSRVPGM. If you want to
retrieve this stuff programmatically then there are APIs for this.
Aren't there any issues with debugging? Aren't the source files needed?
The source files are not needed. See CRTBNDRPG DBGVIEW(*LIST)
Any more fors and againsts for separating source and objects in this way?
Discourages changes on the production machine.
Increases security since less people have access to the development lpar.
Increases security because developers will not have the access on the
production lpar they claim to need on the development lpar.
RCLSTG always seems to run several hours longer on the development lpar
versus the production lpar. Regardless of processor, etc. Therefore
you're reducing the downtime of the production lpar.
No source to get out of sync if on both machines.
No source on production lpar therefore less save time, reducing backup
outage.
No duplicate storage of source therefore less disk space consumed.
A separate test lpar will help reduce errors to production data because
some idiot hardcoded a library in a program, or duped a logical wrong and
it points to production data. An errant DDM file can still be a kick in
the crotch.
No cycles taken up by compiles on the production machine. Years ago, back
when we ran AS/400's, I got a talking to because a compile slowed down the
machine.
You can test ptf's, new releases with the development lpar first.
Con:
You'll upgrade release levels on your development lpar. If you forget to
compile to TGTRLS(*PRV) it won't work. Easily recovered by recompiling.
(And is often a setting in Change Management Software.)
Rob Berendt
midrange.com
