Re: Maintaining Service Program signatures

Buck,

I don't track older versions since all programs in the higher stack can run
on
the newest version of the service programs without recompiling.

When the higher level programs eventually are recompiled they automatically
includes the newest connector/copybook.

To make a simple example, lets say I have som CGI programs that is build
on My Framework V1.6 that run on lowest level Core V4.3 I have an initial
stack

1. My CGI program
2. Framework V1.6 service programs
3. Core V4.3 service programs

You can install any Core V4.3+ without recompilation in that environment,
if you wish to install Framework V1.7 you will at least have to install
Core V4.8
first because Framework V1.7 uses Core V4.8 as lowest level, but you could
also install Core V4.11 and Framework V1.7 - but still without recompiling
the
CGI programs (ad. 1)

The reason I can do that is the Binding source that has all the signatures
of
previous Core Versions in it.

Theoretically this replacing low level service programs with newer versions
can
go on for ever, but in practise sometimes changes in the low level are so
big
that you can't do it without total recompilation but these situations are
rare.


Last I have to do a major change was in 2010 ...

2010.10.19 powerEXT Core 4.0:IMPORTANT! powerEXT Core 4.x is not object
compatible with earlier Core versions due to change of max varying field
length from 32767 to 65535, existing programs that uses Core has to be
recompiled after installation
<http://code.google.com/p/powerext/#IMPORTANT!_powerEXT_Core_4.x_is_not_object_compatible_with_earli>

- All variable length fields changed from 32767 to 65535.

It's a little like shifting from 32bit to 64bit technology


On Wed, Feb 20, 2013 at 7:33 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 2/20/2013 1:09 PM, Henrik Rützou wrote:

I have a lot of versions and deliver program to lot of environments I

don't.

-snip-

The BND source has a

STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(clearSrvPgm)
....

where new subprocedures are added in the buttom. If I need to put new

PARM

to
an existing subprocedure I do it as the last field in the subprocedure

and

the new
PARM has always options(*nopass) otherwise the old subprocedure is kept

as a

depreciated subprocedure.

and a

STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(clearSrvPgm)

section for each previously version

-snip-

Very interesting, Henrik. Thanks for sharing your process. May I ask
what you do with *PRV versions? As a vendor, do you use the version to
track which *PROGRAMs are using only older versions of a *SRVPGM?
--buck

--
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: 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.