Re: Service Program Question

David,

Thanks for responding to my inquiry. I have contacted the CMS vendor (MKS, in this case) and the explanation I received is as follows: On any move request, the CMS will pick up the service program attributes from the "To" or target environment. If the object does not exist in this environment, the command will default to standard command attributes. There is a way to override this behavior (pick up the attributes using the "From environment) on the move request itself. I have tried it and the work around does work however the place to override this attribute is not very obvious.

I decided on using a binding directory to hold all modules related to the service program and simply override the command to use the binding directory to get the module listing. This seems to be more intuitive to me and the binding directory allows me to only add the new modules. All is documented on the move request which is part of my project documentation.

Jim Minisce
Godiva Chocolatier, Inc.



----- Original Message ----
From: David Gibbs <david@xxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Sent: Tuesday, April 7, 2009 9:36:34 AM
Subject: Re: Service Program Question

Jim Minisce wrote:

For some reason our CMS does not retain the original module(s)
listing when the service program is check out for update. Entering 10
or more modules is a little cumbersome on each promotion to a new
environment.

That does seem quite odd ... IMO, the first job of an IBM i based SCM / CMS system should be to preserve the attributes of the objects it's managing.

david
(who works for MKS, a SCM vendor, in addition to running these lists)