This way if you change the size again (encryption, etc) you are covered.
Why do you think you are covered if you use allocate for varying length
fields and then enhance the column length (sometime) again?
If you do not specify ALLOCATE with a length, within the row only 16 Byte
(address of the overflow area) are reserved for the varying length field.
The content of all information within the varying length field is stored
within the overflow area. If the data is read the address of the overflow
area is determined and then the data is read from this address, which is an
additional database operation which could be avoided.
If you specify ALLOCATE with a length the number of bytes (specified with
ALLOCATE) is reserved within the record. Only varying length textes that are
longer than the number of the allocated bytes are stored within the overflow
area.
The the overflow area only must be accessed, if the longer textes are
stored/read.
The best performance can be reached if < ~ 80 Percent varying length textes
can be stored directly within the row.
If a column with an allocated varying length is enhanced, the programs with
native I/O on this table also have to (re-)compiled.
Because RPG stores the data structure with the maximum length of the varying
length fields within the RPG program. If the maximum length is changed, the
data structure must also be changed, i.e. the program needs to be
recompiled.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob
Berendt
Sent: Mittwoch, 31. Juli 2019 15:10
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Expanding a field in a file or adding a new field to the file
I think either/or would work. Since you plan on recompiling all programs
anyway.
I guess I would expand the existing column. Why waste the space in the
table by leaving the old column in there and add a new column? I've worked
with a major ERP package which expanded many of their columns. Even columns
like the key to the item master.
You could make the new column variable length and use the ALLOCATE to
accommodate the "usual" size. This way if you change the size again
(encryption, etc) you are covered.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Alan
Shore via MIDRANGE-L
Sent: Wednesday, July 31, 2019 9:03 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Alan Shore <ashore@xxxxxxxx>
Subject: Expanding a field in a file or adding a new field to the file
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
Hi everyone
Before I forget - we are on V7r3
Are we all sitting comfortably - then let me begin
We presently hold tokens instead of credit card numbers and the web service
calls that are made for settling, authorization, refunds etc. use the token
The token was of a length that we could store it in the old credit card
number field - 17 characters However - we have been informed that the size
of the token is going to increase - to larger than 17 characters
I understand that there will be NUMEROUS service programs, files, programs
etc, that will need to be changed and tested
Here is my question -
Opinion based or fact based - What would be better -
1. expanding the present field from 17 to a much larger field (say 50
- just in case of future increases)
2. Adding a new field (at the end of all the files)
Each has their own foibles (for want of a better word) For example:-
Option 1 - EVERY program that even touches any of the files that this type
of file change is applied to will need to be re-compiled (minimum) - even if
the program has nothing directly to do with this expanded field. However it
will be the same field name, therefore only need to be concerned about the
new field size and what is happening to that field (populating another field
for example)
Option 2 - EVERY program, service program etc. will need to be changed to
use the new field name. Not only need to be concerned about replacing the
old field name with the new field name within the program, service program
etc. but also need to be concerned about the new field size and what is
happening to that field (populating another field for example)
If anyone has more options - please feel free to pass those on
As always - all answers gratefully accepted
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
