About Berkeley db-1.85.
- I know is a rather weird question, but I'm considering
the possibility to compile, under MVS3.8j, with GCCMVS,
the source code of Berkeley db-1.85.
I had a look to the source, there are dependencies
from <sys/types.h>, <unistd.h>, <fcntl.h>, but
for what I can see reading the code, nothing that
really prevent using the basic C90 features implemented
My main doubt is about the type of dataset which may
be used with such a library, which basically require
fseek() to work correctly and with good performance.
Would a RECFM=U dataset fit such a request?
I'm posting here such a weird question because,
I guess, I may find in this group the best know how
about the GCCMVS/PDPCLIB internals.
Thanks, G. Vitillaro.
Giuseppe Vitillaro | E-Mail : giuseppe@...
CNR - ISTM | 06123 Perugia Phone:+39.075.585-5518
- ---In email@example.com, <myyahoo@...> wrote :
> Sorry Paul - I reply using the email interface, which does not have thatEmail doesn't allow you to include any
of the previous message you were
> There is no, one-to-one, universal ASCII <-> EBCDIC translation table -I don't see why it can't be.
> because there can't be.
ASCII-7 already has a very well-defined set
of code points. These are universal. What
people put in the other available code
points that ASCII didn't define can be
anything at all. I don't have a problem
If ASCII can be well-defined, why not
EBCDIC has very clear code points in
the S/370 Reference Summary too.
For decades. Those code points aren't
set in stone like the ASCII ones are
though. For whatever historical reason,
various "standard" (ie that exist in
7-bit ASCII) characters outside of A-Z,
a-z and 0-9 have been assigned to
different code points in different code
pages, even just within America!
I know it's late, but I don't see why we
can't insist on S/370 Reference Card
compatibility, aka code page 1047
*at least for the "standard" characters*.
And if we do that, then finally there is
a universal translation table *for the
Beyond the "standard" characters I
do not care what happens. If you're
talking about "non-standard"
characters then I agree there is no
single translation table available.
But I don't care how many mappings
people make up for that.