Re: How does binder organise copyright statements?

Final comments (for those who care).

It appears this defect has been resolved on current releases (at least
it cannot be reproduced on VRM540). I could find no mention of a PTF
for this defect so suspect it was either fixed internally or
disappeared as a result of some other fix. At least it is no longer
present (or at least not with my particular test-case) and I have a
work-around for earlier releases so normal transmission will be resumed.

On 09/09/2009, at 6:26 PM, Simon Coulter wrote:

Resolved!

I noticed that in the 4 problematic modules the include that contained
the copyright statements was the first item of real code. In all the
OK modules there was another include prior to the copyright one.

Experimentation revealed that if the copyright statements are in the
first include, or an include nested inside the first one, the
resulting module contains copyright statements with the erroneous null
character. If another include (or presumably real code) is encountered
by the compiler first then copyright statements are handled correctly.

Solution was to swap the sequence of a pair of nested includes inside
the first include and the duplicate copyright statements have
disappeared.

Stupid, stupid, stupid compiler (or pre-compiler) but at least I can
work-around the issue.

On 09/09/2009, at 11:00 AM, Simon Coulter wrote:

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.