GDA Woes

Our company are having a lot of problems getting our NaturalONE application to run without getting NAT0933 GDA Timestamp Conflicts. We are running NaturalONE with a UNIX host and have 6 developers all converting our Natural Application.

The set up we have is that we have one Natural Library which is a “Master” library which contains all our programs. Each developer is converting a Program and all Maps that are associated with it in their own Natural Libraries. Once they are happy, the objects are copied to a new “Converted” Natural Library and a steplib is set up to the Original “Master” Library. Our GDA is in the “Master” library and has not changed.
When each developer is converting their maps they need to add the GDA to their Project, which they do and keep it in the “Master” library and do not update this. When the new converted objects are merged together when they are completed we keep getting NAT0933 GDA Timestamp conflicts even though the GDA hasn’t changed.

It appears that when the GDA is added to a Developers project the Last modified date on the Source gets updated on the Local copy, but stays the same on the Server/host copy. How do we get around this problem?

Maybe I am missing something here, but why do the developers add the GDA to
their “local” projects, they don’t have to pull everything, the GDA can stay in a
STEPLIB.

Of course the timestamps do not match between the “developer library” and
the “converted library”.

Within NaturalONE, each developer has their own Project and when they are converting a Map and the associated program they are making the changes in their own Natural Libraries.

However, they have to add the GDA into their NaturalONE project otherwise when they try to Build the project an NAT0082 occurs as the GDA is not found. The GDA is kept in the “Master” Natural Library, so the Project can be Built successfully.

On the UNIX side of things, the GDA is only present in the “Master” Natural Library and the “Developers” and “Converted” Libraries all Steplib to the “Master” library.

On a NaturalONE Project level, each developers’ changes all work fine. When their converted Programs are moved to the “Converted” library is when the NAT0933 errors start (even if the Program are restowed).

What are we doing wrong?

Hi Matt,

Create a project with the GDA and any other ‘reference’ objects (or even the entire MASTER library) in it and add it to the project references in your development project’s properties. To prevent the objects being included in any build process, in the Navigator right-click the reference project and select NaturalONE|exclude.

We do this with our steplibbed common libraries. That way the parser/builder can find the objects and we don’t add clutter to our development projects.

I don’t understand why re-stowing doesn’t fix problem. Are you sure there isn’t a GDA in the converted lib? Do you catall the entire lib?

Cheers,

Graeme Lane

Hi Graeme,

Thanks for this. Sounds like a possible solution for our teams.

So does each developer create an extra project in their own workspace with all the steplibbed common libraries?

I don’t suppose you’d know if this Steplibbed Project could be centralised and referenced by each developer in some way

Or can all developers use one common workspace and create and use their own projects within this?

Regards
Matt

Matt,

no, a workspace can not be shared and no, the developers
still have to download the common (aka ‘referenced’) project, see
http://techcommunity.softwareag.com/ecosystem/documentation/naturalONE/natONE824/core/using/use-local-projects.htm#use-local-projectwhatis

So the “converted” library would be in the “referenced” project.