Moving to CSSC

[Geoff Hull]

Greetings all!

We are a COBOL software development company (now moving to Java) and we moved to using a Red Hat Enterprise Linux server as our main machine at the beginning of this year. We did some trials before moving to Linux, to see if there were likely to be any major problems with using CSSC. We didn't find any.

We copied our 20 years of SCCS files to our new RHEL 4.4 server and started using CSSC in earnest. There were some minor differences between UNIX SCCS and CSSC, but we use a wrapper script (called sccs) so didn't have any problems with dealing with these.

Our move to CSSC has been remarkably trouble-free. It is slightly more fussy about file layout, but we've only had to "fix" about a dozen files out of nearly 13,000. We have been using CSSC exclusively for nearly a year now.

File Problems

1. Our file problems stem from allowing our programmers to manually edit the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate the checksum).

In two of our files we had an extra space before a date field on the "d" line, for example:

^As 00034/00000/03110

^Ad D 35.2  03/08/07 13:36:08 keith 70 69

^Am 8447

^Ac Add Location Co-ordinate Fields

^Ae

This gave us a message like:

prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file. (Invalid number)

It was easily fixed - edit the file to remove the space and do an " cssc admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to avoid conflicts with our sccs script.)

2. We also found problems in about 8 of our files where our programmers had manually removed some simple intermediate revisions from the SCCS file, and had then run "admin -z" to fix the checksum. SCCS handles this but CSSC doesn't. We fixed this by manually editing the file and creating phony auto null deltas.

Minor Differences

 

• prs -d":T" - no space between the "-d" and the parameters

 

• CSSC's rmdel allows a person to delete a revision made by another programmer

 

• CSSC's sccsdiff is better than SCCS at showing differences revisions (doesn't show bogus differences like SCCS does).

 

• CSSC's get command allows for editing (at the same time) of both the main and a branch. (We prevent this with our sccs wrapper script, so it doesn't affect us.)

PRS Bug

One difference between GNU CSSC and AT&T SCCS is in what is displayed for the command "sccs prs -l <s.file>". SCCS gives only the latest revision whereas CSSC also includes all the auto null delta revisions (if present) as well.

James, should I register this as a bug on SourceForge as well?

Regards,

Geoff Hull

Internal Support

McCarthy Associates

Hastings, New Zealand

 

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

[James Youngman-5]

On Dec 13, 2007 9:27 PM, Geoff Hull <gbh@...> wrote:

>
>
>  Greetings all!
>
>
>  We are a COBOL software development company (now moving to Java) and we
> moved to using a Red Hat Enterprise Linux server as our main machine at the
> beginning of this year. We did some trials before moving to Linux, to see if
> there were likely to be any major problems with using CSSC. We didn't find
> any.

I'm not surprised.   I was in the same position just over ten years
ago and built CSSC to do the migration :)

>  We copied our 20 years of SCCS files to our new RHEL 4.4 server and started
> using CSSC in earnest. There were some minor differences between UNIX SCCS
> and CSSC, but we use a wrapper script (called sccs) so didn't have any
> problems with dealing with these.

>  Our move to CSSC has been remarkably trouble-free.

I'm very glad to hear this.

> It is slightly more fussy about file layout,

Any difference there is almost certainly a bug.   Do you have enough
remaining information to be more precise about the differences there?


> but we've only had to "fix" about a dozen files out
> of nearly 13,000. We have been using CSSC exclusively for nearly a year now.

Congratulations and thanks for letting us all know.

>  File Problems
>
>
>  1. Our file problems stem from allowing our programmers to manually edit
> the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate the
> checksum).

So you're pretty sure that the format problems you describe were
manually introduced, and not compatibility issues?

Also, I'm morbidly curious: why do your programmers need to do this?
The only time I have needed to manually edit SCCS files was to fix the
history files which had been corrupted by a non-y2k-compliant version
of SCCS on Dynix.

>
>
>  In two of our files we had an extra space before a date field on the "d"
> line, for example:
>
>
>  ^As 00034/00000/03110
>  ^Ad D 35.2  03/08/07 13:36:08 keith 70 69
>  ^Am 8447
>  ^Ac Add Location Co-ordinate Fields
>  ^Ae

I see you have an MR number there.   Do you use an MR validation
script?   Up to now, I haven't heard of anybody actually using one,
though the functionality is well tested.

>  This gave us a message like:
>
>
>  prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file.
> (Invalid number)
>
>
>  It was easily fixed - edit the file to remove the space and do an " cssc
> admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to
> avoid conflicts with our sccs script.)

Watch out for automatic OS upgrades :)


>  2. We also found problems in about 8 of our files where our programmers had
> manually removed some simple intermediate revisions from the SCCS file, and
> had then run "admin -z" to fix the checksum. SCCS handles this but CSSC
> doesn't. We fixed this by manually editing the file and creating phony auto
> null deltas.


This does sound like an incompatibility.   It would be nice to fix it,
though it sounds like you have resolved the problem.


>  Minor Differences
>
>
>  prs -d":T" - no space between the "-d" and the parameters

Yes; modern implementations allow arguments to be separated from the
options, though this is not the ancient behaviour.  Back when I was
migrating from SCCS, I was using scripts which used options without
arguments to indicate the lack of a checkin comment, for example.

I believe it probably would be useful to support modern argument
interpretation, at least as a configure-time option.  The problem
though is that it is hard to figure out a change which exaclt
minimised incompatibilities.   Because of the risk of unexpected
changes in behaviour I have simply avoid making any changes there.

>  CSSC's rmdel allows a person to delete a revision made by another
> programmer

I had no idea regular SCCS had this feature!    Thanks for telling me!
   Do you have any idea how this interacts with the authorised-user
list?   I think this is a bug, too.

>  CSSC's sccsdiff is better than SCCS at showing differences revisions
> (doesn't show bogus differences like SCCS does).

Curious; CSSC's sccsdiff doesn't try to be especially clever.  Do you
think there might be circumstances where the difference could be a
problem?

>  CSSC's get command allows for editing (at the same time) of both the main
> and a branch. (We prevent this with our sccs wrapper script, so it doesn't
> affect us.)

[frown.]  I didn't know this was not supposed to be possible.  Could
you please please please try to make a test script which succeeds with
"real" SCCS but fails with CSSC?

>  PRS Bug
>
>
>  One difference between GNU CSSC and AT&T SCCS is in what is displayed for
> the command "sccs prs -l <s.file>". SCCS gives only the latest revision
> whereas CSSC also includes all the auto null delta revisions (if present) as
> well.
>
>
>  James, should I register this as a bug on SourceForge as well?

Please do; it certainly sounds like a bug!

James.


_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

[Geoff Hull]

That was a speedy response!

I have included some attached files with are the IP of the company I work for.

I'll send a copy without the files to the mailing list separately. Can you please treat these
files as confidential and delete them when you have finished with them. I'm being super
paranoid here, but want to give my employers some peace of mind.

> On Dec 13, 2007 9:27 PM, Geoff Hull <gbh@...> wrote:
> >
> >
> > Greetings all!
> >
> >
> > We are a COBOL software development company (now moving to Java) and we
> > moved to using a Red Hat Enterprise Linux server as our main machine at
> > the beginning of this year. We did some trials before moving to Linux,
> > to see if there were likely to be any major problems with using CSSC. We
> > didn't find any.
>
> I'm not surprised. I was in the same position just over ten years
> ago and built CSSC to do the migration :)

And you did a very good job of it, I must say!

>
> > We copied our 20 years of SCCS files to our new RHEL 4.4 server and
> > started
> > using CSSC in earnest. There were some minor differences between UNIX
> > SCCS and CSSC, but we use a wrapper script (called sccs) so didn't have
> > any problems with dealing with these.
>
> > Our move to CSSC has been remarkably trouble-free.
>
> I'm very glad to hear this.
>
> > It is slightly more fussy about file layout,
>
> Any difference there is almost certainly a bug. Do you have enough
> remaining information to be more precise about the differences there?
>

Mainly the space before the date issue. A sample file s.uwadvc.fil is attached. Line 244 is
the offender. SCCS on Solaris 10 will handle this.

>
> > but we've only had to "fix" about a dozen files out
> > of nearly 13,000. We have been using CSSC exclusively for nearly a year
> > now.
>
> Congratulations and thanks for letting us all know.
>
> > File Problems
> >
> >
> > 1. Our file problems stem from allowing our programmers to manually
> > edit
> > the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate
> > the checksum).
>
> So you're pretty sure that the format problems you describe were
> manually introduced, and not compatibility issues?
>
> Also, I'm morbidly curious: why do your programmers need to do this?
> The only time I have needed to manually edit SCCS files was to fix the
> history files which had been corrupted by a non-y2k-compliant version of
> SCCS on Dynix.
>

Hmmm. Yes, we have had some rogue programmers. Some of them got into the habit of
editing the SCCS file if they found they had branched a later version than they needed to.

Try "cssc get s.uwtotlnlth.sel" on the attached file. This works fine for Solaris 10 (and
previously HP-UX 11i v2 and AIX 5.3 - you do get a date warning on the latter). I think
there are some deleted revisions, followed by some "deleted" revisions.

Try the same "cssc get" for s.uwrgen.old and s.uwmtft.cbl.dck. They are also both okay
under Solaris 10 and AIX 5.3.

> >
> >
> > In two of our files we had an extra space before a date field on the
> > "d"
> > line, for example:
> >
> >
> > ^As 00034/00000/03110
> > ^Ad D 35.2 03/08/07 13:36:08 keith 70 69
> > ^Am 8447
> > ^Ac Add Location Co-ordinate Fields
> > ^Ae
>
> I see you have an MR number there. Do you use an MR validation
> script? Up to now, I haven't heard of anybody actually using one,
> though the functionality is well tested.
>

We don't use any validation script. I didn't realize we could until your question. We only
switched these on a couple of years ago. These correspond to our "IDs" which are really
job numbers I guess. We sometimes enter 2 or 3 MRs.

> > This gave us a message like:
> >
> >
> > prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file.
> > (Invalid number)
> >
> >
> > It was easily fixed - edit the file to remove the space and do an "
> > cssc
> > admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to
> > avoid conflicts with our sccs script.)
>
> Watch out for automatic OS upgrades :)

We only use CSSC on Linux and it doesn't come with SCCS (obviously), so it would only
happen when we upgraded CSSC.

>
>
> > 2. We also found problems in about 8 of our files where our programmers
> > had
> > manually removed some simple intermediate revisions from the SCCS file,
> > and had then run "admin -z" to fix the checksum. SCCS handles this but
> > CSSC doesn't. We fixed this by manually editing the file and creating
> > phony auto null deltas.
>
>
> This does sound like an incompatibility. It would be nice to fix it,
> though it sounds like you have resolved the problem.

See above.

>
>
> > Minor Differences
> >
> >
> > prs -d":T" - no space between the "-d" and the parameters
>
> Yes; modern implementations allow arguments to be separated from the
> options, though this is not the ancient behaviour. Back when I was
> migrating from SCCS, I was using scripts which used options without
> arguments to indicate the lack of a checkin comment, for example.
>
> I believe it probably would be useful to support modern argument
> interpretation, at least as a configure-time option. The problem
> though is that it is hard to figure out a change which exaclt
> minimised incompatibilities. Because of the risk of unexpected
> changes in behaviour I have simply avoid making any changes there.
>

Yes, I think that is probably not worth the effort.

> > CSSC's rmdel allows a person to delete a revision made by another
> > programmer
>
> I had no idea regular SCCS had this feature! Thanks for telling me!
> Do you have any idea how this interacts with the authorised-user
> list? I think this is a bug, too.

My apologies. I got this information second-hand. I just tried it here and got this with AT&T
SCCS (Solaris 10):
/data/tmp$ delta -m10056 s.uwadvc.fil
comments? deleted some lines
ERROR [s.uwadvc.fil]: login name or SID specified not in p-file (de2)

And with CSSC:
sam:/home/gbh/tmp>cssc delta -m10065 -y'nice one!' s.uwadvc.fil
delta: s.uwadvc.fil: You have no edits outstanding.

Might have been something else our wrapper script was doing.

>
> > CSSC's sccsdiff is better than SCCS at showing differences revisions
> > (doesn't show bogus differences like SCCS does).
>
> Curious; CSSC's sccsdiff doesn't try to be especially clever. Do you
> think there might be circumstances where the difference could be a
> problem?

I'm not sure, I'm going on what one of our programmers told me. I think it is something
that looks like changes in whitespace, but there aren't any changes. I think this has been
tested several times by getting the different versions out then doing a diff on them, which
showed that some of the differences were "phantoms".

>
> > CSSC's get command allows for editing (at the same time) of both the
> > main
> > and a branch. (We prevent this with our sccs wrapper script, so it
> > doesn't affect us.)
>
> [frown.] I didn't know this was not supposed to be possible. Could
> you please please please try to make a test script which succeeds with
> "real" SCCS but fails with CSSC?

Sorry, another thing our script has always stopped us from doing. When I tested this here
myself, it works identically for both SCCS and CSSC.

>
>
> > PRS Bug
> >
> >
> > One difference between GNU CSSC and AT&T SCCS is in what is displayed
> > for
> > the command "sccs prs -l <s.file>". SCCS gives only the latest revision
> > whereas CSSC also includes all the auto null delta revisions (if
> > present) as well.
> >
> >
> > James, should I register this as a bug on SourceForge as well?
>
> Please do; it certainly sounds like a bug!
>
> James.

Using the attached s.uwadvc.fil (you will have to take a copy and edit it to remove the
extra space, then do "admin -z"), if you do these commands, you'll see what I mean:

/home/gbh/tmp$ cssc rmdel -r43.2 s.uwadvc.fil
/home/gbh/tmp$ cssc prs -l s.uwadvc.fil


Just another note - I note that there is a "to do" to rewrite the sccs2rcs script. An IBM
employee - Jonathon Leffler - has already done this, and included it in his "sccstools"
package.

I found it on this page . He says he has made some improvements to it, such as not
getting any source code out of SCCS files to convert them. There is a download link on
that page. He may be willing to allow a link to his page from the CSSC web page.


Geoff




_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

[James Youngman-5]

On Dec 16, 2007 10:05 PM, Geoff Hull <gbh@...> wrote:
> That was a speedy response!
>
> I have included some attached files with are the IP of the company I work for.
>
> I'll send a copy without the files to the mailing list separately. Can you please treat these
> files as confidential and delete them when you have finished with them. I'm being super
> paranoid here, but want to give my employers some peace of mind.

Please don't do this!     I don't want to see your confidential
material, and neither should you be forced to divulge it in order to
get help.

Instead, use the file "testutils/mogrify.awk" in the CSSC distribution
to delete the actual body lines of the SCCS files.  That will expunge
the problematic content of the files.  The comments are left intact
however, so please double-check those for any information you wouldn't
want to be made public.

I think you should be able to reproduce the behaviour you're talking
about on the "mogrified" version of the files.

Please note also though that the GNU Project prefers not to use the
term "Intellectual Property" as it represents a confusion between two
concepts that are in fact distinct; see
http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty
for a brief explanation.

Thanks,
James.


_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

[James Youngman-5]

On Dec 16, 2007 10:05 PM, Geoff Hull <gbh@...> wrote:
> And you did a very good job of it, I must say!

Thanks.

> > Watch out for automatic OS upgrades :)
>
> We only use CSSC on Linux and it doesn't come with SCCS (obviously), so it would only
> happen when we upgraded CSSC.

Yes, but CSSC is included with many Linux distributions, for example
Debian GNU/Linux, so this problem may bite you when you apply OS
updates to your Linux systems.

Thanks,
James.


_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

[Geoff Hull]

James,

I have been on leave for 2 days.

> > I have included some attached files with are the IP of the company I
> > work for.
> >
> > I'll send a copy without the files to the mailing list separately. Can
> > you please treat these files as confidential and delete them when you
> > have finished with them. I'm being super paranoid here, but want to give
> > my employers some peace of mind.
>
> Please don't do this!     I don't want to see your confidential
> material, and neither should you be forced to divulge it in order to
> get help.
>
> Instead, use the file "testutils/mogrify.awk" in the CSSC distribution to
> delete the actual body lines of the SCCS files.  That will expunge the
> problematic content of the files.  The comments are left intact however,
> so please double-check those for any information you wouldn't want to be
> made public.

That sounds like a better solution. In actual fact the amount of proprietary code is tiny and
would be totally useless without the other 13,000 odd files.

I probably won't get back to this until 3 weeks hence, unfortunately. But will definitely will
follow it up.

>
> I think you should be able to reproduce the behaviour you're talking
> about on the "mogrified" version of the files.
>
> Please note also though that the GNU Project prefers not to use the
> term "Intellectual Property" as it represents a confusion between two
> concepts that are in fact distinct; see
> http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty for
> a brief explanation.

Thanks, I'll have a look at it. I have a lot of respect for the opinions of the FSF.

>
> Thanks,
> James.

Geoff


_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

[James Youngman-5]

On Dec 18, 2007 10:37 PM, Geoff Hull <gbh@...> wrote:
> I probably won't get back to this until 3 weeks hence, unfortunately. But will definitely will
> follow it up.

I understand.  Should you wish to add a bug at
http://savannah.gnu.org/bugs/?func=additem&group=cssc to act as a
placeholder until then, that would be handy; it would serve to make
sure we don't entirely forget the problem :)


Thanks,
James.


_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users