SMGR - Overview

SMGR uses a central Progress Database to keep track of Issues and Source components. What you choose to handle as Issues is entirely definable by you. As delivered, SMGR has code values in its database for Errors, Enhancements, and Documentation. However, it could just as well have Work Orders, or any other issue category added to it.

SMGR is accessible from the Progress menu. The primary entry points are two browsers, one for issues and one for sources. This makes it easy for anyone to look through the data. Accelerated Search and Find capabilities exist to speed access when you know exactly what you are looking for.

Sources and Issues are primarily linked via the Fixed By relationship. This makes it easy, when viewing an error report, to see the revisions of software that fixed it, and even which specific lines of code where changed. Or conversely, when looking at a revision, one can see what problems the code change was intended to address. When checking out sources for update, reason codes and problem numbers can be specified. Reporting from SMGR can be used to generate release documents and technical bulletins.

The Error Browser allows for the entry of issues. They can be related to multiple topics for easy categorization. They can be assigned to multiple people for testing, investigation or fixing. Each staff person can readily view only those reports assigned to them. As they proceed with their investigation, they can record the changing status of the issue. This makes it easy to "find the football" as the History display can readily show who has handled an issue, when, and who has it now.

Tracking the thread of responsibility reduces confusion and potential finger pointing. Being able to collect and organise issues by what they relate to helps make effective use of your resources. You can more readily schedule similar issues to be handled all at once. All status and severity codes values are user defined. An escalation policy can be defined for specific severity and status values. SMGR can then re-assign errors to others if they have not been addressed.

The Source Browser shows all the files under control. Files can easily be located by their name, category, or some component of their description. Specific versions of each file can be examined, and compared to other versions. Those files which are currently checked out for update can be shown. Versions can be marked with developer defined status values.

A central Mass Change capability is supported for both issues and sources. An individual can selectively tag errors assigned to them. Files checked out (Inuse) by a developer for update can also be selectively tagged. Then the Mass Change can be used to update the status of the tagged errors to show them being corrected by the files being checked back in one "swell foop".

Integrating SMGR into Your Environment

Source Management - SMGR uses your choice of Sccs, Rcs, or its own internal database storage for source files. Sccs or Rcs is preferred where available, since it reduces storage requirements and complements native OS tools. SMGR can "adopt" an existing Sccs or Rcs file, loading in its revision data.

Production and Release Security - The notion that any system such as SMGR written in Progress can be effective in enforcing security on Progress programmers is tenuous at best. Therefore, SMGR interfaces with the Production Manager, also written by MNOP. This unix system is written in C and provides secure control and auditing over movement of changes into production libraries.

Customized Procedures - SMGR provides extensibility in three basic ways:

A. Reporting - The SMGR database is logical and simple to query with Progress Results or native Progress code.

B. Event Trapping - SMGR provides several spots where you can insert additional behavior to suit local requirements. For instance, after checking in a changed source file, the code here can be used to place a copy of checked in files somewhere specific:

snormal-pathname = "/u2/prod/src". {stfetex.i} C. Calling SMGR procedures - the basic source manipulation commands can be called from within other progress procedures developed locally to handle specific situations. This allows easy customization of deployment procedures while still using the Progress language.