Thanks all for your input.
Of course I can see other ways to solve this, I just didn't want to go down
the route of writing / downloading a tool to control this stuff if there
was something obvious I was missing already available in the OS.
In most places I've worked, you could set up the appropriate creation
parameters one time in ALDON or SOFTLANDING but where I am currently
contracting there is no change control software.
It originally seemed to me that since on CRTSRVPGM you can specify Modules,
it wouldn't be unreasonable for the creation process to disregard anything
on the binding directory that exported the same procedures ( since you've
already explicitly defined something you want to use, that contains them )
I realise there is a hole in that argument you could drive a truck through
- the same service program you want to ignore because it contains
procedures already in your module, might also have additional subprocedures
that you require that aren't implemented in your module.
Oh well...
Other things I ponder...
Having worked mostly at sites that prefer the simplicity of continuing to
treat all their programs as part of the same big system as it was in the
default activation group, by creating ALL ILE objects in named activation
group QILE and scoping all file overrides to the job... ( It's a simple
approach but it works and in some ways preferable to a free for all.
I find myself now wanting to be able to use more of the Control Specs to
define the Activation Group. But there seem to be inconsistencies with
specifying DftActGrp and ActGrp.
- Creating an RPGLE program works fine this way using CRTBNDRPG - I can
specify them both.
- Creating an SQLRPGLE program works fine this way using CRTSQLRPGI with
ObjType( *Pgm ) I can specify them both.
- Creating an SQLRPGLE Service Program using CRTSQLRPGI with ObjType(
*SRVPGM ) Obviously it's not going to be running in the DFTACTGRP, hence
that KeyWord makes no sense, but I don't really see why I can't have
ActGrp( *Caller ) on the Control Spec - after all it IS valid on the
CRTSRVPGM command and I'm really only asking it to do the same thing I got
from CRTBNDRPG ( by which I mean that CRTBNDRPG was happy to ignore the
Control Spec Keywords which were not appropriate for creating the Module in
QTEMP e.g ACTGRP. ) However this would work if I can ensure that ACTGRP(
*CALLER ) is the default, above DUPPROC issues aside..
- It seems to me that there is no single creation command you can use (
short of writing your own utility ) for creating an RPGLE Service Program?
( Make 'em all SQL even if they don't have any SQL in them!!! )
I've always created modules separately and then created either programs or
service programs. Partly this was from the early days when I was trying to
help people understand that one source member does not necessarily = one
program or service program.
But now I'm trying to simplify things for my client who has no change
control and not so much technical resource, hence my ponderings on if I
could set up ( as much as possible ) single compile commands and specify as
much as I could internally in the program.
Maybe It's time to do something like look at Mr Klement's Build tool...
regards as always,
Craig
On 5 February 2018 at 17:47, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 2/5/2018 11:56 AM, Craig Richards wrote:
It seemed to me that there were two ways to solve this problem:
1. Take the Service Program out of the binding directory while you
re-create it, then put it back.
2. Specify Option(*DupProc) on the Create Command.
I always chose the latter of these, but neither seems ideal.
Am I missing something obvious? Has anyone got a better solution?
3) Don't use BNDDIR() for *SRVPGM creation. Use a 'make' CLP that
specifies SRVPGM() that this particular *SRVPGM requires.
4) Use one of the preprocessor utilities and do the compilation with
SRVPGM() instead of BNDDIR() that way. Alan Campin's COMPILE
http://www.think400.dk/downloads.htm and Thomas Raddatz' STRPREPRC
http://www.tools400.de/English/Freeware/Utilities/strpreprutilities.html
are two that spring to mind.
--
--buck
http://wiki.midrange.com
Your updates make it better!
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
midrange.com
