Hi Knut, I think your idea of the "predefined" UARs is a very good one. If you release some fixes (consuming one of the predefined names), add a new dummy.UAR and introduce this additional predefined UAR to the ASN at the same time. So you have a buffer of "x" updates before the uniface application needs to be restarted. Think this will suit 24/7 apps as well. If these predefined resources are specified in an extra ASN subfile (using #file), the complete set can be released in a single ZIP. Greetings from Frankfurt/Germany, Uli

Hi, The uars have worked very well for us. Just keep the ASN subfile a part of the update. As long as there isn't a database update you can release a lot of patches containing eg. the same frm. [RESOURCES] \\\\myserver\\Data1\\uar97\\MyApp_Patch3.uar \\\\myserver\\Data1\\uar97\\MyApp_Patch2.uar \\\\myserver\\Data1\\uar97\\MyApp_Patch1.uar \\\\myserver\\Data1\\uar97\\MYWholeApp_1.uar or even the whole uar can be updated [RESOURCES] \\\\myserver\\Data1\\uar97\\MYWholeApp_2.uar ;\\\\myserver\\Data1\\uar97\\MYWholeApp_1.uar But if you can't demand the ones that should get the patch activated to restart their application, then I understand your problem. Is there some problem I don't get here....  Regards RogerW.

Hi We release them automatically. As Roger said, as long as there is no database update. We use a script that deploys new UARs and renames them inserting timestamp in filename. The script also recreates references to these UARs in a file called resources.asn. So, uservers in execution continue using old UARs (they already have read resources.asn) but new uservers will use the new version. Also, we also use an UAR called "PATCH" for urgent releases. Regards

We do something similar to the above. Our main version is in one uar, and patches are applied 'on top' of that using a sub-asn (patches.asn). We could (and have in the past) release a 'service pack' and disconnect previous patches to cut down search time. The natural cycle of uservers means new code is picked up there, and clients are set to copy the new asn and uar to the local machine as part of the start up.  But it is only luke-warm, not hot, as you say because it means that you have to close the app and re-start to get the new code.  I suppose that in a web environment it would be easier, because you could use the "UROUTMON" pseudoservice to issue an exit command to all running uservers as part of the deployment.  Since all our database access is done via the services, and we update overnight, we can 'get away with' database updates in a live patch by doing this, but I fight it and try and hold them back for major releases.  Also, the uar files are 'open' because they are indexed zip files, and the indexes are locked. I think they are probably loaded at start-up and therefore you still wouldn't get a 'hot' pickup of the new code if that code was 'added' to a currently referenced uar. (If it's not there, you might, but there will be transcript errors about it being missing.) Does V 10 actually force UAR use, or is it just forcing a shift from Classic deployment? Because if it's just removing classic deployment, you can still deploy to a resources folder, not just UARs. 

The last remark of Iain is key: Standardized deployment, as it is called officially, does not force you to use a Uniface archive file (.uar file). If you defined $resources_output as a directory/folder on disk, Uniface compiles all objects to that folder, maintaining a standardized structure. You can use that same folder (or a copy of it) in the [RESOURCES] section of your assignment file. Uniface archive files certainly make distribution and patching easier, but distributing the resources folder plus all of its sub folders may serve the same purpose. And for patching purposes you can also point to another folder that precedes the 'standard' folder in the [RESOURCES] section. Knut's requirement, using Drop from Memory, will still be achievable by using standardized folders instead of Uniface archive files.

Iain Sharp asked Does V 10 actually force UAR use, or is it just forcing a shift from Classic deployment? Because if it’s just removing classic deployment, you can still deploy to a resources folder, not just UARs. 

Hi Iain, Just a forced shift from classic deployment, so deployment to a resources folder is possible. Regards, Arjen

Knut, Have you considered using some form of automated time-out on the client side after a certain period of non-activity? Please take a look at my sample 'Extended timeout on MS Windows' in the Community Samples section. With this sample, using a value of 8,5 hours (full workday plus lunch in The Netherlands) of complete inactivity, I managed to convince a customer to start with automated time-outs after an employee did not log out of their Uniface app before going on a three week holiday, causing a dead-lock situation on a system-parameter record, which got the app to a complete halt, leaving about two dozen employees empty handed for a few hours. Sometimes only after the horse had bolted, the stable-door is locked. Regards, Arjen

Hi Knut,   in the IDF.ASN use : [SETTINGS] $resources_output  ???YOUR-PATH??? esources\\   in the "RUNTIME".ASN use : [SETTINGS] $SEARCH_RESOURCES     resources_only [RESOURCES] ???YOUR-PATH??? esources\\   Regards Norbert

Thank you all - I was under the impression that we had to head down the UAR route. All good. Knut

Hi all, I followed the whole discussion simply agreeing with what I've read...one thing is missing: Proposal: - using $componentinfo with topic "ORIGIN" give back UAR or FILE - using $componentinfo with topic "FILE" give back fullpath name Does these seem to be proper solutions? Gianni