IBM Message Broker: Trace Nodes File Path Configurable - trace

I'm trying to make several trace nodes, each with a configurable file path.
I prefer if it were through a configurable service in the message broker, though is it possible? If not, are there other ways to make them configurable?

Not on a per application / flow basis. If you just want to be able to set a common root then you can use relative paths.
It's not reccomended but you can use relative file paths in the trace node. By default this is relative to the broker's view of the current working directory.
This changes between v7 and v8 so if you really want to use relative you can set the environment variable MQSI_TRACENODES_ROOT_DIRECTORY to hold the base path then set a relative path in your node names.
The other approach you could use is to override the property in the bar file prior to moving between your different environments.
For what its worth I think that having this configurable at runtime is a great idea so I would encourage you to raise a request for enhancement to bring it to the attention of the Broker dev team:
http://www.ibm.com/developerworks/rfe/?PROD_ID=532

Related

Switching between multiple ClearCase regions

I'm trying to figure out how can I switch between multiple ClearCase regions without going and modifying the ClearCase properties every time.
Any help would be appreciated.
Even in the latest ClearCase 9.0.1, changing the region does involve changing the ClearCase properties: see "Assigning a Rational ClearCase host's registry and region".
What you can do (if you don't want to fully switch region through registry/properties) is take advantage of the -reg/-region option for some command.
See for instance cleartool lsview -reg newtwork-region: you can list views of other regions without changing your current one.
But that remains limited to listing resources (Vobs, Views).
Once you are using commands within a view (lscheckout, checkout, ...), said commands are expected to work within the current region.
You might need to consider registering (cleartool register) a view from another region into the registry of this current region.
The alternative, as mentioned in the comments, is to modify the registry, as with this Javascript program REGION_SWITCHER.js from 2005.
Source code.
It modifies:
HKEY_LOCAL_MACHINE\SOFTWARE\Atria\ClearCase\CurrentVersion\Region
You can have multiple regions and share the views between them. The catch is that if you are in a mixed Unix/Windows environment, Unix can only use Unix views, while Windows can use both.
At my company, we have a Unix region and a Windows region. If I want to be able to use the same view in both regions, I create it on Unix and then use the Region Synchronizer (look for this on the Administration tab of ClearCase Home Base) to make the view available in Windows. The tool will take care of registering the view and creating its tag in the second region with the correct path needed to access it. (We share our Unix view storage locations with Windows using Samba.)
I'm not sure what you need to do to set ClearCase up in the first place so that it's able to see both regions, but as long as you can see both (and you can if the cleartool lsview -reg works), the Region Synchronizer is the tool you want to use to make it so you can easily check in and check out and otherwise use the view as if it were created in your own region.

Clearcase find command prerequisites

How do I use cleartool find to search a bare vob? Must I always first define a view?
I typically use CCRC and in this case I am looking for a list of all files of a certain branch type.
EDIT:
This page says:
Typically, you start with all objects in a directory tree as seen in
your view. You can also start with all objects in one or more VOBs,
regardless of they are visible in a particular view.
I'm looking for information on the version of the command that the second sentence describes.
You cannot use cleartool in a CCRC setting.
CCRC (ClearCase Remote Client) is a light-weight ClearCase installation which communicates with a CCRC server (which, in turn, talk to a full ClearCase Vob server).
You can use rcleartool, the CCRC CLI, but it doesn't include a find comnand.
'cleartool find' itself is always used in a view, because it needs a path (to at least a Vob).
You can also start with all objects in one or more VOBs, regardless of they are visible in a particular view.
That doesn't mean you can use cleartool find outside a view.
The two pages giving a lot of examples are:
SAMECS find examples
IBM additional find examples
The SAMECS link and the cleartool man page are clear:
-avobs
By default, find starts with all the elements, branches, and versions in all the VOBs mounted on the local host.
In a snapshot view, find –avobs issues a warning if all mounted VOBs have not been loaded into the view.
This option depends on the MVFS and is ignored on hosts that do not support dynamic views.
You must be in a view context to use find –avobs.
If the CLEARCASE_AVOBS EV is set to a colon-separated list of VOB tags (in UNIX; in Windows, list items must be separated by semicolons), this set of VOBs is used instead.
In short, to access any vob content, they must be loaded (snapshot view) or mounted (dynamic view). In both cases, even though the find is not restricted by the view confi spec (especially in the case of the -avobs option), a view is still needed to run cleartool find.

How to change Netbeans cache directory?

Is there any way to change Netbeans (7.0.1) cache directory?
I'm just wonna change directories of cache/temp for few apps... and one of them is NetBeans...
It seems this is not possible for Netbeans 7 (unless you relocate the whole userdir or create links as suggested by #MadWizard).
Fortunately, it seems this will be possible in Netbeans 7.1 by using the new --cachedir command-line option: http://wiki.netbeans.org/FaqAlternateUserdir
Quoting http://platform.netbeans.org/articles/installation.html
It is not reasonable to share this directory between different Products - the cache would be useless, the logs would get confusing and also the user modifications to the config would could be ambiguous. That is why each Product shall define its own directory prefix (based on its name) and pass it into the general nbexec command (for example using the --defaultuserdir parameter). The user can override the default during invocation of the the product launcher (e.g. nbweb --userdir myuserdir).
Review documentation pointed by me. If it does not help, you may consider using links, ie. create cache dir where desired and then within netbeans directory structure (described by the page) create link pointing to prepared cache.

running multiple configurations of an rcp with different shortcuts

I thought this would be straightforward but through lots of play and googling, I can't find the answer. So apologize up front if the answer is in front of my nose.
We have an rcp app that uses a application specific ini file to determine database, file locations, etc (call it bob.ini) to not confuse with the app ini file (call it xxx.ini and the exe is xxx.exe).
We want to run the app with different shortcuts so that we can use different bob.ini files so we set up variable in the config.ini file to point to that location. No problem so far, you run xxx.exe -configuration \location\config.ini and we have a different location for each configuration we want to run.
But what I also want to do (and I may not be saying this correctly) is to have config.ini file located in a directory that is not writable (ie all the folders like org.eclipse.osgi, etc) and point that stuff to #user.home/somewhere. But that doesn't seem possible because once my shortcut say '-configuration \location\config.ini' the osgi.configuration.area is set. I want different configuration file to be in a folder by itself to give information but read only.
So then I tried using an xxx.ini file which I understand sets vm and vmarg info using -D but couldn't get the right combo
I know there base, default, shared+cascaded (which I don't understand), readonly but can't figure this out.
Your advice and recommendations are greatly appreciated.
You could put information in different xxx_1.ini xxx_2.ini files and have the shortcuts specify which one to use by running xxx.exe --launcher.ini xxx_1.ini.
Otherwise, I'm always a little fuzzy on all the configuration properties, but you can try osgi.configuration.cascaded and osgi.sharedConfiguration.area
So I think you would use xxx.exe -configuration \location\config.ini and then
/location/config.ini:
osgi.configuration.cascaded=true
osgi.sharedConfiguration.area=/sharedLocation/readonly/config.ini
bob.ini.location=bob.ini

Best practices for deploying data to a custom folder

Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.