Re: How does binder organise copyright statements? -- MIDRANGE-L

Talking to myself again (but it's one of the few times I get sensible conversation ...)

Dumping the copyright sections of the modules shows obvious mistakes. Essentially a x'00' character is being added to some of the copyright strings by the compiler. This is probably a typical C programming defect but I can't determine the underlying cause. Each module gets its copyright statement from the same common include. Each module has two entries in the copyright section. One is a user statement (#pragma comment(user, "text") and the other a copyright statement (#pragma comment(copyright, "statement"). In 4 modules both entries contain a trailing x'00' and this 'null-character' is included in the string length field. In 8 modules neither entry has the trailing null and the length field is one less.

I realise the text strings in the include are C strings and therefore have an implicit terminating null-character but the compiler should not be including that in the final object (or at least it should be consistent about doing so).

Given that EXACTLY the same source is used for the user and copyright statements there must be something about the way the compiler processes these statements in the 4 problematic modules that triggers this behaviour but I can't see what it might be.

It is at least consistent: If one copyright string in a module has the erroneous trailing null then all in that module will also have the null.

A search of the System I Support site found nothing relevant but since that site STILL includes results from non-System i platforms that's hardly surprising. It's been 18 months (March 2008) since I complained to IBM Internet Support about the idiocy of including rubbish about System z or System p or whatever in the search results from a System i SPECIFIC search page. Their response was they were aware of the problem and were working on it. Still not fixed I see--IBM responding with glacial rapidity.

To top it off, in the middle of searching I get:

Our search function is temporarily unavailable and will be back online soon. We
apologize for any inconvenience caused. Thank you for your patience.

Error message (URL argument - No action)

Thanks very much!

On 08/09/2009, at 9:01 AM, Simon Coulter wrote:

Responding to my own append:

It appears that this is yet another "issue" with the AIX C compiler
port--such a piece of crap.

If I compile the modules and bind using the V4 C compiler--
TGTRLS(V4R4M0)--I get properly merged copyright statements--exactly as
I expected.

If I compile the modules and bind using the V5 C compiler--
TGTRLS(*CURRENT)--I get the duplicated copyright statements.

If I use the V4 modules and bind using TGTRLS(*CURRENT) I get properly
merged copyright statements.

This suggests to me the problem is in how the V5 C compiler generates
the copyright statements for some modules and the binder is just
working with what it got.

Just another bloody annoyance in the V5 C compiler. At what point does
a list of minor irritations become an aggravation?

Now I'll have to dump the modules and examine the .COPYRIGHT- section
to see if I can spot what it's doing differently in some modules. What
a pain in the arse!

On 28/08/2009, at 11:12 PM, Simon Coulter wrote:

Does anyone KNOW how the binder organises copyright statements in an
ILE program or service program? These are text strings embedded in the
compiled object using:
o COPYRIGHT TEXT('XYZ 2009') CL command
o #pragma comment(copyright, "XYZ 2009") C directive
o COPYRIGHT('XYZ 2009') RPG IV H-spec
o etc.

My problem is duplicate entries appearing in the copyright section of
the output from DSPPGM or DSPSRVPGM.

My observation is that the binder rationalises copyright statements
such that only one occurrence of a given copyright string should
appear.

For example: If I have a program consisting of three modules A, B, and
C, and each module source contains the following:

H COPYRIGHT('(C) XYZ 2009')

then each resulting compiled module will show "(C) XYZ 2009" with
DSPMOD DETAIL(*COPYRIGHT). When these three modules are bound into a
*PGM object DSPPGM DETAIL(*COPYRIGHT) will show only one instance of
"(C) XYZ 2009".

If one module has a different copyright value then DSPPGM
DETAIL(*COPYRIGHT) will show only two strings e.g.:
"(C) XYZ 2009"
"(C) ABC 2000, 2004."

indicating that the duplicates have been merged.

If all three modules have different copyright values then DSPPGM
DETAIL(*COPYRIGHT) will show all three strings.

For this problem I have a *PGM object with 17 bound modules. 13 of
them have exactly the same copyright statement. 1 has no copyright
statement. The remaining three modules each have different copyright
statements.

I was expecting the *PGM object to have 4 copyright statements but I
get 5. The statement from the 13 modules is duplicated.

As part of my investigation I have built the *PGM object in stages by
specifying OPTION(*UNRSLVREF) which allows me to create a *PGM object
with only some of the modules even though all are need to actually run
the program. This shows that 4 of the 13 modules cause the
duplication. If the program is built using only these 4 modules there
is only one copyright statement in the resulting program. If I include
any of these 4 modules with any of the other 9 modules that share the
same copyright statement I get 2 duplicate copyright statements.

Reducing further if I include only the entry module and any one of the
4 problematic modules (i.e., a 2-module program) I get duplicate
copyright statements. If I include only the entry module and any or
all of the other 9 modules I get a single copyright statement.

Although this does not affect the operation of the program the
duplicate copyright statements look extremely ugly.

I KNOW the copyright statements in the 13 modules are IDENTICAL
because they come from the same common include.

So ... what's going on?

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------