ProcOpt Data Size Mismatch

nkuebelbeck

nkuebelbeck

VIP Member
so these types of logs are popping up.

Warning - ProcOpt Data Size Mismatch: Requested 22 is less than Retrieved 24 for App ,Version .? Data Structure allocated successfully. This usually means items have been added to the template and existing? business function will function correctly.

they don't appear to be causing any issues but they are making logs files bigger/noisier.

How can I find out what causes this is and how to fix it?

Thanks
 
This is due to a change to a processing option template that hasn't been fully built and deployed. More than likely, a full package will resolve these warning messages.
 
It is caused by calling the API AllocatePOVersionData when the PO template has been appended. The size of the data structure in the C BSFN is smaller than the actual size of the PO template. The PO typedef can be regenerated and the function recompiled to remove the runtime warning.

Craig
 
is there a way to find out which bsfn is executing API AllocatePOVersionData?
 
Sounds like the easiest way is to generate the PO type def and do a full build. that way, anything using it will be updated.
 
not if API AllocatePOVersionData is used in a C function and the .h has the po type def in it...
 
yeah, I don't understand why the generated header file does not get checked in
 
"Requested 22 is less than Retrieved 24 for App"

is that # of parms or bit/bytes?
 
"Requested 22 is less than Retrieved 24 for App"

is that # of parms or bit/bytes?

to answer my own question, it's bytes - see attached chart
 

Attachments

  • sizechart.jpg
    sizechart.jpg
    24.4 KB · Views: 21
Last edited:
yeah, I don't understand why the generated header file does not get checked in

Business View data structures used to be the same way (back in the Xe days) but Oracle fixed that so now all you have to do is #include the business view header file, not sure why they didn't do the same for processing option templates.

One other thing you might find is that for some reason the same po data struct may be pasted in multiple places which doesn't make a whole lot of sense. What we do when this occurs is to comment out the duplicate "paste" of the PO struct and only have one occurrence of the definition in one BSFN .h file and then simply #include that .h file wherever the definition is needed. That way the next time it changes all you have to do is update the one occurrence, do a full build and your done.
 
Business View data structures used to be the same way (back in the Xe days) but Oracle fixed that so now all you have to do is #include the business view header file, not sure why they didn't do the same for processing option templates.

One other thing you might find is that for some reason the same po data struct may be pasted in multiple places which doesn't make a whole lot of sense. What we do when this occurs is to comment out the duplicate "paste" of the PO struct and only have one occurrence of the definition in one BSFN .h file and then simply #include that .h file wherever the definition is needed. That way the next time it changes all you have to do is update the one occurrence, do a full build and your done.

I've found the offending BSFN. (B310232)

in this case, it's missing the cPMPNMemoLotDefault field in the T31114 ds.

I see the type def pasted in the B310232 .h header file.

So what you are saying is comment out the PO type def and include the PO type def in 1 bsfn header file and include that 1 header anytime you need to use AllocatePOVersionData. (Making sure to keep that 1 bsfn updated)

I'm guilty of pasting in the PO type def into every function when needing to get PO values. :/
 
Last edited:
I'm guilty of pasting in the PO type def into every function when needing to get PO values. :/

Your not the only one and it's not going to break anything...it will certainly work, it just takes more effort and complicates things if you ever change the PO template again in the future. Just pick one BSFN .h file, paste the PO Template typedef (the contents of the po .h file that gets generated from OMW) into the BSFN .h file, remove the po typedef from all other BSFN .h files and instead just put an #include to the one BSFN .h that has the po typedef.

Next time you change that PO typedef instead of having to edit all the BSFN .h files where that typedef is pasted into and re-paste the po typedef, you simply edit the one BSFN .h file, do a full build (which forces a recompile of all C code) and then the compiled code for all the other BSFNs that use that PO typedef will be compiled with the new typedef size.

When I say "comment out" I usually do this as a code cleanup thing when I find a PO typedef pasted multiple times, usually in pristine code. Usually when I change a pristine PO template and pristine code has that po typedef pasted multiple times, since I have to edit those pristine BSFNs anyway so that they have the new PO typedef definition, instead of pasting the new po typedef in all the pristine .h files, I comment out the pristine copy of the po typedef and instead add an #include to the ONE .h file where it is defined. Full build for the full recompile and everything is good to go.


This goes for BSFN function structs (DSTRs) as well, all though in normal practice you almost always have a one-to-one relationship between a DSTR and a function so its not really ever an issue. However, there have been situations where I have created a new function but used the DSTR from some other function. Instead of re-pasting the DSTR typedef into my new BSFN .h file I simply do an #include to the .h file where it is all ready defined.

For example, lets say you want to create a wrapper function to F4211FSEndDoc. You create MyF4211FSEndDocWrapper and use D4200310G as the datastruct so you can do your pre/post processing and pass the lpDS straight through to F4211FSEndDoc. Instead of pasting the typedef for D4200310G into B5642001.h simply do an #include to B4200310.h. That way if Oracle ever changes D4200310G (and by extension B4200310) all you have to do is recompile... you don't even need to change any code - no retrofits needed.
 
I understand. I've always been told not to mess with prestine code, so it's only done when enhancements are required for additional functionality, not internal plumbing
 
yeah, I don't understand why the generated header file does not get checked in

Annoying, isn't it!

You have to paste the typedef into your BSFN header file.

So if the PO template is extended, you have to find-in-files all instances of the PO Typedef, check them out, update and check-in, promote, build and deploy to make the annoying messages go away.
 
I'm guilty of pasting in the PO type def into every function when needing to get PO values. :/

That's what you gotta do. If you #include the generated header file for the PO Typedef it will fail your PY (and above) package build as the generated file does not get promoted. Oracle never quite closed the circle on the idea of generating the .h file for PO Templates!
 
That's what you gotta do. If you #include the generated header file for the PO Typedef it will fail your PY (and above) package build as the generated file does not get promoted. Oracle never quite closed the circle on the idea of generating the .h file for PO Templates!

You misunderstood what I was saying or you didn't read the whole thread. What I said was, paste the contents of the generated PO .h file into a SINGLE BSFN .h file. If you need that struct def in another BSFN then do an #include to the BSFN .h file that contains the PO typedef. What I have seen in the past is pasting the PO typedef multiple times into multiple BSFN .h files - that just creates unnecessary code maintenance when that PO changes in the future.
 
Back
Top