Alan,
Also, in this particular case, to deal with the new larger "Tokens" you could use a different technique that does not require changing any of the existing PFs or LFs -- just create one new table.
Create a new database table to store the "tokens" along with some kind of auto-generated key that will easily fit within your existing 17 position field. The idea is to only ever maintain those "tokens" in one and only one place.
Also, there should really be very few programs or service programs (procedures) that ever really need to know how or where these tokens are actually stored. For example, a 4-byte binary integer ("10i 0") can easily hold up to 2 billion (or 4 billion if unsigned) unique values, so how many unique "tokens" does your application ever really have to deal with? A four-byte integer can also easily be represented as 10 digits. (If you ever need to maintain and store a massive number of unique tokens, you could also consider a "20i 0" 8-byte integer.)
That way, in the future, if you ever need to expand this "token" column again, you only need to "touch" just that one "tokens" table, and one service program (and its procedures) responsible for maintaining that table.
Does that help?
Mark S. Waterbury
On Wednesday, July 31, 2019, 3:48:55 PM EDT, Alan Shore via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Thanks for the reply Mark
Now that this idea has sunk in a little more, here is where I am having a problem
Tell me where I am going wrong
I change the physical to add a new field (called - NEWTOKEN)
Create new logicals - defining all the fields in the physical (including NEWTOKEN) and use these logicals where the new field NEWTOKEN is required
Here is the point I need to make
The logicals that are already built - but do NOT define ANY field - will be recreated to include the NEWTOKEN field and will have an new level identifier - correct?
That means the programs that use these logicals will still need to be recompiled
OR
Change the level check on these logicals to *NO
Im not saying that this is a showstopper for this process - just trying to cover all bases BEFORE work is started where I end up saying - HMMMMMMMMMMMMMMMM
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
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Mark Waterbury
Sent: Wednesday, July 31, 2019 3:38 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXTERNAL] Re: Expanding a field in a file or adding a new field to the file
Alan, and Charles,
Do not force the issue of converting from DDS to SQL DDL ... at least, not "right away" ...
In this case, for "legacy" applications, you can still use DDS to create a Logical File that has the exact same record layout, record format level ID, and it will have an index and so "native" Record I/O (e.g. RPG SETLL, READE etc.) will all work just fine.
This technique has been available since the days of the System/38 and CPF, and I am very surprised that more people are seemingly not aware of this method to avoid having to recompile all of the programs that use the "base" physical file, every time you want to add or change a single field or column in a database physical file.
Hope that helps,
Mark S. Waterbury
On Wednesday, July 31, 2019, 3:07:22 PM EDT, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
Sure it will...
Assume you have 100 programs that access the table now.
But only 10 actually do anything with the CC token column...
Instead of recompiling and testing 100 programs, you need only recompile and test 10.
Only catch is RPG programs that use RPG record level I/O through an SQL index (instead of a keyed logical file) Those would also need to be recompiled and tested as explicitly including columns in an SQL index changes the record layout...but that would only be needed this time. (Time time you change the table, you're golden.) I thought I had an RFE to change this...but guess not..
Charles
On Wed, Jul 31, 2019 at 12:19 PM Alan Shore via MIDRANGE-L < midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Thanks Sam
That article definitely helped
However, Im still not 100% sure this will help in what I need
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
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On
Behalf Of Sam_L
Sent: Wednesday, July 31, 2019 2:08 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: Expanding a field in a file or adding a
new field to the file
This article *might* help understand what Charles is suggesting:
https://www.mcpressonline.com/programming/rpg/use-a-logical-file-layer
-to-minimize-recompiles-from-field-additions
Sam
On 7/31/2019 2:00 PM, Alan Shore via MIDRANGE-L wrote:
Hi Charles
Im not too sure I have an understanding on this
I tried to create some type of diagram, following what you suggested
- but its NOT working out Any chance you could make it simpler for a
simpleton like me?
Alan Shore
--
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
--
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
--
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
--
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
