Change 9904
Port 2008.1 P4 to MVS Unix System Services.
This is an onsite
port carried out at Bank of America in Croydon.
It's not pretty. There are some uglies in here which could
probably be taken care of in better ways, but I was pressed
for time. Here's the background to each of the issues I found:
1. The compiler really didn't like our Zeroconf
code, and since building Avahi on the mainframe wasn't top of
my agenda, I disabled it with some heinous ifdef's in client.cc.
Sorry. The compiler was bitching about types of arguments being
passed to zeroconf methods, and it wasn't obvious to me what the
problem was either. I think we could use a -DUSE_ZEROCONF in
our Jamrules for occasions like this; that would be cleaner than
a platform ifdef in client.cc. With more time, it might be
possible to make the zeroconf code compile on MVS, but getting
dynamic loading working on that platform is ambitious I think.
2. The mapping code needed ifdefs too (again, sorry!). On MVS,
C and C++ don't share the same linkage and qsort() is a C function
so it (apparently) can't take a pointer to a C++ function. So,
all the qsort() compare functions have to be declared as
'extern "C"'. See:
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.bpxbd00/qsort.htm
I didn't ifdef these as I don't think they'll do any harm on other
platforms.
3. support/random.cc needed an ifdef (no big deal)
4. sys/netaddr.cc had to have a (correct) const removed since
the MVS implementation of inet_addr takes a 'char *' argument
instead of 'const char *'. I ifdef'd that to keep it clean
on other platforms.
5. zlib/zconf.h had some old pragmas that no longer apply.
6. Jamrules: I reinstated the old rules from MVS builds, and
made EBCDIC optional rather than compulsory. I also
documented in it the environment variables we set to persuade
the compilers on BofA's machine to behave. These may, or may not
be required on other MVS boxes. No idea.
Building Jam also had a few idiosyncracies:
1. Best to assume the yacc on MVS is broken. It was there, but
not in great shape. I disabled it in Jambase and I think that's
a sensible thing to do going forward.
2. yylineno() can't return a 'const int' on MVS. Not sure why
it's defined that way on other platforms so I changed it to
just returning an int. Hopefully that won't break elsewhere...
There are three binaries being submitted here:
jam - built from main
bin.mvs/p4 - EBCDIC client
bin.mvs/ascii/p4 - Non-EBCDIC client
The ascii client identifies itself as such:
P4/MVS/2008.1.ascii/164042
While unconventional, I thought that was the best plan so that
if we take support calls on it, we'll get a clue.
p4transfer.py: Transferred from production
This is an onsite
port carried out at Bank of America in Croydon.
It's not pretty. There are some uglies in here which could
probably be taken care of in better ways, but I was pressed
for time. Here's the background to each of the issues I found:
1. The compiler really didn't like our Zeroconf
code, and since building Avahi on the mainframe wasn't top of
my agenda, I disabled it with some heinous ifdef's in client.cc.
Sorry. The compiler was bitching about types of arguments being
passed to zeroconf methods, and it wasn't obvious to me what the
problem was either. I think we could use a -DUSE_ZEROCONF in
our Jamrules for occasions like this; that would be cleaner than
a platform ifdef in client.cc. With more time, it might be
possible to make the zeroconf code compile on MVS, but getting
dynamic loading working on that platform is ambitious I think.
2. The mapping code needed ifdefs too (again, sorry!). On MVS,
C and C++ don't share the same linkage and qsort() is a C function
so it (apparently) can't take a pointer to a C++ function. So,
all the qsort() compare functions have to be declared as
'extern "C"'. See:
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.bpxbd00/qsort.htm
I didn't ifdef these as I don't think they'll do any harm on other
platforms.
3. support/random.cc needed an ifdef (no big deal)
4. sys/netaddr.cc had to have a (correct) const removed since
the MVS implementation of inet_addr takes a 'char *' argument
instead of 'const char *'. I ifdef'd that to keep it clean
on other platforms.
5. zlib/zconf.h had some old pragmas that no longer apply.
6. Jamrules: I reinstated the old rules from MVS builds, and
made EBCDIC optional rather than compulsory. I also
documented in it the environment variables we set to persuade
the compilers on BofA's machine to behave. These may, or may not
be required on other MVS boxes. No idea.
Building Jam also had a few idiosyncracies:
1. Best to assume the yacc on MVS is broken. It was there, but
not in great shape. I disabled it in Jambase and I think that's
a sensible thing to do going forward.
2. yylineno() can't return a 'const int' on MVS. Not sure why
it's defined that way on other platforms so I changed it to
just returning an int. Hopefully that won't break elsewhere...
There are three binaries being submitted here:
jam - built from main
bin.mvs/p4 - EBCDIC client
bin.mvs/ascii/p4 - Non-EBCDIC client
The ascii client identifies itself as such:
P4/MVS/2008.1.ascii/164042
While unconventional, I thought that was the best plan so that
if we take support calls on it, we'll get a clue.
p4transfer.py: Transferred from production