Hi,

The dol file is nowadays a zip-file itself. It was a bit faster putting everything in one uar-file, but still very slow.
It's still not clear if it's a file-format problem or a network routing problem, or both.

Hasn't anyone used some good "Auto-updating Rich-Client Applications"-tool with Uniface?

Regards RogerW. 

We've received extensive feedback on this topic. The good news is that we've found a way to improve the start-up time of Uniface 9 (version 9.3 and higher) when started from a network drive.

Starting with the version 9.5.01 patch E108 (released July 20, 2012), the version 9.4.01 patch R128 (scheduled for July 27, 2012), and the version 9.3.02 patch P230 (scheduled for August 10, 2012) the DOL/URR/UAR files are cached in memory. For details see bug 29276 (“Uniface should cache the DOL and URR file in memory”)

By default only the index of the ZIP archive is cached in memory. This however will speed up the start-up time of Uniface already significantly. It is also possible to cache the complete ZIP file in memory. This however will only give a small additional performance boost and as downside increases memory usage considerably.

The new memory mapping functionality can be configured using the ASN setting $memory.

• default (no setting):
  Index of ZIP archive cached in memory
• $memory = zip:all
  Complete ZIP archive is read into memory (please note that this will increase the memory usage of Uniface; only recommended on systems with a lot of memory: for example >3 GB)
• $memory = zip:off
  Disables memory mapping (restores old behavior; recommended for systems with not so much memory; for example < 1 GB) 

I hope the provided information is helpful. 

Kind regards,
Daniel 

*** Usual disclaimer ***

my client has the same situation on 9.4 where DOL and URR are stored on a LINUX machine.

My investigations brought to light that from 9.4 onwards, DOL and URR are internally UAR formatted.

Very slow startup compared to a "couple of seconds" after we relocated these files to a windows-box.

But my client wants to keep his long-year matured distribution patters.

Question for the CPWR decision makers:

- Is "the lab" working on a solution for the bad performance for UAR handling on non-windows boxes?

- can we expect a solution within the next couple of weeks?

Uli

Hi,

yes it's quite interesting.
But you still have the problem with the Uniface runtime which have to be installed on the client or at a network-path.
And of course if your application isn't built as a n-tier application you would probably have to install the database client on the client machine.

But the url-path for the application would perhaps be a first step to something between a desktop- and a real Uniface webb-application, and would hopefully also help to solve possible file-format problems ...

Regards RogerW. 

Hi,

you shouldn't start your question with 'this is probably a stupid question', so I won't.

Would it be a big step/work for Uniface to support urls (http) as the uar-path?

[RESOURCES]

http://myserver/usys.uar

http://myserver/usysicon.uar

http://myserver/myappl.uar

Regards RogerW

Now that is an interesting whish. Please put it in the Wishlist.

Hi,

you shouldn't start your question with 'this is probably a stupid question', so I won't.

Would it be a big step/work for Uniface  to support urls (http) as the uar-path?

[RESOURCES]
http://myserver/usys.uar
http://myserver/usysicon.uar
http://myserver/myappl.uar

Regards RogerW

Hi,

we have now tried to use a windows-server in the same network and the loading is done  quite fast (some seconds). The problem seem to be the Uniface file format and Novell. So in our case it's probably not a network routing problem.

Regards RogerW.

Hello RogerW,

I'm not sure, if this is the same situation, but from time to time, we have a similar problem (most of the time it's pure Windows environment). According to my experiences, this delay was caused by one of 2 things:

• network problem, most of the time unreachable DNS server (for any of used network names, license server, network drive, database server, ...)
• license problems (could be DNS problem again), unreachable license server (if you ever changed license server), bad configuration of lic client, etc...

Sometimes, startup is slow or even with crash or some kind of strange error message (includes via JTi client) and we solve this by just deleting the whole ".compuware" directory - in this dir, there are some configuration files and cache for licensing. (We have license set in our .asn file, so Uniface create this .compuware directory again.) From time to time, we have problem with this and deleteing it helps. Not sure, if this helps you, since we have never used Novell, but symptoms seems to be quite similar. :-)

Zdenek

Didn't help to keep uncompressed files in the uar-files.

Regards RogerW.

Installing with uar-files is  very slow (2 minutes to load). I suppose that the files of the uar are all somehow processed (DNS-search?, Extracted?,....).  There are one file for eg. each message, signature, form, etc.. 
[RESOURCES]
usys:usys.uar
usys:usysicon.uar
G:\\Programs\\MyAppl\\MyAppl.uar
G:\\Programs\\MyAppl\\MyMenu.uar

Installing with default Uniface directory is faster but still quite slow (20 sec to load). This is the same installation as an uar but the files aren't archived (and compressed) to an uar-file. If the uar-files are the problem I suppose that the 20 seconds come from loading the Uniface uar-files. I don't know how eg. messages of the ProgramFiles-directory are loaded in this case, but if they are loaded as they are needed, then it will probably be slower to load a form with 1000 messages than a form with 1 message. The slowness will be spread on the whole session, ie. one will not recognise it in the same way.
[RESOURCES]
usys:usys.uar
usys:usysicon.uar
G:\\Programs\\MyAppl\\ProgramFiles\\
G:\\Programs\\MyMenu\\ProgramFiles\\

Using a dol and an urr hasn't yet been tested with Uniface9, but in this way Uniface7 is fast loaded (some seconds).
usys:uobj.dol     G:\\Programs\\MyAppls\\dol\\uobj.dol
usys:uana.urr    G:\\Programs\\MyAppls\\urr\\uana.urr
*.aps                   G:\\Programs\\MyAppls\\aps\\*.aps
*.frm                   G:\\Programs\\MyAppls\\frm\\*.frm
*.svc                   G:\\Programs\\MyAppls\\svc\\*.svc
etc........

Obs! The problem doesn't exist for a pure windows environment, so it has something to do with the operating system and the novell client. Copying the uar-file down to the client is fast.
I would like to use the same/similar installation for all customers and the uar installation has been very comfortable. Not to diverge to much from it, the second method  above would be a middle course. Is it somehow possible to start an Uniface application without using usys.uar and usysicon.uar in the Resources-section (and not using dol and urr).
Any hints or explanations to the above behaviour appreciated.

Regards RogerW.
 

Hi Roger,

do you have tried a combination of standarized and classic approach in the deployment.

So maybe it helps to access all usys-objekct (dol, urr, usys.cpt) in the "old" mannor and only to deploy your application as one or two uar.

Maybe this can speed up it a little bit.

Good luck

Thomas

At least "Compuware Support Center" couldn't help. They don't have a Novell environment. On the other hand I understand that this is a difficult situation as I myself don't know the exact environment of my client (don't know if they know). As I have understood it the Suse Linux is just used as a "storage-server" and the clients using (xp) novell client. The bad news is that we  yesterday installed to another customer using Novell and the same slow Uniface starting was recognised (sometimes several minutes, which normally is done in two seconds).
I hope that Compuware is reading this and making some statements about the zip-format; advantages, disadvantages in different environments.

After all, as the dol has been changed to zip-format, if there is a problem I think even classic installations will get the same problems. 

Regards RogerW. 

looks like your fate lies in the hand of "the lab", as usual

Furthermore it looks as if the dol is nowadays a zip-file. So this kind of problem is very difficult to workaround with Uniface.
I hope that there aren't any such problems as below with a novell client using SUSE Linux as storage:

"As of Uniface 9.3 the Uniface UAR, DOL, and URR files are stored in standard ZIP format. To quickly locate and access an object in these files, Uniface searches the zip header, which is located in the last 22 bytes of the file (before the end-of-file marker). If the zip header cannot be found in the expected location, Uniface reports the warning and reverts to a global scan of the zip file, which can have a sever performance penalty if the file is large."

"When FTP is used to transfer a binary file from a Windows or Unix environment to an OpenVMS environment, the file is written in fixed-length format of 512 bytes. When FTPing into a physical file on iSeries, the record length is the fixed record length of the physical file (which can be anything, but is usually 92). The EOF marker is written at the end of the last block, but the zip header is located at the end of the data stream that was transferred, so the start of the zip header is usually not found at expected position (22 bytes backwards from the EOF marker)."

Comments appreciated.

Regards RogerW.

The loading is slow, but after having started and reached the aps-code, there is no problem anymore.
Perhaps does it do some dns-search for every file of the uar at the load of the application. Have to try using the ip instead in the asn-file or something simillar.....

Yes I think that a dol-file and classic deployment would solve this issue, but then you can't deploy eg. a patch with just a few new messages without deploying the whole dol.
Perhaps one have to use different deployment architectures for different customers, at least if they have Linux SUSE.

Regards RogerW. 


 

Hi Iain,

thanks for this info. Good to know if some client needs updates "on the fly".

So no speed gain for RogerW. in this case.

Uli

Hi Uli,

So do the uar files (at least, they are locked from modification whilst an application is using them same as the .uar)

Iain

looks like uniface has to open and unzip each UAR to see if the archive contains what they are looking for (message by message).

When opening and closing a file is slow due to the novell OS, it may explain your observations.

Perhaps using the DOL would help if it comes to messages etc. because this file stays open allover the runtime of the application.

Uli