🚀 go-pugleaf

I have discovered that our application baseline is apparently not
intended to be used for releases past version 10.  This  discovery came
about  while trying to test  the workaround for the Y2K compliance of
the SCCS tool.  I wrote three script files to subtract 20 years from the
modification timestamps in the TSCS baseline s.files.  

I applied the scripts to C source code files, 'include' files, 'help'
files and utility script files.  I verified that my scripts did not
change more lines than they were supposed to by 'diff'ing the before and
after files to ensure that no stray lines were changed.  I verfied that
my scripts changed all the lines than they were supposed to by 'grep'ing
the resulting files, looking for 199x dates and verifying that no
modification time stamps escaped the script.  Finally, I was going to
verify the correctness of the transformation by checking the file out,
making a change to it and checking it back into my baseline.  

Checking the file out, for edit, resulted in the following message:
 'ERROR [../SCCS/s.config.sip]: release `11' locked against editing
(co23)'

Further investigation yields the following help message:
 '-> sccs help co23

co23:
... locked against editing
The specified release (or possibly all releases) for the
SCCS file have been locked using the l flag of admin.  Do a
'prs -d:LK: s.filename' to see a list of locked releases
(a means "all").'

Running 'prs -d:LK: s.config.sip' gives the number 11.  

Apparently, when our predicessors originally 'admin'ed our application,
they specified, via the -I flag, that version 11 would not be editable.
I dug out the SCM, page 21, where the our application version numbering
scheme is described.  I believe that paragraph 1.3.3.6.2.1 is describing
how version 11 has been set aside for deltas into the CMA baseline.

If this is true, checking source code out of the current CMA baseline is
not possible, Y2K fix or not.  This implies that we cannot fully test
the workaround solution to the SCCS non-compliance issue without first
fixing the version 11 problem.

I see two possible options  to resolve the version 11 problem.
a)	Restore version 10 into the CMA baseline, repeat the version 11
build, only call it version 12 when using the CMA build scripts (see
SCM, page 33, step 4).  Hopefully, this will fool SCCS into allowing us
to build on that release.  The re-build and especially the testing would
be just as time-consuming as it was the first time.
b)	Incorporate a new, Y2K compliant, CM tool to replace SCCS (bearing in
mind that it will be running under Ultrix).  Based on the amount of work
that went into setting up TSCS to be under SCCS control, I feel that the
effort required to duplicate this feat is prohibitive.

Any suggestions?