Loading ...
Sorry, an error occurred while loading the content.
 

About Berkeley db-1.85.

Expand Messages
  • Giuseppe Vitillaro
    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
    Message 1 of 519 , Feb 20
      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
      in GCCMVS/PDPCLIB.

      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
      -----------------------------------------------------------------------------
    • kerravon86
      ... Email doesn t allow you to include any of the previous message you were replying to??? ... I don t see why it can t be. ASCII-7 already has a very
      Message 519 of 519 , Apr 4
        ---In hercules-os380@yahoogroups.com, <myyahoo@...> wrote :

        > Sorry Paul - I reply using the email interface, which does not have that
        > option.

        Email doesn't allow you to include any
        of the previous message you were
        replying to???

        > There is no, one-to-one, universal ASCII <-> EBCDIC translation table -
        > because there can't be.

        I don't see why it 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
        with that.

        If ASCII can be well-defined, why not
        EBCDIC?

        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
        "standard" characters*.

        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.

        BFN. Paul.
      Your message has been successfully submitted and would be delivered to recipients shortly.