Updating Windows Environment Variables

A well-known fact is that, in order to permanently set/modify an environment variable, one should update the Registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment (System Variable)

or

HKEY_CURRENT_USER\Environment (User Variable)

However, this update does not go into effect until logging off and back on.

The solution is to broadcast a Windows Message to all running applications. The following C++ code provides the details:

SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0, (LPARAM) "Environment", SMTO_ABORTIFHUNG, 5000, &dwReturnValue);

In Perl, you can simply use the AdminMisc module to set environment variables. If you prefer to stick to standard modules (perl 5.8.9 and later), you can use the following code fragment:

use Win32::API;

	use constant HWND_BROADCAST => -1;
	use constant WM_SETTINGCHANGE => 0x1a;

	my $SendMessage = new Win32::API("user32", "SendMessage",
'NNNP', 'N')
    	or die "Couldn't create SendMessage: $!\n";
	my $RetVal =
$SendMessage->Call(HWND_BROADCAST,WM_SETTINGCHANGE,0,'Environment');

Another alternative is to build the aforementioned C++ code into a small exe file, and use this utility anywhere you like.

In any case, note that the environment variable change will not be visible to the calling process. You’ll need to set it internally (for example, using $ENV in Perl) if you need it to be available inside the script.

References: Microsoft KB Article 104011, PerlMonks thread

Advertisements

Remove Problematic ClearCase Views

This handy little Perl script removes all traces of a view which is irremovable via conventional means – e.g. when the view storage is missing or inaccessible.

The script is design to run on UNIX in an interop environment, but can be easily be adjusted to other cases.

## Usage: perl rmview_by_tag.pl <region> <view tag>
$region = $ARGV[0];
$region || die "Region must be specified!";
$tag = $ARGV[1];
$tag || die "View tag must be specified!";
## Detect view UUID
@uuid = `cleartool lsview -l -region $region $tag`;
foreach (@uuid)
{
  chomp;
  if (/View uuid/)
  {
    s/View uuid: //;
    $uuid = $_;
  }
}
# Remove the tag from the registry
system "cleartool rmtag -view -region $region $tag";
# Unregister the view
system "cleartool unreg -view -uuid $uuid";
# Remove view-related records from all VOBs
system "cleartool rmview -all -uuid $uuid";

Reference: Removing a view

Sporadic Cleartext Errors using Samba

A few months ago we migrated to a new VOB server (we have a Solaris/Windows inter-op, Samba-based environment). The transition went smoothly and all seemed well.

Suddenly, after a month or so, some of our users started having problems accessing some files. It all seemed very random, and it was slowly spreading.

In the view log we saw numerous cleartext-related errors:

2012-05-01T12:37:15+03:00 view_server(3124): Error: view_server.exe(3124): Error: Unable to construct cleartext for object "0x96E3D" in VOB "atlas:/disk02/algotec_vobs/3rdparty.vbs
": error detected by ClearCase subsystem
2012-05-01T12:37:15+03:00 view_server(3124): Error: view_server.exe(3124): Error: Type manager "z_whole_copy" failed construct_version operation.
2012-05-01T12:37:15+03:00 view_server(3124): Warning: z_whole_copy: Error: Can't open input file "\\atlas\disk02\algotec_vobs\3rdparty.vbs\s/sdft\e/28/3-6c7f92d47de9400a948cc3a7b52
3a9f9-fb" - Invalid argument

In the samba log we saw the following errors:

[2012/05/01 15:29:15,  1] libads/kerberos_verify.c:442                  
(ads_verify_ticket)                                                     
  ads_verify_ticket: krb5_init_context failed (Too many open files)     
[2012/05/01 15:29:15,  1] smbd/sesssetup.c:342(reply_spnego_kerberos)   
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

Since I couldn’t find anything useful in IBM Rational Support website, or via Google, I contacted IBM Technical Support. After several back-and-forth emails, we nailed the problem. Turns out it wasn’t server-side at all!

The affected users were all using a relatively new PC, all installed from the same image. There were two things wrong with this image:

  1. The CLEARCASE_PRIMARY_GROUP environment variable was not defined.
  2. The ‘maximum mnodes’ value in the MVFS Performance configuration was set to 800 (suitable for 64-bit Samba) instead of 200 (suitable for 32-bit Samba, which we use).

After fixing this configuration, the problem was gone and everyone was happy again. Quite a challenge, it was…

Helpful link: Determine if a UNIX or Linux application is 32-bit or 64-bit

Feature-Based Development in a Version-Based Environment

I work for a company which uses Version-Oriented development. This means that we decide in advance which new features and enhancements to include in each planned version release. Hence, at any given time, most developers are working toward one specific version (with the occasional hot-fixes or patches for past versions).

However, we have some customers who were promised a certain set of  features, which we would like to deliver as soon as possible without having to wait for a formal version release. How do we develop them, and how do we release them?

Surprisingly, one of the toughest problem is “how to name such versions?”. Do our SCM tools support non-standard names? what version ID do we want to show the customer? will we be able to upgrade it to an “official” version in the future?

We recently implemented a simple, but effective solution for this issue. Up until now we used 2 numbers to represent our official versions (e.g. 5.0, 5.1). Now, we started using 4 numbers (e.g. 6.1.2.0). The idea is as follows:

  • The first two numbers are for major releases, just as it was before.
  • The third number represents a minor version – containing relatively small amount of new features or enhancements, and has a shorter release cycle.
  • The fourth number is for feature-specific versions.

Admittedly, the fourth number may cause some confusion, since for example, 6.1.2.4 doesn’t necessarily contain the features from 6.1.2.3. But since each of them it targeted for a different customer, it shouldn’t be a problem. And we do know that both features will be included in the next minor release, 6.1.3.0.

One important thing is to record the customer to which a feature-specific version ID is assigned, in a visible way. Currently we do it via a shared document, but we will implement a better system in the future (such as using a Version Object in the change tracking tool, instead of simple text field).

 

So far the system works well. But as usual, there is always room for improvement…

Welcome!

Welcome to “Adventures in SCM”.

In this blog, I intend to write about all kinds of challenges, problems, and thoughts I have while working as an SCM (Software Configuration Management) Engineer.

Check out the About page for more information about this blog and myself.