|
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?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
