E812, Processing Option Size Mismatch - P42101/T42101

[Frosty the Coder]

Processing options were added to the p/opt template.
Code, for those p/opts was added to the forms.

We're getting a "processing option size mismatch" error.
The logs specifically state P42101 and T42101.
Stuff does continue to run (as the warning says it will) but it's going ZOMBIE.

I've gone into RDA and reselected the p/opts, but the error continues.
It's an appl, so versions SHOULDN'T matter. ("shouldn't").

TIA

Gene

 

[m_brereton]

I=20suspect=20that=20that's=20something=20to=20do=20with=20"C"=20business=20 functs
containing=20references=20to=20the=20T42101=20processing-opt=20template.

We're=20on=20Xe=20here,=20which=20means=20that=20we=20don't=20actually=20h ave=20T42101/P42101
so=20I=20can't=20check=20for=20specifics=20for=20those=20objects,=20but=20 mods=20which=20we've
made=20to=20P4210/T4210=20in=20Xe=20have=20tripped=20us=20up=20in=20a=20si milar=20way=20in=20the
past.

It=20might=20be=20worth=20searching=20the=20files=20in=20the=20"include"=20 directory=20of=20the
appropriate=20development=20environment,=20to=20see=20if=20any=20of=20the
business-function=20headers=20contain=20"T42101".=20If=20any=20do,=20you'l l=20need=20to
update=20the=20"C"=20header=20of=20each=20function=20to=20take=20account=20 of=20the=20changed=20PO
template,=20pasting=20the=20new=20definition=20into=20the=20header=20of=20 each=20of=20the
affected=20functions.=20If=20that's=20as=20long-winded=20for=20you=20in=20 T42101=20as=20it=20is
for=20us=20with=20T4210,=20you'll=20probably=20be=20C-sick=20by=20the=20ti me=20you're=20finished
;-)

Cheers,
Mark

Xe=20SP23.R1=20,=20Oracle=209.2.0.8=20,=20Solaris=208=20operating=20system =20on=20Sun=20Servers.

=09

 

[JMR]

Gene,

You get those 'warnings' from a call to the api, AllocatePOVersionData. Somewhere in one or more bsfn's there is a call to this api that is trying to retrieve the PO's for that app (P42101). To eliminate the log entries you need to find the bsfn's that are using that PO data structure (T42101) and re-paste the typedef and recompile all the affected bsfn's.

Like you mentioned, it is harmless. Basically it is allocating memory for the size of the structure DEFINED in the bsfn's (which is smaller than the actual size of the structure since you added options). The bsfn's using that structure are not using your new options, so it is essentially harmless. BUT, if you want to do away with the log messages, you will have to change the bsfn's as I mentioned.

Good luck.

 

[BOster]

There are BSFNs that are calling AllocatePOVersionData to retrieve the processing options. You will have to find all the source files that have the T42101 data structure and paste in the new DS. What I have done, instead of pasting in the new DS in 20 different places is to create a dummy BSFN, paste the DS into the .h file and then include the .h file in every BSFN that uses the PO data struct (be sure and comment out the one in each of the BSFN .h files). I actually use the dummy BSFN for ALL PO data structs, that way, if I modify a PO data struct I know I have to paste in the new typedef and recompile everything.

Having said all that. If all you did was add some items to the existing PO, I believe you should be fine (aside from the warnings in the log). The AllocatePOVersionData has a uSizeOf param that in all the existing BSFNs will be the smaller than the PO data, HOWEVER, I believe that internally AllocatePOVersionData will only copy data into the allocated memory up to a maximum of uSizeOf, so there shouldn't be any memory violations. That is why it is a warning in the log and not an error.