This is exactly the reason we're sticking with the good ol' way of doing things - all of our components are 'drop-from-memory' in order to facilitate hot-fixes during the day without having to have 4000+ users exit the app and log back in.... We simply distribute the fix - replacing the component on the fly so to speak. Of course, we still have the issue with DOL/URR - but that's something we don't play with (or I should say - have had to play with for the last 4 years)... Knut

Iain Sharp said It is very probably horses for courses.  Our app is deployed to 40 independent customer servers, and from within those to 800 some clients, and we haven't the resource to chase those up manually, therefore it is imperative that we can have something we can 'roll out' easily using automated scripts. We have 2 testing versions for each installation (latest patch, and next release), so that's 120 server installs, and all the clients.  I understand that some people are managing one production installation of the software and using file sharing for client access to the code etc.  So yes, we are patching maybe twice a month max, and new versions can be a year apart and the important thing to us is that the patch level be obvious for bug tracking.  Different world it would appear.  Iain  

Ian, For one of our customers, your environment that you describe (above) is very similar....servers are closer to 25 or so (same number of end users though). We have a promote program that sends out the updated components including the asn files. We also support a test and production environment at the customer site. I agree that it is different in that we are constantly adding features / functionality daily as well as bug fixes or just changes in preferences from one administration change to another. Db changes are handled in a precise manor so we only compile the components that have the entity or entities painted on them. The only time we re-compile everything is when Uniface forces us to do so. The classic approach works very well for my needs. I openly admit that I'm not an expert on the standard method of deployment. That being said, I am always looking for ways to improve on existing processes so I'm open to more efficient ways to get things done. I have yet to hear any aspect of the standard method that would result in less steps than the process I currently employ.....but I will keep looking and waiting for improvements to the product that perhaps one day, might turn out a better mouse trap. Thanks, Larry

Hi,  one of the great things with the uar-patching is that we can describe every patch and it's possible to put a resources.asn file (asn sub-file) and sql-scripts in the same place as the patch (although we until now have done the resource.asn change manually). It's also easy to remove a patch (not containing sql-scripts). When you install the application to let's say 50 customers, it's also easy to investigate what patch-level each customer has. I think this isn't as important for those managing just one installation. Regards RogerW.

It is very probably horses for courses.  Our app is deployed to 40 independent customer servers, and from within those to 800 some clients, and we haven't the resource to chase those up manually, therefore it is imperative that we can have something we can 'roll out' easily using automated scripts. We have 2 testing versions for each installation (latest patch, and next release), so that's 120 server installs, and all the clients.  I understand that some people are managing one production installation of the software and using file sharing for client access to the code etc.  So yes, we are patching maybe twice a month max, and new versions can be a year apart and the important thing to us is that the patch level be obvious for bug tracking.  Different world it would appear.  Iain

 Hi, Iain said: Presumably for the db changes, everyone has to be off system anyway? How do you handle it otherwise? If so, why isn’t your main uar replaced then and all patches wiped down… You’d only get up to (on average) about 6 patches between db changes by your numbers.  Larry said: We don’t recompile components if it’s not necessary so replacing a patchX.uar file will probably never make sense (for me).  We have often discussed how often the main uars, should be replaced. We don't replace the whole uars with every database change. Actually we have had customers with over 100 patches, before the main  uars are replaced. And at least I think that this is not an ideal situation, it will probably be slower. We have also applications/uars that we always replace with the main uar. It really depends how you organize your source and applications, how active the programming is and how many programmers are involved. As I said earlier, you shouldn't necessary have only one source. I wouldn't though say that we have an ideal situation .  I really think Iain has a point above. Larry, the standardized deployment isn't for you, if you won't rethink your statement that I quote above. Regards RogerW.  

Iain, Thanks for taking me through that exercise, but I think your steps are an over-simplification of the process and as I think through our normal procedures for promoting programs to test then to the production environment -- it would get easy to get lost in what was included in a uar and why. For new tables, no one has to leave the system and in most other db changes, we restrict access to the db during the update. We don't recompile components if it's not necessary so replacing a patchX.uar file will probably never make sense (for me). If all the uar files are for is to replace the components that are zipped up inside them then we're replacing one thing for another without a real good reason to do so. So having a list of a couple of hundred uar files in the resources directory (which is the only replacement for what I'm doing now) doesn't sound like a more efficient way of managing applications. Sure, in the end, you're still pointing to the same components to run your application.....but can't you do the same thing in a less complicated way with just putting your components in a folder like we used to do? No offense to those that use this new way to manage deployments, but I do look for the most efficient ways to manage applications and I've tried using the standard method and found it to involve more steps and harder to manage than the classic method for my applications. That's just me and my opinion (I know I'm not alone), but it is very hard for me to hear someone explain using the urm to create a uar then updating the asn file referencing that new uar file versus copying formX, serviceY and reportZ from one folder to another (essentially that's it with no asn update) and somehow claiming the uar method as "easier" or "better" is a very hard sell. I've had these conversations at conferences with other developers and with people that work for Uniface and my conclusion is that I can see the need for having the uar files, but I will always need the classic way to stick around until a replacement is shown to be more efficient. I also want the classic method to be improved upon -- such as giving me the flexibility to put the compiled components in a folder that I specify as a file redirection. Larry

Hi Larry, So what we would do there is something like this.  Take a base system and compile it into one (or more) uar files.  Set the $resources_output to point to an actual folder rather than a uar (kind of necessary for multi developer/idf working anyway).  Compile the new programs as changed, which builds contents in this folder.  To release a patch use winzip or windows compressed folders to create a zip file. (PatchX.uar) Port the uar to production, and change the asn to point at it.  DO NOT clear out the patch folder.  Continue to compile, creating new programs in the patch folder, (and overwriting any changed more than once).  For next patch, zip up as before to PatchY.uar,  Change the asn to remove patchX.uar and point to PatchY.uar.  When all clients/uservers have had a chance to cycle, remove PatchX.uar from the production environment,  You can then create a new patch. and put it in as PatchX.uar.  If you keep your patch files archived, you can still roll back (db changes notwithstanding).  Presumably for the db changes, everyone has to be off system anyway? How do you handle it otherwise? If so, why isn't your main uar replaced then and all patches wiped down... You'd only get up to (on average) about 6 patches between db changes by your numbers.    Iain

rogerw said Hi Ingo, We have over 8000 frm files, and a lot of different applications. Unfortunately many of them are in the same source. I would have preferred more sources, especially with the standardized deployment it would have been easy to make uars to use as self-contained component libraries. However, the standardized deployment has made our Uniface life a lot more easy. Hope you understand that I meant that the deployment archive is useful as you want to patch just some small errors in some forms with no database changes. Hope you also understand the connection between  loading sources on runtime and creating components [RESOURCES] \\\\server\\uar97\\wforms20203.uar                    ;This contains a new version of all w-forms ;\\\\server\\uar97\\wforms20202patch001.uar      ;This uar contains only the patched form(s), eg w0001.frm and w0002.frm ;\\\\server\\uar97\\wforms20202.uar                   ;This contains the w-forms \\\\server\\uar97\\pforms20202.uar                    ;This contain all the p-forms Have a beer in the sauna, start testing on monday and you will notice how flexible the standardized deployment is . Regards RogerW.  

Roger, How many patches do you deploy in a month with your applications (typical average)? And how many db changes are processed each month (again typical average)? Do you think the standard approach is easier in an environment with 4k+ components where there are at least 2 "patches" released per day (with anywhere between 2 and 400 components in each patch) with approximately 15 db changes per month? Honestly, I can't imagine having to add a new line to the resources section of the asn file multiple times a day. I would think at some point, there would be a performance hit with Uniface tracking down through those layers of compressed files? I guess I'm really trying to grasp where standard is easier/better than classic and reading through these posts I'm actually being convinced that standard might be better for the small shops or for the large shops with few changes/releases and classic for those with "special needs". So I hope that both will continue to be supported and that they will both be expanded to handle more situations to best meet the needs of developers. I'll cross my fingers I guess. Thanks, Larry

Hi, as a wish to Uniface. The "Define Deployment Archive -> Add -> Select Components" would need a search-function (on ObjectName) or at least a range selection. Being able to search forms/services containing specific entities would be really nice. Regards RogerW.

We compile our entire system using $resources_output, and then use urm move to split it down to the UAR files we want. (Admittedly only frms over here, and svcs over there, and that only to make the files a more manageable size for deployment over the internet.) It should be possible (nearly easy) to make a repository tool which loops through your UFORM/UXGROUP files and uses your internal rules to decide which archive to move the files to post compilation. Run it as a  regular thing or post compilation for release and you're away.  I do think that $resources_output needs work though, having something which allows for splits like this automatically is WAY more useful than having the manual manager provided in the IDF.  Rules should be coded into the settings, not written down and manually implemented....    Iain

Hi Ingo, We have over 8000 frm files, and a lot of different applications. Unfortunately many of them are in the same source. I would have preferred more sources, especially with the standardized deployment it would have been easy to make uars to use as self-contained component libraries. However, the standardized deployment has made our Uniface life a lot more easy. Hope you understand that I meant that the deployment archive is useful as you want to patch just some small errors in some forms with no database changes. Hope you also understand the connection between  loading sources on runtime and creating components [RESOURCES] \\\\server\\uar97\\wforms20203.uar                    ;This contains a new version of all w-forms ;\\\\server\\uar97\\wforms20202patch001.uar      ;This uar contains only the patched form(s), eg w0001.frm and w0002.frm ;\\\\server\\uar97\\wforms20202.uar                   ;This contains the w-forms \\\\server\\uar97\\pforms20202.uar                    ;This contain all the p-forms Have a beer in the sauna, start testing on monday and you will notice how flexible the standardized deployment is . Regards RogerW.

Perhaps it would be easier to run the complete compile into a special resource output. And here comes the postprocessing part: duplicate this resources directory into your different resources_W, resources_P, ... In these direcories, just DELETE frm and sig files whose prefix doesn't match the postfix.

rogerw said

Hi Roger

Hi, The standardized deployment is better and more flexible than the classic.

For sure :-)

[RESOURCES] \\\\server\\uar97\\myapp20202patch001.uar      ;This uar contains only the recompiled form(s) \\\\server\\uar97\\myapp20202.uar                   ;This contains the whole version

 This is for loading sources on runtime, not for creating components

Ingo: You will probably have to do the dividing only at the deployment stage: Make a bat-file idf.exe /asn=w_frms.asn /ini=usys9704.ini /frm w*

Didn't solve the problem when compiling all components belong to one on table. Some of the depeing components are W ones, other are P ones. And I dont' want to miss a component but compile them as a whole bunch.

This is especially efficient for small patches as you know the frms that you want to patch. 

Small patches? We do have over 5000 components, where about 1000 of the W type. (there are much more then only w*.frm ) If there is a need to recompile all components for some tables, there are over 500 components involved. And a normal patch contains much more then 1 data structure change. Our application is not "fixed" as some schoolbooks describe it in there isolated islands :-) [Think about the german tax laws and how often they change ...] Ingo

Hi, The standardized deployment is better and more flexible than the classic. Knut: Didn't you understand this way of doing the deployment, last time we discussed it: [RESOURCES] \\\\server\\uar97\\myapp20202patch001.uar      ;This uar contains only the recompiled form(s) \\\\server\\uar97\\myapp20202.uar                   ;This contains the whole version Ingo: You will probably have to do the dividing only at the deployment stage: Make a bat-file idf.exe /asn=w_frms.asn /ini=usys9704.ini /frm w* The "w_frms.asn" will contain a  $RESOURCES_OUTPUT = \\uar\\w_frms.uar Or then use the "Pulldown -> Goto -> Administration -> Deployment Archive" to make the uars. This is especially efficient for small patches as you know the frms that you want to patch. Regards RogerW.

Hi Ingo,

You could create a separate UAR-file for these forms and add it to the [RESOURCES]. It's best to create the UAR-file using the Uniface Resource Manager (command line tool urm.exe). You can either use the copy or move operation for this.

When using the Standardized Approach then file redirection will only work for non-Uniface files. Uniface application objects need to be stored in a standardized directory structure (as described in the doc). But what is the reason behind redirecting the forms? What are you trying to achieve here? Hope this helps. Daniel

adkinsl said This certainly limits my flexibility. I fail to understand why I can't make the determination myself where to send the Uniface files to fit my needs. I guess now I can only hope that this gets changed to give more flexibility back to developers. Larry   

Oh shit. So I have to implement N environments? Environment for A-Files Environment for B-Files Environment for C-Files .... And what about, if I compile all components depending to a table? Some of them are P-Files, some W-Files Is it true, that I have to go through Z:\\ufs\\u_dtf\\frm\\ (and all other subdirectories) to find all files matching P* resp W* and copy them to other directories? Super, makes it much more complicated to bundle necassary files for deploy As Larry sad: "flexibility is gone" So UnifAce, bring back good old things. Not every "Neuland" (german for new land) is a better land Ingo

Daniel, I see what you are saying and you're correct....Uniface isn't paying attention to my redirection in the [FILES] section. I just found this in the documentation:

adkinsl said Ingo, I agree with Peter but I have chosen not to use the uar method at all. While I understand the concept and usefulness of it, it is a bit more than what I'd like to manage. I'm using U10.2 and while I'm not happy with the changes in the IDF/UDE, I've come to appreciate the way that the $resources_output and [FILES] section can work together to be very similar to the classic approach. [SETTINGS] $resources_output = Z:\\customer\\comp\\ [FILES] usys:*.xml usysuniface:misc\\*.xml usys:ResourceBundle.def $RES:fil\\ResourceBundle.def *.frm Z:\\customer\\comp\\*.frm *.svc Z:\\customer\\comp\\*.svc *.aps Z:\\customer\\comp\\*.aps [RESOURCES] usys:ide.uar usys:ide_messages.uar usys:ide_classic.uar I think you get the picture.....and I'm sure I'm not the only one using this method as a way to cross the bridge from classic to "standard" deployment. Everyone has to do what they can in the box that the lab dreams up for us and this is my answer. I will have to say that the one thing I've asked for since Uniface 8.2 was "hot deployment". It was promised to us in 9.2 but never realized until 10.2. And even though most would not consider it a true hot deployment (no need to exit and log back in) it's close enough for my needs and it is the one and ONLY thing I can say they got right with Uniface 10. True hot deployment is still possible if that passenger still has his notes from our conversation at the Vdara Uniface conference. Good luck, Larry  

Thanks for your reply, Larry. But are you sure that the file-redirections of the FRM, SVC, and APS-files really work? As mentioned in an earlier post: file redirection will only work for non-Uniface files when using the Standardized Approach. Thanks, Daniel

istiller said To deploy, I cann still pack all (not special) FRMs into one ZIP-File an renamed it to UAR :-)

 Hi Ingo, I don't want to rain on your parade, but creating a UAR-file with non-Uniface tools is not such a great idea. We had several reports from customers that had problems (stability or performance related) when using UAR-files that were created with normal archiving tools. If you want to be on the safe side then it's best to use the command line tool urm.exe (Uniface Resource Manager). Just a friendly advice. Hope this helps. Daniel

adkinsl said Ingo, I agree with Peter but I have chosen not to use the uar method at all. While I understand the concept and usefulness of it, it is a bit more than what I'd like to manage. I'm using U10.2 and while I'm not happy with the changes in the IDF/UDE, I've come to appreciate the way that the $resources_output and [FILES] section can work together to be very similar to the classic approach. ... I think you get the picture.....and I'm sure I'm not the only one using this method as a way to cross the bridge from classic to "standard" deployment. Everyone has to do what they can in the box that the lab dreams up for us and this is my answer. I will have to say that the one thing I've asked for since Uniface 8.2 was "hot deployment". It was promised to us in 9.2 but never realized until 10.2. And even though most would not consider it a true hot deployment (no need to exit and log back in) it's close enough for my needs and it is the one and ONLY thing I can say they got right with Uniface 10. True hot deployment is still possible if that passenger still has his notes from our conversation at the Vdara Uniface conference. Good luck, Larry  

Hi Larry This is the first usefull answer to my problem :-) We not only have W-files but much more other "special"-names. And I don't want to switch the environment every time I compile such a special file To deploy, I cann still pack all (not special) FRMs into one ZIP-File an renamed it to UAR :-) Such easy it is ThanX for your answer Ingo

Ingo, I agree with Peter but I have chosen not to use the uar method at all. While I understand the concept and usefulness of it, it is a bit more than what I'd like to manage. I'm using U10.2 and while I'm not happy with the changes in the IDF/UDE, I've come to appreciate the way that the $resources_output and [FILES] section can work together to be very similar to the classic approach. <idfU10.asn> [SETTINGS] $resources_output = Z:\\customer\\comp\\ [FILES] usys:*.xml usysuniface:misc\\*.xml usys:ResourceBundle.def $RES:fil\\ResourceBundle.def *.frm Z:\\customer\\comp\\*.frm *.svc Z:\\customer\\comp\\*.svc *.aps Z:\\customer\\comp\\*.aps [RESOURCES] usys:ide.uar usys:ide_messages.uar usys:ide_classic.uar I think you get the picture.....and I'm sure I'm not the only one using this method as a way to cross the bridge from classic to "standard" deployment. Everyone has to do what they can in the box that the lab dreams up for us and this is my answer. I will have to say that the one thing I've asked for since Uniface 8.2 was "hot deployment". It was promised to us in 9.2 but never realized until 10.2. And even though most would not consider it a true hot deployment (no need to exit and log back in) it's close enough for my needs and it is the one and ONLY thing I can say they got right with Uniface 10. True hot deployment is still possible if that passenger still has his notes from our conversation at the Vdara Uniface conference. Good luck, Larry

Hello Ingo One can spread Uniface development objects in different resources: directories or uar files. The standard approach uses a fixed structure. However within [RESOURCES] one can have several resources [RESOURCES] Z:\\\\ufs\\u_DTF Z:\\\\vfs\\v_DTG ....... Each resource can be created by setting $resources_output when compiling: For your w forms it would be $resources_output = Z:\\\\ufs\\u_DTF this will create Z:\\\\ufs\\u_DTF\\frm\\w*.frm Z:\\\\ufs\\u_DTF\\sig\\w*.sig $resources_output can even point to a network path: $resources_output=$TCP:.\\app1.uar Compared to the classic approach the disadvantage for the standard approach is that you'll need to change $resources_output per resource that needs to be created. The advantage is the easy deployment via [RESOURCES]: no more need for ulana , usysana , dol , uobj ...: adding an extra line in [RESOURCES] is enough and one can easily switch between versions by enabling the desired version via [RESOURCES]. Uniface development objects end up in a resource: [FILES] no longer applies. More flexibility in the standard approach could be an option but would be complicated and will cost performance. Not needing all those redirections in [FILES] is something to get used to. However I find it in the end more simple. Peter

diseli said Hi Ingo

istiller said Loading from different UAR is not the problem. I want to store FRMs to different directories. So I'm sure, that our customers got only the "application" components.

What's the difference between storing FRMs in different directories to storing them in different UARs? Seems to be more or less the same.

istiller said Doing this manual is too fault-prone

 You don't need to do this manually. The required steps can be easily automated. Let's say you've compiled everything to customer_package.uar. You then just have to move all w*.frm files to a new UAR-file; e.g.

urm.exe move customer_package.uar:frm\\w*.frm internal_package.uar:frm\\ Moving the related signatures is a bit more tricky, but you can create a list of the signatures using 'urm list' and then loop over it with 'urm move'; e.g.

for /F %%F in ('urm list internal_package.uar:frm\\w*.frm customer_package.uar:sig\\w*.sig 2^> nul') do (   urm.exe move %%F internal_package.uar:sig\\ ) I'm sure that there are more elegant ways to do this (like PowerShell or some other scripting language), but this works. And if you want to make sure that the customer does not get any internal components you can check the customer_package.uar with 'urm list'; e.g.

urm list customer_package.uar:frm\\w*.frm This now should not return any files. Hope this helps. Daniel  

sound very "complicated" So  - as we don't have a workig whishlist - I do express my hish at this place: Bring back the easy way to do. Like in every version before 10  w*.frm Z:\\\\ufs\\u_DTF\\frm_w\\w*.frm Once done a global ASN-file and nobody have to care about it. No need for doing some things after compiling. Just compile and you find the component neat sorted ... Ingo

Hi Ingo

istiller said Loading from different UAR is not the problem. I want to store FRMs to different directories. So I'm sure, that our customers got only the "application" components.

What's the difference between storing FRMs in different directories to storing them in different UARs? Seems to be more or less the same.

istiller said Doing this manual is too fault-prone

 You don't need to do this manually. The required steps can be easily automated. Let's say you've compiled everything to customer_package.uar. You then just have to move all w*.frm files to a new UAR-file; e.g.

urm.exe move customer_package.uar:frm\\w*.frm internal_package.uar:frm\\ Moving the related signatures is a bit more tricky, but you can create a list of the signatures using 'urm list' and then loop over it with 'urm move'; e.g.

for /F %%F in ('urm list internal_package.uar:frm\\w*.frm customer_package.uar:sig\\w*.sig 2^> nul') do (   urm.exe move %%F internal_package.uar:sig\\ ) I'm sure that there are more elegant ways to do this (like PowerShell or some other scripting language), but this works. And if you want to make sure that the customer does not get any internal components you can check the customer_package.uar with 'urm list'; e.g.

urm list customer_package.uar:frm\\w*.frm This now should not return any files. Hope this helps. Daniel

diseli said Hi Ingo, As mentioned in my last post, you can create a separate UAR-file with the internal-use forms and then add it to the [RESOURCES]. E.g.

[RESOURCES]
internal_use.uar
application_base.uar

  That should work. Daniel  

Moin Daniel Loading from different UAR is not the problem. I want to store FRMs to different directories. So I'm sure, that our customers got only the "application" components. Doing this manual is too fault-prone Ingo