Transport import log gives warning about includes for the public section of a class

[matt]

On an import a transport, I'm getting the warning message in the import log

ZCLxxxxxxxxxxxxx==============CU is included by 462 master programs, therefore the buffer synchronisation may take some time.

Now, the ...===CU include is the public section of class ZCLxx... There are certainly not 462 master programs in my system that contain INCLUDE xxxxxxxxxxxxx==============CU.

The class is a container for various utility static methods, and may well have one or more of those methods called by a few hundred programs/classes/function groups - possibly exactly 462. But surely this wouldn't produce the same issue as actually including an INCLUDE in multiple programs - which is of course always a no-no.

Has anyone else encountered this, and is it just a spurious warning?

[raymond_giuseppi]

I only saw this message during some upgrades, e.g. "IF_HTTP_SERVER================IT is included by 101384 master programs, therefore the buffer synchronisation may take some time."

Solved by stopping AS (not database) and executing import from command lines...

[pokrakam · Accepted solution]

I think the message is slightly misleading. Not include as in "INCLUDE <report>", but as in "used by".

Things you change in the public section are parameters and methods, therefore anything that references that class could potentially be affected. So I'd see the warning as a warm fuzzy reassurance that the system is doing a sensible thing by regenerating all usages of your class.

The warning is just about the about the amount and length of time it may take. I've seen someone send an activation of one of the core IS-U data elements into production by accident and slow the system to a crawl for over an hour while pretty much all of IS-U was compiling.

[matt · Accepted solution]

This is exactly it. There is one static method of the class used by an include that is used in 462 places. I can't go into details about why, but it's the right solution in this particular case. (Unlike in another place, where an included borked the system entirely for quite awhile. Note: do not use the same include in a more than one BW routine).

It's possible this is a new check in recent releases (this is into a 7.52 system), as I don't recall seeing it before.

[Sandra_Rossi · Accepted solution]

or things like enhancing CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD is to avoid 😉 (will make everything using CL_GUI_FRONTEND_SERVICES recompile)