Converting 3.0 Programs

10.) We're now ready to convert the programs. There were two different options for source code in TAS Professional 3.0. They were .SRC or .EDT files. If you edited programs with the source code editor you have .EDT files. If you used a text editor then you probably have .SRC files, although, many people learned the codes for the .EDT format and, due to limitations of the editor, learned how to program by the numbers. In TAS Professional 5.1 there's only one format, .SRC. The editor can handle this format and it's the same file if you wish to use a text editor.

The conversion program doesn't care which you used, although, you can only convert one type

at a time.

To start the conversion program type: R50 C:\TAS50\CNVTPALL The first question it asks is what type of program you're converting. Since this is the 3.0 conversion you will enter either E (.EDT type) or S (.SRC type). Next enter the file path and name, wildcards are acceptable. So to convert all the BK*.EDT programs in the TAS30 subdirectory you would enter E for the program type and then the following for the file name(s): C:\TAS30\BK*

The program will then ask if you wish to convert DEFINE fields that are type N from BCD to new form floating point. In this case you would answer N if you have DEFINEd overlays in which one or more of the fields is an old form BCD.

NOTE: ** VERY IMPORTANT ** This conversion routine converts your old programs line-for-line. However, if you have DEFINEd overlays you need to make sure, after conversion, that the entire block of DEFINEs is at the beginning of the program. This is due to the way the 5.1 compiler adds fields to the field list during compilation. You may think you've got a contiguous block of data in memory but in reality you may not. By putting all the defined fields in that block at the beginning of the program you can be assured, they will be contiguous

in memory at runtime. This only applies to those DEFINEd fields that are also part of a DEFINEd overlay.

Once you enter the file name(s) the program will start the conversion process. During conversion the defined field are first located so that the screen/report formats can be converted properly. Next the lines are converted to the 5.1 .SRC format. As each line is converted the

program displays the line number and the percentage completed. Due to differences in programs and the process required the percentage will probably never be exactly 100 upon completion and is meant to be an approximation only. This process is very fast and should take

less than an hour. However, this is very dependent on the number of programs you're converting and the speed of your computer.

When this process is complete you should have a file in the new sub-directory with the same name as the program in the old. These will all have the extension .SRC.

Compile the converted programs

11) The next step is to compile the converted programs. We have found 3 general problems in this conversion process and they show up here. They are:

A) Multi-defined fields. In TAS Professional 3.0 you could define a field in a program several times and never get an error. This caused many problems when running, especially if you defined the field as one type at the beginning and another further down in the program. The compiler would always use the last DEFINE command so you would think the field was alpha when it was actually numeric and might spend hours trying to figure it out. In 4.0 we solved this problem and gave a syntax error for multiple defines. In 5.1, with the push to convert 3.0 code, we have made this a warning error in the compiler, and the DEFINE command itself will be ignored. This means that only the first DEFINE will be effective. The warning error is displayed, printed or sent to the .ERR file as appropriate. You should make sure that none of these are going to effect your program. However, if these are all the errors you get, the program will compile successfully and you will be able to run the program. This happens alot in many programs.

B) Another problem that was not caught by the 3.0 compiler was extra parentheses in an expression. In 5.1 the expression compiler is much more sophisticated and catches those kinds of errors. There's no way to tell which ones are just conversion and which are actually bad so this does become a syntax error and needs to be fixed before you can compile the program. This is generally not a big problem, and only happens occasionally.

C) The last is when your program accesses TASFILE or TASDICT fields in the dictionary. Since the data dictionary has changed completely so have the field names. If you have a program that does this you will have to go through it and change these references yourself. This should be very rare and shouldn't take you much time at all. We decided not to put this in the conversion routine due to the time it would take to check each and every field on the off-chance one of them was a TASFILE or TASDICT field. The corresponding field

names for those old dictionary files are:

OLD NEW FILE

-------------------------- ----------------------------- --------------

DICT.NAME DICT_FIELD_NAME FILEDICT

DICT.SCHEMA DICT_BUFF_NAME FILEDICT

DICT.SKEY DICT_OVERLAY1 FILEDICT

DICT.OFFSET DICT_OFFSET FILEDICT

DICT.TYPE DICT_TYPE FILEDICT

DICT.SIZE DICT_SIZE FILEDICT

DICT.DEC DICT_DEC FILEDICT

DICT.UPCASE DICT_UPCASE FILEDICT

DICT.KEY KEY_NAME2 FILEKEY

DICT.KEYN KEY_NUM2 FILEKEY

DICT.OVLY DICT_TYPE3 FILEDICT

DICT.SIZEH Internal size is calculated at runtime.

DICT.ARRAY DICT_ARRAY_ELE FILEDICT

DICT.DECH DICT_HDEC FILEDICT

DICT.SIZEHLD DICT_HSIZE FILEDICT

DICT.OFFH DICT_HOFFSETFILEDICT

BTLFNAME LOC_FILE_NAME FILELOC

BTLSCHEMA LOC_BUFF_NAME FILELOC

BLTMLOC LOC_LOCATION FILELOC

1 This is actually no longer a field but just a key. If you try to set this equal to something

you will get a field not found error during compilation. You need to set the

DICT_FIELD_NAME and DICT_BUFF_NAME equal to their individual parts and then

just use the key.

2 With segmented keys the whole key structure has been separated from the fields. There

really is no need anymore for key names to exist in the field structure so these are a little

more difficult. You can either use these fields, which are 24 element arrays, or use the

fields in FILEKNUM. A single record exists in this file for each key. The key name is in

KNUM_KEY_NAME and the number is in KNUM_KEY_NUMB.

3 Overlays are now just a separate type of V.

12.) The conversion process is now complete. All that's left is to run the programs. If you desire

you can slowly (or quickly) add the new features of TAS Professional 5.1 or you can just stick

with the 3.0 code. In fact, we have converted the 3.0 editor/screen painter/report writer so that

you can continue to edit program in 3.0 .EDT format. You will have to convert them to 5.1 before they can be compiled but that takes just a few moments, as you can see. The decision is yours.

Page url: http://www.cassoftware.com/tas/manual/converting3_0programs.htm