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

GCCCMS question

Expand Messages
  • mfnoel
    KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the
    Message 1 of 13 , Oct 11, 2011
      KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
      -- distribute custom pdpclib generated wo/memmgr, or
      -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
      -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
      -- ???
      What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
    • kerravon86
      By default PDPCLIB does not use memmgr. Even when it does, the default allocation is 60 MB not 10 MB. So are you talking about the behaviour of your own
      Message 2 of 13 , Oct 11, 2011
        By default PDPCLIB does not use memmgr. Even when
        it does, the default allocation is 60 MB not 10 MB.

        So are you talking about the behaviour of your own
        version of PDPCLIB?

        BFN. Paul.




        --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
        >
        > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
        > -- distribute custom pdpclib generated wo/memmgr, or
        > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
        > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
        > -- ???
        > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
        >
      • mfnoel
        no, just the stock 8.5 version from sourceforge
        Message 3 of 13 , Oct 11, 2011
          no, just the stock 8.5 version from sourceforge

          --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
          >
          > By default PDPCLIB does not use memmgr. Even when
          > it does, the default allocation is 60 MB not 10 MB.
          >
          > So are you talking about the behaviour of your own
          > version of PDPCLIB?
          >
          > BFN. Paul.
          >
          >
          >
          >
          > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
          > >
          > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
          > > -- distribute custom pdpclib generated wo/memmgr, or
          > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
          > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
          > > -- ???
          > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
          > >
          >
        • kerravon86
          So if you just type in hexdump to get the usage, it immediately gets 10 MB too? What method are you using to determine how much memory is being obtained? It
          Message 4 of 13 , Oct 12, 2011
            So if you just type in "hexdump" to get the usage, it
            immediately gets 10 MB too?

            What method are you using to determine how much memory
            is being obtained?

            It could be something related to the OS emulation
            support. Maybe the first person who does a GETMAIN,
            even if it's for only 1 byte, causes CMS to reserve
            10 MB to dish out to other GETMAIN requests.

            BFN. Paul.



            --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
            >
            > no, just the stock 8.5 version from sourceforge
            >
            > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
            > >
            > > By default PDPCLIB does not use memmgr. Even when
            > > it does, the default allocation is 60 MB not 10 MB.
            > >
            > > So are you talking about the behaviour of your own
            > > version of PDPCLIB?
            > >
            > > BFN. Paul.
            > >
            > >
            > >
            > >
            > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
            > > >
            > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
            > > > -- distribute custom pdpclib generated wo/memmgr, or
            > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
            > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
            > > > -- ???
            > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
            > > >
            > >
            >
          • mfnoel
            #include int main (int argc, char *argv[]) { int *MAINSTRT = (int*)0x504; int *MAINHIGH = (int*)0x510; int *FREELOWE = (int*)0x514; int *LOCCNT =
            Message 5 of 13 , Oct 12, 2011
              #include <stdio.h>
              int main (int argc, char *argv[]) {
              int *MAINSTRT = (int*)0x504;
              int *MAINHIGH = (int*)0x510;
              int *FREELOWE = (int*)0x514;
              int *LOCCNT = (int*)0x574;
              char memtrcbuf[80];
              int i=0; char *m[5];
              printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
              i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
              for (i=0; i<5; i++) {
              m[i] = malloc((i+1)*100);
              if (m[i] == 0) exit(999);
              printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
              i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
              }
              for (i=5; i>0; i--) {
              free(m[i-1]);
              printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
              i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
              }
              }
              gives
              1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
              -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
              -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000

              --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
              >
              > So if you just type in "hexdump" to get the usage, it
              > immediately gets 10 MB too?
              >
              > What method are you using to determine how much memory
              > is being obtained?
              >
              > It could be something related to the OS emulation
              > support. Maybe the first person who does a GETMAIN,
              > even if it's for only 1 byte, causes CMS to reserve
              > 10 MB to dish out to other GETMAIN requests.
              >
              > BFN. Paul.
              >
              >
              >
              > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
              > >
              > > no, just the stock 8.5 version from sourceforge
              > >
              > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
              > > >
              > > > By default PDPCLIB does not use memmgr. Even when
              > > > it does, the default allocation is 60 MB not 10 MB.
              > > >
              > > > So are you talking about the behaviour of your own
              > > > version of PDPCLIB?
              > > >
              > > > BFN. Paul.
              > > >
              > > >
              > > >
              > > >
              > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
              > > > >
              > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
              > > > > -- distribute custom pdpclib generated wo/memmgr, or
              > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
              > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
              > > > > -- ???
              > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
              > > > >
              > > >
              > >
              >
            • mfnoel
              Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie, 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48,
              Message 6 of 13 , Oct 13, 2011
                Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                which shows the big chunk still there but memory alloc/free happening above it.
                If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.


                --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                >
                > #include <stdio.h>
                > int main (int argc, char *argv[]) {
                > int *MAINSTRT = (int*)0x504;
                > int *MAINHIGH = (int*)0x510;
                > int *FREELOWE = (int*)0x514;
                > int *LOCCNT = (int*)0x574;
                > char memtrcbuf[80];
                > int i=0; char *m[5];
                > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                > for (i=0; i<5; i++) {
                > m[i] = malloc((i+1)*100);
                > if (m[i] == 0) exit(999);
                > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                > }
                > for (i=5; i>0; i--) {
                > free(m[i-1]);
                > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                > }
                > }
                > gives
                > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                >
                > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                > >
                > > So if you just type in "hexdump" to get the usage, it
                > > immediately gets 10 MB too?
                > >
                > > What method are you using to determine how much memory
                > > is being obtained?
                > >
                > > It could be something related to the OS emulation
                > > support. Maybe the first person who does a GETMAIN,
                > > even if it's for only 1 byte, causes CMS to reserve
                > > 10 MB to dish out to other GETMAIN requests.
                > >
                > > BFN. Paul.
                > >
                > >
                > >
                > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                > > >
                > > > no, just the stock 8.5 version from sourceforge
                > > >
                > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                > > > >
                > > > > By default PDPCLIB does not use memmgr. Even when
                > > > > it does, the default allocation is 60 MB not 10 MB.
                > > > >
                > > > > So are you talking about the behaviour of your own
                > > > > version of PDPCLIB?
                > > > >
                > > > > BFN. Paul.
                > > > >
                > > > >
                > > > >
                > > > >
                > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                > > > > >
                > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                > > > > > -- ???
                > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                > > > > >
                > > > >
                > > >
                > >
                >
              • mfnoel
                I m wondering if #if USE_MEMMGR (in several places) should actually be #ifdef USE_MEMMGR ...
                Message 7 of 13 , Oct 13, 2011
                  I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...

                  --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                  >
                  > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                  > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                  > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                  > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                  > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                  > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                  > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                  > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                  > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                  > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                  > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                  > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                  > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                  > which shows the big chunk still there but memory alloc/free happening above it.
                  > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                  > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                  >
                  >
                  > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                  > >
                  > > #include <stdio.h>
                  > > int main (int argc, char *argv[]) {
                  > > int *MAINSTRT = (int*)0x504;
                  > > int *MAINHIGH = (int*)0x510;
                  > > int *FREELOWE = (int*)0x514;
                  > > int *LOCCNT = (int*)0x574;
                  > > char memtrcbuf[80];
                  > > int i=0; char *m[5];
                  > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                  > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                  > > for (i=0; i<5; i++) {
                  > > m[i] = malloc((i+1)*100);
                  > > if (m[i] == 0) exit(999);
                  > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                  > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                  > > }
                  > > for (i=5; i>0; i--) {
                  > > free(m[i-1]);
                  > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                  > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                  > > }
                  > > }
                  > > gives
                  > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                  > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                  > >
                  > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                  > > >
                  > > > So if you just type in "hexdump" to get the usage, it
                  > > > immediately gets 10 MB too?
                  > > >
                  > > > What method are you using to determine how much memory
                  > > > is being obtained?
                  > > >
                  > > > It could be something related to the OS emulation
                  > > > support. Maybe the first person who does a GETMAIN,
                  > > > even if it's for only 1 byte, causes CMS to reserve
                  > > > 10 MB to dish out to other GETMAIN requests.
                  > > >
                  > > > BFN. Paul.
                  > > >
                  > > >
                  > > >
                  > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                  > > > >
                  > > > > no, just the stock 8.5 version from sourceforge
                  > > > >
                  > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                  > > > > >
                  > > > > > By default PDPCLIB does not use memmgr. Even when
                  > > > > > it does, the default allocation is 60 MB not 10 MB.
                  > > > > >
                  > > > > > So are you talking about the behaviour of your own
                  > > > > > version of PDPCLIB?
                  > > > > >
                  > > > > > BFN. Paul.
                  > > > > >
                  > > > > >
                  > > > > >
                  > > > > >
                  > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                  > > > > > >
                  > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                  > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                  > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                  > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                  > > > > > > -- ???
                  > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                  > > > > > >
                  > > > > >
                  > > > >
                  > > >
                  > >
                  >
                • kerravon86
                  No, that should be fine. If USE_MEMMGR is undefined it will be 0 and that will be false. I have an explanation for the 10 MB result though. 60 MB % 16 MB = 10
                  Message 8 of 13 , Oct 14, 2011
                    No, that should be fine. If USE_MEMMGR is undefined
                    it will be 0 and that will be false.

                    I have an explanation for the 10 MB result though.
                    60 MB % 16 MB = 10 MB, so the theory that memmgr
                    is being used is consistent.

                    Note that during the build process it first builds
                    a memmgr version of PDPCLIB, so maybe that isn't
                    being successfully replaced.

                    Can you also do a LISTF PDPCLIB TXTLIB * to see if
                    you are picking up an old rogue version of it?

                    BFN. Paul.




                    --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                    >
                    > I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...
                    >
                    > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                    > >
                    > > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                    > > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                    > > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                    > > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                    > > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                    > > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                    > > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                    > > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                    > > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                    > > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                    > > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                    > > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                    > > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                    > > which shows the big chunk still there but memory alloc/free happening above it.
                    > > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                    > > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                    > >
                    > >
                    > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                    > > >
                    > > > #include <stdio.h>
                    > > > int main (int argc, char *argv[]) {
                    > > > int *MAINSTRT = (int*)0x504;
                    > > > int *MAINHIGH = (int*)0x510;
                    > > > int *FREELOWE = (int*)0x514;
                    > > > int *LOCCNT = (int*)0x574;
                    > > > char memtrcbuf[80];
                    > > > int i=0; char *m[5];
                    > > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                    > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                    > > > for (i=0; i<5; i++) {
                    > > > m[i] = malloc((i+1)*100);
                    > > > if (m[i] == 0) exit(999);
                    > > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                    > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                    > > > }
                    > > > for (i=5; i>0; i--) {
                    > > > free(m[i-1]);
                    > > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                    > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                    > > > }
                    > > > }
                    > > > gives
                    > > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                    > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                    > > >
                    > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                    > > > >
                    > > > > So if you just type in "hexdump" to get the usage, it
                    > > > > immediately gets 10 MB too?
                    > > > >
                    > > > > What method are you using to determine how much memory
                    > > > > is being obtained?
                    > > > >
                    > > > > It could be something related to the OS emulation
                    > > > > support. Maybe the first person who does a GETMAIN,
                    > > > > even if it's for only 1 byte, causes CMS to reserve
                    > > > > 10 MB to dish out to other GETMAIN requests.
                    > > > >
                    > > > > BFN. Paul.
                    > > > >
                    > > > >
                    > > > >
                    > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                    > > > > >
                    > > > > > no, just the stock 8.5 version from sourceforge
                    > > > > >
                    > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                    > > > > > >
                    > > > > > > By default PDPCLIB does not use memmgr. Even when
                    > > > > > > it does, the default allocation is 60 MB not 10 MB.
                    > > > > > >
                    > > > > > > So are you talking about the behaviour of your own
                    > > > > > > version of PDPCLIB?
                    > > > > > >
                    > > > > > > BFN. Paul.
                    > > > > > >
                    > > > > > >
                    > > > > > >
                    > > > > > >
                    > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                    > > > > > > >
                    > > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                    > > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                    > > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                    > > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                    > > > > > > > -- ???
                    > > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                    > > > > > > >
                    > > > > > >
                    > > > > >
                    > > > >
                    > > >
                    > >
                    >
                  • mfnoel
                    No old versions apparent. Y (mnt19e) has pdpclib txtlib with 1549 recs dated 6/6/9. My CMSUSER B drive has a pdpclib txtlib with 1589 recs dated 1/1/11 (that s
                    Message 9 of 13 , Oct 14, 2011
                      No old versions apparent. Y (mnt19e) has pdpclib txtlib with 1549 recs dated 6/6/9. My CMSUSER B drive has a pdpclib txtlib with 1589 recs dated 1/1/11 (that's the one from the sourceforge distro "gcccms-3_2_3-8_5-exe.vmarc") and I have the CMSUSER B drive released when I want to use the older compiler/library that came with the 6pk. There is also a version on the GCCCMS E drive (GCC591) that's 1549 recs dated 6/11/9, but I've not tried it.

                      I have not so far tried to rebuild pdpclib but have been reading up on what's necessary...

                      --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
                      >
                      > No, that should be fine. If USE_MEMMGR is undefined
                      > it will be 0 and that will be false.
                      >
                      > I have an explanation for the 10 MB result though.
                      > 60 MB % 16 MB = 10 MB, so the theory that memmgr
                      > is being used is consistent.
                      >
                      > Note that during the build process it first builds
                      > a memmgr version of PDPCLIB, so maybe that isn't
                      > being successfully replaced.
                      >
                      > Can you also do a LISTF PDPCLIB TXTLIB * to see if
                      > you are picking up an old rogue version of it?
                      >
                      > BFN. Paul.
                      >
                      >
                      >
                      >
                      > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                      > >
                      > > I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...
                      > >
                      > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                      > > >
                      > > > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                      > > > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                      > > > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                      > > > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                      > > > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                      > > > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                      > > > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                      > > > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                      > > > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                      > > > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                      > > > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                      > > > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                      > > > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                      > > > which shows the big chunk still there but memory alloc/free happening above it.
                      > > > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                      > > > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                      > > >
                      > > >
                      > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                      > > > >
                      > > > > #include <stdio.h>
                      > > > > int main (int argc, char *argv[]) {
                      > > > > int *MAINSTRT = (int*)0x504;
                      > > > > int *MAINHIGH = (int*)0x510;
                      > > > > int *FREELOWE = (int*)0x514;
                      > > > > int *LOCCNT = (int*)0x574;
                      > > > > char memtrcbuf[80];
                      > > > > int i=0; char *m[5];
                      > > > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                      > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                      > > > > for (i=0; i<5; i++) {
                      > > > > m[i] = malloc((i+1)*100);
                      > > > > if (m[i] == 0) exit(999);
                      > > > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                      > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                      > > > > }
                      > > > > for (i=5; i>0; i--) {
                      > > > > free(m[i-1]);
                      > > > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                      > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                      > > > > }
                      > > > > }
                      > > > > gives
                      > > > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                      > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                      > > > >
                      > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                      > > > > >
                      > > > > > So if you just type in "hexdump" to get the usage, it
                      > > > > > immediately gets 10 MB too?
                      > > > > >
                      > > > > > What method are you using to determine how much memory
                      > > > > > is being obtained?
                      > > > > >
                      > > > > > It could be something related to the OS emulation
                      > > > > > support. Maybe the first person who does a GETMAIN,
                      > > > > > even if it's for only 1 byte, causes CMS to reserve
                      > > > > > 10 MB to dish out to other GETMAIN requests.
                      > > > > >
                      > > > > > BFN. Paul.
                      > > > > >
                      > > > > >
                      > > > > >
                      > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                      > > > > > >
                      > > > > > > no, just the stock 8.5 version from sourceforge
                      > > > > > >
                      > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                      > > > > > > >
                      > > > > > > > By default PDPCLIB does not use memmgr. Even when
                      > > > > > > > it does, the default allocation is 60 MB not 10 MB.
                      > > > > > > >
                      > > > > > > > So are you talking about the behaviour of your own
                      > > > > > > > version of PDPCLIB?
                      > > > > > > >
                      > > > > > > > BFN. Paul.
                      > > > > > > >
                      > > > > > > >
                      > > > > > > >
                      > > > > > > >
                      > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                      > > > > > > > >
                      > > > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                      > > > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                      > > > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                      > > > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                      > > > > > > > > -- ???
                      > > > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                      > > > > > > > >
                      > > > > > > >
                      > > > > > >
                      > > > > >
                      > > > >
                      > > >
                      > >
                      >
                    • mfnoel
                      I did notice that STDCOMP PARM on the GCCCMS F disk (GCC691) says -DUSE_MEMMGR. None of the other PARM files I saw say that.
                      Message 10 of 13 , Oct 14, 2011
                        I did notice that STDCOMP PARM on the GCCCMS F disk (GCC691) says -DUSE_MEMMGR. None of the other PARM files I saw say that.


                        --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                        >
                        > No old versions apparent. Y (mnt19e) has pdpclib txtlib with 1549 recs dated 6/6/9. My CMSUSER B drive has a pdpclib txtlib with 1589 recs dated 1/1/11 (that's the one from the sourceforge distro "gcccms-3_2_3-8_5-exe.vmarc") and I have the CMSUSER B drive released when I want to use the older compiler/library that came with the 6pk. There is also a version on the GCCCMS E drive (GCC591) that's 1549 recs dated 6/11/9, but I've not tried it.
                        >
                        > I have not so far tried to rebuild pdpclib but have been reading up on what's necessary...
                        >
                        > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                        > >
                        > > No, that should be fine. If USE_MEMMGR is undefined
                        > > it will be 0 and that will be false.
                        > >
                        > > I have an explanation for the 10 MB result though.
                        > > 60 MB % 16 MB = 10 MB, so the theory that memmgr
                        > > is being used is consistent.
                        > >
                        > > Note that during the build process it first builds
                        > > a memmgr version of PDPCLIB, so maybe that isn't
                        > > being successfully replaced.
                        > >
                        > > Can you also do a LISTF PDPCLIB TXTLIB * to see if
                        > > you are picking up an old rogue version of it?
                        > >
                        > > BFN. Paul.
                        > >
                        > >
                        > >
                        > >
                        > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                        > > >
                        > > > I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...
                        > > >
                        > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                        > > > >
                        > > > > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                        > > > > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                        > > > > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                        > > > > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                        > > > > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                        > > > > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                        > > > > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                        > > > > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                        > > > > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                        > > > > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                        > > > > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                        > > > > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                        > > > > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                        > > > > which shows the big chunk still there but memory alloc/free happening above it.
                        > > > > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                        > > > > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                        > > > >
                        > > > >
                        > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                        > > > > >
                        > > > > > #include <stdio.h>
                        > > > > > int main (int argc, char *argv[]) {
                        > > > > > int *MAINSTRT = (int*)0x504;
                        > > > > > int *MAINHIGH = (int*)0x510;
                        > > > > > int *FREELOWE = (int*)0x514;
                        > > > > > int *LOCCNT = (int*)0x574;
                        > > > > > char memtrcbuf[80];
                        > > > > > int i=0; char *m[5];
                        > > > > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                        > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                        > > > > > for (i=0; i<5; i++) {
                        > > > > > m[i] = malloc((i+1)*100);
                        > > > > > if (m[i] == 0) exit(999);
                        > > > > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                        > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                        > > > > > }
                        > > > > > for (i=5; i>0; i--) {
                        > > > > > free(m[i-1]);
                        > > > > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                        > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                        > > > > > }
                        > > > > > }
                        > > > > > gives
                        > > > > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                        > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                        > > > > >
                        > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                        > > > > > >
                        > > > > > > So if you just type in "hexdump" to get the usage, it
                        > > > > > > immediately gets 10 MB too?
                        > > > > > >
                        > > > > > > What method are you using to determine how much memory
                        > > > > > > is being obtained?
                        > > > > > >
                        > > > > > > It could be something related to the OS emulation
                        > > > > > > support. Maybe the first person who does a GETMAIN,
                        > > > > > > even if it's for only 1 byte, causes CMS to reserve
                        > > > > > > 10 MB to dish out to other GETMAIN requests.
                        > > > > > >
                        > > > > > > BFN. Paul.
                        > > > > > >
                        > > > > > >
                        > > > > > >
                        > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                        > > > > > > >
                        > > > > > > > no, just the stock 8.5 version from sourceforge
                        > > > > > > >
                        > > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                        > > > > > > > >
                        > > > > > > > > By default PDPCLIB does not use memmgr. Even when
                        > > > > > > > > it does, the default allocation is 60 MB not 10 MB.
                        > > > > > > > >
                        > > > > > > > > So are you talking about the behaviour of your own
                        > > > > > > > > version of PDPCLIB?
                        > > > > > > > >
                        > > > > > > > > BFN. Paul.
                        > > > > > > > >
                        > > > > > > > >
                        > > > > > > > >
                        > > > > > > > >
                        > > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                        > > > > > > > > >
                        > > > > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                        > > > > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                        > > > > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                        > > > > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                        > > > > > > > > > -- ???
                        > > > > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                        > > > > > > > > >
                        > > > > > > > >
                        > > > > > > >
                        > > > > > >
                        > > > > >
                        > > > >
                        > > >
                        > >
                        >
                      • kerravon86
                        The build procedure (compile exec) switches to stdpdp parm, where it has XXX_MEMMGR defined instead (which does nothing). BFN. Paul.
                        Message 11 of 13 , Oct 14, 2011
                          The build procedure (compile exec) switches to stdpdp parm,
                          where it has XXX_MEMMGR defined instead (which does nothing).

                          BFN. Paul.



                          --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                          >
                          > I did notice that STDCOMP PARM on the GCCCMS F disk (GCC691) says -DUSE_MEMMGR. None of the other PARM files I saw say that.
                          >
                          >
                          > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                          > >
                          > > No old versions apparent. Y (mnt19e) has pdpclib txtlib with 1549 recs dated 6/6/9. My CMSUSER B drive has a pdpclib txtlib with 1589 recs dated 1/1/11 (that's the one from the sourceforge distro "gcccms-3_2_3-8_5-exe.vmarc") and I have the CMSUSER B drive released when I want to use the older compiler/library that came with the 6pk. There is also a version on the GCCCMS E drive (GCC591) that's 1549 recs dated 6/11/9, but I've not tried it.
                          > >
                          > > I have not so far tried to rebuild pdpclib but have been reading up on what's necessary...
                          > >
                          > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                          > > >
                          > > > No, that should be fine. If USE_MEMMGR is undefined
                          > > > it will be 0 and that will be false.
                          > > >
                          > > > I have an explanation for the 10 MB result though.
                          > > > 60 MB % 16 MB = 10 MB, so the theory that memmgr
                          > > > is being used is consistent.
                          > > >
                          > > > Note that during the build process it first builds
                          > > > a memmgr version of PDPCLIB, so maybe that isn't
                          > > > being successfully replaced.
                          > > >
                          > > > Can you also do a LISTF PDPCLIB TXTLIB * to see if
                          > > > you are picking up an old rogue version of it?
                          > > >
                          > > > BFN. Paul.
                          > > >
                          > > >
                          > > >
                          > > >
                          > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                          > > > >
                          > > > > I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...
                          > > > >
                          > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                          > > > > >
                          > > > > > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                          > > > > > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                          > > > > > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                          > > > > > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                          > > > > > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                          > > > > > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                          > > > > > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                          > > > > > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                          > > > > > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                          > > > > > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                          > > > > > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                          > > > > > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                          > > > > > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                          > > > > > which shows the big chunk still there but memory alloc/free happening above it.
                          > > > > > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                          > > > > > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                          > > > > >
                          > > > > >
                          > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                          > > > > > >
                          > > > > > > #include <stdio.h>
                          > > > > > > int main (int argc, char *argv[]) {
                          > > > > > > int *MAINSTRT = (int*)0x504;
                          > > > > > > int *MAINHIGH = (int*)0x510;
                          > > > > > > int *FREELOWE = (int*)0x514;
                          > > > > > > int *LOCCNT = (int*)0x574;
                          > > > > > > char memtrcbuf[80];
                          > > > > > > int i=0; char *m[5];
                          > > > > > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                          > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                          > > > > > > for (i=0; i<5; i++) {
                          > > > > > > m[i] = malloc((i+1)*100);
                          > > > > > > if (m[i] == 0) exit(999);
                          > > > > > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                          > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                          > > > > > > }
                          > > > > > > for (i=5; i>0; i--) {
                          > > > > > > free(m[i-1]);
                          > > > > > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                          > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                          > > > > > > }
                          > > > > > > }
                          > > > > > > gives
                          > > > > > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                          > > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                          > > > > > >
                          > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                          > > > > > > >
                          > > > > > > > So if you just type in "hexdump" to get the usage, it
                          > > > > > > > immediately gets 10 MB too?
                          > > > > > > >
                          > > > > > > > What method are you using to determine how much memory
                          > > > > > > > is being obtained?
                          > > > > > > >
                          > > > > > > > It could be something related to the OS emulation
                          > > > > > > > support. Maybe the first person who does a GETMAIN,
                          > > > > > > > even if it's for only 1 byte, causes CMS to reserve
                          > > > > > > > 10 MB to dish out to other GETMAIN requests.
                          > > > > > > >
                          > > > > > > > BFN. Paul.
                          > > > > > > >
                          > > > > > > >
                          > > > > > > >
                          > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                          > > > > > > > >
                          > > > > > > > > no, just the stock 8.5 version from sourceforge
                          > > > > > > > >
                          > > > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                          > > > > > > > > >
                          > > > > > > > > > By default PDPCLIB does not use memmgr. Even when
                          > > > > > > > > > it does, the default allocation is 60 MB not 10 MB.
                          > > > > > > > > >
                          > > > > > > > > > So are you talking about the behaviour of your own
                          > > > > > > > > > version of PDPCLIB?
                          > > > > > > > > >
                          > > > > > > > > > BFN. Paul.
                          > > > > > > > > >
                          > > > > > > > > >
                          > > > > > > > > >
                          > > > > > > > > >
                          > > > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                          > > > > > > > > > >
                          > > > > > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                          > > > > > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                          > > > > > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                          > > > > > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                          > > > > > > > > > > -- ???
                          > > > > > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                          > > > > > > > > > >
                          > > > > > > > > >
                          > > > > > > > >
                          > > > > > > >
                          > > > > > >
                          > > > > >
                          > > > >
                          > > >
                          > >
                          >
                        • mfnoel
                          Hard to say what I may have broke, but I recompiled START & STDLIB (wo/USE_MEMMGR) and have a fixed pdpclib with them. KICKS now runs in a 2M vm instead of
                          Message 12 of 13 , Oct 14, 2011
                            Hard to say what I may have broke, but I recompiled START & STDLIB (wo/USE_MEMMGR) and have a 'fixed' pdpclib with them. KICKS now runs in a 2M vm instead of 12M, and GCC apps work!
                            Assuming it seems stable I suppose I could just distribute this fixed library with KICKS. Is it generally true that an 8.5 library should be OK for use with 7.0 compiled pgms?


                            --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
                            >
                            > The build procedure (compile exec) switches to stdpdp parm,
                            > where it has XXX_MEMMGR defined instead (which does nothing).
                            >
                            > BFN. Paul.
                            >
                            >
                            >
                            > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > >
                            > > I did notice that STDCOMP PARM on the GCCCMS F disk (GCC691) says -DUSE_MEMMGR. None of the other PARM files I saw say that.
                            > >
                            > >
                            > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > > >
                            > > > No old versions apparent. Y (mnt19e) has pdpclib txtlib with 1549 recs dated 6/6/9. My CMSUSER B drive has a pdpclib txtlib with 1589 recs dated 1/1/11 (that's the one from the sourceforge distro "gcccms-3_2_3-8_5-exe.vmarc") and I have the CMSUSER B drive released when I want to use the older compiler/library that came with the 6pk. There is also a version on the GCCCMS E drive (GCC591) that's 1549 recs dated 6/11/9, but I've not tried it.
                            > > >
                            > > > I have not so far tried to rebuild pdpclib but have been reading up on what's necessary...
                            > > >
                            > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                            > > > >
                            > > > > No, that should be fine. If USE_MEMMGR is undefined
                            > > > > it will be 0 and that will be false.
                            > > > >
                            > > > > I have an explanation for the 10 MB result though.
                            > > > > 60 MB % 16 MB = 10 MB, so the theory that memmgr
                            > > > > is being used is consistent.
                            > > > >
                            > > > > Note that during the build process it first builds
                            > > > > a memmgr version of PDPCLIB, so maybe that isn't
                            > > > > being successfully replaced.
                            > > > >
                            > > > > Can you also do a LISTF PDPCLIB TXTLIB * to see if
                            > > > > you are picking up an old rogue version of it?
                            > > > >
                            > > > > BFN. Paul.
                            > > > >
                            > > > >
                            > > > >
                            > > > >
                            > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > > > > >
                            > > > > > I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...
                            > > > > >
                            > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > > > > > >
                            > > > > > > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                            > > > > > > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                            > > > > > > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                            > > > > > > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                            > > > > > > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                            > > > > > > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                            > > > > > > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                            > > > > > > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                            > > > > > > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                            > > > > > > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                            > > > > > > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                            > > > > > > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                            > > > > > > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                            > > > > > > which shows the big chunk still there but memory alloc/free happening above it.
                            > > > > > > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                            > > > > > > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                            > > > > > >
                            > > > > > >
                            > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > > > > > > >
                            > > > > > > > #include <stdio.h>
                            > > > > > > > int main (int argc, char *argv[]) {
                            > > > > > > > int *MAINSTRT = (int*)0x504;
                            > > > > > > > int *MAINHIGH = (int*)0x510;
                            > > > > > > > int *FREELOWE = (int*)0x514;
                            > > > > > > > int *LOCCNT = (int*)0x574;
                            > > > > > > > char memtrcbuf[80];
                            > > > > > > > int i=0; char *m[5];
                            > > > > > > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                            > > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                            > > > > > > > for (i=0; i<5; i++) {
                            > > > > > > > m[i] = malloc((i+1)*100);
                            > > > > > > > if (m[i] == 0) exit(999);
                            > > > > > > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                            > > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                            > > > > > > > }
                            > > > > > > > for (i=5; i>0; i--) {
                            > > > > > > > free(m[i-1]);
                            > > > > > > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                            > > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                            > > > > > > > }
                            > > > > > > > }
                            > > > > > > > gives
                            > > > > > > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                            > > > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                            > > > > > > >
                            > > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                            > > > > > > > >
                            > > > > > > > > So if you just type in "hexdump" to get the usage, it
                            > > > > > > > > immediately gets 10 MB too?
                            > > > > > > > >
                            > > > > > > > > What method are you using to determine how much memory
                            > > > > > > > > is being obtained?
                            > > > > > > > >
                            > > > > > > > > It could be something related to the OS emulation
                            > > > > > > > > support. Maybe the first person who does a GETMAIN,
                            > > > > > > > > even if it's for only 1 byte, causes CMS to reserve
                            > > > > > > > > 10 MB to dish out to other GETMAIN requests.
                            > > > > > > > >
                            > > > > > > > > BFN. Paul.
                            > > > > > > > >
                            > > > > > > > >
                            > > > > > > > >
                            > > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > > > > > > > > >
                            > > > > > > > > > no, just the stock 8.5 version from sourceforge
                            > > > > > > > > >
                            > > > > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                            > > > > > > > > > >
                            > > > > > > > > > > By default PDPCLIB does not use memmgr. Even when
                            > > > > > > > > > > it does, the default allocation is 60 MB not 10 MB.
                            > > > > > > > > > >
                            > > > > > > > > > > So are you talking about the behaviour of your own
                            > > > > > > > > > > version of PDPCLIB?
                            > > > > > > > > > >
                            > > > > > > > > > > BFN. Paul.
                            > > > > > > > > > >
                            > > > > > > > > > >
                            > > > > > > > > > >
                            > > > > > > > > > >
                            > > > > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                            > > > > > > > > > > >
                            > > > > > > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                            > > > > > > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                            > > > > > > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                            > > > > > > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                            > > > > > > > > > > > -- ???
                            > > > > > > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                            > > > > > > > > > > >
                            > > > > > > > > > >
                            > > > > > > > > >
                            > > > > > > > >
                            > > > > > > >
                            > > > > > >
                            > > > > >
                            > > > >
                            > > >
                            > >
                            >
                          • kerravon86
                            Yes, as far as I know 7.0 and 8.5 should be compatible, and it s been a long time since the compiler changed in a way that would make it incompatible. Good
                            Message 13 of 13 , Oct 15, 2011
                              Yes, as far as I know 7.0 and 8.5 should be compatible,
                              and it's been a long time since the compiler changed in
                              a way that would make it incompatible.

                              Good news that you managed to fix PDPCLIB. Not sure
                              what's going wrong with the build process.

                              BFN. Paul.



                              --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                              >
                              > Hard to say what I may have broke, but I recompiled START & STDLIB (wo/USE_MEMMGR) and have a 'fixed' pdpclib with them. KICKS now runs in a 2M vm instead of 12M, and GCC apps work!
                              > Assuming it seems stable I suppose I could just distribute this fixed library with KICKS. Is it generally true that an 8.5 library should be OK for use with 7.0 compiled pgms?
                              >
                              >
                              > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                              > >
                              > > The build procedure (compile exec) switches to stdpdp parm,
                              > > where it has XXX_MEMMGR defined instead (which does nothing).
                              > >
                              > > BFN. Paul.
                              > >
                              > >
                              > >
                              > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > >
                              > > > I did notice that STDCOMP PARM on the GCCCMS F disk (GCC691) says -DUSE_MEMMGR. None of the other PARM files I saw say that.
                              > > >
                              > > >
                              > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > > >
                              > > > > No old versions apparent. Y (mnt19e) has pdpclib txtlib with 1549 recs dated 6/6/9. My CMSUSER B drive has a pdpclib txtlib with 1589 recs dated 1/1/11 (that's the one from the sourceforge distro "gcccms-3_2_3-8_5-exe.vmarc") and I have the CMSUSER B drive released when I want to use the older compiler/library that came with the 6pk. There is also a version on the GCCCMS E drive (GCC591) that's 1549 recs dated 6/11/9, but I've not tried it.
                              > > > >
                              > > > > I have not so far tried to rebuild pdpclib but have been reading up on what's necessary...
                              > > > >
                              > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                              > > > > >
                              > > > > > No, that should be fine. If USE_MEMMGR is undefined
                              > > > > > it will be 0 and that will be false.
                              > > > > >
                              > > > > > I have an explanation for the 10 MB result though.
                              > > > > > 60 MB % 16 MB = 10 MB, so the theory that memmgr
                              > > > > > is being used is consistent.
                              > > > > >
                              > > > > > Note that during the build process it first builds
                              > > > > > a memmgr version of PDPCLIB, so maybe that isn't
                              > > > > > being successfully replaced.
                              > > > > >
                              > > > > > Can you also do a LISTF PDPCLIB TXTLIB * to see if
                              > > > > > you are picking up an old rogue version of it?
                              > > > > >
                              > > > > > BFN. Paul.
                              > > > > >
                              > > > > >
                              > > > > >
                              > > > > >
                              > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > > > > >
                              > > > > > > I'm wondering if "#if USE_MEMMGR " (in several places) should actually be "#ifdef USE_MEMMGR "...
                              > > > > > >
                              > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > > > > > >
                              > > > > > > > Sorry for the previous mildly bugged post. My 1st printf was bad -- all the lines should be the same, ie,
                              > > > > > > > 1st- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > which shows that the big chunk of memory is grabbed before user code starts. Further, if you display the malloc returned pointers they are inside the big chunk. And if you code a similar program to use GETMAIN/FREEMAIN instead of MALLOC/FREE you get
                              > > > > > > > -1st- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                              > > > > > > > -m0- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                              > > > > > > > -m1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                              > > > > > > > -m2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                              > > > > > > > -m3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                              > > > > > > > -m4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6498, FREELOWE=D3C000
                              > > > > > > > -f5- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B62A0, FREELOWE=D3C000
                              > > > > > > > -f4- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B6110, FREELOWE=D3C000
                              > > > > > > > -f3- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5FE0, FREELOWE=D3C000
                              > > > > > > > -f2- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5F18, FREELOWE=D3C000
                              > > > > > > > -f1- LOCCNT=02D0A0, MAINSTRT=02D0A0, MAINHIGH=9B5EB0, FREELOWE=D3C000
                              > > > > > > > which shows the big chunk still there but memory alloc/free happening above it.
                              > > > > > > > If you link against gcclib instead of pdpclib (the getmain/freemain version of course) its the same except the big chunk is gone.
                              > > > > > > > This behavior is not unique to the gcccms 8.5 I installed from sourceforge: it also happens with the 7.0 that comes with the 6pk.
                              > > > > > > >
                              > > > > > > >
                              > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > > > > > > >
                              > > > > > > > > #include <stdio.h>
                              > > > > > > > > int main (int argc, char *argv[]) {
                              > > > > > > > > int *MAINSTRT = (int*)0x504;
                              > > > > > > > > int *MAINHIGH = (int*)0x510;
                              > > > > > > > > int *FREELOWE = (int*)0x514;
                              > > > > > > > > int *LOCCNT = (int*)0x574;
                              > > > > > > > > char memtrcbuf[80];
                              > > > > > > > > int i=0; char *m[5];
                              > > > > > > > > printf(" 1st- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                              > > > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                              > > > > > > > > for (i=0; i<5; i++) {
                              > > > > > > > > m[i] = malloc((i+1)*100);
                              > > > > > > > > if (m[i] == 0) exit(999);
                              > > > > > > > > printf(" -m%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                              > > > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                              > > > > > > > > }
                              > > > > > > > > for (i=5; i>0; i--) {
                              > > > > > > > > free(m[i-1]);
                              > > > > > > > > printf(" -f%d- LOCCNT=%06X, MAINSTRT=%06X, MAINHIGH=%06X, FREELOWE=%06X\n",
                              > > > > > > > > i, *LOCCNT, *MAINSTRT, *MAINHIGH, *FREELOWE);
                              > > > > > > > > }
                              > > > > > > > > }
                              > > > > > > > > gives
                              > > > > > > > > 1st- LOCCNT=000000, MAINSTRT=02D038, MAINHIGH=02D038, FREELOWE=9B5E48
                              > > > > > > > > -m0- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -m1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -m2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -m3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -m4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -f5- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -f4- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -f3- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -f2- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > > -f1- LOCCNT=02D038, MAINSTRT=02D038, MAINHIGH=9B5E48, FREELOWE=D44000
                              > > > > > > > >
                              > > > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                              > > > > > > > > >
                              > > > > > > > > > So if you just type in "hexdump" to get the usage, it
                              > > > > > > > > > immediately gets 10 MB too?
                              > > > > > > > > >
                              > > > > > > > > > What method are you using to determine how much memory
                              > > > > > > > > > is being obtained?
                              > > > > > > > > >
                              > > > > > > > > > It could be something related to the OS emulation
                              > > > > > > > > > support. Maybe the first person who does a GETMAIN,
                              > > > > > > > > > even if it's for only 1 byte, causes CMS to reserve
                              > > > > > > > > > 10 MB to dish out to other GETMAIN requests.
                              > > > > > > > > >
                              > > > > > > > > > BFN. Paul.
                              > > > > > > > > >
                              > > > > > > > > >
                              > > > > > > > > >
                              > > > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > > > > > > > > >
                              > > > > > > > > > > no, just the stock 8.5 version from sourceforge
                              > > > > > > > > > >
                              > > > > > > > > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                              > > > > > > > > > > >
                              > > > > > > > > > > > By default PDPCLIB does not use memmgr. Even when
                              > > > > > > > > > > > it does, the default allocation is 60 MB not 10 MB.
                              > > > > > > > > > > >
                              > > > > > > > > > > > So are you talking about the behaviour of your own
                              > > > > > > > > > > > version of PDPCLIB?
                              > > > > > > > > > > >
                              > > > > > > > > > > > BFN. Paul.
                              > > > > > > > > > > >
                              > > > > > > > > > > >
                              > > > > > > > > > > >
                              > > > > > > > > > > >
                              > > > > > > > > > > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                              > > > > > > > > > > > >
                              > > > > > > > > > > > > KICKS for CMS is mostly working on the VM/370 six pack, but one piece that is sorta not is GCC support. The problem is (I think) that PDPCLIB is built for the memory manager. When KICKS starts up it grabs nearly 10megs of the 14megs storage. Fine: maps and cobol programs come & go without any problem in what's left. But the first time I try to run a GCC program it goes out for another 10megs & I get an 80A abend! I can think of a couple ways around this but am looking for advice on the 'best' way. I've considered:
                              > > > > > > > > > > > > -- distribute custom pdpclib generated wo/memmgr, or
                              > > > > > > > > > > > > -- leave it to users who want to use gcc to build their own custom pdpclib - ie, point them to doc(gcccms), or
                              > > > > > > > > > > > > -- try to write KICKS code to bypass cmsstart and __start, maybe convincing memmgr to reserve lots less memory, or
                              > > > > > > > > > > > > -- ???
                              > > > > > > > > > > > > What I'm hoping is I didn't read carefully enough & there is actually some simple way to get the standard pdpclib to not use the memory manager (or to restrict the amount of memory it reserves).
                              > > > > > > > > > > > >
                              > > > > > > > > > > >
                              > > > > > > > > > >
                              > > > > > > > > >
                              > > > > > > > >
                              > > > > > > >
                              > > > > > >
                              > > > > >
                              > > > >
                              > > >
                              > >
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.