If memory serves me right I think 1.5 came out much earlier than 1997; more like 1992-93. To migrate to the latest version of ProIV you will need to do this in version steps as you can't upgrade directly from 1.5 to 8.2. You may want to consider using NorthgateArinso to migrate your source code as they probably have the older versions installed. Of course SCO is dead so you will need to decide what platform you want to run on; Linux or Windows. If you move to Windows you will have to find an alternate method to handle printing.
It's quite simple. This is what I would do for each file.
1. Copy the ProISAM ProIV filedef to a file with say a small 's' appended to the name. E.g. GL_MSTR to GL_MSTRs.
2. In the file definition header change GL_MSTRs to file type SQLSERVE. Set the physical name as GL_MSTR. You will also have to go into the storage tab and set the Ext Type, format and alternate name for each field. Alpha fields are ALPHA and numeric fields are NUMBER. For NUMBER the format is <total field length including precision>.<precision>. If the number can be a negative append the format with an "S". E.g. S8.2 (can store a max of 999999.99-)
3. In the file definition window use the SQL icons to create and save the script to a text file for GL_MSTRs.
4. In SQL Server Management Studio open the script previously created and execute it in the right database to create the table.
5. Create an update function that reads all of GL_MSTR in look mode and adds to GL_MSTRs in add mode.
6. Delete file definition GL_MSTR.
7. Rename file definition GL_MSTRs as GL_MSTR.
8. Regen functions that use GL_MSTR.
You will need to update your c:\windows\pro4v8.ini file with the appropriate SQL database settings. You will also need to create an ODBC driver on the server that has the ProIV kernel; it needs to point to the SQL Server database.
When I did this for our system in 2003 I automated the process by writing a series of functions that used the filedef bootstrap files to create one SQL table creation script file. I also wrote a function that automated the file renaming. If your system is large you may want to consider this route.
A word of caution with moving to SQL Server. Depending on how your system is written/structured you may encounter a lot of table locking. This is especially true for control files where you say get the next available invoice number. In ProISAM you can have a logical update that gets and increments the number. After the record is written it is unlocked and other sessions can read and update it. This is not true for SQL tables. Typically you will have to either exit the function to commit the records or execute a commit command in logic. Executing the commit command can have unwanted consequences with other tables you are processing. Because of this we continue to maintain our control files in ProISAM.
We started using OpenClient heavily when 7.1 was released. During this time we discovered and reported numerous problems to NGA with the way OC renders on the screen. When we upgraded to newer 7.1 releases some issues would get fixed whereas new ones would pop up. These are all issues that only applied to OC, not the MFC Client. The same thing happened when we migrated to 8.0 and 8.1. We are now on 8.2 and most of the rendering issues have been fixed. Since this issue didn`t exist in 184.108.40.206 you have struck a release that has broken your OC app. Since you are on the last release of 7.1 you have these options:
First check with NGA to see if this is a known problem with 220.127.116.11.
Create a new simple dummy one time screen that just has a couple of statics and a couple of scratch variables. If they render correctly then its probably not a one time screen issue.
Check the positioning of the fields in relation to their static prompts and their widths. Make sure there are no overlaps. I can`t remember the exact release we were on but we had the same issue where a field wasn`t displaying. Even though the static was not overlaying the field, we moved the field one more character to the right and it then displayed correctly. If that doesn`t work, do a test with stripping out all of the statics and see what happens.
Break your app down by deleting it into a simpler function until either you have nothing left or the last thing you delete fixes the problem. Change the screen to many time to see if that fixes it. Before I report an issue to NGA I always create a test case this way to send to them. Many times I have discovered the exact object that right or wrong fixes the problem. It may not help you in the end but it may help you to slightly redesign your function until it works again.
Go back to 18.104.22.168.
Test your app on an 8.2 installation and consider upgrading if it works OK. I know, this can be an expensive option.
My guess is you will eventually find a work around for this. It may be something simple you are doing that OC 22.214.171.124 (for right or wrong) is not expecting. Deleting components bit by bit always works for me.