5 replies to this topic

[Chris Pepper]

I had to laugh... I'm finally working on converting our development system from 3.0 to 5.5 and hit a problem with Tags.

Searching for help here I found an old topic I created that starts...
Posted 15 January 2003 - 06:40 AM

I've looked at the history on converting from 4.6 to 5.0. Has anyone any more comments?
I'm not interested in any GUI related changes as our ProIV is purely server side. I am interested in any bootstrap file changes as we store source in text files in a code management system and I need to load functions from this into a 5.0 environment. It won't be a one off as I'll need to support multiple versions for a while. Any comments on the 'Tags' would be helpful if they are related to non-gui code.

How optimistic was that!

Anyway I did get some clues to help from here. Just in case anyone else is upgrading from and end-of-life version to a slightly newer end-of-life version... I was getting a 729 - DUPLICATE FIELD TAG NAME error on genning. It appears the Import/Export is adding Tags to both the fields and LS - however @CFUN is not Tag aware so when I copied LS2 to LS3 on a Function it happily duplicated the name Cycle2 for both LS. It appears that Tags in Cycles aren't accessible in @MOD - at least if they are I can't find where! So just beware of that!
At least when I've finished getting our development environment up the real source code of our system won't be being loaded through Import/Export, it'll be loaded by my routines straight from the Source Code Control System.

[Rory]

Chris,

This has been a regular snag for us, moreso with screen field tags - our old dev environment allows a blank tag for a screen field, $XFR would then replace the blank tag with e.g. Dynamic1 which was already present and the gen would fail.
As you say @LS_TAGNAME (another favourite) isn't accessible in @MOD.

After reading your post I don't feel so bad about still being on 5.5.....!

Rory

[George Macken]

Hi Chris

Rory & I moved a large system from ver4 to ver5.5 in 2005. I recollect it was fairly easy to-do, there was some messing around with ini and piv files and some config required for arrows/Fkeys.

I would advise that you install a clean version of Version 5 and then review the list of function names and global logics supplied with the base install of pro-iv, you need to check that none of these names are used by the functions and global logics in your application. For example with Ver 5 there is a function named #, this had been a function name in our application on ver 4.

Functions
On your ver5 account check that user security category is ok for accessing the following bootstrap functions
@SFUNCT & @RFUNCT & FUNCHECK

Filedefs
When we migrated to 5.5 we identified that on VARDEF the variable @VDTVL was truncated to length of 79, beforehand it had been 132. The system we migrated has a dependency on usage Value Variables, we just amended the lenght back to 132.

If I think of anything else I will add to this (my memory/computer has not retained anthing of moving to ver 4!!!).

see also http://www.proivrc.c...ch__1#entry6200

Rgds

George

[Wim Soutendijk]

Hi Chris,

Do you have dots in your variable names? I remember we had to take out the dots in those names, because in verson 5.5 the dot is used to assign properties to labels.
we ran an update changing the (few) dots we had to underscore signs, and keep the dots in the alternate variable name, so we didn't have to rename these fields in the database.

Wim

[Chris Pepper]

Thanks for all the advice.

Just to note that we have been distributing all our Oracle and DB2 code under 4.6 and 5.5 for ages (more than 10 years) now, so we have no problems with variable naming that were not fixed a long time ago. It's just our development environment that we are moving to 5.5. We have very sophisticated mechanisms for translating the native isam code into Oracle compliant code as part of the automatic gen process before delivery. Now that most of the installed base is Oracle it makes sense to develop directly in an Oracle environment.
The changes are primarily in the interface with our code repository - when a developer checks out code in the new system we have to recognise that it was last saved from Isam then apply the code conversion as the source code is loaded into the development environment. Primarily this is because some of the alternate File Definitions had key structures that were not Oracle compliant (different numbers of key parts) so the code is automatically rewritten. Also any embedded SQL must be written as comments in the Isam code, then uncommented in the Oracle code.

I've had a couple of issues with 5.5, mainly where the Import/Export was applying tags to the code - but I only needed it to bootstrap the routines to interface with the code repository. Now I have them loaded and working I don't need Import/Export so tags are no longer an issue. Fortunately we're not using the ProIV GUI so I don't need to support any of the GUI features which seem to have lots of additional options.

[George Macken]

. . . _ _ _ . . .

Our system is Version 5.5 and ORACLE
The field names on the file definitions and other fields/scratch$#variables still primarily use the full.stop in the variable names, example CM.CLIENT.NAME
The alternate variable name on the file definition uses the under_score, example CM_CLIENT_NAME
The tag name on screen fileds does not use the full.stop or the under_score, example CmClientName

I recollect we also trialled conversion to verion 6 with the above variable namin convention and all was OK.
There are other posting on this forum on the usage or not of full.stop in the variable name.

We mainly use our own dev env and a little of @MOD.

Rgds

George