At first: uniface does not support distributed development at all:
you will not find "publish-subscribe" or "protected areas" functionality.

So you have to carefully plan distributed development
(including a strict naming guideline to keep sub-domains separate from each other)
and run all sync activities outside of ihe IDF.

If you use global variables to transfer information BETWEEN sub-domains,
you run in a lot of problems; but architecturewise, transfer by global variables does not really make any sense.

But if you have a standard set of globval variables,
this standard has to be maintained in a single location, because it is a standard.

Merging global variables is an option if you want to create a "cross-subdomain utility development environment":
- export the variables from your different sources
- load them in a separate environment
send updated versions to all remote development environments as a routine job.

If you want to run "distributed development", you have to have a sound strategy
how to cope with "common" codeparts. Not only with uniface, but with other languages as well.

Uli

Hi Roger,

You are looking at this problem from the very end of it, the deployment.

Let's look at it from the other end, the development where you define global variables.

These are stored in UCVAR as seperate records and the compiled into UOBJ as 1 record.

So it might be an idea to share the UCVAR table between both repositories.

Theo.

Hi Theo,

and thanks that would solve the problem for accessible code, possible to recompile by oneself.

However, Uli claimed

"At first: uniface does not support distributed development at all:
you will not find "publish-subscribe" or "protected areas" functionality."

sounds a bit worrying. But that's another question.

Regards RogerW.

Uli is right: there are no such formal methodologies in Uniface.

But that doesn't mean you cannot achieve what you want.

Succes Roger!

Hi rogerW.

let me point it out again because I think you missed the good news:

there is a solution which needs ONLY the UAR files at hand;
no need to have access to sourcecode and recompiles.

And it can be applied to all the uniface versions supporting the UAR concept, even "older ones".

Uli

Hi Uli,

already at april 6 I understood that you know how to solve this without the source.  There seem to be a clear pattern in those $$register-files so I suppose that it wouldn't be that difficult to merge them....
I'm more inrested in how to explain these system_library-variables, or what to compare them with in other programming-languages, ie. the academic view of this problem :-).

Regards RogerW.

... thanks for clearing this point about the merge. BTW it's not only a merge of $$REGISTER, but other library clustered objects as well.

On your other academic interest:

What is your question? Perhaps I just have not understand what you want to know about it.

Uniface is component-centric, nothing seems to exist outside of the scope of a component.
Global Variables are just pieces of memory where you break this barrier and have a chance
to manage information in your application as a whole (or at least a bunch of components).

Apart from these global variables, you have the $1 - $99 as GENERAL registers.

In other languages I think variables defined in the outermost scope may be a good analogy;
each sublevel can access and manipulate these variables (and cause a lot of side effects with it)

It's a bit more tricky because you can assign different libraries to each component
AND you have a application startup-shell library as well with all kind of nice overlay effects.

Perhaps this can help your academic interest,

Uli

Hi Uli,

I understand your  standpoint. These problems originate from old code made during 1990-2000, so I admit that there could be weaknesses of the code. Nowadays we don't even use global variables.

SYSTEM_LIBRARY sounds like a library that should be very easy accessed without $variation, $library problems etc. and so I think this have been very often used in the Uniface world. We do use some code made outside the house and all use SYSTEM_LIBRARY.
As I said, usually merging works fine except for the "Global Variables" as they are stored in one file.

Perhaps a more critical thing is that after having found a library the "run-time" searching is stopped. This will make it impossible to deploy patches with only some objects of a library. 

[RESOURCES]
PATCH01.UAR    ;contains only some objects from a library
APPLIC.UAR       ;contains all objects from library and all components etc., ie. the application-uar.

Unfortunately I have got some diverse info/results about how the searching in the libraries of the UARs is done. We have to do some more testing.....
But if someone knows how this is working or should work, which library/libraryobjects do stop the search in other UARs etc., please inform me about this. 

Regards RogerW.
 

Hi RogerW.,

the tricky bit is that from day one onwards, all global variables are compiled into a single object $$REGISTER.
As you stated in you message: all other objects can be scattered around in different UARs, but not the $$REGISTER cluster.

A small utility to help solve this situatuation is very easy to implement.
Unfortunately, I gave up the dITo initiative, so I can not give it to you free of charge.

Uli

Hi Uli,

unfortunately I'm broke :-).

No, actually I do have access to all the source needed to reorganize my code if needed. I'm more interested in how it's working and how it should work to be a good development/deployment environment in the future. I hope that other Unifacers do start to use the new deployment style. At least our customers are very eager to get good server-deployed solutions. I think uar-files are the first step to get some kind of server-deployed applications with eg. automatic download to the client as the UARs change, or something similar.....

It's not that easy to quickly develop new web-based solutions for all old applications, not to mention all those security restrictions existing in a web-application. So why not find something between a desktop and web-based solution.....

However, I'm still intrested in how the searching in UAR-files is done. I was informed by a programmer that putting a message in a PATCH.UAR would stop the searching of other messages of that library in UARs being listed later. This is probably false. But it would still be nice to see a diagram about how the searching is done and when the search is stopped for different Uniface-objects/libraries.
Nice feature this "Goto -> Administration -> Deployment Archive", hadn't seen that before.

Regards RogerW.
 

... the routine I mentioned works only with the UARs, you do not have to have access to the code to make it work.

on all the documentation issues, I think it's the best you contact CPWR directly.

Uli

.....if you still want a question I think that it would be, is it right to merge those global variables or should they actually be application/session variables of  the starting/calling process, and the system_library of the called components should be out of scope, ie Uniface is perhaps handling it correctly as it doesn't search for more than one system_library.

RogerW

... it's not the question if uniface is right how it handles UARs; it depends what YOU want/need to do your business.
If for whatever reason you need an additional variable, message or so to do your job you have 2 options:

As you have found out:
you have to have access to the sources of all global variables, messages, global procs of a library
to add a single message or global variable (and resync always).

If this is the way you can do your work, fine.

If you need a way to add a single object on top of the other library objects (may be delivered from a 3rd party)
UAR merging is the way to support incremental delivery/patches.
Merging is done completely ouside of uniface and delivers a product uniface handles as you need it

Uli

Why bother to merge?

Install main system (system.uar)

Install patch 1 (patch1.uar) - Set the assigment file [RESOURCES] section to read
patch1.uar
system.uar

Install patch 2 (patch2.uar) - Asn file becomes
patch2.uar
patch1.uar
system.uar

The latest copy of the software is always found first. The patches can be installed on the system without coming out of uniface (because you are never modifying a file uniface has locked) and kick in when the application is next re-started.

We have a statement in out main asn
#include patches.asn

and then patches.asn is simply a list of patches in reverse chronological order.

As the meerkat says. Simples!

Hi,

actually this was the start of this discussion. I had got wrong info about; if a patch contains one or some messages from a library then that library is no longer searched for, ie. all other messages of that library will be out of scope. This is false, but try to put something (just som objects) from system_library in the patch, the system_library of system.uar is probably out of scope, ie. it's not searched for in system.uar as the library was found in the patch. That's why I wanted some rules for how the libraries are searched for, when does the search stop for library/library-objects. When does the search stop as the library is found and when does the search continue until the correct library-object is found.

Regards RogerW.