I've had dogs that did not worry a bone as much as you have this problem. ;-)
P.S. Take this as a complement!!!
Senior Software Engineer
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Simon Coulter
Sent: Wednesday, September 09, 2009 3:27 AM
To: Midrange Systems Technical Discussion
Subject: Re: How does binder organise copyright statements?
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
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
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.
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
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
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
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
Reducing further if I include only the entry module and any one of
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?
FlyByNight Software OS/400, i5/OS Technical Specialists
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l