First of all, I'm delighted to see this... :).
I've Bcc'd bug-cvs on this as a marker, but suggest
the follow-ups *not* go to the list.
FYI others who have taken a crack at porting to OS/390:
Kessler, Dieter [[EMAIL PROTECTED]]
Michael MacIssac [[EMAIL PROTECTED]]
I have a patch/instructions from Dieter which I can send you. I think(?) Michael is
the other person from whom I received a (rough)
port.
Lars, your patch includes the differences in getdate.c which is generated from
getdate.y by yacc. I don't see any changes to
getdate.c, so hopefully you just have differences due to using a different yacc. If
you made changes to getdate.c directly, those
changes really need to go into getdate.c instead.
A while back IBM announced a residency in Poughkeepsie to port a selection of open
source tools to OS/390 and CVS came to the top of
the most-requested list (to my surprise and delight :). I think that this residency
has passed, but don't know what come of this
and if CVS was ported.
I'm using one of the rough ports. I does OK with text in pserver mode but not
binaries or compressed streams (i.e. "cvs -z3
update") across the network.
Still I am very glad to have it :).
Our developer machine is *very* slow (an R/390) so I just can't find the motivation to
work on a CVS port :). It also looks like I
got a bit too enthusiastic last time we ran short of space, and nuked the CVS sources
I built from on OS/390.
> -----Original Message-----
> From: Lars Berntzon (QDT) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 05, 2000 7:08 AM
> To: '[EMAIL PROTECTED]'
> Subject: Porting CVS to IBM OS/390 UNIX
>
>
> I grant permission to distribute this patch under
> the terms of the GNU Public License.
>
> Hi, i have ported CVS to IBM OSS/390 USS UNIX.
> The beast uses EBCDIC for character encoding so most
> of the port was related to that.
>
> Changes for that was reversing your changes of '\012'
> back to '\n' again in several files. It does not work
> with having it as \012 since other routines seems to
> demand the row separator is a newline och CR in the
> systems native code page.
>
> Also a lot of getopt_long parameters was encode with
> characters 129-134. I added a thousand to those since
> it is an integer and not a char,
> thus resulting in 1129-1134.
>
> Another problem is that the USS methods getenv and putenv
> does not seem to be correct. The getenv method seems to
> return a pointer to the same static area for all
> environment and thus invalidating all earlier
> gotten environment variables.
>
> The patch below does it all:
[snip]
