SWID changes after running an object

[lukef]

Hi,

i made some minor changes to an existing BASE24 TAL satellite program
and rebuilt it and recorded the SWID of the new object.

i then ran the object and re-SWIDed it, and the SWID changed. this
doesn't normally change. any ideas?

the SWID doesn't change again if i change the library file.

i have made lots of changes to this program in the past and rebuilt
without finding this issue.

thanks, luke.

$B24T2 L6ATN50 216> #tosversion

#tosversion expanded to:

Q 6

[lukef]

but it doesn't appear to happen if i don't axcel the object

[Robert Hutchings]

Hi lukef...

I checks the SWID manual and found this snippet...


Operations That Do Change the Fingerprint
Microcode Files
•
Recompiling the object from the same source and the same tools (compiler,
Binder, and so on)
•
Recompiling with a change in file name, variable name, and so on
Operations That Do Change the Fingerprint
Edit Files
•
Renumbering lines
•
Using the EDIT compaction function
Zero-Byte Files
Changing a file’s characteristic, such as file code, type, primary extent, secondary
extent, max extent, or buffer size

[Keith Dick]

I assume the sequence was:

compile
accelerate
run SWID
run the program
run SWID and see different fingerprint

Is that correct?

Was there anything unusual about the minor changes you made to the program? I don't know what "unusual" would be -- I suppose something that you haven't done before in that program. SWID is supposed to skip over any parts of the object file that normally can be changed by running it, so I can't think of anything unusual that the program could do that would cause the fingerprint to change, but maybe there is something that SWID includes that it should not include.

If you start over with compiling the program, does the same thing happen, or was this a one-time anomaly?

[Tom]

Did you run the program from xpnet and have the LIBRARY process parameter set to something (I am guessing that you are working with an N50 device handler based on the path in your question)?

[lukef]

On 20 May, 10:32, Tom <to...@hrescak.si> wrote:
> Did you run the program from xpnet and have the LIBRARY process parameter set to something (I am guessing that you are working with an N50 device handler based on the path in your question)?

tom, yes from xpnet with a library specified

keith, yes that was the sequence & no nothing unusual. this has
happened to this program once before, but next code change fixed it.
we have made >200 code changes to this source file over the years.

the problem didn't recur when this same code was compiled on the
blades, only on the s-series.

i tweaked the fix a small amount (thought it may be ddl related so
fixed a possible word boundary issue with a filler byte but not
convinced there was a problem) with same result, swid changes after
running it.

[Keith Dick]

If you can get the problem to occur every time you build the current version of your program, I think it would be a good idea to report the problem to HP support and send your example to them. I think that even though it is happening on S-series, they probably would want to know about it and fix it. I imagine they still want to be able to verify the integrity of object files that they deliver for S-series systems, and if the fingerprint is changing for your program, it might change for one of theirs, too.

I don't know anything about running programs from xpnet, so it might be that ACI does something to the object file that changes the fingerprint, though I don't know why they would do so. If it is possible to build, fingerprint, run directly from TACL, check fingerprint and see a fingerprint change, I think that would rule out the possibility that ACI changed the object file. If the fingerprint changes only when the program is run from xpnet, then I guess you should contact ACI support rather than HP support.

I don't know the low-level details of how SWID operates, but I believe it is intended only to look at things in the object file that are directly related to how the program operates when it is run -- its code and initial data. So this change of fingerprint could be a sign that something is modifying the object file in a way that could change how the program operates. It is probably an accident, but whether accidental or intentional, if it changes how the program operates, that definitely is something undesirable and should be tracked down and fixed.

I hope I'm not being alarmist here and forgetting some benign changes that will trigger a fingerprint change. Assuming I'm right and the fingerprint change is as serious a matter as I think it is, you probably ought to get ACI or HP to investigate until they find out why it is happening and fix it.

[g.j.a...@gmail.com]

I saw this when running a Golden Gate object, in 2010 - the SWID of the object changed after it had been run for the first time. Can't remember now which GG object it was (think it may have been the GG Extract), but it was run on an S-Series machine. I asked for support from both GG (now Oracle), and from HP.

The solution came from HP, and it was to upgrade to the latest release of the version of NSK we were running. It worked.

Therefore, get current with your operating system. I think that's the first step.

[Warren M]

On Monday, May 20, 2013 12:30:14 PM UTC-4, lukef wrote:
> On 20 May, 10:32, Tom <to...@hrescak.si> wrote: > Did you run the program from xpnet and have the LIBRARY process parameter set to something (I am guessing that you are working with an N50 device handler based on the path in your question)? tom, yes from xpnet with a library specified keith,

Running an object file with a new or different library will change the fixups in the object file.
The last library used is also stored as an attribute of the object file.
I would expect this to generate a different fingerprint.

[lukef]

keith, i can run direct from TACL and the SWID changes.
warren, SWID is smart enough to only use the 'static' portion of an
object else our SWID would change everytime after the first execution.
g.j.a.s, we are imminently moving to blades so not looking for an os
upgrade on the s-series!

one for HP then...