Concerning: Migration from DF2.3b Enhanced towards DF3.1

I have done some investigating on possible traps concerning a migration towards DF3.1. We have to look into all possibilities. Any additional features can be added to this document.

I would also like to refer to the book ‘Transformation’ of Doug Goldner.

Investigation

Here are the issues that you should investigate.
There are 3 commands to set the data towards the Y2K compatibility. If it is used in conjunction with the adding of 693??? to the date, it will result in very odd dates. Double-check whether this number is still being used in the source codes.
When the customer has made changes to the original FMAC, these changes might also be necessary for the new DF3.1-FMAC.
We already know that many locks have been programmed in a way that locking does not guarantee data integrity. DF3.1 will result in error messages when locking has been used inefficiently. These might need to be replaced. An option to look at is to make transaction blocks and forget about manual locking (ad hoc).
MIN and MAX operators in DF2.3 were introduced with the < > - sign. These signs have now another meaning. It are logical expressions (less than, greater than). When it is used at the project site, these commands might need to be changed to MIN MAX. (!!! The operators < > in expressions)
String expressions now have a new meaning. We can use expressions like a + b. This expression will lead to a concatenation, just as * and – can be used as well. This might result to missing and/or wrong information. I will give an example and you will immediately see that it is very hard to find it back in the sources.

/scr1
Description QtyIn QtyOut
___________ ____. _____.
___________ ____. _____.
Total ___ ____. _____.
/*

Autopage scr1
Page scr1
Move 'Line1' to scr1.1
Move 'Line2' to scr1.4
Move 20 to scr1.2
Move 30 to scr1.3
Move 40 to scr1.5
Move 50 to scr1.6
Move 'FLU' to scr1.7

String sKey
For Windowindex from 1 to 2
Calc (scr1.1& + scr1.4&) to scr1.7&
loop

inkey skey

You would expect that this would result in 60 and 80, but this is not true. This will result in 2040 and in 3050. This is of course something that throws another perspective on the migration phase. It will be a lot harder to investigate if these kind of expressions where used. This ends in these results because the type checking is interpreted otherwise. This means that all string expressions should be looked at.

Move ‘1’ to sVal1
Move ‘2’ to sVal2
Move (sVal1 + sVal2) to sVal3

This will result in 12 as the calculation is done on string values meaning a calculation.
While migrating, we can also change sysdate to sysdate4 commands, but this is not seen as a needed issue. However, if we need to make changes, we might want to look into this as well.

Remarks

  1. When Data Access first deployed their DF3.01 version they have defined a compiler variable called –X23. When compiling the sources with DF3.1 and using this, I can confirm that the <> operators and the string expressions are fully compatible with the 2.3b style. Looking at this parameter and if it is successful would gain us a lot of days. Especially testing with the locks, the inclusion on the year2000 commands and the changed FMAC should still be considered. However, if these changes are successful we could do the job in just a few days.
  2. Each of the above situations should have a little study on its own. We should compare the behavior between a normal compilation and compiling with the –x23 parameter.
  3. Test this application with a multi-user runtime, because locking in a single user version is excluded.

Hope this will help in making the best decision.

Frank Vandervelpen