Relationship between $STRING = and UDT size?

[Mike Luther]

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
wrongly.

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]

[Mel Bishop]

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.


------------------

[Michael Mattias]

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.


MCM

[Lance Edmonds]

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.



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

[Mike Luther]

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]

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]

[Michael Mattias]

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").

MCM


[This message has been edited by Michael Mattias (edited September 20, 2002).]

[Tom Hanlin]

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

------------------
Tom Hanlin
PowerBASIC Staff