SirLib configuration options
Manipulating update procedures instead of whole procedure files offers a large number of advantages in managing the Model 204 environment. These advantages are seen in simplified and more flexible pathing schemes for promoting changes, clearer accountability for change, and a more powerful and direct way of building a bug-free production system.
The flexibility of SirLib allows sites to use the product in a number of different ways. The best SirLib implementation is the simplest one that handles all the complexities of a site's application needs. Factors to consider include:
- The number of regions available for developing, testing, maintaining, and running production Model 204 systems.
- The relative volume of new development versus maintenance activity.
- The complexity and length of application testing.
- Local coding standards.
In general, sites want to accomplish as much as possible in each available Online region. Therefore, functional areas tend to be merged whenever possible: either development and testing, or development and maintenance are run in a single region. Some sites have the luxury of a unique region for each functional area, and others have to develop and test, run and maintain production all in a single region.
SirLib can accommodate any of these situations, but this page discusses a kind of optimal situation where functional areas are merged into a single region, whenever it is possible without causing programmers, testers, and users to interfere with each other.
A practical limit with Model 204 makes it difficult to merge more than two functional areas into a single region.
Assuming that a shop is taking advantage of the Application Subsystem
(APSY) feature of Model 204, and that there are embedded references to procedure files in the SOUL code (for example, statements like IN PROCFILE INCLUDE xxxxxx), only two versions of any application subsystem can be run in the region — one with the specified procedure file, and a second whose APSY definition has a procedure group defined with the same name.
If a site wants to run three versions of a subsystem in a region, say a development subsystem, a test subsystem, and a copy of the production subsystem, programmers have to do one of the following:
- Change procedure references when moving procedures between subsystems
- Code in such a way that no procedure file references are used
- Dynamically free and allocate files
- Change the definition of the procedure group used by one of the subsystems
A site might also code all procedure file references with dummy string substitution or, as mentioned above, not use the Application Subsystem feature. Any of these options sacrifices some of the strengths of Model 204, or it places unnecessary restrictions on coding staff.
Configuration examples
Given that no more than two functional areas should operate within a region, and assuming a shop requires a full-scale testing environment, the following example shows one possible implementation of change management using SirLib:
Managing changes across three environments, using SirLib in each
The problem with the above example is that any volume of maintenance fixes interfere with the normal course of development. With testing given its own Online region, programmers will have to balance scheduled development with production fixes. Development may have to be set aside (by temporarily renaming procedures being worked on, for instance) while emergency fixes are coded, then the fixes will have to be incorporated with the new development work quickly, as the region is turned back over to development tasks. If fixes to production are a regular occurrence, this can be an expensive and time-wasting way to work.
If a site wants to eliminate the complexity of dealing with update procedures in every region, the previous flow of change could be simplified to look like this:
Managing changes across three environments, using one copy of SirLib
Again, this configuration has the same problems with emergency fixes and other unscheduled maintenance interfering with the development schedule, and the ensuing complications in the development environment. In addition, while you gain the simplicity of only dealing with update procedures in the development region, you lose some of the strengths of SirLib: the ability to verify and reconfigure the state of procedure files in any region, and the simplified distribution provided by the FixFile.
In addition, under this scheme, testers need to be given the entire test file again every time changes are requested of the development team. And of course, the entire procedure file must be sent to production each time a release is made.
A final example of a SirLib configuration is the way that one company used the product for its own development and maintenance distribution. Because the company "production" environment was a large number of client sites, and the amount of maintenance required on a release was unpredicatable, the company used a single environment for development and testing, and it reserved a second environment for ongoing maintenance on each production release.
This configuration allowed the building of new releases in the same Online region where complex testing occurred, and it allowed the simultaneous reconfiguring of the maintenance environment to match that of the client experiencing problems. An example of this setup is shown below:
Separately managed development/unit testing and release testing
The "next" release of an application was developed in the Development/Testing region, using SirLib to manage the staging of completed units.
This is an excellent option for anyone with a large volume of development work in progress, complex testing requirements, and production environments that may require unsheduled programming not easily integrated with ongoing new development.