We have one huge application model, with a variety of business systems.
These business systems are what groups the Action Block Types.
Services, which are exposed to the client tier are in the Services Business System.
Operations, which are consumed by services, are in the Operations Business System (and so forth).
The problem we have, if a Service (build Pstep and AB) calls a lot of Operations (ABs), then these are all linked into the same C# DLL - there is no concept of static/dynamic packaging in C#. We haven't had a big issue since we converted from COBOL, but now that the application has grown, there are more Operations consumed by Services and the total size of the application is becoming quite large (++GBs).
Build times are also large ... because if a common Operation is changed (not the interface for it), then all affected Services are rebuilt. Adding up to some considerable build time. Another negative artefact is that the DLLs themselves are starting to become quite large ...
So, what is the expectation of packaging the target Operations into Opslib? Will these be included into the Service DLL? Or at link time it determines that the target AB is in an Opslib and doesn't need to add to the Service DLL as there already is an Opslib DLL that contains the AB.
I gave it a go and found that if the Operations and Services where in the same model, even though Opslib were generated for the Operations, the Operations were statically linked into the Services DLL.
Only when I separated the Services into another model did it work as I expected. However, this is not the behaviour I want - as it is considerable effort to move the large amount of services to another model - not counting the transition time for developers to conform to the new structure.
We are running Gen 8.5 at this site, with a CSE and GuardIEn.
Any advice is appreciated!
I am not sure if this is the same problem as described above, but we have noticed that if a p-step or action block A calls an action block B (which is packaged into an OPSLIB) and B calls C (which is not explicitly included in the OPSLIB and is hence static in the OPSLIB), then the icm generated for the load module containing A statically links C even if it does not directly call C.
There is a workaround for this for GuardIEn builds. If you set a project or target property ICMOPFIX to YES then GuardIEn will check the generated icm and remove any action blocks that should not be static in the load module. This is an undocumented feature since the ideal solution is for the Gen icm generator to not include these action blocks, but you can enable this functionality as a workaround until the icm generator resolves this problem.