Admin: 1 revision

2015-10-19T21:37:23Z

1 revision

← Older revision	Revision as of 21:37, 19 October 2015
(No difference)

JAL at 18:59, 16 October 2015

2015-10-16T18:59:55Z

New page

After reading this page, you should read [[SirLib "getting started" steps]]
for tips on configuring your <var class="product">SirLib</var> and <var class="product">SirPro</var> environment.

<var class="product">SirLib</var> runs as an APSY subsystem inside a <var class="product">Model 204</var> online, as does
<var class="product">SirPro</var>, a package of productivity tools.
Together they provide a
complete, integrated User Language developers' environment.
<var class="product">SirPro</var> provides the programmers' environment, and <var class="product">SirLib</var> provides the
management environment for applying and backing out updates.

There is some overlap in programmer and management activity in managed
environments, and there is no reason why programmers cannot be
responsible for performing <var class="product">SirLib</var> functions.
This document covers briefly the <var class="product">SirPro</var> functions related to managed changes.
These functions are also covered in the &SIRPROR..

Configuration management functions typically fall into four categories:
<ul>
<li>Identifying, grouping, and documenting system changes.
<li>Providing an environment for controlling change and programmer activity.
<li>Backing out changes.
<li>Reporting on system configurations.
</ul>

<var class="product">SirLib</var> provides specific functions for each facet of change control.
Furthermore, <var class="product">SirLib</var> reduces the complexities of procedure distribution
to such an extent that only a single, small procedure file needs to be
distributed to production environment(s), no matter how many applications
run in that environment.

In addition, <var class="product">SirLib</var> is designed to provide specific mechanisms to
automate and simplify programmers' tasks:

<ul>
<li><var class="product">SirLib</var> prevents programmers overwriting each others' changes.
In typical change management systems, this involves a procedure lock.
<var class="product">SirLib</var> performs this function without locking procedures.</li>

<li><var class="product">SirLib</var> allows developers to continue working in the manner they're used to.
<var class="product">SirLib</var> does not dictate a development method.</li>

<li><var class="product">SirLib</var> allows for quick fixes and fast backout of changes when
introduced changes cause production problems.</li>

<li>Reporting capabilities are integrated, and the data for reporting does
not have to be manually entered — reporting data is generated to the
internal dataset SIRLIBD when system activity occurs.</li>

<li>Verification of change level (or status, release number, etc.) is
available in all environments where <var class="product">SirLib</var> runs, via both reports and
optional internal procedure comments.</li>
</ul>

Most change management systems will not work in <var class="product">Model 204</var>, because:
<li>They cannot be integrated with developer tools.</li>

<li>They cannot handle the long procedure names permitted in <var class="product">Model 204</var>.</li>

<li>They don't understand the concept of <var class="product">Model 204</var> GROUPs.</li>
</ul>

<var class="product">SirLib</var> was designed to deal with all these change management issues and
to work under a wide range of <var class="product">Model 204</var> configurations.
<var class="product">SirLib</var> provides primarily a means to achieve a well-managed User
Language environment: it doesn't dictate procedure promotion schemes,
and it doesn't force any project to manage its changes the same way as
other projects in the same shop.
A shop can standardize on a single mechanism, while allowing each project to
promote changes via a path that is as simple and straightforward as possible.

In addition, <var class="product">SirLib</var> allows multiple users to make updates to the same
procedure at the same time, and it eliminates the risk of programmers
overwriting each others' changes.
Essentially the granularity of an update is reduced to a section of
a program, and possible update collisions are detected and handled
unambiguously and early in the development process.

A managed update refers to any change to a <var class="product">Model 204</var> procedure
which is managed by the change management system.
In this document, that means any change generated using <var class="product">SirPro</var> and
applied using <var class="product">SirLib</var>.
Managed updates may be small bug fixes, major application enhancements,
or additions and deletions of whole procedures.
Managed and unmanaged updates are made via the full screen interface to the
<var class="product">Model 204</var> editor, <var class="product">SirPro</var>.
A managed file is one that is being managed by a change management
system, in this case, <var class="product">SirLib</var>.

In managed files, only managed updates should occur.
If unmanaged updates are allowed to occur to procedures in managed files,
the entire change management scheme can be compromised.
This is why it is recommended that you:
<ol>
<li>Convert your managed files to PUBLIC with low (x'0221') privileges.</li>
<li>Allocate the files to the <var class="product">SirLib</var> subsystem.</li>
</ol>

Then anyone can read the file, but only the change
management system can update procedures in it.
<blockquote class="note">Note: If this is your first time using <var class="product">SirLib</var>,
you should read [[SirLib "getting started" steps]] before continuing
with the detailed portions of the <var class="product">SirLib</var> manual.
</blockquote>

==See also==
{{Template: SirLib topic list}}

[[Category: SirLib]]

SirLib and configuration management - Revision history

Admin: 1 revision

JAL at 18:59, 16 October 2015