You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In general we favor dynamic calls which avoids having to manage SYSLIB concatenations during Linkedit.
Unfortunately there are exceptions, especially with assembly programs (which few people know how to manage properly today).
With the switch to IBM DBB, we have come to manage a build context that is completely independent of the run context.
For call interfaces between Applications, we have a mechanism for exposing and importing copybooks / includes based on Git repositories: the calling application imports the Git repositories dedicated to storing the copybooks / includes of the called Applications, (and thanks to the sparse checkout mechanism we manage the level of sharing of copybooks / includes : public, protected, private...).
We are looking for a similar solution allowing us to expose and reference object modules / programs between Applications for static calls.
Each Application is stored in its own Git Repository, produce its own packages of built components.
This solution must meet the following constraints:
version management according to the build context: we not necessarily used the same object modubles / programs versions when doing a User Build (git feature branch) and when doing a Project Build for production (git master branch)
the level of sharing (or exposure): according to the Information System's urbanization scheme, sharing between applications is not the same; "sister" applications can share modules, while "non-sister" applications cannot
the solution must be dynamic: it is by settings that the module libraries must be referenced
the solution must be independent of run environments : we don't build and run (deploy) on same z/OS partition
the load module libraries (PDS) must not be permanently resident on the build system: they must be retrieved and instantiated during the build, (for example from an Artifactory repository).
I would be interested to know the solutions that other DBB users have been able to implement for the management of static calls between Applications, as well as to have implementation suggestions from the IBM team.
Thanking you in advance for your suggestions and feedback.
The text was updated successfully, but these errors were encountered:
Unfortunately it does not deal with the subject that I exposed here: how to manage static linking between different applications, without having to permanently maintain PDS data sets on the z/OS build system, containing the referenced object modules or programs (because you can also link programs to each other).
Hi,
In general we favor dynamic calls which avoids having to manage SYSLIB concatenations during Linkedit.
Unfortunately there are exceptions, especially with assembly programs (which few people know how to manage properly today).
With the switch to IBM DBB, we have come to manage a build context that is completely independent of the run context.
For call interfaces between Applications, we have a mechanism for exposing and importing copybooks / includes based on Git repositories: the calling application imports the Git repositories dedicated to storing the copybooks / includes of the called Applications, (and thanks to the sparse checkout mechanism we manage the level of sharing of copybooks / includes : public, protected, private...).
We are looking for a similar solution allowing us to expose and reference object modules / programs between Applications for static calls.
Each Application is stored in its own Git Repository, produce its own packages of built components.
This solution must meet the following constraints:
I would be interested to know the solutions that other DBB users have been able to implement for the management of static calls between Applications, as well as to have implementation suggestions from the IBM team.
Thanking you in advance for your suggestions and feedback.
The text was updated successfully, but these errors were encountered: