[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[To CVS-Dev] CVS Directory Order and

From: Wayne_Johnson
Subject: [To CVS-Dev] CVS Directory Order and
Date: Thu, 25 Jan 2001 11:15:01 -0600

I've almost got the CVS for MVS (AKA OS/390) port working, including binary and
compression.  At this point I'm trying to get through but am having a
few problems.

1) Some of IBM's system messages like "update: cannot open CVS/Entries for
reading: No such file or directory" actually come out as "update: cannot open
CVS/Entries for reading:  EDC5129I No such file or directory.".  This is pretty
easily avoided by changing the regexp to "update: cannot open CVS/Entries for
reading: .*".  Is this acceptable?

2) It seems that quite often the order that files are processed is different on
MVS.  For example, in basicb-7, the output that is expected is:
 'T Emptydir/sfile1
T sdir2/sfile2'

but on MVS it's:
'T sdir2/sfile2
T Emptydir/sfile1'

I am assuming that the change is due to a different collating sequence between
ASCII and EBCDIC.  My question is, shouldn't LC_COLLATE=C fix this?  I looked in
the opendir/readdir function descriptions on several different UNIX (UNII?) and
LINUX docs and none mention the order that these files/directories should be
listed, nor use of LC_COLLATE.

Is this a hole in the tests?  If the order of files returned by opendir/readdir
if undefined, should they be written a bit more specific, such that the
individual directories/files to be used in the test be explicitly listed in the
command?  Or should I just put a MVS specific bypass in the tests to expect the
alternate order?

Thanks for your input.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]