Re: Max length of a VARYING field

Hi Scott,

I'm from the era where it was considered good practice to choose a record length for disk files that would fit within a multiple of the disk's sector size. I don't think anyone worries about that these days, so it occurred to me to question why are we still paying such close attention to other hardware requirements? I suppose at some point when we have organic computers that don't have to worry about binary machine registers it will no longer matter. I don't know the hardware specifics of registers anymore, but my guess would be that a 4-byte integer would handle better than a 1- or 2-byte integer; possibly an 8-byte integer would be fastest, so you don't have to mask off all the other bytes before doing any register arithmetic. Or maybe the hardware handles half-words or double-words just as fast.

Btw, no, I can't think of any specific advantage to the other sizes, it just occurred to me that varying(x) implies other possibilities than 2, 4 or 8. For example, you said the hardware handles 1-byte integers natively. IIRC, Intel 386 chips and prior would handle 1 byte for memory transfer, but for integer arithmetic if you wanted to deal with 1 byte, you had to mask off the other byte of the word.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /



Scott Klement wrote:

Hi Peter,

Why VARYING(x) as opposed to VARYINGx? The former implies (to me anyway) that I can put whatever I want in there -- VARYING(1), VARYING(7), etc. Or maybe that's the intention; after all, why not?

I prefer VARYING4, VARYING8, etc, myself. However, Barbara said that they (the team at IBM) liked the parenthesis better. here's her message:
http://archive.midrange.com/rpg400-l/200705/msg00392.html

Let's be flexible. Aren't all these 2-byte, 4-byte integers simply those sizes because they're closer to what the hardware can handle?

Hardware typically is able to handle 1, 2, 4 and 8 bit integers natively. Note that when you define an integer in RPG (data types B, I and U) it must be one of those 4 sizes. Why would the prefix be different?

Bearing in mind that allowing other lengths (3,5,6,7 bytes) would make VARYING strings significantly slower, my question to you is this: What would be the advantage? Can you think of a situation where you'd want to use a 3-byte prefix, but a 4-byte wouldn't work just as well? Or a 5 byte where an 8 byte wouldn't work just as well? What would be the advantage of the other sizes?

Later responses mention a %indexsize BIF. Index? It's a current length subfield isn't it?. How about %sizelen, or %lensize or something? Unless it's considered an index to the end of the string...but I think most people think of it as the current length, hence the %len BIF.

I think something like %varysize() or %vsize() would be better than %sizelen() which seems ambiguous to me.

Or instead of giving us the size of the length prefix, maybe something like %addr(myVaryFld: *DATA) and %size(myVaryFld: *DATA) or %len(myVaryFld:*MAX)