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 switching
to another system with a 120 byte limit. The data will be interfaced data
back to us for our legacy applications and we are creating new file layouts
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 bytes
for descriptions. On the upside, based on a quick test I did, if I define
as VARLEN(30) and then later find out most are 50, I can change the DDS and
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 hammers
until I find out what size really hurts and what size is an annoyance. The
sledgehammer in the garage is definitely out of the running.
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon
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 bytes
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 answer.
My guess is that across the board it has little impact. The embedded length
avoids any overhead from (for example) scanning for hex zeros to determine
the end of the field. You will also have reduced disk access if you've got
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. You need
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" would be
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 access
to that file was within that 60%.
You should not "guess" - as a minimum you need to analyze your file and see
what the lengths are currently in use. Are 90% under xx bytes with the other
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) 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 http://archive.midrange.com/midrange-l.