No announcement yet.

Relationship between $STRING = and UDT size?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Relationship between $STRING = and UDT size?

    Suddenly, again .. whole pile full of 511 and 611 errors. Same song
    with huge programs and memory that others outside of OS/2 will
    likely never be able to see.

    But! Maybe insight?

    My UDT sizes in a seven of the programs in the suite have grown into
    the limit range of the almost full 16384 byte max allowable for such
    things. OK .. yes, I've learned it is safer to make them all divisible
    evenly by four (4) and that's made life more civilized rightly or

    But now back to the issue of changing one line of code up and around
    the 62K-64K MAIN mark and forced added $SEGMENT statements to even
    keep going here... Move a $SEGMENT one way or another .. add a variable
    whatever ... old story, but fully infested with it at this point.

    But -- on hunch or research or whatever, I increased my $STRING
    directive to $STRING = 16 from the older $STRING = 8 in one of the
    offending programs and ... poof! No more wrong out of stack space,
    611's and 511's and so on at this point in two programs giving me fits
    for several days now...

    Is this something I've been missing all along, that the $STRING size
    must at least equal the max size for a UDT which is determined in
    the source for a program?

    If so .. what about all the myriad of libraries and those made up
    into PBU's that are all benchmarks for standardized lower level
    work with these very large 25000 line up programs? None of the
    underlaying .PBU's and so on have anything like this UDT size in
    them. It's just this sub-suite of .EXE's that have to use them
    as life gets more complicated.

    OK, right or wrong and it works, or seems to. But do I now have to
    go back in and recompile all the master libraries for this change
    if nothing else but for safety or perceived safety sake? They too
    or many of them are used in these executables everywhere in them.

    I can do it. It'll mean another complete master pass at the entire
    111 libraries and EXE's in the suite and a full major release update
    for the code. But if that's the or a potential 'fix' for problems
    or future troubles and instability of the product, so what... The
    automated moron make master file and program for auto-refurbish will
    get another run...

    Or is this another one of these never-never know or demo deals?
    Just more hocus pocus and I haven't solved anything by this
    experiment, really?

    Thoughts please ..

    Mike Luther
    [email protected]
    Mike Luther
    [email protected]

  • #2
    Mike, I don't have an answer to your specific question but if
    you will allow for a suggestion:

    If you have a really large program, you may want to consider the
    use of the CHAIN capability. This will allow you to chop your
    program into smaller more manageable chunks and makes debugging
    one heck of a lot easier.

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3
      Is this something I've been missing all along, that the $STRING size
      must at least equal the max size for a UDT which is determined in
      the source for a program
      I have never seen this documented, but if you are doing something like...
      LSET udt = (any dynamic string)
      ' or
      (dynamic string) = STRING$(LEN(udt))
      ' or
      (dynamic string) = PEEK$(VARPTR(udt), LEN(udt))
      .. that actually makes perfect sense.


      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]


      • #4
        As that operation clearly involves dynamic strings, the operations are clearly covered by the documentation relating to $STRING.

        That is, $STRING specifies the maximum string size in all places that a string might be used, not just in relation to what may be stored in string variables.

        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        mailto:[email protected]


        • #5
          Yes, friend Michael .. in handling Binary lookup stuff in large
          chunks that were related to UDT's, that is exactly how I wound up
          long ago and far away at the $STRING = 8 size! Been a long time
          now and much of my life got lot's easier with that size which looks
          like it just caught all the possibilities.

          Then, as I expanded this main UDT to these huge dimensions, all heck
          broke loose again in this specialized collection of programs.

          To be more honest about how I arrived at this 'perhaps' this is
          related, I got there from Btrieve! This UDT is involved with Btrieve
          files. I use compression buffer techniques with Btrieve. Suddenly
          I got a "Compression Buffer Too Small" error with it! Duhhh, what's
          that now, Mikey, from years ago it took me a while to unconfuse?
          I finally 'learned' that the /U:# buffer setting in the BTI.CFG file
          is a direct "1K" per record sizing for that. I learned that as I hit
          the 16 size for this needed UDT, which forms the record for the Btrieve
          file, I had to use /U:16 in the setup!

          And, keep in mind as well, that the entire Btrieve interface is done
          in in-line assembler inside PB 3.5 as well. That may affect this
          maximum string size deal too.

          Aha! Mule has been hit in nosey with the 2X4 here! Ever see a mule
          rub its nose with a hoof?

          Now these huge programs don't ALWAYS have this problem. You'll hit a
          place where it erupts. You make a few changes and it goes away. If
          it is stable, makes no difference. Then a few hours of code work later
          off we go again into the time sewer figit with this and that.

          Now in THIS case, there is no use of the UDT as a pure string in these
          programs at all. There are only 1133 discrete variables in it now which
          have to be mangled within the Btrieve file committed back and forth to
          and from the disk, locked, unlocked, manipulated for each tiny change
          that is made in real-time as the suite moves forward in real-time
          with all the operational interfaces ...

          That's why the CHAIN function is useless or near useless.

          You can't have network awareness of some 2000 'common' variables across
          the network if they are all hidden in some data-pig's memory!
          Each box on the network has to know exactly the split second it can
          properly have access to pieces of the data. You can't sell the
          same seat in the airplane twice when running out of seats in a
          mission critical medical flight would perhaps kill the patient!

          So I made the 'leap of Btrieve faith' and bumped the $STRING = to 16!
          Just took a 'what if' Alice in Wonderland curiouser and curiouser gambit!
          It's too soon to tell yet, but suddenly ... no more 515's and 611's and
          Out of Stack space that simply isn't true ... for two whole days of
          development time now....

          Darn I wish PowerBASIC where there in OS/2.

          I've even got a for-real OS/2 Developer's Kit for Btrieve. Roll Forward,
          Roll Back, and all are absolutely wonderful with it. To date in all these
          years I've never lost a single file or record with it .. ever .. as a
          result of what was going on with any given record.

          And yes, PowerBASIC is right up there with it for stability and rock solid
          operations there too. The mule just has to learn where the rows are and
          how to make the Go Devil turn on a dime at the ends with a side-step or two!

          Mike Luther
          [email protected]
          Mike Luther
          [email protected]


          • #6
            Gee Lance thanks!

            You posted whilst I was composing Michael's reply.

            I wonder if we have finally hit on something I am doing wrong with a few
            of these really hard to find deals I've described?

            As I long ago noted, Mule isn't the smartest slave on the plantation,
            but he tries so hard to be able to go to church with all the rest.

            Mike Luther
            [email protected]
            Mike Luther
            [email protected]


            • #7
              You can't have network awareness of some 2000 'common' variables across the network
              I first saw a posting of yours which outlined this massive number of "common" variables, I'll betcha it was three-four years ago.

              I am not going to say it is a crummy design, but:

              1. Three years ago I thought it was a crummy design.
              2. I am at an age where I do not easily change my mind.

              (I think you can do the math.)

              You really need to reconsider any system with that many "common" datanames. Disk drives today are as fast as memory was then, so the speed argument is gone.

              All that said, this $STRING thing is interesting. If confirmed by PB, this will no doubt be the record for 'longest-lived undiscovered bug!" (Compiler should have errored out with "attempt to use string access in excess of current $STRING segment size").


              [This message has been edited by Michael Mattias (edited September 20, 2002).]
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]


              • #8
                Please resist the urge to criticize when you are not familiar with
                the design constraints. This is not constructive behavior.

                Tom Hanlin
                PowerBASIC Staff