CHAR to JCHAR warnings w/in NER build

[Frosty the Coder]

Is there a way to globally correct, or suppress, the "CHAR to JCHAR" warnings generated when building NERs or BSFNs?

I realize that they are just WARNINGS but they are cluttering up logs.
I'd just like to be tidy.

Please AND Thanks

 

[BOster]

I guess I am not familiar with the "CHAR to JCHAR" warnings that you are talking about. Can you post an example of one?

In general terms, I wouldn't think it would be a problem with NERs since they re-generate the C code when you build them, and I would think that the generated code would be error/warning free (other than the unused vars warning... which should be cleaned up by the developer).

As far as C BSFNs, I generally view warnings as errors... because they usually are. If it were me I would review the code and fix it so it doesn't cause any warnings.

But again, this particular warning may be caused by something else and not a problem with the code.

 

[Remo Williams]

Yeah, how do you get those warnings in a NER, I wanna know too.

And as for build/compile warnings in general: Any decent programmer will make sure that his or her deliverables don't contain any warnings

 

[Frosty the Coder]

Here are examples of the CHAR to JCHAR warning
and a "macro redefinition" warning that we get during
during an NER build.

We ran into the CHAR to JCHAR at both my last, and current site.
Both are XE to 9.x upgrades.
Both 9.x are on iSeries (AS/400) platforms. Coincidence? Probably not.

I haven't noticed the "macro redefinition" prior to my current site, but it is pointing at base tables.
I'm seeing a lot of these in the log.

\\MN001HJA001\E900\DV900\package\FDV031013\include\f5800061.h(24) : warning C4005: 'NID_UPMT' : macro redefinition
\\MN001HJA001\E900\DV900\package\FDV031013\include\f00921.h(62) : see previous definition of 'NID_UPMT'

\\MN001HJA001\E900\DV900\package\UDV130410\source\N580111D.c(1198) : warning C4133: 'function' : incompatible types - from 'char [11]' to 'const JCHAR *'
\\MN001HJA001\E900\DV900\package\UDV130410\source\N580111D.c(1633) : warning C4133: 'function' : incompatible types - from 'char [11]' to 'const JCHAR *'

\\MN001HJA001\E900\DV900\package\FDV031013\include\f580103.h(10) : warning C4005: 'NID_SHAN' : macro redefinition
\\MN001HJA001\E900\DV900\package\FDV031013\include\f4201.h(36) : see previous definition of 'NID_SHAN'

As noted, they are warnings, the NER builds, and seems to function correctly.

REMO - OUCH, that left a mark!

 

[Frosty the Coder]

Actually, the macro redefinition is pointing at a custom table and referencing a base table.

 

[craig_welton]

Looks like your custom table header files are still using the char datatype. Try re-creating the .H in OMW

 

[Remo Williams]

[ QUOTE ]
REMO - OUCH, that left a mark!

[/ QUOTE ]

Hehheh

I was talking about cases where you create/mod bsfns yourself. But this looks like an upgrade issue (right?), so it's not aimed at you

 

[Frosty the Coder]

Craig/Remo,

I recreated the .H on one table, and its macro-definition errors went away.
I recreated the .H on a 2nd table, and both its macro-definition errors AND the CHAR->JCHAR errors went away.

Thank you BOTH very much!

 

[Remo Williams]

Actually I hadn't contributed anything useful yet

But I was just about to say "Looks like Craig's remark might hit the spot"

Anyway, glad you solved it.

 

[JMR]

Just a note if you've not already done so...

In order for the changes to move along the promotion path without issue, you need to check-out the affected table(s); regen the .H header(s); then check-in the TBLE object.

In other words, the table objects need to be part of the OMW project and promoted. AND the regen of .h file should be done while the table object is checked-out, so when it's checked-in, the new .h is copied to the deployment server.