Re: Best way of using Service programs.

Thanks for so many tips guys.. I really appreciate it.
This is a real happening forum and now I rue, I should have found it much
before.

Anyways, I like these suggestions..
One of the biggest practical problem I am finding with using one copy book
per service program to store the procedure declaration is:
Each time I add a new procedure to the service program, the copy book
changes and as such I have to recompile all of my programs that use this.
Also I cannot use updpgm as Turnover does not allow it.

I do not have a problem with Turnover compiling all the programs, but we
have 4 production environments spread across us and each change has to be
distributed to all 4 m/c.  So say if 20 pgms use my srvpgm & include a copy
book, I have to compile all the 20 pgms even though they do not use all the
procedures or the new one added and distribute them.

So for this setup I feel the best way to go might be to not use copybooks.
Am I missing anything here.



On 2/15/06, Larry Ducie <larry_ducie@xxxxxxxxxxx> wrote:
>
> Hi Praveen,
>
> Some things to note:
>
> 1) We use TurnOver from Softlanding to work with service programs. We use
> binding directories but do NOT promote them to the production environment.
> We add them to our worklists, and run them on forms, but the object type
> is
> set to not distribute to production environments.
>
> 2) It doesn't really matter whether you use binding directories or simply
> define the modules/service programs used directly on the create command.
> As
> you are aware, TurnOver saves the custom create command and will offer it
> every time you check the program out and attempt a recompile. The binding
> directory is used to specify places to look for objects to bind to, and a
> simple addition to the H-spec will cause the binder to search the binding
> directory for entries that match. This is better for us as we have a
> reference object that we can check if things don't seem correct. It is
> easy
> for a user to remove the custom create command and once done you are in
> trouble unless you document your implementations down to the binding level
> (or you are very good with TurnOver). Obviously, you need to watch your
> binding directory entry definition. for example, if you specify your
> programmer library for an object while you are developing, the binding
> directory will not change the library to the next level library when the
> object is promoted on a form. The entries will need to be set with library
> *LIBL or you will need to amend the entries after each promotion (if
> needed). That is, named libraries are named permanently and are immutable.
>
> 3) Regarding changing copysource used within a service program and
> recompilation of client programs. You should find that TurnOver does NOT
> provide any form of update program facility. The default action is to
> recompile ALL client programs when a service program is changed. When I
> set
> up our Turnover environment to use service programs that was a question I
> asked and I was told UPDPGM is not an option - TurnOver always recompiles
> just to make sure. So, your client programs should be updated when your
> service program is changed. This is assuming you have Hawkeye and the
> database has been recently rebuilt.
>
> 4) Ensure your service programs are defined to have an associated binding
> source file (in QSRVSRC). That is, if you take option 32 to edit the
> service
> program object in your programmer library it should take you into SEU for
> the binding source. You may not need it now, but you'll kick yourself in
> the
> future when you do need it. Having said that, I ALWAYS use binding source
> -
> again, it documents what is being exported and supports multiple levels of
> concurrent operation.
>
> 5) Promoting binding directories via TurnOver does NOT place a binding
> directory in each level (as it does with database files). Thus, once you
> promote a binding directory from you DEV to your QA environment, the
> binding
> direcory is physically moved from one library to the next.
>
> I hope this is of help.
>
> Cheers
>
> Larry Ducie
>
>
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>