And to add the usual proviso - IT DEPENDS!
Jon presented considerations that take into account some of the "DEPENDS" -
On 7/29/2014 8:46 PM, Vernon Hamberg wrote:
IBM recommends that your allocated length takes in 90-95% of the
records - this is best for performance. For space, set allocated to 0
- the default.
Performance, because it is not necessary to go to the auxiliary space
to get the rest of the data.
Normally I'd say the worst thing to do is NOT to set the allocated
length - the default is 0, so ALL data ends up in the auxiliary space
and you have a 2nd IO for each such field. But there might be space
reasons - this takes the least space, because what is stored in
auxiliary storage is ONLY the actual data, no padding at the end.
This link gives a great presentation of this - it's been around since
varying length was introduced. -
On 7/29/2014 12:12 PM, John R. Smith, Jr. wrote:
The current system has a 30 byte limit for descriptions but we are
to another system with a 120 byte limit. The data will be interfaced
back to us for our legacy applications and we are creating new file
to accommodate the new system. We have no idea what the users (or our
legacy applications) will do when they get access to an additional 90
for descriptions. On the upside, based on a quick test I did, if I
as VARLEN(30) and then later find out most are 50, I can change the
recreate the PF and not get level checks from my RPGLE programs.
So for now, I am going to have to experiment with different sizes of
until I find out what size really hurts and what size is an
sledgehammer in the garage is definitely out of the running.
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
Sent: Tuesday, July 29, 2014 12:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: Variable length fields question
On 2014-07-29, at 12:09 PM, "John R. Smith, Jr." <smith5646@xxxxxxxxx>
I have some questions about variable length fields in files created
even if all 100 are spaces.
When I learned about them, I was told that if there is a field with a
100 bytes with a VARLEN(20), the system allocates 20 bytes in the
record and if the value is longer than 20 bytes, it stores the
additionally needed bytes elsewhere. When the record is read, the OS
knows to retrieve the 20 bytes from the record and concatenates the
additional bytes from the elsewhere storage (if any exist) and it
returns a 100 byte field. The net result is less DASD tied up with
extraneous spaces in the file with no impact to the developer.
However, when I look at the file via DSPPFM or WRKLNK, I see all 100
My questions are:
Yes it is - your understanding is basically correct.
1) Is the OS smart enough to pad out the 21-100 bytes when displayed
via WRKLNK and DSPPFM so I don't see the difference or is my
understanding of how the DDS VARLEN works flawed?
2) Assuming my VARLEN is guessed correctly and most records fit into
the allocated bytes, is there any noticeable impact with using VARLEN
So much depends on how the file is used that that is really hard to
My guess is that across the board it has little impact. The embedded
avoids any overhead from (for example) scanning for hex zeros to
the end of the field. You will also have reduced disk access if
the retain value set right - which is a very slow process relatively.
3) If my guess is incorrect and a big chunk of records require the
This is in the category of "Doctor my head hurts when I bang it with a
additional 21-100 bytes, does this have a huge performance impact?
hammer" - You can cure it very easily by stopping using the hammer.
to make sure that the retention value is set high enough to avoid the
additional disk access. For some uses, 80% of the records "fitting"
good enough. For others 90% would be a better target but I've seen shops
that went as low as 60% because they knew that the vast majority of
to that file was within that 60%.
You should not "guess" - as a minimum you need to analyze your file
what the lengths are currently in use. Are 90% under xx bytes with
10% widely spread? etc. etc.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.